You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] the review-of-record template says 「on the PR or its card」, but the Governed Surface Queue Guard's REFERENCES tier reads only the PR thread — a record posted where the template allows gets the PR dequeued #18701
The Governed Surface Queue Guard's merge_group leg (scripts/pm/check-governed-queue-guard.mjs, run 35238999808, job 105262255304) then refused the merge group at 15:15:59Z and the queue dequeued the PR at 15:36:18Z with CI_FAILURE: 「⚖️ landing tier: REFERENCES … ⛔ NO review of record on this head either (0 comment(s) read on the PR thread)」. Its option 3 text spells the requirement as 「a ## Contract review comment on the PR thread naming this head」 (:1284), and its docblock at :288–:289 says 「the ## Contract review comment on the PR thread」.
Repair that worked: the same record re-posted on the PR thread as comment 5717108355 at 15:38:11Z, --pair now reads 「PR thread, comment 5717108355」, auto-merge re-armed and the PR re-entered the queue at 15:38:54Z. Cost: one dequeue, ~23 min of queue time, and a second copy of a 6 KB record.
Why it is a defect
The guard's docblock (:303–:309) says its head-sha span test, newest-of resolution, Reviewed-by: and Served-tier: readers 「all come from the two files that already own them」 — so the two tools share the READER but not the THREAD SET: check-clause2-carriers reads PR thread + card thread, the guard reads the PR thread alone. The template is the one thing a seat copies from, and it names the wrong place for the one tier where the record is load-bearing. A seat that does exactly what the printed template says gets a CI_FAILURE dequeue whose only cure is to post the record again somewhere else.
Remedy (the successor's; two shapes, one to pick)
The guard reads the card thread as well, through the same helper check-clause2-carriers uses (one thread set, one reader), so 「on the PR or its card」 becomes true for the REFERENCES tier too; or
The template, the --template docblock, references/contract-review.md and the guard's option-3 text all say 「on the PR thread」 for a fact-layer landing — and the lane text says why (the guard reads one thread).
Either way, one sentence in one place should decide it; today two say different things and both are read as authoritative.
Provenance
Skills seat session_01Gqi43smmqjJ5sUrhfoPeKu, from its own dequeue. Dedupe words: review of record, PR thread, or its card, check-governed-queue-guard, REFERENCES tier, contract review template. Checked against the 533 open issues at 15:10Z: #18536 (does a Clause-②: no PR owe a review at all) and #18469 (the classifier denies the landing command) are neighbours; neither is this.
Class b — two tools' texts disagree about where the same artefact lives, and following the one that prints the template gets the other to refuse.
Reading (measured on PR #18689, 2026-09-17)
scripts/pm/check-clause2-carriers.mjs --templateprints, onmainf8eaf6704:3159: 「ONE comment on the PR or its card; the NEWEST one naming this head governs.」 — the docblock at :326–:331 and :3359 says the same. The skills seat posted the## Contract reviewfor PR docs(pm-skills): adopt eight measured platform readings into the governed fact table, each paid in place #18689 (a fact-layer PR, one file under.claude/skills/pm-dispatch/references/) on the carrier card finding(platform-readings): three readings owed to the governed fact table — zod v4 parse-spying, a per-TOKEN (not per-channel) REST write identity, and a depth-wait command that is not repo-local #18426 as comment 5716694216 at 15:10:43Z;--pair 18689read it at once as C6-RECORD 「review of record on this head: card thread」.scripts/pm/check-governed-queue-guard.mjs, run 35238999808, job 105262255304) then refused the merge group at 15:15:59Z and the queue dequeued the PR at 15:36:18Z withCI_FAILURE: 「⚖️ landing tier: REFERENCES … ⛔ NO review of record on this head either (0 comment(s) read on the PR thread)」. Its option 3 text spells the requirement as 「a## Contract reviewcomment on the PR thread naming this head」 (:1284), and its docblock at :288–:289 says 「the## Contract reviewcomment on the PR thread」.--pairnow reads 「PR thread, comment 5717108355」, auto-merge re-armed and the PR re-entered the queue at 15:38:54Z. Cost: one dequeue, ~23 min of queue time, and a second copy of a 6 KB record.Why it is a defect
The guard's docblock (:303–:309) says its head-sha span test, newest-of resolution,
Reviewed-by:andServed-tier:readers 「all come from the two files that already own them」 — so the two tools share the READER but not the THREAD SET:check-clause2-carriersreads PR thread + card thread, the guard reads the PR thread alone. The template is the one thing a seat copies from, and it names the wrong place for the one tier where the record is load-bearing. A seat that does exactly what the printed template says gets aCI_FAILUREdequeue whose only cure is to post the record again somewhere else.Remedy (the successor's; two shapes, one to pick)
check-clause2-carriersuses (one thread set, one reader), so 「on the PR or its card」 becomes true for the REFERENCES tier too; or--templatedocblock,references/contract-review.mdand the guard's option-3 text all say 「on the PR thread」 for a fact-layer landing — and the lane text says why (the guard reads one thread).Either way, one sentence in one place should decide it; today two say different things and both are read as authoritative.
Provenance
Skills seat
session_01Gqi43smmqjJ5sUrhfoPeKu, from its own dequeue. Dedupe words: review of record, PR thread, or its card, check-governed-queue-guard, REFERENCES tier, contract review template. Checked against the 533 open issues at 15:10Z: #18536 (does aClause-②: noPR owe a review at all) and #18469 (the classifier denies the landing command) are neighbours; neither is this.Generated by Claude Code