Filed unassigned by the domain:cli seat (session session_019bmVFqoQPq63zhKrxdYG1r), from a mistake I made today. Recording only; not graded by the filing seat.
Measured
#10255. The triage seat presented three options; the maintainer ruled at 2026-08-20T16:50:49Z (comment 5359007897): option A — validate requires manage_platform_settings — with dispatch notes already specifying Clause-②: yes, the deliberate capability: null test flip, the 403 PERMISSION_DENIED refusal shape, the changeset shape, and a same-file serial constraint.
At 2026-08-21T01:18:06Z — eight hours later — I posted a claim (5364019124) fencing the same card as an open fork:
"This is a security card with a real possibility that the omission was deliberate, and the two readings have opposite fixes… ⛔ Do not assume (a) because the card is labelled security."
…plus a three-part investigation to establish (a) vs (b). All of it was work the maintainer had already closed.
I wrote the brief from the card's title and labels as they appeared in a pm:queue listing, and never opened the card's comments before writing.
Why the protocol did not catch it
CLAUDE.md and the claim protocol are explicit about re-reading comments, but the stated purpose is race arbitration:
"before writing code you must re-read the comments: an earlier claim with a different session ID means it's taken, whatever the assignee says."
That predicate answers "is this card taken?" It does not answer "has this card already been decided?" A ruling comment is not a claim comment, carries no session ID, and trips no part of the check. And the ruling had already moved the card needs-user-decision → pm:queue, so the label state that made it dispatchable is the same label state a never-decided card would have — the queue listing cannot distinguish them.
So the gap is not that I skipped a step. There is no step.
Why it matters more than one wasted brief
- A dev sent to "establish the fork" on a settled question may re-decide it. That is the failure mode the
needs-user-decision label exists to prevent, arriving through a door the label has already been removed from. On this card the dev found the ruling and implemented it (because the brief separately told him to read the card in full) — but that recovery was luck of instruction, not structure. - It is silent and self-consistent. Nothing in the report, the PR, or the gates would flag a brief that re-litigates a ruling. Here it surfaced only because the dev quoted the ruling comment back at me.
- It spends the most expensive dispatches. Ruled cards are disproportionately clause-② work at the
claude-fable-5 floor — exactly where a re-derivation of a closed fork costs most. - The waste compounds with the ruling's own dispatch notes. Rulings here routinely carry implementation constraints (test-flip shape, refusal vocabulary, serial constraints). A brief written without reading them re-derives those too, or contradicts them — mine told the dev the card would carry no
needs:contract-review, where the ruling said "contract-review tier or needs:contract-review".
Leads, not decisions
- Add a decision re-read to the PM's pre-brief checklist, symmetrical to the race re-read: before writing a brief, read the card's comments to the last page and quote any maintainer ruling into the brief as binding, or state that none exists. Cheapest fix, and it is the one that matches what briefs already demand of devs.
- Make it machine-visible: have the ruling comment carry a greppable marker (the triage seat already uses
pm-dispatch markers elsewhere), so a brief-writer can check one grep instead of reading a long thread — and so a gate could assert that a claim on a card carrying a ruling marker quotes it. - Carry the ruling in the card body, not only in a comment, when triage flips
needs-user-decision → pm:queue. The body is what a listing-driven reader is most likely to see, and this repo already relies on body-only channels for Restart-when: / Blocked-by: for exactly that reason.
⛔ Which of these — and whether a gate should enforce it at all — is a process call for whoever owns the dispatch skill, not a seat's.
Not claimed
⛔ I have not swept for other briefs that re-opened settled cards; this is one instance, self-reported. Whether it has happened before is unmeasured, and the cheap measurement that would settle it is: for each card that moved needs-user-decision → pm:queue, check whether the subsequent claim comment quotes the ruling.
Filed unassigned by the
domain:cliseat (sessionsession_019bmVFqoQPq63zhKrxdYG1r), from a mistake I made today. Recording only; not graded by the filing seat.Measured
#10255. The triage seat presented three options; the maintainer ruled at 2026-08-20T16:50:49Z (comment
5359007897): option A —validaterequiresmanage_platform_settings— with dispatch notes already specifyingClause-②: yes, the deliberatecapability: nulltest flip, the403 PERMISSION_DENIEDrefusal shape, the changeset shape, and a same-file serial constraint.At 2026-08-21T01:18:06Z — eight hours later — I posted a claim (
5364019124) fencing the same card as an open fork:…plus a three-part investigation to establish (a) vs (b). All of it was work the maintainer had already closed.
I wrote the brief from the card's title and labels as they appeared in a
pm:queuelisting, and never opened the card's comments before writing.Why the protocol did not catch it
CLAUDE.mdand the claim protocol are explicit about re-reading comments, but the stated purpose is race arbitration:That predicate answers "is this card taken?" It does not answer "has this card already been decided?" A ruling comment is not a claim comment, carries no session ID, and trips no part of the check. And the ruling had already moved the card
needs-user-decision→pm:queue, so the label state that made it dispatchable is the same label state a never-decided card would have — the queue listing cannot distinguish them.So the gap is not that I skipped a step. There is no step.
Why it matters more than one wasted brief
needs-user-decisionlabel exists to prevent, arriving through a door the label has already been removed from. On this card the dev found the ruling and implemented it (because the brief separately told him to read the card in full) — but that recovery was luck of instruction, not structure.claude-fable-5floor — exactly where a re-derivation of a closed fork costs most.needs:contract-review, where the ruling said "contract-review tier orneeds:contract-review".Leads, not decisions
pm-dispatchmarkers elsewhere), so a brief-writer can check one grep instead of reading a long thread — and so a gate could assert that a claim on a card carrying a ruling marker quotes it.needs-user-decision→pm:queue. The body is what a listing-driven reader is most likely to see, and this repo already relies on body-only channels forRestart-when:/Blocked-by:for exactly that reason.⛔ Which of these — and whether a gate should enforce it at all — is a process call for whoever owns the dispatch skill, not a seat's.
Not claimed
⛔ I have not swept for other briefs that re-opened settled cards; this is one instance, self-reported. Whether it has happened before is unmeasured, and the cheap measurement that would settle it is: for each card that moved
needs-user-decision→pm:queue, check whether the subsequent claim comment quotes the ruling.