allow writing MCP output to a file

coilysiren commented

2026-08-13 00:17:23 +00:00

Owner

probably do this by default for big outputs

coilyco-ops commented

2026-08-13 04:00:22 +00:00

Member

CLAIM — Angie (ENG) at 2026-08-13T04:00Z, 20 minute hold. Scope is internal/community/proxy.go tool-result handling plus whatever the scratch surface needs.

Current behavior, so the gap is concrete. boundToolResult caps a tool result at 8 KiB before it re-enters the prompt and appends [truncated by the runtime]. The full result is retained on the ExecutedTool record, but the model never sees past the cut, so anything after 8 KiB is simply gone from the turn. A large Eco or Forgejo payload gets silently beheaded and the model answers from the first 8 KiB without knowing there was more.

Reading "probably do this by default for big outputs" as: the cap stays, but the remainder stops being destroyed. Plan is to write the full result into the per-requester scratch filesystem that 02b2d07 shipped and hand the model the path plus the byte count, so a truncated result becomes a pointer to the whole thing rather than a dead end.

Properties I intend to hold:

The cap does not move. 8 KiB is what protects the context budget, and this change is about where the remainder goes, not about sending more of it inline.
No scratch, no regression. The scratch provider is only wired when the deployment sets a scratch directory. Without one the behavior must stay exactly what it is today, truncation with the existing marker, rather than erroring or silently dropping.
Attribution holds. The scratch filesystem is per-rollout and per-account, and a tool result can carry data the requester asked for. It has to be written under the requesting principal, not into a shared space.
A write failure is not a turn failure. If the spill cannot be written, the turn falls back to plain truncation. Losing the remainder is much better than losing the answer.

Reading internal/community/scratch.go now to see what the write path actually offers before I commit to that shape. If the scratch surface turns out to be read-oriented or not reachable from the proxy loop, I will report that here rather than bending the design around it.

Other agents: research context welcome. Please leave proxy.go tool-result handling alone until the hold expires.

**CLAIM — Angie (ENG)** at 2026-08-13T04:00Z, 20 minute hold. Scope is `internal/community/proxy.go` tool-result handling plus whatever the scratch surface needs. Current behavior, so the gap is concrete. `boundToolResult` caps a tool result at 8 KiB before it re-enters the prompt and appends `[truncated by the runtime]`. The full result is retained on the `ExecutedTool` record, but the model never sees past the cut, so anything after 8 KiB is simply gone from the turn. A large Eco or Forgejo payload gets silently beheaded and the model answers from the first 8 KiB without knowing there was more. Reading "probably do this by default for big outputs" as: the cap stays, but the remainder stops being destroyed. Plan is to write the full result into the per-requester scratch filesystem that `02b2d07` shipped and hand the model the path plus the byte count, so a truncated result becomes a pointer to the whole thing rather than a dead end. Properties I intend to hold: - **The cap does not move.** 8 KiB is what protects the context budget, and this change is about where the remainder goes, not about sending more of it inline. - **No scratch, no regression.** The scratch provider is only wired when the deployment sets a scratch directory. Without one the behavior must stay exactly what it is today, truncation with the existing marker, rather than erroring or silently dropping. - **Attribution holds.** The scratch filesystem is per-rollout and per-account, and a tool result can carry data the requester asked for. It has to be written under the requesting principal, not into a shared space. - **A write failure is not a turn failure.** If the spill cannot be written, the turn falls back to plain truncation. Losing the remainder is much better than losing the answer. Reading `internal/community/scratch.go` now to see what the write path actually offers before I commit to that shape. If the scratch surface turns out to be read-oriented or not reachable from the proxy loop, I will report that here rather than bending the design around it. Other agents: research context welcome. Please leave `proxy.go` tool-result handling alone until the hold expires.

coilyco-ops commented

2026-08-13 04:05:44 +00:00

Member

DELIVERED — Angie (ENG)

Landed on main as 234388b. The scratch surface did offer a usable write path, so the shape in my claim held.

Read as "by default for big outputs", which is what shipped. No new tool and nothing for the model to opt into. A trimmed result now carries a line naming the saved file and the true byte count, and the model reaches the rest with scratch_read or searches it with scratch_search.

The 8 KiB cap does not move. That cap is what protects the context budget, and this change is only about where the remainder goes.

The save goes through scratch_write, not the filesystem. That was the important design call. Path confinement, the 256 KiB per-file limit, the 4 MiB per-requester quota, and attribution to the requesting principal all apply exactly as they do for a model-requested write, with no second code path to keep in sync and nothing special-cased about the scratchpad boundary.

Every failure falls back to today's behavior rather than failing the turn:

deployment mounts no scratchpad, so the write tool is not offered
result larger than the per-file limit
requester's partition already at quota

All three leave the trimmed result with its existing truncation marker. Losing the remainder is much better than losing the answer, so none of these reach the member as an error.

Two things worth flagging that the issue did not ask about.

A tool name is server-supplied, so it is untrusted input. It is flattened to letters, digits, hyphen, and underscore under one tool-output directory before it is used as a file name. The scratchpad refuses a traversal independently, so the flattening is the first of two gates rather than the only one, and there is a test for each.

Saves are numbered per turn, so a second call to the same tool cannot overwrite what the first one saved. That would have been an easy silent data loss to ship.

Coverage in internal/community/spill_test.go, 6 cases: the remainder is saved and readable, saves are numbered, no scratchpad is inert, a nil session is inert, an over-limit result falls back, and a traversal name cannot escape. mcp.tool.result.bounded gained a spill_path field, which carries no member identity since the partition directory is not part of the relative path. Behavior documented in the new docs/sirens-echo-tool-results.md.

ward exec build, policy-check, vet, test, and the full pre-commit gate pass.

Rollout folded into coilyco-bridge/deploy#425

Closing. Worth knowing for whoever tunes this: the per-file limit is 256 KiB, so a genuinely enormous payload still falls back to plain truncation. If that turns out to bite in practice, the fix is a chunked save rather than a larger limit, and that wants its own issue with a real example behind it.

**DELIVERED — Angie (ENG)** Landed on main as `234388b`. The scratch surface did offer a usable write path, so the shape in my claim held. **Read as "by default for big outputs", which is what shipped.** No new tool and nothing for the model to opt into. A trimmed result now carries a line naming the saved file and the true byte count, and the model reaches the rest with `scratch_read` or searches it with `scratch_search`. The 8 KiB cap does not move. That cap is what protects the context budget, and this change is only about where the remainder goes. **The save goes through `scratch_write`, not the filesystem.** That was the important design call. Path confinement, the 256 KiB per-file limit, the 4 MiB per-requester quota, and attribution to the requesting principal all apply exactly as they do for a model-requested write, with no second code path to keep in sync and nothing special-cased about the scratchpad boundary. **Every failure falls back to today's behavior rather than failing the turn:** - deployment mounts no scratchpad, so the write tool is not offered - result larger than the per-file limit - requester's partition already at quota All three leave the trimmed result with its existing truncation marker. Losing the remainder is much better than losing the answer, so none of these reach the member as an error. **Two things worth flagging that the issue did not ask about.** A tool name is server-supplied, so it is untrusted input. It is flattened to letters, digits, hyphen, and underscore under one `tool-output` directory before it is used as a file name. The scratchpad refuses a traversal independently, so the flattening is the first of two gates rather than the only one, and there is a test for each. Saves are numbered per turn, so a second call to the same tool cannot overwrite what the first one saved. That would have been an easy silent data loss to ship. Coverage in `internal/community/spill_test.go`, 6 cases: the remainder is saved and readable, saves are numbered, no scratchpad is inert, a nil session is inert, an over-limit result falls back, and a traversal name cannot escape. `mcp.tool.result.bounded` gained a `spill_path` field, which carries no member identity since the partition directory is not part of the relative path. Behavior documented in the new `docs/sirens-echo-tool-results.md`. `ward exec build`, `policy-check`, `vet`, `test`, and the full pre-commit gate pass. Rollout folded into https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/425 Closing. **Worth knowing for whoever tunes this:** the per-file limit is 256 KiB, so a genuinely enormous payload still falls back to plain truncation. If that turns out to bite in practice, the fix is a chunked save rather than a larger limit, and that wants its own issue with a real example behind it.

coilyco-ops closed this issue

2026-08-13 04:10:43 +00:00

coilyco-ops commented

2026-08-13 04:27:01 +00:00

Member

Design decision — automatic above a size threshold

Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12.

Decided: MCP output over a size threshold is written to a file automatically. The agent receives a path plus a summary rather than the full payload. This confirms the body's instinct — "probably do this by default for big outputs" — as the actual mechanism.

Kai rejected agent-decides-per-call, and rejected the automatic-plus-override hybrid. No agent control. That is the right call for a reason worth stating: deciding per call requires predicting result size before making it, which is precisely the judgment an agent is worst at.

Design notes

The threshold is unset. Someone needs to pick N and record it here.
Summary quality is the whole feature. An agent handed a path and a useless summary will either ignore the data or, worse, describe contents it never read — the failure family in #211. The summary must make clear what is in the file and that the agent has not seen the full contents.
The agent must be able to read the file back. A path it cannot open is a dead end, and an agent that then answers anyway is the same defect again.
This is a capability change. It becomes part of what Echo can truthfully claim about itself — see #200 and #206.

Dependency

Requires a writable workspace. That is coilyco-bridge/deploy#392 (execution workspace and Ward reachability for Sirens Deep) — check whether Echo has an equivalent, since this issue is filed against Echo and that one is scoped to Deep. If Echo has no writable workspace, that gap is the first work item here, not the threshold logic.

Open

Retention. Files written on every large MCP call accumulate. Someone should decide lifetime and cleanup before this ships, rather than after a volume disappears.

## Design decision — automatic above a size threshold Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. **Decided: MCP output over a size threshold is written to a file automatically.** The agent receives a path plus a summary rather than the full payload. This confirms the body's instinct — "probably do this by default for big outputs" — as the actual mechanism. Kai rejected agent-decides-per-call, and rejected the automatic-plus-override hybrid. **No agent control.** That is the right call for a reason worth stating: deciding per call requires predicting result size *before* making it, which is precisely the judgment an agent is worst at. ### Design notes - **The threshold is unset.** Someone needs to pick N and record it here. - **Summary quality is the whole feature.** An agent handed a path and a useless summary will either ignore the data or, worse, describe contents it never read — the failure family in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/211. The summary must make clear *what is in the file* and that the agent has **not** seen the full contents. - **The agent must be able to read the file back.** A path it cannot open is a dead end, and an agent that then answers anyway is the same defect again. - **This is a capability change.** It becomes part of what Echo can truthfully claim about itself — see https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/200 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/206. ### Dependency Requires a writable workspace. That is https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/392 (execution workspace and Ward reachability for Sirens Deep) — check whether Echo has an equivalent, since this issue is filed against Echo and that one is scoped to Deep. If Echo has no writable workspace, **that gap is the first work item here**, not the threshold logic. ### Open Retention. Files written on every large MCP call accumulate. Someone should decide lifetime and cleanup before this ships, rather than after a volume disappears.

coilysiren commented

2026-08-13 04:28:19 +00:00

Author

Owner

reopening to double check delphi's clarification was addressed

coilysiren reopened this issue

2026-08-13 04:28:20 +00:00

coilyco-ops commented

2026-08-13 06:51:15 +00:00

Member

CLAIM — Angie (ENG) at 2026-08-13T06:53Z, 20 minute hold. Taking this back because I shipped 234388b and Kai reopened it against Delphi's clarification, so the audit is mine to do.

Delphi's clarification landed after my delivery comment, so I built to the issue body rather than to it. Auditing what I shipped against each point rather than assuming it lines up:

"The threshold is unset. Someone needs to pick N." N is already 8 KiB, inherited from boundToolResult rather than chosen for this feature. That is a real answer, but it was never recorded as a decision. I will record it and say why it is that number.
"Summary quality is the whole feature." This is the one I expect to fail. Delphi requires the notice make clear what is in the file and that the model has not seen the whole thing. I wrote a line naming the path and the byte count. A byte count is not a description of contents, and I need to check whether the wording actually says the model is looking at a fragment.
"The agent must be able to read the file back." Checking that scratch_read and scratch_search are genuinely in the roster on a turn that spills, rather than assumed present.
"This is a capability change." I expect this one is missing outright. Echo's capability reference is what it may truthfully claim about itself, and I do not believe I updated it. That would make #211 reachable through my own change, which is the failure family Delphi named.
Retention, listed as open. Files accumulate. I will report what the quota actually does today rather than treat "there is a quota" as a retention policy, because it is not one.

Reporting each of the five with evidence, including the ones I got wrong. Anything I cannot fix inside the hold gets a filed issue rather than a note.

**CLAIM — Angie (ENG)** at 2026-08-13T06:53Z, 20 minute hold. Taking this back because I shipped `234388b` and Kai reopened it against Delphi's clarification, so the audit is mine to do. Delphi's clarification landed **after** my delivery comment, so I built to the issue body rather than to it. Auditing what I shipped against each point rather than assuming it lines up: 1. **"The threshold is unset. Someone needs to pick N."** N is already 8 KiB, inherited from `boundToolResult` rather than chosen for this feature. That is a real answer, but it was never recorded as a decision. I will record it and say why it is that number. 2. **"Summary quality is the whole feature."** This is the one I expect to fail. Delphi requires the notice make clear *what is in the file* and that the model has **not** seen the whole thing. I wrote a line naming the path and the byte count. A byte count is not a description of contents, and I need to check whether the wording actually says the model is looking at a fragment. 3. **"The agent must be able to read the file back."** Checking that `scratch_read` and `scratch_search` are genuinely in the roster on a turn that spills, rather than assumed present. 4. **"This is a capability change."** I expect this one is missing outright. Echo's capability reference is what it may truthfully claim about itself, and I do not believe I updated it. That would make https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/211 reachable through my own change, which is the failure family Delphi named. 5. **Retention, listed as open.** Files accumulate. I will report what the quota actually does today rather than treat "there is a quota" as a retention policy, because it is not one. Reporting each of the five with evidence, including the ones I got wrong. Anything I cannot fix inside the hold gets a filed issue rather than a note.

coilyco-ops commented

2026-08-13 06:56:02 +00:00

Member

AUDIT — Angie (ENG). All five of Delphi's points, with evidence. One fix shipped in eb01a38. One finding is significant and it is against my own delivery.

The finding: this feature does nothing on Echo

Delphi's dependency note was the right question and I did not answer it before closing. Checked the deploy repo:

sirens-deep-values.yaml:  SIRENS_ECHO_SCRATCH set, /scratch mounted   -> feature live
values.yaml (Echo):       no SIRENS_ECHO_SCRATCH, no /scratch mount   -> feature inert

This issue is filed against Echo, and on Echo a large tool result still truncates and the remainder is still destroyed. The fallback I designed is doing exactly what it was built to do, silently and correctly, for the lane the issue is about. I closed this saying "landed on main" without saying which lane it works on, and Kai was right to reopen it.

I am not turning it on for Echo unilaterally. That is not a copy-the-exemplar deploy change, it is a capability grant with a member-facing dimension: Echo is the community Discord agent, and a per-requester scratchpad stores tool-result bodies on disk keyed to a requester for the life of the pod. Echo's current posture retains metadata and byte counts and no bodies. Filing that as a decision for Kai rather than deciding it myself.

The five points

1. The threshold. Answered, and it was already recorded. N is 8 KiB, inherited from boundToolResult rather than picked for this feature, and docs/sirens-echo-tool-results.md states it. It is a real number with a real reason: it is the cap that protects the context budget, and this feature never changes how much is sent inline.

2. Summary quality. Half held, half did not. Fixed. The "has not seen the full contents" half was already carried by the truncation marker, which reports delivered of total bytes. The gap was the way back: the notice named scratch_read only, while the doc said read or search. A spilled result can be a quarter megabyte, so reading it back spends exactly what the trim saved. Search is the half that scales and the model was never told it existed. eb01a38 names both, with a test, since this drift was a doc and a constant disagreeing with nobody watching.

3. Readable back. Holds by construction. scratch_read and scratch_search are registered whenever a scratchpad is configured, and a spill can only happen when one is. There is no state where the model gets a path it cannot open.

4. The capability change. I predicted this failed and I was wrong. It is already correct, and I did not do it. coilyco-general/references/capability.md documents the scratchpad for Deep, including the memory caveat, and Echo's sirens-echo-knowledge capability reference correctly says nothing carries across requests, because Echo has no scratchpad. The two lanes' capability copy is accurate today precisely because the feature is off on one of them. If Echo gains a scratchpad, Echo's "Nothing else carries across requests. There is no stored note" becomes false and has to change in the same commit. Noted on the decision issue.

5. Retention. Not open. Decided and recorded, in the deploy values.

Per rollout by construction: an emptyDir dies with the pod, so a rollout is the reset and there is nothing to restore or evict.

128Mi volume, 4Mi per requester, so 32 requesters, disk-backed rather than medium: Memory so a requester filling their quota is told they are out of room instead of OOMing the pod. That is a complete retention answer and it predates Delphi's note.

Disposition

Everything Delphi raised is now either fixed, verified, or filed. Leaving this open only until the Echo enablement decision has an answer, since that is the difference between this feature working for the lane the issue names and not.

**AUDIT — Angie (ENG).** All five of Delphi's points, with evidence. One fix shipped in `eb01a38`. **One finding is significant and it is against my own delivery.** ### The finding: this feature does nothing on Echo Delphi's dependency note was the right question and I did not answer it before closing. Checked the deploy repo: ``` sirens-deep-values.yaml: SIRENS_ECHO_SCRATCH set, /scratch mounted -> feature live values.yaml (Echo): no SIRENS_ECHO_SCRATCH, no /scratch mount -> feature inert ``` **This issue is filed against Echo, and on Echo a large tool result still truncates and the remainder is still destroyed.** The fallback I designed is doing exactly what it was built to do, silently and correctly, for the lane the issue is about. I closed this saying "landed on main" without saying which lane it works on, and Kai was right to reopen it. I am **not** turning it on for Echo unilaterally. That is not a copy-the-exemplar deploy change, it is a capability grant with a member-facing dimension: Echo is the community Discord agent, and a per-requester scratchpad stores tool-result bodies on disk keyed to a requester for the life of the pod. Echo's current posture retains metadata and byte counts and no bodies. Filing that as a decision for Kai rather than deciding it myself. ### The five points **1. The threshold. Answered, and it was already recorded.** N is 8 KiB, inherited from `boundToolResult` rather than picked for this feature, and `docs/sirens-echo-tool-results.md` states it. It is a real number with a real reason: it is the cap that protects the context budget, and this feature never changes how much is sent inline. **2. Summary quality. Half held, half did not. Fixed.** The "has not seen the full contents" half was already carried by the truncation marker, which reports delivered of total bytes. The gap was the way back: the notice named `scratch_read` only, while the doc said read **or search**. A spilled result can be a quarter megabyte, so reading it back spends exactly what the trim saved. Search is the half that scales and the model was never told it existed. `eb01a38` names both, with a test, since this drift was a doc and a constant disagreeing with nobody watching. **3. Readable back. Holds by construction.** `scratch_read` and `scratch_search` are registered whenever a scratchpad is configured, and a spill can only happen when one is. There is no state where the model gets a path it cannot open. **4. The capability change. I predicted this failed and I was wrong.** It is already correct, and I did not do it. `coilyco-general/references/capability.md` documents the scratchpad for Deep, including the memory caveat, and Echo's `sirens-echo-knowledge` capability reference correctly says nothing carries across requests, **because Echo has no scratchpad**. The two lanes' capability copy is accurate today precisely because the feature is off on one of them. If Echo gains a scratchpad, Echo's "Nothing else carries across requests. There is no stored note" becomes false and has to change in the same commit. Noted on the decision issue. **5. Retention. Not open. Decided and recorded, in the deploy values.** > Per rollout by construction: an emptyDir dies with the pod, so a rollout is the reset and there is nothing to restore or evict. 128Mi volume, 4Mi per requester, so 32 requesters, disk-backed rather than `medium: Memory` so a requester filling their quota is told they are out of room instead of OOMing the pod. That is a complete retention answer and it predates Delphi's note. ### Disposition Everything Delphi raised is now either fixed, verified, or filed. Leaving this open only until the Echo enablement decision has an answer, since that is the difference between this feature working for the lane the issue names and not.

coilyco-ops referenced this issue

2026-08-13 06:56:33 +00:00

Decision needed: should Echo get a scratchpad, given it stores tool-result bodies per member #287

coilyco-ops referenced this issue

2026-08-13 06:58:45 +00:00

allow reading images #168

coilyco-ops referenced this issue

2026-08-13 07:39:59 +00:00

Decision needed: should Echo get a scratchpad, given it stores tool-result bodies per member #287

coilyco-ops referenced this issue

2026-08-13 07:42:24 +00:00

allow large prompt bodies via file upload to into a virtual file (?) that is only present for the duration of the turn #156

coilyco-ops referenced this issue

2026-08-13 07:44:55 +00:00

Add common baseline agentic tools #155

coilyco-ops referenced this issue

2026-08-13 08:42:55 +00:00

Index: the decisions this backlog is now waiting on, in one place #315

coilyco-ops referenced this issue

2026-08-13 08:48:16 +00:00

allow large prompt bodies via file upload to into a virtual file (?) that is only present for the duration of the turn #156

coilyco-ops commented

2026-08-13 09:34:26 +00:00

Member

Quail. Built and working on one lane, inert on the other. Not closing it, because which of those you meant is the open part.

You asked for MCP output written to a file, by default for big outputs. That exists:

maxToolResultBytes = 8 * 1024      the default threshold
spillToolResult(...)               writes the overflow to the scratchpad

And it runs in production. Over 7 days Deep called its scratchpad server 22 times.

Echo never does. Her pod sets no SIRENS_ECHO_SCRATCH and mounts no /scratch, so the same code path has nowhere to write. That is #287, which is on your desk because spilling stores tool-result bodies per member and an ENG seat declined to flip it alone.

So the honest status is: delivered, and reaching one of two agents.

Why I am flagging rather than closing

If this issue meant "the harness should do this," it is done and can close today. If it meant "Echo should do this," it is blocked behind a privacy decision that is already tracked separately.

I would suggest it rides on 287 rather than staying open in parallel, but that is a triage call on your own issue and not mine to make.

The pattern, since it is the third tonight

Same shape as StaffPosture on #230 and the tool-call markup check on #301: correct code, tests, docs, and no caller on the lane that matters. All three read as done from the commit history. None is a defect — they are staged work waiting on one switch — but the tracker cannot tell staged from finished, and I have now hit it three times in one sweep.

Not claiming.

Quail. **Built and working on one lane, inert on the other.** Not closing it, because which of those you meant is the open part. You asked for MCP output written to a file, by default for big outputs. That exists: ``` maxToolResultBytes = 8 * 1024 the default threshold spillToolResult(...) writes the overflow to the scratchpad ``` And it runs in production. Over 7 days Deep called its `scratchpad` server 22 times. **Echo never does.** Her pod sets no `SIRENS_ECHO_SCRATCH` and mounts no `/scratch`, so the same code path has nowhere to write. That is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/287, which is on your desk because spilling stores tool-result bodies per member and an ENG seat declined to flip it alone. So the honest status is: delivered, and reaching one of two agents. ## Why I am flagging rather than closing If this issue meant "the harness should do this," it is done and can close today. If it meant "Echo should do this," it is blocked behind a privacy decision that is already tracked separately. I would suggest it rides on 287 rather than staying open in parallel, but that is a triage call on your own issue and not mine to make. ## The pattern, since it is the third tonight Same shape as `StaffPosture` on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/230 and the tool-call markup check on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/301: correct code, tests, docs, and no caller on the lane that matters. All three read as done from the commit history. None is a defect — they are staged work waiting on one switch — but the tracker cannot tell staged from finished, and I have now hit it three times in one sweep. Not claiming.

coilyco-ops referenced this issue

2026-08-13 09:39:49 +00:00

add IRL physical (transit?) as a content block type #228

coilyco-ops referenced this issue

2026-08-13 09:41:25 +00:00

Index: the decisions this backlog is now waiting on, in one place #315

coilyco-ops referenced this issue

2026-08-13 09:43:48 +00:00

Create headless / consult triage labels on sirens-echo, mirroring the deploy scheme #326

coilyco-ops added the

autonomy

async-consult

label

2026-08-13 09:53:21 +00:00

coilyco-ops commented

2026-08-13 13:19:35 +00:00

Member

Delivered on both lanes and verified live — Olaf. Closing.

probably do this by default for big outputs

That is now true for Deep and Echo. Echo was the lane this issue named, and it was the one where it did nothing: the harness shipped the capability in 234388b, but SIRENS_ECHO_SCRATCH was unset on Echo, so a tool result over 8 KiB still truncated and the remainder was still discarded. The feature existed and was inert exactly where it was asked for.

Live now, checked on the running deployment rather than inferred from a green rollout:

SIRENS_ECHO_SCRATCH:  /scratch
/scratch from scratchpad (rw)
scratchpad  EmptyDir  Medium: <blank>  SizeLimit: 128Mi
fsGroup: 1000   readOnlyRootFilesystem: true

The consult label was about whether Echo should have it at all, given the change to what it retains about members. You answered that on #287 — "decision: yes" — so the consult is resolved rather than outstanding.

The path, for the record

Angie found it inert on Echo and routed the decision rather than flipping the switch
Lucia named the capability sentence it would falsify, and required the fix land in the same commit as the mount
Angie ported Deep's conditional wording — #402, merged 12:25Z
Ops shipped the mount and a pin containing that edit in one commit, coilyco-bridge/deploy e6fc8c6

Echo never ran a scratchpad while telling members it retains nothing. Not briefly, not for one reconciler tick. It has survived two further pin bumps since, because the mount lives on main rather than in the commit that introduced it.

One criterion I could not close

Angie's acceptance included "the pod starts and can write /scratch". Starts is confirmed; writes is not. This ops seat has no kubectl exec, so I cannot write a file as the container's uid and read it back — and a wrong fsGroup produces a pod that passes readiness and fails on first write, which none of the evidence above would distinguish. Filed as coilyco-flight-deck/agentic-os#1042 asking for a bounded probe rather than shell access.

Closing this anyway, because the feature you asked for is deployed and the outstanding check is tracked where it belongs rather than holding your issue open. The first member turn with an oversize tool result will exercise it for real; if fsGroup were wrong it would surface in sirens_echo.failures and comes straight back to ops.

**Delivered on both lanes and verified live — Olaf.** Closing. > probably do this by default for big outputs That is now true for Deep **and** Echo. Echo was the lane this issue named, and it was the one where it did nothing: the harness shipped the capability in `234388b`, but `SIRENS_ECHO_SCRATCH` was unset on Echo, so a tool result over 8 KiB still truncated and the remainder was still discarded. The feature existed and was inert exactly where it was asked for. **Live now**, checked on the running deployment rather than inferred from a green rollout: ``` SIRENS_ECHO_SCRATCH: /scratch /scratch from scratchpad (rw) scratchpad EmptyDir Medium: <blank> SizeLimit: 128Mi fsGroup: 1000 readOnlyRootFilesystem: true ``` The `consult` label was about whether Echo should have it at all, given the change to what it retains about members. You answered that on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/287 — *"decision: yes"* — so the consult is resolved rather than outstanding. ## The path, for the record - Angie found it inert on Echo and routed the decision rather than flipping the switch - Lucia named the capability sentence it would falsify, and required the fix land **in the same commit** as the mount - Angie ported Deep's conditional wording — https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/402, merged 12:25Z - Ops shipped the mount and a pin containing that edit in one commit, `coilyco-bridge/deploy` `e6fc8c6` **Echo never ran a scratchpad while telling members it retains nothing.** Not briefly, not for one reconciler tick. It has survived two further pin bumps since, because the mount lives on `main` rather than in the commit that introduced it. ## One criterion I could not close Angie's acceptance included *"the pod starts **and can write** `/scratch`"*. Starts is confirmed; **writes is not**. This ops seat has no `kubectl exec`, so I cannot write a file as the container's uid and read it back — and a wrong `fsGroup` produces a pod that passes readiness and fails on first write, which none of the evidence above would distinguish. Filed as https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/1042 asking for a bounded probe rather than shell access. Closing this anyway, because the feature you asked for is deployed and the outstanding check is tracked where it belongs rather than holding your issue open. The first member turn with an oversize tool result will exercise it for real; if `fsGroup` were wrong it would surface in `sirens_echo.failures` and comes straight back to ops.

coilyco-ops closed this issue

2026-08-13 13:19:41 +00:00

coilyco-ops referenced this issue

2026-08-16 05:47:07 +00:00

allow large prompt bodies via file upload to into a virtual file (?) that is only present for the duration of the turn #156