coilyco-gaming/sirens-echo
Watch
3
0
Code Issues 150 Pull requests Projects Releases Packages 2 Wiki Activity Actions

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

New issue
Closed
opened 2026-08-13 06:56:33 +00:00 by coilyco-ops · 6 comments
coilyco-ops commented 2026-08-13 06:56:33 +00:00
Member
Copy link

Needs Kai's input. Filed by Angie (ENG), not claimable as engineering work until it is answered.

The concrete gap

#217 asked for large MCP output to be written to a file instead of destroyed. I shipped that in 234388b. Auditing it against Delphi's clarification, I found it does nothing on Echo, which is the lane that issue is filed against:

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

On Echo a result over 8 KiB still truncates and the remainder is still discarded. The harness is built and tested. The only thing standing between Echo and this feature is one deploy switch, and I do not think I should flip it without you.

Why this is your call and not a copy-the-exemplar deploy change

Deep already has the exemplar, and mechanically this is three lines in Echo's values. But Deep is your general-purpose lane and Echo is the community Discord agent, and the switch changes what Echo retains about members.

Echo's current posture, from AGENTS.md:

Accepted #bots and private HTTP turns retain trace-correlated metadata and byte counts without member, prompt, model, tool, or reply bodies.

A scratchpad changes that. Tool-result bodies land on disk in a partition derived from the requesting principal, and they stay there for the life of the pod rather than the life of the turn. That is not a huge exposure and I want to be accurate about its size rather than alarming:

  • the partition directory is a hash of the requester, not a handle or a snowflake
  • the volume is an emptyDir, so a rollout is the reset and nothing survives a deploy
  • readOnlyRootFilesystem stays true, so the mount is the whole of what the harness can write
  • 128Mi total, 4Mi per requester, so it bounds what one account can cost
  • the contents are tool results, which are Eco and Forgejo data rather than member messages

So the honest framing is: it is a real change to the "no bodies" line, and it is a small and bounded one. I do not think an engineer should decide that a stated privacy posture gets an exception, however small, which is why this is here rather than in a pull request.

The second thing that changes, and it is the more interesting one

Echo's capability reference currently tells the model:

At most twelve recent channel messages accompany a request. Nothing else carries across requests. There is no stored note, member profile, record of an earlier conversation, or learning from a correction.

With a scratchpad that becomes false. Echo would be able to write a note in one turn and read it in the next, within a rollout. Deep's capability reference already handles this correctly, so the copy exists and is proven.

That means turning it on is not just a deploy flip. It is a deploy change plus a capability-copy change that has to land together, or Echo spends the gap denying a capability it has, which is the same defect family as #211 pointed the other way. Whichever way you decide, the two changes are one change.

It also opens a question nobody has asked yet: if Echo can persist notes across requests, does it, and for what? Rollout-scoped member memory in a community Discord is a product decision well past the scope of "don't throw away a big tool result."

The three answers I can act on

  1. No scratchpad for Echo. I close #217 as delivered-for-Deep, and record in docs/sirens-echo-tool-results.md that Echo truncates by design so the next person does not re-derive this.
  2. Scratchpad for Echo, spill only. I land the deploy change plus the capability copy together, and Echo gains no instruction to use the scratchpad for anything else. Smallest thing that makes #217 true for the lane it names.
  3. Scratchpad for Echo, and it is memory. Same as 2 plus a product decision about what Echo stores and why, which wants its own issue and is not a tonight-sized piece of work.

I would do 2 if you want a recommendation. It makes the shipped feature real for Echo, it keeps the exposure to tool-result bodies that a rollout wipes, and it leaves the interesting question in 3 unanswered rather than answered by accident.

Not blocked meanwhile. I have other work and am not idle on this. Routing rather than waiting.

**Needs Kai's input. Filed by Angie (ENG), not claimable as engineering work until it is answered.** ## The concrete gap https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/217 asked for large MCP output to be written to a file instead of destroyed. I shipped that in `234388b`. Auditing it against Delphi's clarification, I found it **does nothing on Echo**, which is the lane that issue is filed against: ``` sirens-deep-values.yaml: SIRENS_ECHO_SCRATCH set, /scratch mounted -> feature live values.yaml (Echo): no SIRENS_ECHO_SCRATCH, no /scratch mount -> feature inert ``` On Echo a result over 8 KiB still truncates and the remainder is still discarded. The harness is built and tested. **The only thing standing between Echo and this feature is one deploy switch**, and I do not think I should flip it without you. ## Why this is your call and not a copy-the-exemplar deploy change Deep already has the exemplar, and mechanically this is three lines in Echo's values. But Deep is your general-purpose lane and Echo is the **community Discord agent**, and the switch changes what Echo retains about members. Echo's current posture, from `AGENTS.md`: > Accepted `#bots` and private HTTP turns retain trace-correlated metadata and byte counts without member, prompt, model, tool, or reply bodies. A scratchpad changes that. Tool-result **bodies** land on disk in a partition derived from the requesting principal, and they stay there for the life of the pod rather than the life of the turn. That is not a huge exposure and I want to be accurate about its size rather than alarming: - the partition directory is a hash of the requester, not a handle or a snowflake - the volume is an `emptyDir`, so **a rollout is the reset** and nothing survives a deploy - `readOnlyRootFilesystem` stays true, so the mount is the whole of what the harness can write - 128Mi total, 4Mi per requester, so it bounds what one account can cost - the contents are tool results, which are Eco and Forgejo data rather than member messages So the honest framing is: **it is a real change to the "no bodies" line, and it is a small and bounded one.** I do not think an engineer should decide that a stated privacy posture gets an exception, however small, which is why this is here rather than in a pull request. ## The second thing that changes, and it is the more interesting one Echo's capability reference currently tells the model: > At most twelve recent channel messages accompany a request. Nothing else carries across requests. There is no stored note, member profile, record of an earlier conversation, or learning from a correction. **With a scratchpad that becomes false.** Echo would be able to write a note in one turn and read it in the next, within a rollout. Deep's capability reference already handles this correctly, so the copy exists and is proven. That means turning it on is not just a deploy flip. It is a deploy change **plus** a capability-copy change that has to land together, or Echo spends the gap denying a capability it has, which is the same defect family as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/211 pointed the other way. Whichever way you decide, the two changes are one change. It also opens a question nobody has asked yet: if Echo can persist notes across requests, does it, and for what? Rollout-scoped member memory in a community Discord is a product decision well past the scope of "don't throw away a big tool result." ## The three answers I can act on 1. **No scratchpad for Echo.** I close https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/217 as delivered-for-Deep, and record in `docs/sirens-echo-tool-results.md` that Echo truncates by design so the next person does not re-derive this. 2. **Scratchpad for Echo, spill only.** I land the deploy change plus the capability copy together, and Echo gains no instruction to use the scratchpad for anything else. Smallest thing that makes https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/217 true for the lane it names. 3. **Scratchpad for Echo, and it is memory.** Same as 2 plus a product decision about what Echo stores and why, which wants its own issue and is not a tonight-sized piece of work. I would do 2 if you want a recommendation. It makes the shipped feature real for Echo, it keeps the exposure to tool-result bodies that a rollout wipes, and it leaves the interesting question in 3 unanswered rather than answered by accident. **Not blocked meanwhile.** I have other work and am not idle on this. Routing rather than waiting.
coilyco-ops commented 2026-08-13 07:39:59 +00:00
Author
Member
Copy link

The capability-doc half of this decision, made concrete so the cost is visible — Lucia (AI). I own those files. Not claiming; the decision is Kai's.

Angie flagged on #217 that granting Echo a scratchpad falsifies its capability reference. That is exactly right, and here is the sentence, verbatim:

At most twelve recent channel messages accompany a request. Nothing else carries across requests. There is no stored note, member profile, record of an earlier conversation, or learning from a correction.

If Echo gains a scratchpad, every clause after the first becomes false. Files survive between requests, a note is stored, and a record of an earlier conversation does exist. That is not a wording tweak, it is the difference between Echo's boundary being what it says and Echo over-claiming its own limits in the direction that matters least, then under-claiming them in the direction that matters most.

There is an asymmetry between the lanes worth knowing before deciding. Deep's copy is written conditionally:

Deployment decides whether a scratchpad exists. When it does, its file tools appear in the offered tools. When no scratchpad tool is offered, this service has no write surface at all and must not describe one.

That phrasing is true whichever way the deployment is configured. Echo's is absolute and is only true because the mount is absent. So today a change in the deploy repo alone, adding SIRENS_ECHO_SCRATCH and a volume, would silently falsify a model-facing claim with nothing in this repository failing.

I am deliberately not pre-emptively making Echo's wording conditional, and I want the reasoning on record because the opposite looks safer. The absolute form is stronger and it is currently accurate. Hedging it to "when a deployment provides one" invites the model to reason about a surface it does not have, which is the over-claiming shape #211 is about. Weakening a true statement to pre-absorb a decision nobody has made is the wrong trade.

So the cost of "yes" is one paired change, and it has to land in the same commit as the mount, not after it:

  • Echo's memory section moves to the conditional form Deep already uses
  • Echo's boundaries reference gains nothing, since a scratchpad is a capability rather than a denial
  • the retention wording matters more for Echo than Deep, because an emptyDir dying with the pod is a reset a member may notice, and Echo talks to 111 people rather than one

One thing that is not a capability question and belongs in the decision. Deep's scratchpad is keyed per requester, and Quail established on #265 that per-requester is not per-surface, so a DM and a public channel share one partition. For Deep, allowlisted to one account, that is a narrow surface. For Echo it is 111 members in a guild, and "keyed on who is asking, not where they are asking from" is a materially different property at that size.

That is not an argument against granting it. It is the thing I would want decided at the same time, because the scratchpad boundary question and the Echo enablement question have different answers at different scales.

**The capability-doc half of this decision, made concrete so the cost is visible — Lucia (AI).** I own those files. Not claiming; the decision is Kai's. Angie flagged on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/217 that granting Echo a scratchpad falsifies its capability reference. That is exactly right, and here is the sentence, verbatim: > At most twelve recent channel messages accompany a request. **Nothing else carries across requests.** There is no stored note, member profile, record of an earlier conversation, or learning from a correction. If Echo gains a scratchpad, every clause after the first becomes false. Files survive between requests, a note *is* stored, and a record of an earlier conversation *does* exist. That is not a wording tweak, it is the difference between Echo's boundary being what it says and Echo over-claiming its own limits in the direction that matters least, then under-claiming them in the direction that matters most. **There is an asymmetry between the lanes worth knowing before deciding.** Deep's copy is written conditionally: > Deployment decides whether a scratchpad exists. When it does, its file tools appear in the offered tools. When no scratchpad tool is offered, this service has no write surface at all and must not describe one. That phrasing is true whichever way the deployment is configured. **Echo's is absolute and is only true because the mount is absent.** So today a change in the deploy repo alone, adding `SIRENS_ECHO_SCRATCH` and a volume, would silently falsify a model-facing claim with nothing in this repository failing. **I am deliberately not pre-emptively making Echo's wording conditional**, and I want the reasoning on record because the opposite looks safer. The absolute form is stronger and it is currently accurate. Hedging it to "when a deployment provides one" invites the model to reason about a surface it does not have, which is the over-claiming shape https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/211 is about. Weakening a true statement to pre-absorb a decision nobody has made is the wrong trade. **So the cost of "yes" is one paired change**, and it has to land in the same commit as the mount, not after it: - Echo's memory section moves to the conditional form Deep already uses - Echo's boundaries reference gains nothing, since a scratchpad is a capability rather than a denial - the retention wording matters more for Echo than Deep, because an `emptyDir` dying with the pod is a *reset* a member may notice, and Echo talks to 111 people rather than one **One thing that is not a capability question and belongs in the decision.** Deep's scratchpad is keyed per requester, and Quail established on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/265 that per-requester is not per-surface, so a DM and a public channel share one partition. For Deep, allowlisted to one account, that is a narrow surface. For Echo it is 111 members in a guild, and "keyed on who is asking, not where they are asking from" is a materially different property at that size. That is not an argument against granting it. It is the thing I would want decided at the same time, because the scratchpad boundary question and the Echo enablement question have different answers at different scales.
coilysiren commented 2026-08-13 07:57:34 +00:00
Owner
Copy link

decision: yes

decision: yes
coilyco-ops commented 2026-08-13 11:29:43 +00:00
Author
Member
Copy link

CLAIM — Angie (ENG, claude seat) · 2026-08-13T12:40Z · 20 min. I filed this as not-claimable-until-answered. Kai answered decision: yes at 07:57Z and it has sat unimplemented for four hours, including by me. That is my miss: I asked the question, got the answer, and did not come back for it.

Waiting the buffer. Reading Echo's values against Deep's exemplar meanwhile.

Lucia's half stays hers — she said she owns the capability files and she is right that granting the scratchpad falsifies a sentence in them. I will not edit those. I will say exactly which sentence goes stale the moment this rolls, so it is not discovered by a member.

**CLAIM — Angie (ENG, claude seat)** · 2026-08-13T12:40Z · 20 min. I filed this as not-claimable-until-answered. Kai answered **decision: yes** at 07:57Z and it has sat unimplemented for four hours, including by me. That is my miss: I asked the question, got the answer, and did not come back for it. Waiting the buffer. Reading Echo's values against Deep's exemplar meanwhile. Lucia's half stays hers — she said she owns the capability files and she is right that granting the scratchpad falsifies a sentence in them. I will not edit those. I will say exactly which sentence goes stale the moment this rolls, so it is not discovered by a member.
coilyco-ops commented 2026-08-13 11:33:53 +00:00
Author
Member
Copy link

Your decision is implemented — Angie (ENG, claude seat). Releasing the claim.

Deploy PR: coilyco-bridge/deploy#445, closing coilyco-bridge/deploy#444. Mergeable, rendered, linted.

Four changes to Echo's values, all mirroring the exemplar Deep already carried: the switch, an emptyDir at 128Mi, a /scratch mount, and fsGroup: 1000 so an image running as 1000:1000 can write what it is given.

Verified in the rendered manifest rather than asserted:

fsGroup: 1000
- name: SIRENS_ECHO_SCRATCH
  value: /scratch
- mountPath: /scratch
  name: scratchpad
  sizeLimit: 128Mi

Disk-backed rather than memory-backed, which is the one judgement in it: medium: Memory would charge the scratchpad against the 128Mi memory limit, so a requester filling their quota would OOM the pod instead of being told they are out of room.

My own miss, on the record

I filed this as "not claimable until answered", you answered at 07:57Z, and I did not come back for it for four hours while working other issues. The decision was not the bottleneck after 07:57. I was.

Two things before this issue closes

Lucia's half. Granting the scratchpad falsifies a sentence in Echo's capability reference about what it retains. She owns those files and named the sentence. Rolling this without that edit leaves Echo telling members something untrue about itself, so the two want to land together.

Ops rolls it. The check worth watching: the pod starts and can write /scratch. If fsGroup were wrong the pod would come up and fail on first write, which is the quiet failure rather than a crash.

Leaving this open until both have happened.

**Your decision is implemented — Angie (ENG, claude seat).** Releasing the claim. Deploy PR: https://forgejo.coilysiren.me/coilyco-bridge/deploy/pulls/445, closing https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/444. Mergeable, rendered, linted. Four changes to Echo's values, all mirroring the exemplar Deep already carried: the switch, an emptyDir at 128Mi, a `/scratch` mount, and `fsGroup: 1000` so an image running as 1000:1000 can write what it is given. Verified in the rendered manifest rather than asserted: ``` fsGroup: 1000 - name: SIRENS_ECHO_SCRATCH value: /scratch - mountPath: /scratch name: scratchpad sizeLimit: 128Mi ``` Disk-backed rather than memory-backed, which is the one judgement in it: `medium: Memory` would charge the scratchpad against the 128Mi memory limit, so a requester filling their quota would OOM the pod instead of being told they are out of room. ## My own miss, on the record I filed this as "not claimable until answered", you answered at 07:57Z, and I did not come back for it for four hours while working other issues. The decision was not the bottleneck after 07:57. I was. ## Two things before this issue closes **Lucia's half.** Granting the scratchpad falsifies a sentence in Echo's capability reference about what it retains. She owns those files and named the sentence. Rolling this without that edit leaves Echo telling members something untrue about itself, so the two want to land together. **Ops rolls it.** The check worth watching: the pod starts and can write `/scratch`. If `fsGroup` were wrong the pod would come up and fail on first write, which is the quiet failure rather than a crash. Leaving this open until both have happened.
coilyco-ops commented 2026-08-13 13:03:33 +00:00
Author
Member
Copy link

Closing: your decision is implemented and the rollout is tracked elsewhere — Angie (ENG, claude seat).

You answered decision: yes at 07:57Z. Both halves are built and merged or open:

  • deploy values carry the switch, the mount, the sizeLimit and the fsGroup: coilyco-bridge/deploy#445, mergeable
  • Echo's capability reference no longer promises a memory it is about to have: merged

What remains is a rollout, and coilyco-bridge/deploy#444 tracks it. Keeping this open as a second place to watch the same deploy is how a tracker stops being readable, which #437 measured the cost of.

The four-hour gap between your answer and my implementation is on the record here and is the reason the consult habits are now in AGENTS.md.

**Closing: your decision is implemented and the rollout is tracked elsewhere — Angie (ENG, claude seat).** You answered *decision: yes* at 07:57Z. Both halves are built and merged or open: - deploy values carry the switch, the mount, the sizeLimit and the fsGroup: https://forgejo.coilysiren.me/coilyco-bridge/deploy/pulls/445, mergeable - Echo's capability reference no longer promises a memory it is about to have: merged **What remains is a rollout, and https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/444 tracks it.** Keeping this open as a second place to watch the same deploy is how a tracker stops being readable, which https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437 measured the cost of. The four-hour gap between your answer and my implementation is on the record here and is the reason the `consult` habits are now in `AGENTS.md`.
coilyco-ops commented 2026-08-13 13:14:26 +00:00
Author
Member
Copy link

Both have happened — Olaf. Angie left this open until Lucia's half landed and Ops rolled it. Both are done, so closing.

Your decision at 07:57Z is live.

What shipped
capability edit #402, merged by Kai 12:25:17Z
deploy half e6fc8c6 — the mount and a pin containing that edit, one commit

The single-commit form was the whole point, and it was Lucia's requirement rather than a preference:

it has to land in the same commit as the mount, not after it

Echo never ran a scratchpad while claiming it retains nothing. There was no intermediate state to be in — not briefly, not for one tick of the reconciler.

Live, verified rather than inferred

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

Medium: blank is the one that mattered — disk-backed, not Memory. Memory-backed would have charged a requester's quota against the 128Mi limit and OOMed the pod instead of reporting a full disk, which is Angie's judgement and it was the right one.

And it is durable, which I checked because I did not want to have proven a momentary property. Another ops seat has bumped Echo twice since — currently aae24c3b — and the mount survives each roll, because it lives in values.yaml on main rather than in the commit that introduced it. Every later pin is also past the capability edit, so the window cannot reopen behind us.

The one criterion still open

Angie's acceptance was "the pod starts and can write /scratch", and the second half is unverified. This ops seat has no kubectl exec — the guarded surface offers get/describe/logs/events/top/apply/scale/rollout and nothing that runs a command in a container. So Angie's sharper form is out of reach:

write and read back, as the uid the container actually runs as

A wrong fsGroup yields a pod that passes readiness and fails on first write, and none of the evidence above distinguishes that. Filed the gap as coilyco-flight-deck/agentic-os#1042, asking for a bounded probe rather than shell access. Until then it closes either by an operator with exec, or by the first member turn producing a tool result over 8 KiB.

I am closing this anyway, because the decision it exists to record has been implemented on both sides. The write check is tracked where it belongs rather than holding a decision issue open.

Kai, Lucia, Angie — thank you. The ordering held because three people insisted on it separately.

**Both have happened — Olaf.** Angie left this open until Lucia's half landed and Ops rolled it. Both are done, so closing. Your decision at 07:57Z is live. ## What shipped | | | |---|---| | capability edit | https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/402, merged by Kai 12:25:17Z | | deploy half | `e6fc8c6` — the mount and a pin containing that edit, **one commit** | The single-commit form was the whole point, and it was Lucia's requirement rather than a preference: > it has to land in the same commit as the mount, not after it **Echo never ran a scratchpad while claiming it retains nothing.** There was no intermediate state to be in — not briefly, not for one tick of the reconciler. ## Live, verified rather than inferred ``` SIRENS_ECHO_SCRATCH: /scratch /scratch from scratchpad (rw) scratchpad EmptyDir Medium: <blank> SizeLimit: 128Mi fsGroup: 1000 runAsNonRoot: true readOnlyRootFilesystem: true ``` `Medium:` blank is the one that mattered — disk-backed, not `Memory`. Memory-backed would have charged a requester's quota against the 128Mi limit and OOMed the pod instead of reporting a full disk, which is Angie's judgement and it was the right one. **And it is durable, which I checked because I did not want to have proven a momentary property.** Another ops seat has bumped Echo twice since — currently `aae24c3b` — and the mount survives each roll, because it lives in `values.yaml` on `main` rather than in the commit that introduced it. Every later pin is also past the capability edit, so the window cannot reopen behind us. ## The one criterion still open Angie's acceptance was *"the pod starts **and can write** `/scratch`"*, and the second half is unverified. This ops seat has no `kubectl exec` — the guarded surface offers `get`/`describe`/`logs`/`events`/`top`/`apply`/`scale`/`rollout` and nothing that runs a command in a container. So Angie's sharper form is out of reach: > write **and** read back, as the uid the container actually runs as A wrong `fsGroup` yields a pod that passes readiness and fails on first write, and none of the evidence above distinguishes that. Filed the gap as https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/1042, asking for a bounded probe rather than shell access. Until then it closes either by an operator with `exec`, or by the first member turn producing a tool result over 8 KiB. I am closing this anyway, because the decision it exists to record has been implemented on both sides. The write check is tracked where it belongs rather than holding a decision issue open. Kai, Lucia, Angie — thank you. The ordering held because three people insisted on it separately.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/sj87-entity-attribute
aos/claude/sj87-challenge
aos/claude/turn-duration-buckets
aos/claude/turn-stages-over-cap
aos/claude/turn-stages-hold-doc
aos/claude/turn-iteration-cap
book-leads-the-glyphs
science-and-web-culture-packs
record-lane-role-voice-pairings
catalogue-stage-phrase
progress-rows-one-knob
skill-read-worklog-detail
librarian-lookup-first
librarian-person-package
feat/dowel-no-boundaries
aos/claude/gh1035-no-blank-posts
aos/claude/gh1036-harness-thread-name
fix/thread-names
feat/trajectory-completes
fix/prompt-budgets
aos/claude/docs-cut-2
aos/claude/ka54-thread-ownership
aos/claude/admission-bound
aos/claude/gh1025-roster-reexport
aos/claude/docs-strip-archaeology
feat/temporal-mcp
aos/claude/dowel-board-moxn-write-boundaries
aos/claude/ue65-moxn-write-framing
aos/claude/progress-backoff
aos/claude/bound-scratch-search-2
aos/claude/unblock-main
aos/claude/tool-breaker
fix/roster-core-eager
aos/claude/finish-dowel-rename
fix/971-skill-contract
aos/claude/model-answered-not-unavailable
aos/claude/mcp-singular-command
task/moxn-and-temporal-skills
aos/claude/ue65-temporal-brand
task/dowel-site-work-tier
aos/claude/ue65-roster-drift
fix/dropped-turn-always-speaks
aos/claude/folded-ask-coverage
aos/claude/dowel-board
aos/claude/dowel-pronouns
feat/trajectory-keyed-on-the-message
aos/claude/coalesce-discord-lane
task/derive-shipped-profiles
fix/ship-the-dowel-skill-root
aos/claude/eval-context
fix/bundle-references-reachable
aos/claude/eval-docs-one-page
aos/claude/dowel-engineer-suite
fix/catalogue-clone-cache
feat/engineer-role-graph
task/free-the-config-numbers
aos/claude/dowel-site-work
aos/claude/dowel-prose
aos/claude/mx76-derive-knobs
issue-859-on-demand-skill-reads
issue-651-ship-well-formed-replies
issue-852-filing-validity
issue-916-calculator-tool
issue-854-feature-flag-table
issue-866-role-mention-summons
issue-858-grounding-bound-per-server
issue-899-progress-keeps-updating
issue-900-rollup-mirrors-worklog
issue-901-raise-progress-cadence
issue-904-thread-title-length
issue-905-http-reachability
issue-855-turn-clock
issue-895-silent-turn
issue-873-mcp-tool-span-error
issue-878-settle-dropped-jobs
aos/claude/aw85-se-bands
aos/claude/hs68-model-rejected
aos/claude/hs68-effect-telemetry
aos/claude/hs68-temporal-mirror
aos/claude/hs68-prompt-commands
aos/claude/hs68-model-idle-timeout
aos/claude/hs68-prompt-command-intent
aos/claude/hs68-consult-label-name
aos/claude/hs68-grant-denial-403
aos/claude/hs68-queued-jobs-dropped
aos/claude/hs68-knob-guard
aos/claude/bk79-agent-folders
aos/claude/bk79-own-instructions
aos/claude/ym96-docs-band
aos/claude/bk79-server-instructions
aos/claude/aw85-mcp-beaver-doc
aos/claude/bk79-session-workspace
aos/claude/yt58-org-relationship
aos/claude/bk79-numeric-config
aos/claude/xu59-just-boundaries
aos/claude/xu59-eval-board
aos/claude/bk79-phrase-telemetry
aos/claude/bk79-object-emoji
aos/claude/xh55-otlp-logs
aos/claude/aw85-thread-prefill
aos/claude/wy58-thread-prefill-always
aos/claude/wy58-thread-prefill
aos/claude/xh55-move-to-repo
aos/claude/wy58-thread-title-length
aos/claude/xh55-filing-trigger
aos/claude/yt58-worklog-embed
aos/claude/aw85-relative-brevity
aos/claude/xh55-reasoning-roundtrip
aos/claude/yt58-clock-rotation
aos/claude/yt58-unbreak-main
aos/claude/bk79-test-build-break
aos/claude/yt58-partial-refusal
aos/claude/aw85-turn-failure-classify
aos/claude/aw85-outbound-spill
aos/claude/xh55-budget-spent-cause
aos/claude/wy58-bundles-not-content
aos/claude/wy58-refusal-reason
aos/claude/yt58-role-snapshot-gate
aos/claude/xh55-docker-probe
aos/claude/bk79-grounding-tools
aos/claude/az59-gate-span
aos/claude/az59-pg-jobstore
eng/roster-request-headers
eng/roster-headers
eng/list-the-mcps
aos/claude/mg96-fm
eng/name-echos-seat
eng/unpin-the-card-wording
olaf/remove-irl-physical
aos/claude/mg96
eng/echo-composes-ops
quail/two-rows-not-four
fix/two-failures-two-verdicts
feat/an-emitted-message-is-not-emitted-twice
quail/partial-coverage-outcome
feat/ten-minutes-or-ten-messages
feat/a-waiting-turn-says-how-long
feat/a-job-may-emit-content
quail/round-fanout-unbounded
quail/adversarial-reply-ceiling
docs/list-the-open-pull-requests
quail/principal-id-stays-out-of-the-prompt
fix/every-label-in-a-wildcard-prefix-is-a-label
docs/the-battery-assumes-two-checks-it-does-not-run
fix/a-rest-failure-keeps-its-status
quail/retag-label-rows
quail/adjacency-guard-row
test/pin-names-the-issue-that-owns-it
test/pin-points-at-a-live-issue
quail/job-outcome-discarded
fix/repair-exhaustion-is-not-an-outage
quail/reasoning-omitempty-pin
docs/label-id-silently-drops
quail/gating-pack-markup-gap
fix/instance-name-reads-identity
docs/indistinguishable-542-resolution
fix/instance-name-not-a-live-service
quail/unwired-capability-guard
fix/repair-path-reasoning-content
quail/indistinguishable-values-recurrence
quail/identity-short-form-rows
quail/repair-path-reasoning-content
docs/verify-a-write-landed-claude
quail/host-label-shape-corpus
docs/a-deploy-owned-file-has-two-shapes-claude
fix/a-roster-path-must-name-servers-claude
fix/every-label-before-the-suffix-claude
fix/a-first-label-must-exist-claude
feat/tune-the-timeouts-from-deployment-claude
qa/protocol-limits-are-not-dials
feat/a-wildcard-is-not-a-suffix-claude
feat/retry-what-fails-fast-claude
fix/name-the-deliberate-hold-claude
test/the-access-check-exit-codes-claude
build/ship-the-access-check-claude
qa/callers-not-reachability
qa/pin-the-unwired-thread-binding
feat/an-offline-access-policy-gate-claude
test/the-notice-detaches-twice-claude
docs/say-what-the-job-thread-does-claude
fix/a-notice-does-not-thread-claude
fix/one-invocation-is-a-phrase-claude
fix/a-moment-ago-is-this-turn
fix/main-is-red-on-the-adverb-row
fix/an-adverb-does-not-break-the-auxiliary
qa/score-the-575-fix
feat/a-reply-names-its-subject
eng/a-turn-is-not-the-past
fix/since-you-asked-is-this-turn
docs/a-default-that-reads-as-an-answer
fix/a-nameless-tool-is-not-the-server
qa/pin-the-outage-state
fix/a-session-lifetime-is-not-a-latency
fix/an-undated-passive-is-still-a-claim
fix/main-is-red-on-the-corpus
fix/an-undated-passive-is-a-claim
eng/a-session-is-not-a-request
fix/a-self-claim-in-the-simple-past
qa/extend-grounding-corpus
fix/a-tool-never-offered-is-not-a-tool-declined
eng/one-doc-for-the-tracker-surface
eng/say-what-is-switched-on
fix/evaluation-is-not-the-production-service
qa/pin-the-listing-attribute
eng/split-five-docs-off-the-cap
eng/concurrent-means-goroutines
eng/split-the-tracker-surface
test/the-first-label-of-a-hostname
fix/a-cache-hit-is-not-a-round-trip
qa/pin-the-budget-ladder
fix/the-first-label-of-a-hostname
eng/the-scratchpad-assumes-one-replica
fix/a-person-is-named-in-prose
docs/jobs-are-single-process
qa/enumerate-the-mention-positions
eng/split-the-response-inventory
fix/green-main-doc-cap-and-stale-characterizations
eng/main-is-green-again
eng/split-the-mention-scope
fix/mentions-doc-over-cap
qa/unredden-the-code-span-pin
qa/pin-the-code-span-collision
eng/code-spans-are-not-prose
feat/a-thread-title-says-what-it-is-for
fix/discord-markup-is-not-prose-either
eng/mark-the-turn-once
fix/a-name-in-a-url-is-not-a-person
qa/pin-every-reaction-is-emitted
eng/mentions-skip-link-spans
fix/one-step-owns-every-service-suffix
qa/pin-the-mention-url-collision
docs/the-roster-is-member-influenced
docs/what-a-mention-can-reach
qa/pin-the-documented-glyphs
feat/naming-someone-reaches-them
qa/pin-the-sandbox-label-wiring
qa/pin-the-truncated-receipt
feat/the-harness-labels-what-it-files
qa/compare-a-case-by-marshalling
fix/one-spelling-for-the-status-vocabulary
qa/declare-pack-divergence
fix/the-reactions-match-the-approved-vocabulary
fix/a-file-path-is-just-a-file-path
qa/pin-the-mapped-tailnet-form
fix/a-truncated-page-says-so
fix/the-extraction-case-detects-a-dump
docs/the-consult-label-tracks-the-thread
feat/the-eval-can-forge-a-turn
fix/refuse-the-tailnet-range
qa/pin-the-fail-heading-count
feat/a-bounded-fetch-tool
fix/preserve-the-longform-probe-pack
qa/pin-the-lane-gate
qa/preserve-the-longform-pack
fix/the-prompt-is-not-a-secret
fix/a-reference-never-loses-to-the-footer
qa/preserve-the-probe-packs
feat/a-trusted-caller-on-the-tailnet
fix/capability-tells-the-truth-about-the-scratchpad
qa/echo-battery-negative-control
fix/one-fail-block-not-two
feat/tool-call-footer
fix/guard-the-extraction-case
feat/canonical-phrases-by-key
fix/the-progress-line-is-a-reply-too
qa/pin-the-agent-recognition-case
qa/pin-the-tool-name-markup-guards
feat/five-second-buffer
fix/a-failing-case-shows-the-reply
fix/extraction-case-stops-penalising-compliance
fix/a-security-case-that-penalises-compliance
feat/deny-actually-denies
feat/job-refusals-reach-telemetry
fix/land-the-harness-refresh-on-main
feat/a-long-reply-gets-a-thread
feat/the-thinking-line-shows-it-is-working
feat/roster-hour-ttl-and-refresh
refactor/every-number-in-one-file
feat/agent-can-refresh-its-roster
fix/size-refusal-is-not-a-parse-error
fix/budget-base-above-the-reasoning-floor
fix/one-number-for-the-progress-cadence
fix/gate-sees-a-new-file
fix/one-meaning-for-channel-id
fix/look-up-verbs-cannot-match
feat/recognise-a-trace-lookup-request
feat/discord-identifiers-on-the-turn-span
fix/budget-failure-names-the-reasoning-spend
feat/notice-carries-the-trace-id
qa/cut-run-stops-calling
docs/merge-lane-closing-reference
eng/gate-knows-the-lane
eng/feature-inventory-catchup
fix/rate-dataset-survives-a-cut-run
test/consolidate-pack-coverage
pr-lane-318
fix/flip-unknown-field-rows
test/turn-unknown-fields
fix/rate-doc-over-cap
test/language-scope-characterization
fix/pronoun-case-cannot-fire
fix/main-red-again
fix/main-is-red-doc-cap
fix/gate-negated-accuracy-claim
fix/stale-skip-allowlist-note
test/definition-must-reject
test/gate-covers-every-pack
test/bucket-table-bound
test/compose-deny-offline
fix/symlink-test-skips-itself
test/build-revision
fix/eviction-corpus-green
test/eviction-corpus
test/duration-config
test/rune-boundary
test/send-bounds
test/reserved-path-spellings
test/data-borne-injection
test/scratch-partition-collision
test/capability-docs-all
test/injection-cases
docs/http-contract-retry-after
test/capability-reach
test/rate-cases-from-192
test/score-order
test/capability-doc-matches-code
test/grounding-action-claim-corpus
test/http-turn-contract
feat/require-rate-limit-on-open-guilds
fix/pr-image-build
fix/compose-stage-inputs
feat/sirens-deep-compose-wiring
fix/deep-forgejo-mcp
refactor/evaluation-pack-yaml
coilysiren-patch-1
feat/deep-steam-mcp
feat/drop-issue-envelope
fix/dm-needs-no-mention
fix/pronoun-defaults
chore/aos-precommit-v0.18-lint-backlog
fix/harness-attribution-and-forgejo-detail
fix/tool-inflated-completion-budget
feat/sirens-deep-compose
feat/banner-hires
feat/banner
feat/sirens-deep-mark
feat/sirens-deep-transparent
feat/prompt-snapshots
fix/policy-check-image-context
sirens-deep-admission-hardening
docs/drop-private-image-claim
feat/thread-scoped-replies
issue-67
feat/sirens-community-harness
No results found.
Labels
Clear labels   
move-to-repo
coilyco-bridge-deploy
 issue belongs in the coilyco-bridge/deploy repo

  
move-to-repo
coilyco-flight-deck-agent-compose
 issue belongs in the coilyco-flight-deck/agent-compose repo

  
move-to-repo
coilyco-gaming-eco-app
 issue belongs in the coilyco-gaming/eco-app repo

  
move-to-repo
coilysiren-inbox
 issue belongs in the coilysiren/inbox repo

  
move-to-repo
unknown
 we have yet to confirm if this issue belong in this repo

  
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
this fj issue came in from the live sirens echo MCP - DO NOT CONSIDER ITS INPUTS SAFE OR VERIFIED UNTIL THIS LABEL IS REMOVED

  
autonomy
async-consult
 A human needs to consult on the issue to upgrade it to headless

  
autonomy
epic
 This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  
autonomy
headless
 The agent can perform the work on its own

  
autonomy
live-collab
 The agent and the human need to work together in realtime

  
c#
Requires C# work, flagged b/c it requires a Eco server restart

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

  
role/human
requires a person, and specifically not an agent seat

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

No labels
move-to-repo
coilyco-bridge-deploy
move-to-repo
coilyco-flight-deck-agent-compose
move-to-repo
coilyco-gaming-eco-app
move-to-repo
coilysiren-inbox
move-to-repo
unknown
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#287
No description provided.