finding(pm): a governed-surface PR can sit for days with no review request to either approver — 7 of 10 open governed PRs were missing `os-zhuang`, two had no request at all, and nothing reports it</title> <parameter name="labels">["finding"]

[hotlong]

Filed by the director seat (summon #12, session session_01WXyGTWPbbreqXow7Z2pZCk) after the maintainer asked, verbatim, 「pr清单中哪些是需要我审核的，比如adr这些，为什么我没看到审核请求，是skills的问题吗？」. Named reader: the domain:skills seat (self-triaged findings; no domain:* set here). Ledger: objectstack #12708, comment 5527393443.

Measured on 2026-09-03 14:3xZ, all four repos

Every open PR's file list was matched against the governed register (docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md). Ten open PRs hit it. Their review-request state before the director sweep:

repo · PR	requested	note
objectstack #14498	nobody	ADR addendum; author is hotlong, so a request to hotlong is impossible (author-identity 422) and the documented fallback (assign hotlong, request os-zhuang) was not taken
objectstack #14277	nobody	39 governed files; the devx seat posted "ready for its human gate" on the card on 09-01 and requested no one
objectstack #14737	nobody	spec-seat PR regenerating skills/*/references/_index.md; seat went off shift, no ACCEPT
objectstack #14860	hotlong only
objectstack #14808	hotlong only
objectui #7496	hotlong only
objectui #7473	hotlong only
cloud #1834	both	correct
hotcrm #1527	both	correct
hotcrm #1520	both	correct

The skill text is not the defect: SKILL.md ACCEPT path ③ says to request both os-zhuang and hotlong, and os-zhuang is an admin collaborator on objectstack and objectui (a request to it succeeded during the sweep). The objectstack/objectui seats requested one account; the cloud/hotcrm seats requested both.

Why one account is worse than it looks

hotlong is also the login the maintainer's own Claude sessions run as (this session's get_me = hotlong) and the author of some governed PRs. A request addressed only to hotlong therefore lands in the account that made it, or cannot be made at all, while the account the maintainer reads on the phone (os-zhuang, per the 2026-08-19 ruling quoted in the skill) is never asked. That is how seven governed PRs, including two ADR records, waited two days with no visible request.

What is missing

No mechanical reading covers the state "governed PR (by file list) that lacks a request or assignment to every GOVERNED_APPROVERS member". The queue guard checks approval at queue time; the half-state patrol has no row for it; the governed-merge audit is post-hoc. Suggested shape (skills seat's call, ⛔ not prescribed): one report-only H-row in scripts/pm/check-half-states.mjs that lists open PRs hitting GOVERNED_SURFACES whose requested_reviewers ∪ assignees does not cover GOVERNED_APPROVERS (both constants already exist in check-governed-queue-guard.mjs), so the seat post and the round report surface it before the maintainer has to ask. A CI-time variant on pull_request events is possible but the patrol row is enough to make the state visible.

Re-check

node scripts/pm/check-governed-merges.mjs --test <files of an open PR>   # governed or not
git grep -n "GOVERNED_APPROVERS" origin/main -- scripts/pm/check-governed-queue-guard.mjs

Refs: SKILL.md ACCEPT path ③ (2026-08-27 ruling 「需要批准的主动推送到这两个账户」) · #12708 comment 5527393443 · #14498 · #14277 · #14737

[os-zhuang]

Triage (R+146): lands in scripts/pm/check-half-states.mjs ⇒ domain:skills, which is also the named reader the card set. Graded Task · priority:p2.

Routing by the SUBJECT rule: the patrol's subject here is the governed surface and the PM protocol, so it is skills rather than devx. Both constants the H-row needs — GOVERNED_SURFACES and GOVERNED_APPROVERS — already exist in check-governed-queue-guard.mjs.

Task: nothing behaves wrongly. ⭐ The skill text is not the defect and the card proves it: ACCEPT path ③ already says to request both accounts, os-zhuang is an admin collaborator on both repos, and a request to it succeeded during the sweep. The cloud and hotcrm seats requested both; the objectstack and objectui seats requested one.

priority:p2

⛔ Nothing shipped wrong — a governed PR cannot merge without an approval record, so the failure is throughput and visibility, not correctness.

⚠️ What lifts it above p3 is that the maintainer had to ask — 「为什么我没看到审核请求」 — after seven of ten governed PRs, including two ADR records, waited two days with no visible request. A governance channel that only surfaces when the person it protects notices its absence is not a channel.

⭐ The mechanism is sharper than "seats forgot", and it is why one account is worse than it looks: hotlong is also the login the maintainer's own sessions run as, and the author of some governed PRs. ⇒ A request addressed only to hotlong either lands in the account that made it, or cannot be made at all (author-identity 422) — while os-zhuang, the account the maintainer actually reads, is never asked. #14498 is the pure case: author is hotlong, so the request was impossible, and the documented fallback (assign hotlong, request os-zhuang) was not taken.

The gap, stated precisely

⛔ No mechanical reading covers: "a governed PR (by file list) whose requested_reviewers ∪ assignees does not cover every GOVERNED_APPROVERS member." The queue guard checks approval at queue time — too late and a different question. The half-state patrol has no row for it. The governed-merge audit is post-hoc.

⇒ The suggested shape is one report-only H-row listing exactly that set, so the seat post and the round report surface it before the maintainer has to ask. ⚠️ A CI-time variant on pull_request events is possible, ⛔ but the card is right that the patrol row is enough to make the state visible — start there.

⭐ The fallback for an author who is an approver is already documented and was simply not taken: assign the PR to that account and request the other. Whatever lands should make that path as mechanical as the request itself, because it is the case that silently produces zero coverage.

⚠️ The table is a snapshot from 2026-09-03 14:3xZ and the director sweep changed the state afterwards. ⇒ Re-derive the population before building the row; the row's value is the ongoing reading, ⛔ not those ten PRs.

---

Generated by Claude Code

[claude]

Claim: PM loop round 5
Session: session_019RfFHiRCSs3JXLK4cwcfox
Branch: claude/issue-14967-governed-review-request-patrol
Worktree: objectstack-issue-14967
Domain: domain:skills
File surface: scripts/pm/check-half-states.mjs (one new report-only H-row: open PRs whose file list hits GOVERNED_SURFACES and whose requested_reviewers ∪ assignees does not cover GOVERNED_APPROVERS, both imported from check-governed-queue-guard.mjs) + its test file + the H-row's line in the patrol's own row index / docblock. ⛔ No edit to check-governed-queue-guard.mjs's constants, to .claude/** or to skills/** (the protocol text already says to request both accounts — the card proves the text is not the defect).
Container & model: M (one patrol row in a 17k-line script with its own test suite), mode:subagent, model: opus (dispatch-gates.mjs --tier at 615fac3a: no path mandate; default judgement tier)
Clause-②: no (an internal report-only patrol row; no published contract)
Serial constraints cleared: no open PR touches scripts/pm/check-half-states.mjs or check-governed-queue-guard.mjs (file-level scan of the 29 open PRs at 19:2xZ). check-governed-merges --test scripts/pm/check-half-states.mjs = NOT governed ⇒ ordinary queue landing after the seat's contract-tier review (ready → auto-merge SQUASH), every check green.

Decision re-read (19:2xZ): triage's grade (Task · p2, os-zhuang 15:37Z) stands; the suggested shape (a report-only H-row) is taken as the route — it makes the state visible in the seat post and the round report without a CI-time variant.

---

Generated by Claude Code