_GOVERNANCE_RULES in .github/scripts/test_release_lib.py pins load-bearing sentences in the release skill by asserting a set of anchor tokens is present. A rule fires only when all its tokens are present, so it can detect its own deletion only if at least one token disappears entirely when the protected sentence goes.
Six rules have no such token — every anchor also occurs elsewhere in the file, so the guarded sentence can be deleted and the rule stays green:
| rule |
anchors (occurrences in the source skill) |
footer BLOCK / never-auto-fill |
CHANGELOG: ×7, auto-fill ×2 |
publish read-back |
gh release view ×3, non-draft ×4 |
immutable-tag hard rule |
published tag is immutable ×2 |
pre-tag BLOCK-on-nonzero |
pre-tag ×8, non-zero exit ×4, BLOCK ×11 |
HIGH-1 (re-run): tag_sha is peeled… |
git rev-parse ${TAG_PREFIX}MAJOR.MINOR.PATCH ×2, peel-tag ×2 |
HIGH-2 (re-run): back-fill declares latest-eligible… |
latest-eligible: true\`` ×5, single-target` ×3 |
How this surfaced
While mutation-testing the run-4 rules, the --cleanup=verbatim rule survived its mutant. It was anchored on the bare flag, which occurs once in the git tag command and once in the sentence explaining the flag. Deleting it from the command — the only place it does anything — left the explanatory mention behind, and the rule stayed green.
That rule is now re-anchored on -F <message-file> --cleanup=verbatim and its mutant dies. The six above are the same defect class, pre-existing.
Also worth fixing: the verification habit
The manual uniqueness check used to date was grep -c, which counts matching lines. Phase 2 step 1 of the release skill is a single line thousands of characters long, so two occurrences on it report as 1. Every "verified unique" claim made with grep -c against that file is unreliable. Occurrence counting (grep -o | wc -l, or str.count) is the only form that discriminates.
Current state
GovernanceSurvivalTest.test_every_rule_has_at_least_one_uniquely_occurring_anchor enforces the invariant as a ratchet: the six are declared in _KNOWN_WEAK_ANCHORS, and the test fails in both directions — a newly-weak rule is caught, and a repaired one must be removed from the set. New rules must be sound from the start.
Fixing these six means finding a span unique to each protected sentence. That is prose work on a dense file, deliberately not rushed into a HIGH-remediation commit.
_GOVERNANCE_RULESin.github/scripts/test_release_lib.pypins load-bearing sentences in the release skill by asserting a set of anchor tokens is present. A rule fires only when all its tokens are present, so it can detect its own deletion only if at least one token disappears entirely when the protected sentence goes.Six rules have no such token — every anchor also occurs elsewhere in the file, so the guarded sentence can be deleted and the rule stays green:
footer BLOCK / never-auto-fillCHANGELOG:×7,auto-fill×2publish read-backgh release view×3,non-draft×4immutable-tag hard rulepublished tag is immutable×2pre-tag BLOCK-on-nonzeropre-tag×8,non-zero exit×4,BLOCK×11HIGH-1 (re-run): tag_sha is peeled…git rev-parse ${TAG_PREFIX}MAJOR.MINOR.PATCH×2,peel-tag×2HIGH-2 (re-run): back-fill declares latest-eligible…latest-eligible: true\`` ×5,single-target` ×3How this surfaced
While mutation-testing the run-4 rules, the
--cleanup=verbatimrule survived its mutant. It was anchored on the bare flag, which occurs once in thegit tagcommand and once in the sentence explaining the flag. Deleting it from the command — the only place it does anything — left the explanatory mention behind, and the rule stayed green.That rule is now re-anchored on
-F <message-file> --cleanup=verbatimand its mutant dies. The six above are the same defect class, pre-existing.Also worth fixing: the verification habit
The manual uniqueness check used to date was
grep -c, which counts matching lines. Phase 2 step 1 of the release skill is a single line thousands of characters long, so two occurrences on it report as1. Every "verified unique" claim made withgrep -cagainst that file is unreliable. Occurrence counting (grep -o | wc -l, orstr.count) is the only form that discriminates.Current state
GovernanceSurvivalTest.test_every_rule_has_at_least_one_uniquely_occurring_anchorenforces the invariant as a ratchet: the six are declared in_KNOWN_WEAK_ANCHORS, and the test fails in both directions — a newly-weak rule is caught, and a repaired one must be removed from the set. New rules must be sound from the start.Fixing these six means finding a span unique to each protected sentence. That is prose work on a dense file, deliberately not rushed into a HIGH-remediation commit.