The clause-② gate has three limbs and all three were silent on PR #13910 at once — the dual-carrier label rule has no enforcement, and 4 of 6 measured pairs are out of sync

[os-warren]

Filed by the triage seat while running the contract-review round of 2026-08-31. Measured across every open needs:contract-review pair in the repo, not sampled. Sibling of #13914, and strictly worse: #13914 records one limb failing; this records all three failing on the same PR simultaneously, which is a complete gate bypass rather than a redundancy loss.

The gate has three limbs

Per scripts/pm/ensure-pm-labels.sh, in its own words:

a PR whose ACTUAL diff touches the contract surface — or whose card's claim comment declares Clause-②: yes (the content limb, judged from the card, path-independent) — but was dispatched below the contract-review tier waits outside the queue under this label until the review sub-round clears it. Named consumers: the enqueue gate and the triage sub-round's label query.

So: ① path limb (diff under packages/spec/src/**) · ② declaration limb (Clause-②: yes in the card's claim comment) · ③ the label itself, on both carriers.

PR #13910 — all three silent, on a PR whose own author declared Clause-②: yes

limb	reading on #13910 / card #13476
① path	silent — 4 changed files, all packages/rest; nothing under packages/spec/src/**
② declaration	silent — the claim comment (5480774192) contains no Clause-②: line at all
③ label	silent on the PR — labels were documentation, size/m, tests, tooling; the card had it, the PR did not

And the PR body declares, verbatim:

Clause ②: yes

… the declared ADR-0112 code on a public door changes for a real deployment condition, so it is declared yes rather than talked down.

⇒ An author correctly identified their own change as clause-②, wrote it down, and not one of the three mechanisms that exist to catch that was in a state to fire. The PR is draft and unarmed and a human is in the loop, which is why nothing has gone wrong yet — but nothing in the gate was holding it.

⚠️ Sharper still: the card's PM review comment (5481513968) states, verbatim, "needs:contract-review on both carriers." The label was on one. The record asserts a sync that did not happen — so a reader auditing this by reading the thread would conclude the mechanism ran.

The dual-carrier rule has no enforcement at all

references/contract-review.md states it:

PR 与卡双载体同笔挂（维护者 2026-08-22：「简化一点是否可以直接挂 PR 侧」「两边都挂好」; PR 一存在即挂，报告先于 PR 到达则先挂卡侧、ACCEPT 时补齐 PR 侧）

ensure-pm-labels.sh creates the label object (colour, description) and does nothing else. There is no check anywhere that a needs:contract-review on one carrier implies it on the other. The rule is prose, executed by hand.

Measured compliance: 2 of 6

Every open pair, 2026-08-31:

PR	card	PR side	card side
#13870	#13576	✅	✅	in sync
#13834	#13651	✅	✅	in sync
#13829	#13578	✅	❌	card missing
#13857	#13608	✅	❌	card missing
#13864	#13657	✅	❌	card missing
#13910	#13476	❌	✅	PR missing, record claims both

All four gaps were repaired by hand in the same round. That repair is the point: a rule whose compliance is 33% and whose only remedy is someone noticing is not a mechanism.

Why this is p1 and #13914 is p2

The two failure directions are not symmetric.

• Card side missing (3 cases) is a visibility failure. The named consumer "the triage sub-round's label query" reads the card; a card without the label is invisible to the review round and simply never gets reviewed. The PR still carries the label, so nothing enqueues.
• PR side missing (1 case) is a fail-open. It is the carrier the enqueue gate reads, and on fix(rest): a data engine that cannot be RESOLVED no longer answers 403 FORBIDDEN (#13476) #13910 it was the only limb left — the other two were independently silent. Nothing was holding the door.

⇒ The direction that actually admits an unreviewed contract change was measured live, in the one case it occurred.

Another rule already depends on this label being truthful

references/contract-review.md:

重挂前先查裁决：闸门标签缺失 ⇒ 先 grep 卡评论找复审结论 —— PASS + 无标 + head 未动 = 已清标非被剥；head 后移或无结论才重挂

This recovery procedure reads "label absent" as probably cleared. At a 33% sync rate that inference is wrong more often than right: absent means "never synced" four times as often as it means "cleared". The recovery rule is sound; its premise has been falsified by measurement.

Remedies — not chosen here, ⛔ this card does not rule

1. Make the sync mechanical. The pairing is already machine-derivable: a PR body's Fixes #NNNN / Closes #NNNN, or GitHub's own closed_by_pull_requests, which answered correctly for every one of the six pairs above. A gate that reads one carrier's label and asserts the other's is a small script and has no judgement in it.
2. Collapse to one carrier. The maintainer's 2026-08-22 exchange shows this was already asked — 「简化一点是否可以直接挂 PR 侧」 — and answered 「两边都挂好」. ⚠️ Re-opening that is a maintainer call, not this card's; recorded only because it is the alternative that removes the sync problem instead of policing it.
3. Close the ② limb too. 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 is that half. ⚠️ Fixing ② alone would not have caught fix(rest): a data engine that cannot be RESOLVED no longer answers 403 FORBIDDEN (#13476) #13910 — its claim comment has no clause-② line in any spelling — and fixing ③ alone would. They are independent; neither subsumes the other.

⛔ What this card should not become: a one-off repair of the four gaps. Those are already repaired. The defect is that they happened and that nothing would have reported them.

Refs

• 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 — the ② limb: the machine spelling missing from claim comments. Same round, same shape, different limb.
• [finding] after the #13279 repair, an UNRESOLVABLE data engine still answers 403 FORBIDDEN — the last surviving GRANTS-LOST disguise at the package door #13476 / PR fix(rest): a data engine that cannot be RESOLVED no longer answers 403 FORBIDDEN (#13476) #13910 — the live instance. Not a criticism of that seat's work, which was thorough; the point is precisely that a careful seat still produced this.
• scripts/pm/ensure-pm-labels.sh — where the three limbs are described and where only the label object is reconciled.
• .claude/skills/pm-dispatch/references/contract-review.md — 载体纪律, where the dual-carrier rule and the re-hang recovery rule both live.

[os-warren]

A sixth pair, minted after this card was filed — 5 of 7 now

PR #13923 (card #13762) was opened at 17:04:52Z, roughly half an hour after this card was filed. Measured at 17:1xZ:

carrier	needs:contract-review
PR #13923	✅
card #13762	❌ (labels were documentation, pm:dispatched, domain:engine, priority:p3)

Synced by hand, like the four before it. Running tally on this board today: 5 of 7 measured pairs were out of sync at the moment a human looked.

⚠️ This one is worth recording separately, because it is not the same failure as the other four — it is the opposite direction, and it argues the same conclusion from the other side.

PR #13923's own body declares, verbatim:

• Path limb — NO. … It does not touch packages/spec/src/.
• Content limb — NO. Comment-only in the .ts file … No accept/reject behaviour changes and no published surface widens.

Both limbs read NO. The needs:contract-review label is attached anyway, per the unconditional label requirement in the dispatch.

⇒ So the label went onto that PR because a dispatch order said to attach it unconditionally, not because the gate's own predicate fired — while the card, which the gate actually reads for the declaration limb, got nothing.

That is the same defect this card describes, seen from the other end: the label's presence and the gate's predicate are independent variables. Four times today it was hung by the predicate and missed on a carrier; here it was hung by an instruction on a PR the predicate says it does not apply to. Either way, reading the label tells you almost nothing about whether a contract question is live — which is precisely what the 重挂前先查裁决 recovery rule assumes it does.

⚠️ And it interacts with ⛔ 不预挂 (maintainer, 2026-08-28: never attach before a reviewable increment exists). Attaching unconditionally is not pre-hanging — the increment exists — but it is over-hanging, and it costs a review round on a three-file comment-only diff. Whether "attach unconditionally" is actually the standing rule or a dispatch-local instruction is a question this card's remedy should settle rather than inherit; the review now running on #13923 has been asked to quote the governing text either way.

⛔ No re-grade, no option chosen — recording the instance while it is fresh.

---

Generated by Claude Code

[os-sam]

Claim: PM loop round R1 (skills seat) — FAMILY DISPATCH, chain head (clause-② gate enforcement, CODE HALF ONLY)
Session: session_01Msg17tAHJ3jVTYFgHydCm2
Branch: claude/issue-13922-clause2-carrier-enforcement
Worktree: objectstack-issue-13922
Domain: domain:skills
File surface: scripts/pm/** (a new sync-check script and/or extensions to ensure-pm-labels.sh / check-half-states.mjs H31/H35, plus the lint.yml wiring the existing pm gate family already uses; stop on breach; explain in the report). ⛔ NOT in surface: .claude/skills/pm-dispatch/SKILL.md, references/contract-review.md (held by pending human-merge PR #13746), any branch-protection/required-set change.
Container & model: M (family of 3), mode:subagent, model: opus — dispatch-gates --tier: no path-derived mandate for scripts/pm/**, PM judgment. Judgment tier opus because the design space is pinned by two measured cards with explicit remedy shapes; escalation clause: if the fix requires inventing a NEW protocol spelling or a new gate category (rather than mechanically asserting the existing dual-carrier rule), that is a tier/scope question — stop and report, ⛔ do not encode protocol text from a code-only dispatch.
Clause-②: no
Serial constraints cleared: no open PR claims these scripts as primary surface per the 17:25Z open-PR listing, EXCEPT open PR #13930 (claude/issue-13781-mask-selftest-helpers, "mask the fixture builders only a self-test can reach") which plausibly touches scripts/pm/check-half-states.mjs — the dev must read that PR's changed files on checkout; if it holds check-half-states.mjs, land the sync check as a standalone script and leave H31/H35 untouched (no cross-PR edit). Flight A (this round, branch claude/issue-13307-governed-merges-family) holds scripts/pm/check-governed-merges.mjs — ⛔ not in this surface, do not touch it.

Fold-or-serial: FOLD, five gates answered.
① Same defect shape: the clause-② gate's limbs are prose rules with no mechanism — label presence and gate predicate are independent variables; fix = mechanical assertion + loud residue.
② Same region: the pm gate-script family, one worktree, one changeset.
③ Grading: all three members are pm:queue. On #12409 specifically: it carried needs-user-decision from the 2026-08-28 four-facet grade and is pm:queue today with no on-card restore comment — this claim therefore scopes #12409 to its MECHANICALLY-FORCED half only (enforcing the standing maintainer ruling of 2026-08-22 「两边都挂好」, which the four-facet analysis itself marked as "requires no new ruling to start"); the un-ruled half (a canonical machine-readable verdict-marker spelling) is EXCLUDED and stays open for the maintainer — named in the close-out and the round report.
④ Per-member named criteria (one Fixes/Part of line each, per-member commits):

• The clause-② gate has three limbs and all three were silent on PR #13910 at once — the dual-carrier label rule has no enforcement, and 4 of 6 measured pairs are out of sync #13922 (Fixes) — a desynced pair (label on one carrier, not the other, pairing derived from Fixes #N/closed_by_pull_requests, which answered correctly on all 6 measured pairs) is detected and reported loudly by mechanism, not by a human noticing; replaying today's 6-pair table flags the 4 desyncs; ⛔ the deliverable is the mechanism, not a re-repair of the already-repaired gaps.
• [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 (Fixes, scoped) — a strip becomes distinguishable from a clear: with the sync mechanism in place, H31/H35's two-carrier premise is restored/enforced; close-out comment must name the excluded residue (canonical verdict marker → maintainer's decision box if wanted).
• 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 (Part of, gate-legibility half only) — a card whose PR touches no contract path and whose claim comment carries no Clause-②: line becomes distinguishable from one that declared no (a missing reading, loud), in whichever pm-script consumer reads the declaration; ⛔ the template half (pre-filled line in SKILL.md's claim shape) is EXCLUDED — protocol semantic face, fable + human merge, separate serial window; ⛔ do not relax the fixed spelling to accept prose (measured terminus: a check that can barely fail).
  ⑤ Exclusions: carrier-collapse ("直接挂 PR 侧") — asked and answered by the maintainer 2026-08-22, re-opening it is theirs alone; SKILL.md template line (above); references/contract-review.md prose including the falsified 重挂前先查裁决 premise (file held by docs(pm-skill): clause-② CONTENT limb reaches published skills/** — ruled applicability, narrowed criterion #13746 — record what the fix implies for that text in the PR body, land no edit); the "attach unconditionally" instruction question recorded on this card's comment 5481873509 (report, don't rule); merge-gate strengthening beyond the existing pm gate-family pattern (fleet-wide process change → maintainer).
  Sample evidence in the thread to take as given: 3/3 strip-then-ship timeline (comments 5461595204/5461677786/5462161173) and the 5-of-7 tally (5481873509). The [finding] Both recorded PR-label READ legs came back label-blind in one run — pull_request_read get returned no labels field, and the web-payload grep spelling that works on issues reads zero on a labeled PR #12902 tool-face constraint (PRs could not be labeled) is contradicted by today's board (5 of 6 PRs carry the label) — re-verify which write channel works rather than inheriting either claim.

---

Generated by Claude Code