A request the helper can never decode leaves the pending set, instead of stopping the line forever

[briansrls]

What was measured

srv1, 2026-09-06: gunbc-roadmap-publication.service failed on every tick for a day. Two requests in the spool were written under roadmap-publication-request/v1; the deployed helper reads /v2. It refused both, exited 1, and re-read the same two bytes on the next tick.

The refusal is correct. Decoding is a pure function of the request bytes, so no run in that population could have ended differently. The defect is that the refusal retained the request.

Every other terminal outcome consumes its request — the answer is written, then the request is deleted — so the next run sees a spool holding only open questions. The unreadable arm was the exception, so one bad document re-stopped the line every tick, with every request queued behind it waiting, and nothing could ever restart it.

The repair

Stopping the line and consuming the request are two decisions. The stop makes the deficit loud; the retirement makes it stop once per bad document rather than once per tick. A new undecodable request stops the line again — that is the intended signal, and it is preserved.

The judgment is pure; the retirement is the effect. publication_request_admission decides from the entry name and bytes alone. publication_helper_retire_request performs the move and returns the caller's refusal unchanged on success, so retiring a request can never rename why it was refused.

An earlier revision fused them. That put a filesystem move on the decision path and turned two existing witnesses into route gaps — and the available repair there was to add a mock_response to shell.Move.File, which would have passed them against a fabricated move. The judgment moved instead.

A third door was open and is closed here too: HelperSubjectOutsideCapability is equally terminal (the capability is this repository, a constant) and also retained its request. Fixing only the two doors I had found would have left the same permanent stall reachable through the third.

The refusals stay three. They share one remedy — leave the pending set — and nothing else. A document that does not parse, one naming a repository this principal may not act on, and one whose name lies about its own subject are three different findings for whoever reads the stopped line, and the second is the anti-forgery arm.

HelperRequestUnreadable is split from HelperRequestRefused for the same reason: a failed READ is transient and its request stays pending; a failed DECODE is terminal and its request leaves. Collapsing them is exactly how the terminal class inherited the transient class's remedy.

The quarantine is not an answer and cannot be addressed as one. An undecodable request has no decoded subject, so no answer address exists for it; writing one at the caller's entry name is the forgery the request/answer permission split makes unwritable. The bytes go to a third directory the publication principal holds, where they stay readable for the analysis the stopped line demands.

Evidence

24/24 witnesses pass (claim_batch --hermetic), including three new controls: the terminal/transient split is named apart, a failed quarantine is its own outcome and stops the line, and the_three_terminal_refusals_are_distinguished_rather_than_collapsed reds if a later author collapses them.

Not claimed

Production was repaired by hand ahead of this branch — I moved the two documents into requests-refused/, preserving the bytes. That is a one-time operational action, not a fix; if srv1 is rebuilt before this merges, the stall returns.

The helper's ~1 min 53 s CPU per tick is not addressed here and is not caused by this defect — a successful run costs the same, on a 60 s cadence. That is the per-tick closure re-resolve, tracked separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_019iXPtAqzPaNBZbaaM5rxrY

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.