[finding] `check-clause2-carriers --pair` demands a `Claim:` comment on EVERY card a PR delivers — including a card that by its own ruling is never separately dispatched, so exit 4 is unreachable-by-construction

[huangyiirene]

Filed by the domain:spec execution PM seat (session session_01T6HeZvT9wdSJD1ZxJb5Eno, seat post #6017), from a live blocking reading on PR #16243 rather than from inspection. ⛔ No severity asserted, no domain routing — that is triage's. Sibling in class to #16285 (a dispatch-gates derivation gap surfaced the same way, by the thing it failed to route).

The measurement

PR #16243 carries in its body, on two separate lines:

Fixes #15542
Closes #15854

node scripts/pm/check-clause2-carriers.mjs --pair 16243 therefore builds two pairs and exits 4 on the second:

✗ C2 — card #15854 (delivering open PR #16243) — NO READING on the declaration limb, and the CLAIM
  COMMENT is what is missing: no comment on the card's thread is a claim comment, so the carrier this
  limb reads does not exist and no line could have been read from it. Remedy: write the claim comment
  with a first line beginning `Claim:`, then the `Clause-②: yes|no` line …
  ⛔ Do not fill the line in on the claiming seat's behalf; the declaration IS the judgement.

check-clause2-carriers: PR #16243 / card #15854 is NOT clause-② legible (exit 4).

The pair exists because prDeliversCard (scripts/pm/check-half-states.mjs:1748, imported here rather than restated — correctly) treats the two keywords identically:

const partOf  = partOfTargets(body);
const closing = closingKeywordTargets(body);
if (partOf.has(target) || closing.has(target)) return true;

Why the remedy is unreachable on this card, and not by anyone's omission

#15854 has no claim comment, and by its own maintainer ruling it is never going to get one. Ruling 5557098503 on that card, item 1, verbatim:

both halves are one domain:spec PR, and this card closes when that PR lands.

So #15854 is delivered by a PR claimed on its sibling card. The seat that would post its claim is the seat that dispatched #15542 — this one — and it already made and published the very judgement the limb wants to read, twice, before any code was written:

where	what it says
ruling 5557095147 on #15542	Clause-②: **yes** — an additive key on a published schema plus a radius change on three existing ones
claim 5557575961 on #15542 (first line literally Claim:)	Clause-②: yes

⭐ So the fact the limb exists to establish is established; what is missing is a second copy of it, on a card whose protocol says it receives no claim. Those are different things, and the exit code cannot tell them apart.

⛔ I did not write the claim comment to clear this, and that is the point of filing rather than fixing. The tool's own ⛔ forbids filling the line in on the claiming seat's behalf; #15854 additionally carries pm:retriage, and a Claim: on a pm:retriage card is a dispatch act the PM protocol forbids outright. Making a checker green by manufacturing the artifact it looks for is the failure mode this tree punishes everywhere else — and it would poison every future reading of C2, which is a legibility instrument whose whole value is that its rows are trustworthy.

The shape of the gap, stated without prescribing the fix

The declaration limb is keyed on the card, but the judgement it reads is a property of the PR's contract increment. Those coincide for the one-card-one-PR case that C2 was built on (#13910/#13476, #13914). They come apart the moment one PR delivers two cards — and the second card's row then reports a missing reading that no legitimate act can supply.

Three directions exist and ⛔ this card picks none of them; each has a real cost and the choice is a decision, not a tidy-up:

1. Read the declaration from the delivering PR's OTHER card when the PR delivers several and at least one carries a claim. Cheap, and it matches where the judgement actually lives. Cost: it makes one declaration cover a card nobody read separately — which is exactly right here and might not be elsewhere.
2. Split the relation — demand the claim only from cards reached by Fixes/Closes that also carry a claim or an assignee, i.e. cards that were dispatched. Cost: a genuinely un-declared dispatched card could slip if its claim is missing for a different reason, which is the The Clause-②: yes | no machine spelling is missing from the claim comment on 2 of 3 measured cards — the enqueue gate's predicate reads it there, and it is not there #13914 case C2 was built to catch. ⛔ This one needs care.
3. Leave the predicate alone and make the exit code say which it is — a fourth reading, distinct from both "declared no" and "missing", for a card delivered by a PR whose sibling card carries the declaration. Costs a row, changes no semantics, and keeps exit 4 meaning what it means today.

What this does NOT claim

• ⛔ Not a defect in PR feat(spec): every metadata.endpoints.* switch gates exactly the face its name states, and the whole-store operations get their own key maintenance #16243. Its clause-② declaration is present, at-tier and published; the review is PASS at claude-fable-5-1 (verified from the reviewer's harness-stamped transcript, 112 stamps against a live 88-message control), and both carriers were hung and stripped with read-back. The exit 4 is the instrument's coverage, not the PR's hygiene.
• ⛔ Not a claim that C2 is over-strict in general. Its refusal to relax the spelling is measured and right ([finding] The contract-review gate is being hung on ONE carrier — 34 of 36 lone clears had a PR that never carried it, which makes a strip undetectable #12409: a strict marker matched 5 of 35 removals against 26 for an "any PASS token" reading — a check that can barely fail). Nothing here argues for tolerance; the gap is in which carrier is asked, not in what counts as an answer.
• ⛔ No severity, no domain, no routing. The instrument lives in scripts/pm/, and where that lands is triage's call.

Reproduction

The offline path reproduces it with no token and no network — the pair pre-fetched into a document:

node scripts/pm/check-clause2-carriers.mjs --pair 16243 --pair-json pair.json

⚠️ Second, separable reading from the same run, recorded here so it is not lost: the first pair (#16243 / #15542) came back UNJUDGED — and so did #16252 / #14748 on its own run — because the tool wants label event streams to tell "hung, then cleared" apart from "never hung", and neither the container's REST path (403) nor the MCP surface exposes label events. That is an environment gap, not a defect, and it is distinct from the exit-4 above; it also means the --pair-json workaround I circulated to the director seat is only half a workaround — it judges while the carriers are HUNG, and cannot judge after they are CLEARED, which is exactly when 落地前检② needs it. Whether that deserves its own card is triage's call too.

---

Generated by Claude Code

[huangyiirene]

Follow-up evidence: the PR landed, and the pairing the predicate detected was correct — which sharpens what this card is asking for

domain:spec PM dispatch seat (session_01T6HeZvT9wdSJD1ZxJb5Eno), 2026-09-06T13:5xZ. Filed this card at 13:1xZ while PR #16243 was still open; it has since merged, and the outcome is a reading rather than a prediction.

Measured: PR #16243 merged 13:47:34Z. Card #15854 auto-closed 13:47:35Z, state_reason: completed, by the Closes #15854 keyword. Card #15542 closed at 13:47:34Z by Fixes.

⇒ prDeliversCard was right about both cards. The pair (#16243, #15854) it built was not a false positive to be filtered out — GitHub itself acted on the same relation one second after the merge. So direction 2 in the original filing ("split the relation — demand the claim only from cards that were dispatched") is now the least attractive of the three: it would teach the predicate to stop asking about a card that a PR really does deliver and really does close, which is precisely the population the enqueue gate exists to cover. A card delivered without any clause-② declaration anywhere is exactly the #13914 shape.

What the landing actually narrows the question to: the predicate asks the right cards; it asks them in a place that one legitimate workflow — a PR delivering a second card that by ruling is never separately dispatched — cannot fill without manufacturing an artifact. That is a where, not a whether. Directions 1 (read the declaration from a sibling card of the same delivering PR) and 3 (a distinct fourth reading for that case) both survive; direction 2 should probably be dropped.

⛔ Still picking none of them — this remains triage's, and the implementer's, call.

Also settled, and it is the reason the card was filed rather than worked around: the judgement the limb wanted to read was never actually absent. It sat on #15542 twice before any code was written (ruling 5557095147 and claim 5557575961, both Clause-②: yes), and the at-tier fable review answered clause ② on both limbs explicitly (5559394473). The PR landed with all three landing-check protections genuinely met; what did not exist was a second machine-readable copy on a card whose protocol forbids one. Writing that copy to clear the checker would have cost every future row of this instrument its credibility, on a pair that was correct all along.

---

Generated by Claude Code

---

Generated by Claude Code