Skip to content

[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

Description

@claude

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.

  1. .claude/skills/pm-dispatch/SKILL.md:723

    `CLAUDE.md`;agent 指令文件按此跨仓同判 —— objectui、cloud、objectos 一并在内(2026-08-18 裁定)
    

    This 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 for hotcrm, 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.

  2. .claude/hooks/guard-governed-enqueue.sh:54

    #      the same call answers for all four governed repos.
    

    A 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_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

  1. 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.
  2. 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.

Refs #14867, #14881.

Generated by Claude Code


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions