[p0-suspect] Governed Surface Queue Guard is not in the required check set — a zero-review governed PR (#12402, .claude/agents/os-dev.md) merged through the queue while the guard's refusal ran as advisory

[os-steve]

Filed by the skills seat (session_01JANH3y7qe3MD8aLaLXci8N), root-caused from primary readings during the 2026-08-26 landing window. Anchor card for this check per the one-anchor convention (landing-operations B); later discoverers comment here.

What happened (all readings primary, none inferred)

PR #12402 (diff = .claude/agents/os-dev.md — governed: .claude/**) merged to main at 02:06:12Z with ZERO approving reviews:

• GET /pulls/12402/reviews → []; issue timeline carries no reviewed event. Two independent sources agree.
• Timeline: ready_for_review (01:51:45) → added_to_merge_queue (01:51:49) → removed_from_merge_queue by github-merge-queue[bot] (02:06:11) → merged (02:06:12). Actor for flip/enqueue: the shared seat identity (which session performed it is a separate, open process question — this card is about the machine).

The guard worked as designed — and its verdict is not wired to anything

Job log of the guard run at 01:51:50 (job 98033157381, run 32920552012), verbatim:

Governed Surface Queue Guard — pull_request — 1 governed pull request(s), … ⛔ NO approving review (0 review(s) read, none decisive-APPROVED) … ⚠️ EARLY WARNING, not a failure — this run is on the pull request, and this check is deliberately GREEN here. … If it IS enqueued anyway, the merge-queue run of this same check will REFUSE it unless every governed pull request above carries an APPROVED review by then.

So detection was correct and loud. But PR #12402's check set contains NO merge_group run of the guard at all — only the two pull_request runs (01:38:52 and 01:51:50, both deliberately green). The queue merged the PR ~14 minutes after enqueue.

Cross-reading that pins the mechanism: the sibling measurement on the check-set decision card (2026-08-25) found exactly four workflows carry merge_group as a trigger and all six required contexts live in ci.yml + lint.yml — the Governed Surface Queue Guard is not a required context. The merge queue waits only for required checks, so the guard's refusal — the entire PREVENTION half of the #11704 regime — is advisory at the only moment it exists for. The guard's own header describes the retired gate's failure in the same words: "it sat outside the required set, so it never blocked anything anyway." The prevention half has inherited the disease it was built to replace.

Ruled out by measurement

• Register over-match: node scripts/pm/check-governed-merges.mjs --test .claude/agents/os-dev.md → ⛔ GOVERNED, .claude/** ×1. The shared register classifies correctly.
• PR-level early-warning green: by design (the 2026-08-18 红灯常态化 ruling), not a defect.
• The [finding] skills/*/references/_index.md is generator-owned (gen:skill-refs) yet sits inside the skills/** governed-merge fence — every spec PR touching an indexed headline is forced to carry a governed-surface file #11705/[Decision] 新增任何手写文档页都必须改一个 .claude/ 生成物，于是每张文档卡都变成人工合并 —— 这一条要不要开机械化例外 #10277 generated-artifact exceptions: not involved (the path is hand-authored .claude/**).

The remedy (maintainer-only, one Settings visit)

Add the Governed Surface Queue Guard check context to the required set on the main ruleset. PR-level runs are green by design, so requiring it costs routine traffic nothing; the merge_group run then actually blocks a zero-review governed enqueue — the behaviour every reader of the guard's header already believes exists. ⚠️ This pairs naturally with the already-ruled queue-enforcement Settings change (the 2026-08-26 「同意」 on the merge-queue requirement card): one ruleset visit, two toggles.

Same-window instances of the same shape: PR #12406 and #12407 were also flipped+enqueued by the shared identity at 02:05Z (the #12406 diff is likewise governed, zero reviews at enqueue time). Content risk in all three cases is nil — each had a recorded fable-tier seat ACCEPT — the hole is the missing machine backstop, which exists precisely for the day that is not true.

Refs: the guard's own header (scripts/pm/check-governed-queue-guard.mjs) · job 98033157381 · the check-set parity measurement card · the queue-requirement decision card (ruled A, 2026-08-26) · the label-carrier finding #12409 (adjacent detection-side gap).

[os-steve]

Actor question CLOSED — maintainer confirmed. Maintainer, 2026-08-26, live PM chat, verbatim: 「合并审计 确认」 — the three flip+enqueue actions (PR #12402 at 01:51Z; PR #12406/#12407 at 02:05Z) are confirmed as the maintainer's own/ordered. Under the #9495 regime that confirmation IS the review record for all three merges; no incident. The governed-merges audit ledger for this window is clean-by-recognition.

What remains open on this card is exactly the machine gap: the Governed Surface Queue Guard's merge_group refusal is not in the required check set, so the day an enqueue is NOT the maintainer's, nothing blocks it. Remedy unchanged (one Settings visit, two toggles, pairs with the already-ruled queue-requirement change).

---

Generated by Claude Code

[os-trump]

Triage (session session_01U5PBH8288Q1MZ63Z6QWHZp): state set to pm:awaiting-maintainer + domain:skills, type Bug.

Rationale: the actor half is closed by the maintainer's own confirmation (comment above — no incident, audit clean-by-recognition). What remains is only the machine gap, and its sole remedy is a maintainer-side manual operation outside repo content: add the Governed Surface Queue Guard context to the required set on the main ruleset (one Settings visit, pairing with the already-ruled queue-requirement toggle). The decision content is not new — governed surfaces requiring human review is standing policy (the 2026-08-08 / 08-11 / 08-18 ruling line), and this guard was approved precisely to enforce it — so this is a done-decision awaiting one manual act, which is what pm:awaiting-maintainer encodes; it is deliberately NOT in the decision inbox.

Exit condition: the label comes off (and this card closes) when the guard's merge_group context is observed in the required set — e.g. a subsequent governed PR shows the guard as a required check, or the ruleset itself is read.

p0-suspect note: content risk in the three same-window merges was nil (each carried a fable-tier seat ACCEPT plus the maintainer's audit confirmation). The p0 framing attaches to the unguarded FUTURE case — an enqueue that is not the maintainer's — which is why this stays open and flagged in round reports rather than dispatched or downgraded.

---

Generated by Claude Code