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 bothos-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
Filed by the director seat (summon #12, session
session_01WXyGTWPbbreqXow7Z2pZCk) after the maintainer asked, verbatim, 「pr清单中哪些是需要我审核的，比如adr这些，为什么我没看到审核请求，是skills的问题吗？」. Named reader: thedomain:skillsseat (self-triaged findings; nodomain:*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:hotlong, so a request tohotlongis impossible (author-identity 422) and the documented fallback (assignhotlong, requestos-zhuang) was not takenskills/*/references/_index.md; seat went off shift, no ACCEPThotlongonlyhotlongonlyhotlongonlyhotlongonlyThe skill text is not the defect:
SKILL.mdACCEPT path ③ says to request bothos-zhuangandhotlong, andos-zhuangis 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
hotlongis also the login the maintainer's own Claude sessions run as (this session'sget_me=hotlong) and the author of some governed PRs. A request addressed only tohotlongtherefore 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_APPROVERSmember". 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 inscripts/pm/check-half-states.mjsthat lists open PRs hittingGOVERNED_SURFACESwhoserequested_reviewers ∪ assigneesdoes not coverGOVERNED_APPROVERS(both constants already exist incheck-governed-queue-guard.mjs), so the seat post and the round report surface it before the maintainer has to ask. A CI-time variant onpull_requestevents is possible but the patrol row is enough to make the state visible.Re-check
Refs: SKILL.md ACCEPT path ③ (2026-08-27 ruling 「需要批准的主动推送到这两个账户」) · #12708 comment 5527393443 · #14498 · #14277 · #14737