[finding] The clause-② label protocol says `needs:contract-review` attaches to the CARD, but contract-review seats scan PRs — 2 measured instances of a parked PR that was invisible instead

[os-elon]

Filed by the domain:services PM seat (session session_012WkdHQwHr2KQmaX7P1BHzi). Unassigned, ungraded, no pm:queue — grading is triage's field. Two instances measured today, three hours apart, by two different actors following the protocol correctly.

The mechanism

A clause-② PR is parked by a below-tier seat withholding actions: don't flip ready, don't arm auto-merge, don't clear needs:contract-review. The 2026-08-28 director note executing the maintainer's ruling on #12887 (verbatim 「同意，你现在就执行」) says the label attaches once a reviewable increment exists:

the label now attaches only when a reviewable contract increment (draft PR, or an earlier report) EXISTS; forward pre-marks on queue/blocked cards are retired … the label re-attaches the moment this card's PR exists.

⇒ The trigger is "the PR exists"; the object the note names is "this card". ⛔ But a CONTRACT_REVIEW_TIER seat looking for work scans open PRs. A PR without the label is not parked — it is invisible to the queue it is parked in.

Instance 1 — PR #13371 (card #10025)

opened      2026-08-30 07:11Z
updated_at  2026-08-30 07:12Z      ← no activity for ~2.6 hours
PR labels   documentation, size/m, tests, tooling      ⛔ no needs:contract-review
card labels …, needs:contract-review                   ✅ present on the CARD

The PR body even says "contract review re-attaches its label at review time" — i.e. its author read the responsibility as the reviewer's. Meanwhile the reviewer cannot find it. I attached the label; the class is recorded on #10025.

Instance 2 — PR #13409 (card #12020), three hours later

The dev's own report states it "re-attached needs:contract-review on the card per the 2026-08-28 director note" — and it did, correctly, quoting the note. The PR still carried only documentation, size/m, tests, tooling.

⇒ ⭐ Two different actors, both following the note as written, both producing a hidden PR. That is the definition of a protocol defect rather than two mistakes. I attached the label here too.

Why this is worth fixing rather than remembering

⚠️ The reassurance every seat gives itself about parked clause-② work — "parked is not stuck; PR #13181 merged as b579b0382, and dce5cd4f0 (a feat(spec)!) landed the same way" — is evidence about PRs that were correctly labelled. It says nothing about one that was never in the list. ⛔ A below-tier seat can therefore be simultaneously right that the chain moves and wrong that its own PR is on it.

⭐ And the asymmetry makes the fix safe: attaching that label applies the control, only clearing it is forbidden to a below-tier seat. So there is no tension with the parking rules — the note can simply say both objects.

Suggested shape (⛔ not a ruling — this is governed text this seat does not edit)

State the object explicitly in the protocol: the label attaches to the PR the moment it exists, and to the card while no PR does. Optionally, the reviewer-facing sweep should look at both, so a missed label degrades to noise rather than silence.

⚠️ Confidence gaps

1. Not asserted: that the missing label is WHY nothing picked feat(service-automation): definition-level input-schema refusal is non-retryable (FLOW_INPUT_SCHEMA_INVALID) #13371 up. It is a sufficient explanation and is now removed. ⇒ If feat(service-automation): definition-level input-schema refusal is non-retryable (FLOW_INPUT_SCHEMA_INVALID) #13371 is still untouched on the next sweep, the label was not the blocker and the contract-review chain itself is what wants reporting. I have that scheduled.
2. I did not read how a CONTRACT_REVIEW_TIER seat actually finds its work. "Scans open PRs for the label" is my inference from the label existing on PRs at all and from feat(spec,lint,metadata-protocol): a page member on the view type enum — mount a published page on an object view #13372/feat(spec): register driver-memory as a UNIQUE_VIOLATION emitter in the error-code ledger #13354 carrying it. ⇒ If that seat sweeps cards instead, this finding is wrong in its mechanism even though both instances are real. Whoever grades this should establish that first — it is the load-bearing fact and it is the one I did not measure.
3. Two instances, both from this session and this seat's lane. Not established that the class is repo-wide.

Refs: #10025 / PR #13371 (instance 1) · #12020 / PR #13409 (instance 2) · #12887 and its 2026-08-28 director note (the protocol text) · #13181 = b579b0382 (the "parked is not stuck" evidence, which was correctly labelled)

Generated by Claude Code