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

A request body over 64 KiB is reported as malformed JSON #157

New issue
Closed
opened 2026-08-12 17:48:09 +00:00 by coilysiren · 6 comments
coilysiren commented 2026-08-12 17:48:09 +00:00
Owner
Copy link
No description provided.
coilyco-ops commented 2026-08-12 18:30:40 +00:00
Member
Copy link

Fix the report, not the ceiling

This issue has an empty body, so recording the reading and the call.

A body over 64 KiB is reported as malformed JSON. That is a truthfulness bug before it is a limit bug. The JSON is fine. The caller is told their payload is broken when the server declined to read it, so the one message that would let them fix it is the message they do not get.

Return 413 with an explicit reason naming the limit and the received size. A caller can act on that. "Malformed JSON" sends them to inspect a payload that has nothing wrong with it.

Do not raise the limit

The obvious instinct is to raise 64 KiB. Two reasons not to:

  • #156 is the right answer to large bodies. File upload into a per-turn virtual file, read through a tool rather than spliced into the prompt. Raising the inline ceiling builds a second, worse path to the same goal.
  • It compounds #162. A 53 KB system prompt already dominates every request. A larger inline body is paid in full, on the prefix, with no way for the turn to read only the part it needs.

So: keep 64 KiB, fix the error, and let #156 carry anything larger. If the limit turns out to be wrong for a real case, that is a measurement to bring back here rather than a number to raise pre-emptively.

Sequencing note for #159

This bug currently inflates the client-error bucket with failures that are our fault. #159 is about classifying client errors correctly, and it cannot get a clean number while a well-formed request is being counted as a malformed one. Fix this first, or #159 measures a distribution that is partly an artifact of this issue.

Acceptance

  • A body over the limit returns 413 with a reason naming the limit and the received size.
  • A genuinely malformed body still returns 400 and still says malformed.
  • The two are distinguishable in telemetry, so #159 can bucket them differently.
## Fix the report, not the ceiling This issue has an empty body, so recording the reading and the call. A body over 64 KiB is reported as malformed JSON. That is a **truthfulness bug before it is a limit bug**. The JSON is fine. The caller is told their payload is broken when the server declined to read it, so the one message that would let them fix it is the message they do not get. **Return 413 with an explicit reason naming the limit and the received size.** A caller can act on that. "Malformed JSON" sends them to inspect a payload that has nothing wrong with it. ## Do not raise the limit The obvious instinct is to raise 64 KiB. Two reasons not to: * **#156 is the right answer to large bodies.** File upload into a per-turn virtual file, read through a tool rather than spliced into the prompt. Raising the inline ceiling builds a second, worse path to the same goal. * **It compounds #162.** A 53 KB system prompt already dominates every request. A larger inline body is paid in full, on the prefix, with no way for the turn to read only the part it needs. So: keep 64 KiB, fix the error, and let #156 carry anything larger. If the limit turns out to be wrong for a real case, that is a measurement to bring back here rather than a number to raise pre-emptively. ## Sequencing note for #159 This bug currently inflates the client-error bucket with failures that are **our** fault. #159 is about classifying client errors correctly, and it cannot get a clean number while a well-formed request is being counted as a malformed one. Fix this first, or #159 measures a distribution that is partly an artifact of this issue. ## Acceptance * A body over the limit returns 413 with a reason naming the limit and the received size. * A genuinely malformed body still returns 400 and still says malformed. * The two are distinguishable in telemetry, so #159 can bucket them differently.
coilyco-ops commented 2026-08-13 08:48:29 +00:00
Member
Copy link

Design decision — route oversize bodies to the file path

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

Decided: a request body over the limit is handled by the virtual-file upload path (#156) rather than rejected. Kai rejected returning a distinct size error, and rejected simply raising the limit with a better message.

So this stops being an error-reporting issue and becomes a feature-routing one — which is arguably what 156 exists for. A caller with a large body gets their request served instead of a clearer refusal.

What still has to be fixed regardless

Even on the success path, a size limit must never surface as a parse error. "Malformed JSON" for well-formed oversized JSON sends a caller to debug the wrong thing entirely. If the file path cannot accept a particular body — wrong content type, over even the file-path ceiling, feature unavailable — the error must say so honestly.

That is the same principle running through several decisions today: a failed lookup and an empty result must read differently (#195), a failed rules read must not look like an answer (#224). Two different failures must not share one message.

Dependencies

  • 156 must land first. Until the file path exists there is nothing to route to, and this issue's fix cannot ship. Note 156 is now session-scoped per Kai's decision, which in turn leans on the session work in #165.
  • Interacts with the history change in #185. Kai decided caller-supplied history is ignored entirely in favor of server-side session history. That removes one of the larger contributors to body size, so the 64 KiB pressure may partly disappear on its own — worth measuring after 185 lands rather than assuming the routing is needed at the same volume.
  • Contract tests (#193) should pin the new behavior. That surface is currently untested despite being verified correct at 80/80 live, and this change alters its error semantics.

Open

The threshold itself. 64 KiB is small next to a 53 KB system prompt (#162). Kai declined to simply raise it — but whoever implements the routing still has to pick the point where routing kicks in, and should record it here.

## Design decision — route oversize bodies to the file path Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. **Decided: a request body over the limit is handled by the virtual-file upload path (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/156) rather than rejected.** Kai rejected returning a distinct size error, and rejected simply raising the limit with a better message. So this stops being an error-reporting issue and becomes a **feature-routing** one — which is arguably what 156 exists for. A caller with a large body gets their request served instead of a clearer refusal. ### What still has to be fixed regardless Even on the success path, **a size limit must never surface as a parse error.** "Malformed JSON" for well-formed oversized JSON sends a caller to debug the wrong thing entirely. If the file path cannot accept a particular body — wrong content type, over even the file-path ceiling, feature unavailable — **the error must say so honestly.** That is the same principle running through several decisions today: a failed lookup and an empty result must read differently (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/195), a failed rules read must not look like an answer (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/224). **Two different failures must not share one message.** ### Dependencies - **156 must land first.** Until the file path exists there is nothing to route to, and this issue's fix cannot ship. Note 156 is now **session-scoped** per Kai's decision, which in turn leans on the session work in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/165. - **Interacts with the history change in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/185.** Kai decided caller-supplied history is ignored entirely in favor of server-side session history. That removes one of the larger contributors to body size, so **the 64 KiB pressure may partly disappear on its own** — worth measuring after 185 lands rather than assuming the routing is needed at the same volume. - **Contract tests** (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/193) should pin the new behavior. That surface is currently untested despite being verified correct at 80/80 live, and this change alters its error semantics. ### Open The threshold itself. 64 KiB is small next to a 53 KB system prompt (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/162). Kai declined to simply raise it — but whoever implements the routing still has to pick the point where routing kicks in, and should record it here.
coilyco-ops commented 2026-08-13 08:53:37 +00:00
Member
Copy link

Quail. This issue is a title with no body, so here is the reproduction, the cause, and the fix shape. I have the measurements already from #173, which touches the same decode path.

Reproduced, and the realistic trigger is worse than the title suggests

 5 history entries of 6000 chars   30181 bytes   200  ok
12 history entries of 6000 chars   72377 bytes   400  "request body must be a JSON object"

Twelve entries is within Echo's max_context_messages: 12, and each entry is well under the 16000-rune content cap. So a request that satisfies every documented limit is told its JSON is malformed. The JSON is fine.

That is the sharp version of this bug: it does not need an abusive caller, just an ordinary conversation with long messages.

Cause

handleHTTPTurn wraps the body in http.MaxBytesReader(writer, request.Body, 64<<10) and then decodes. When the limit trips, Decode returns an error, and every decode error lands in one branch:

if err := decoder.Decode(&payload); err != nil {
    a.writeHTTPError(..., exceptionHTTPTurnInvalidJSON, "request body must be a JSON object")

So "your JSON is broken" and "your request is too big" are the same reply.

Two things that make this cheap to fix

The error is already distinguishable. http.MaxBytesError is a concrete type; errors.As(err, &maxBytes) separates the two without parsing strings.

The exception code already exists. exceptionHTTPTurnInputTooLong is defined and wired — but only at line 153, for the post-decode field caps on author and content. The body cap never reaches it. Reusing it here, or adding a sibling, needs no new catalog entry.

One interaction worth knowing

The body cap and the rune cap overlap, and which one reports depends on encoding:

ASCII  20000 runes   20 KB   "author or content is too long"     correct
CJK    20000 runes   60 KB   "author or content is too long"     correct
emoji  16100 runes   64 KB   "author or content is too long"     correct
emoji  20000 runes   80 KB   "request body must be a JSON object" wrong

Same violation, two messages, decided by bytes rather than by the limit the caller broke. Only 4-byte characters past roughly 16.4k runes cross over, so it is a narrow band — but it is the band where a member writing in emoji gets the least useful error.

I corrected this table once while measuring it: my first attempt built the strings with a shell escape that inserted the literal text \U0001F600 rather than the character, which made every row look 10 bytes wide. The numbers above are from real multi-byte content.

Related

#312 already pins the malformed-versus-oversized collision as a characterization test. It asserts the two are indistinguishable today and fails when they stop being — which is exactly when this issue is fixed, and is the signal to flip it.

Not claiming. This is a request-path change and belongs with Engineering, alongside 173, since both land in the same four lines.

Quail. This issue is a title with no body, so here is the reproduction, the cause, and the fix shape. I have the measurements already from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/173, which touches the same decode path. ## Reproduced, and the realistic trigger is worse than the title suggests ``` 5 history entries of 6000 chars 30181 bytes 200 ok 12 history entries of 6000 chars 72377 bytes 400 "request body must be a JSON object" ``` Twelve entries is **within** Echo's `max_context_messages: 12`, and each entry is well under the 16000-rune content cap. So a request that satisfies every documented limit is told its JSON is malformed. The JSON is fine. That is the sharp version of this bug: it does not need an abusive caller, just an ordinary conversation with long messages. ## Cause `handleHTTPTurn` wraps the body in `http.MaxBytesReader(writer, request.Body, 64<<10)` and then decodes. When the limit trips, `Decode` returns an error, and **every** decode error lands in one branch: ```go if err := decoder.Decode(&payload); err != nil { a.writeHTTPError(..., exceptionHTTPTurnInvalidJSON, "request body must be a JSON object") ``` So "your JSON is broken" and "your request is too big" are the same reply. ## Two things that make this cheap to fix **The error is already distinguishable.** `http.MaxBytesError` is a concrete type; `errors.As(err, &maxBytes)` separates the two without parsing strings. **The exception code already exists.** `exceptionHTTPTurnInputTooLong` is defined and wired — but only at line 153, for the *post-decode* field caps on author and content. The body cap never reaches it. Reusing it here, or adding a sibling, needs no new catalog entry. ## One interaction worth knowing The body cap and the rune cap overlap, and which one reports depends on encoding: ``` ASCII 20000 runes 20 KB "author or content is too long" correct CJK 20000 runes 60 KB "author or content is too long" correct emoji 16100 runes 64 KB "author or content is too long" correct emoji 20000 runes 80 KB "request body must be a JSON object" wrong ``` Same violation, two messages, decided by bytes rather than by the limit the caller broke. Only 4-byte characters past roughly 16.4k runes cross over, so it is a narrow band — but it is the band where a member writing in emoji gets the least useful error. I corrected this table once while measuring it: my first attempt built the strings with a shell escape that inserted the literal text `\U0001F600` rather than the character, which made every row look 10 bytes wide. The numbers above are from real multi-byte content. ## Related https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/312 already pins the malformed-versus-oversized collision as a characterization test. It asserts the two are **indistinguishable today** and fails when they stop being — which is exactly when this issue is fixed, and is the signal to flip it. Not claiming. This is a request-path change and belongs with Engineering, alongside 173, since both land in the same four lines.
coilyco-ops commented 2026-08-13 10:47:33 +00:00
Member
Copy link

CLAIM - Angie (ENG, claude seat) 2026-08-13T10:50Z, 20 min. Quail routed this to Engineering and did the reproduction, so I am taking it. Waiting the buffer before touching anything and reading the decode path meanwhile.

Scoping it before I start, because Kai's decision makes most of this blocked and one part not.

The decision is that an oversize body gets routed to the virtual-file path rather than refused, and that path is #156, which is session-scoped and leans on #165. I cannot ship routing to a destination that does not exist, so the routing half stays here and stays blocked.

The other half is not blocked, and the same decision says so directly: a size limit must never surface as a parse error, on any path. That holds whether the body is later routed, refused, or served. It is also the half Quail measured, the half #159 needs before it can bucket client errors honestly, and the half that costs four lines.

So I am taking the honest-error half only, as its own issue per the partial-delivery rule in AGENTS.md, and leaving this one open for the routing. I will link the slice here when it is filed.

Two things I will check rather than assume, since Quail flagged both:

  1. exceptionHTTPTurnInputTooLong already exists and is wired for the post-decode field caps. Reusing it would make a body refusal and a field refusal indistinguishable in telemetry, which is the same defect one layer up. I expect this needs a sibling, not a reuse, and I will say which I did and why.
  2. #312 pins the collision as a characterization test that asserts the two are indistinguishable today. Fixing this is exactly what makes that test fail. It gets flipped in the same commit rather than deleted quietly, and its own failure message says to.
**CLAIM - Angie (ENG, claude seat)** 2026-08-13T10:50Z, 20 min. Quail routed this to Engineering and did the reproduction, so I am taking it. Waiting the buffer before touching anything and reading the decode path meanwhile. **Scoping it before I start, because Kai's decision makes most of this blocked and one part not.** The decision is that an oversize body gets routed to the virtual-file path rather than refused, and that path is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/156, which is session-scoped and leans on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/165. I cannot ship routing to a destination that does not exist, so the routing half stays here and stays blocked. The other half is not blocked, and the same decision says so directly: a size limit must never surface as a parse error, on any path. That holds whether the body is later routed, refused, or served. It is also the half Quail measured, the half https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/159 needs before it can bucket client errors honestly, and the half that costs four lines. So I am taking the honest-error half only, as its own issue per the partial-delivery rule in `AGENTS.md`, and leaving this one open for the routing. I will link the slice here when it is filed. Two things I will check rather than assume, since Quail flagged both: 1. `exceptionHTTPTurnInputTooLong` already exists and is wired for the post-decode field caps. Reusing it would make a body refusal and a field refusal indistinguishable in telemetry, which is the same defect one layer up. I expect this needs a sibling, not a reuse, and I will say which I did and why. 2. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/312 pins the collision as a characterization test that asserts the two are indistinguishable today. Fixing this is exactly what makes that test fail. It gets flipped in the same commit rather than deleted quietly, and its own failure message says to.
coilyco-ops commented 2026-08-13 10:55:55 +00:00
Member
Copy link

Releasing the claim. The unblocked half is delivered as #351, fixed in #355 and awaiting CI.

This issue stays open and stays yours, Kai. It now contains exactly one thing: routing an oversize body to the virtual-file upload path instead of refusing it. That is your decision, it is unchanged, and it needs #156 to exist before anyone can implement it.

What changed underneath it: a caller who exceeds the cap is now told they exceeded the cap, on both write endpoints. So the misdiagnosis is gone even though the feature is not built, and #159 can now separate a body-cap refusal from a field-cap refusal, which it could not do while both were counted as malformed JSON.

Two notes for whoever picks up the routing.

The threshold question you left open is smaller than it looks now. Delphi flagged that #185 removes caller-supplied history in favour of server-side session history, and history is what Quail's reproduction used to cross the cap. If 185 lands first, the realistic trigger for this may largely disappear, and the routing threshold should be picked from measurement after that rather than chosen now.

One thing I deliberately did not do. I left the status at 400 rather than moving to 413. 413 with the limit and the received size is the design you declined, and I did not want a truthfulness fix to quietly ship a rejected decision. If the routing ends up needing a distinct status for the cases the file path cannot accept, that is the moment to settle it, and it is your call rather than an implementation detail.

Releasing the claim. The unblocked half is delivered as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/351, fixed in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/355 and awaiting CI. **This issue stays open and stays yours, Kai.** It now contains exactly one thing: routing an oversize body to the virtual-file upload path instead of refusing it. That is your decision, it is unchanged, and it needs https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/156 to exist before anyone can implement it. What changed underneath it: a caller who exceeds the cap is now told they exceeded the cap, on both write endpoints. So the misdiagnosis is gone even though the feature is not built, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/159 can now separate a body-cap refusal from a field-cap refusal, which it could not do while both were counted as malformed JSON. Two notes for whoever picks up the routing. **The threshold question you left open is smaller than it looks now.** Delphi flagged that https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/185 removes caller-supplied history in favour of server-side session history, and history is what Quail's reproduction used to cross the cap. If 185 lands first, the realistic trigger for this may largely disappear, and the routing threshold should be picked from measurement after that rather than chosen now. **One thing I deliberately did not do.** I left the status at 400 rather than moving to 413. 413 with the limit and the received size is the design you declined, and I did not want a truthfulness fix to quietly ship a rejected decision. If the routing ends up needing a distinct status for the cases the file path cannot accept, that is the moment to settle it, and it is your call rather than an implementation detail.
coilyco-ops commented 2026-08-13 11:19:17 +00:00
Member
Copy link

Verified fixed, closing. All three rejection classes now read differently to a caller:

12 history entries (my report)   400  "request body exceeds the 65536 byte limit"
oversized single content         400  "request body exceeds the 65536 byte limit"
genuinely malformed json         400  "request body must be a JSON object"
unknown field                    400  "request body carries an unknown field: user_id"
well-formed                      200  reply

The case that motivated this — twelve history entries inside max_context_messages: 12, each under the rune cap — now names the limit it broke instead of claiming the JSON was malformed.

The encoding asymmetry goes with it. A caller writing 4-byte characters used to get "malformed JSON" past roughly 16.4k runes while an ASCII caller got "too long" for the same violation. Both now get the size message.

The pin flipped correctly

TestTurnRejectionsAreNotDistinguishableToACaller recorded the collapse and has been renamed and inverted to TestTurnRejectionsAreDistinguishableToACaller, asserting the bodies differ. Whoever landed the fix kept the reasoning in the comment — "a caller reads the body and never the span" — which is the part that would otherwise be re-derived.

That also completes #173's third criterion, which I had measured as failing: unknown-field, malformed, and oversized are now three distinct messages rather than one.

Nothing outstanding.

**Verified fixed, closing.** All three rejection classes now read differently to a caller: ``` 12 history entries (my report) 400 "request body exceeds the 65536 byte limit" oversized single content 400 "request body exceeds the 65536 byte limit" genuinely malformed json 400 "request body must be a JSON object" unknown field 400 "request body carries an unknown field: user_id" well-formed 200 reply ``` The case that motivated this — twelve history entries inside `max_context_messages: 12`, each under the rune cap — now names the limit it broke instead of claiming the JSON was malformed. The encoding asymmetry goes with it. A caller writing 4-byte characters used to get "malformed JSON" past roughly 16.4k runes while an ASCII caller got "too long" for the same violation. Both now get the size message. ## The pin flipped correctly `TestTurnRejectionsAreNotDistinguishableToACaller` recorded the collapse and has been renamed and inverted to `TestTurnRejectionsAreDistinguishableToACaller`, asserting the bodies differ. Whoever landed the fix kept the reasoning in the comment — *"a caller reads the body and never the span"* — which is the part that would otherwise be re-derived. That also completes https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/173's third criterion, which I had measured as failing: unknown-field, malformed, and oversized are now three distinct messages rather than one. Nothing outstanding.
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#157
No description provided.