You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] two prose statements of the governed REPO set live outside the register and go stale when #14867 lands — pm-dispatch/SKILL.md:723 and guard-governed-enqueue.sh:54, with no gate on either #14984
Filed by the os-dev seat while implementing #14867 (session session_019RfFHiRCSs3JXLK4cwcfox, branch claude/issue-14867-governed-repos-hotcrm). ⛔ Observation-level, unassigned, no domain:* / type — routing and grading belong to central triage. Out of scope for the #14867 PR by construction: both sites are inside .claude/**, a governed surface, so folding them into that pure-scripts/pm/** diff would fork the PR under Prime Directive #14.
What is wrong
#14867 adds hotcrm to GOVERNED_REPOS in scripts/pm/check-governed-merges.mjs, taking the audited set from four repos to five. Two places outside that file state the set — or its size — in prose, and neither is reached by any gate. Both go stale the moment #14867 lands.
The register is GOVERNED_REPOS and GOVERNED_SURFACES in scripts/pm/check-governed-merges.mjs — AGENTS.md Prime Directive #14 says so explicitly for surfaces, and #14867's ruling establishes the same for repos. pnpm check:pm-governed-prose already reds when the instruction files' surface list drifts from the register, in both directions. There is no equivalent for the repo set: I ran that gate on the #14867 branch and it passes, correctly — its scope is GOVERNED_SURFACES only (scripts/pm/check-governed-prose.mjs:190 maps surfaces to globs, and nothing there reads GOVERNED_REPOS).
So the failure mode is the one this family keeps producing: a seat reads a prose enumeration, treats it as the register, and acts on a set that is one repo short — the exact reading error #14867's own header now warns about for the 2026-08-18 quotation. A PM seat that reads SKILL.md:723 and concludes hotcrm's instruction-file PRs are not on the governed path would reverse the 2026-09-03 ruling by inference.
Two shapes of remedy, not ruled here
Correct the two lines. Cheap, and it is a governed-surface edit, so it needs the human-merge path. Leaves the drift class open — this is the second time the set has grown.
Extend check-governed-prose to the repo set, so the instruction surfaces that enumerate repos are held equal to GOVERNED_REPOS the way they are already held equal to GOVERNED_SURFACES. Needs a decision on which prose statements are in scope — a Chinese enumeration inside a sentence is harder to parse than the glob list the gate reads today, and a parser that guesses wrong reds on correct text.
⚠️ Not asserting which. Grading and routing to central triage.
Duplicate check
Enumerated every open issue in this repo through the REST list endpoint with completeness self-proof (state=open&per_page=100, pages 1–6, last page 18 rows; 499 open non-PR issues) and grepped the titles locally. Positive control in the same reading: governed returns 4 rows including the known-must-hit #14867, so the channel is live and a zero would have been a reading. No open card covers either site. Nearest neighbours, both distinct: #14870 (gate-script comments saying the decision frame has "four" copies — same shape, unrelated subject) and #14967 (governed-PR review requests). ⚠️ Titles only; a card filed under body text I did not grep could exist.
Blocked-by: #14867 — both lines are correct until it lands.
Filed by the
os-devseat while implementing #14867 (sessionsession_019RfFHiRCSs3JXLK4cwcfox, branchclaude/issue-14867-governed-repos-hotcrm). ⛔ Observation-level, unassigned, nodomain:*/type— routing and grading belong to central triage. Out of scope for the #14867 PR by construction: both sites are inside.claude/**, a governed surface, so folding them into that pure-scripts/pm/**diff would fork the PR under Prime Directive #14.What is wrong
#14867 adds
hotcrmtoGOVERNED_REPOSinscripts/pm/check-governed-merges.mjs, taking the audited set from four repos to five. Two places outside that file state the set — or its size — in prose, and neither is reached by any gate. Both go stale the moment #14867 lands..claude/skills/pm-dispatch/SKILL.md:723This is the PM's own operating text for the ACCEPT path-fork. It enumerates the sibling repos in which agent-instruction files are judged governed, and after check-governed-merges has no coverage for
hotcrm, a repo whose AGENTS.md is hand-merged as governed — the audit cannot report a gap it was never pointed at #14867 that enumeration is short by one. The line is the same shape the check-governed-merges has no coverage forhotcrm, a repo whose AGENTS.md is hand-merged as governed — the audit cannot report a gap it was never pointed at #14867 card criticised in the script's header: a derived statement of the set, presented as if it were the register..claude/hooks/guard-governed-enqueue.sh:54A count, in a hook's header, of the repos one call covers. Five after check-governed-merges has no coverage for
hotcrm, a repo whose AGENTS.md is hand-merged as governed — the audit cannot report a gap it was never pointed at #14867.Why it matters
The register is
GOVERNED_REPOSandGOVERNED_SURFACESinscripts/pm/check-governed-merges.mjs— AGENTS.md Prime Directive #14 says so explicitly for surfaces, and #14867's ruling establishes the same for repos.pnpm check:pm-governed-prosealready reds when the instruction files' surface list drifts from the register, in both directions. There is no equivalent for the repo set: I ran that gate on the #14867 branch and it passes, correctly — its scope isGOVERNED_SURFACESonly (scripts/pm/check-governed-prose.mjs:190maps surfaces to globs, and nothing there readsGOVERNED_REPOS).So the failure mode is the one this family keeps producing: a seat reads a prose enumeration, treats it as the register, and acts on a set that is one repo short — the exact reading error #14867's own header now warns about for the 2026-08-18 quotation. A PM seat that reads
SKILL.md:723and concludes hotcrm's instruction-file PRs are not on the governed path would reverse the 2026-09-03 ruling by inference.Two shapes of remedy, not ruled here
check-governed-proseto the repo set, so the instruction surfaces that enumerate repos are held equal toGOVERNED_REPOSthe way they are already held equal toGOVERNED_SURFACES. Needs a decision on which prose statements are in scope — a Chinese enumeration inside a sentence is harder to parse than the glob list the gate reads today, and a parser that guesses wrong reds on correct text.Duplicate check
Enumerated every open issue in this repo through the REST list endpoint with completeness self-proof (⚠️ Titles only; a card filed under body text I did not grep could exist.
state=open&per_page=100, pages 1–6, last page 18 rows; 499 open non-PR issues) and grepped the titles locally. Positive control in the same reading:governedreturns 4 rows including the known-must-hit #14867, so the channel is live and a zero would have been a reading. No open card covers either site. Nearest neighbours, both distinct: #14870 (gate-script comments saying the decision frame has "four" copies — same shape, unrelated subject) and #14967 (governed-PR review requests).Blocked-by: #14867 — both lines are correct until it lands.
Refs #14867, #14881.
Generated by Claude Code
Generated by Claude Code