1,073 byte-identical Optimus-Branch.json replicas are a STALE, WEAKER policy than the canonical — and the design doc's canonical pointer does not resolve

[hyperpolymath]

Summary

Optimus-Branch.json exists 1,076 times in the local estate. 1,073 of them are byte-identical (single sha256, 706B) and all sit at .github/rulesets/Optimus-Branch.json — a path GitHub does not read. Rulesets are API/UI objects; a JSON file committed at that path is applied by nothing unless a script applies it.

That alone would be tidiness. The reason this is filed is the next measurement: the 1,073 replicated copies are a STALE, WEAKER policy than the canonical one. If any applier ever consumes a copy, it downgrades the ruleset rather than failing.

All figures re-measured 2026-09-14T22:0xZ. An earlier carried figure of "79 files" was wrong by 13x — it was the scope of the 09-02 design doc, not the population on disk.

The population

Variant	sha256 (12)	Bytes	Count	Path shape
replicated	712e66e7aea1	706	1,073	.github/rulesets/Optimus-Branch.json
canonical	800699d2f357	1,022	2	standards/config/rulesets/, worktrees/standards-ws0-taxonomy/config/rulesets/
one-off	a322fcb54a28	1,014	1	hermeneia/.github/rulesets/

Distribution of the 1,073: hyper-repos/ 517, archive/ 425, meta-repos/ 79, tools/ 27, gists/ 23, dev-notes/ 2, oikosbot-estate/ 1, .github/ 1.

The actual hazard: the replicated copy is the weaker policy

diff of a 706B copy against the 1,022B canonical — the canonical has everything the copies have, plus:

>         "require_extra_approval_for_unattributed_changes": true,
>         "required_reviewers": [],
>     {
>       "type": "required_status_checks",
>       "parameters": {
>         "strict_required_status_checks_policy": true,
>         "do_not_enforce_on_create": false,
>         "required_status_checks": []

So the 1,073 copies are missing the unattributed-changes approval requirement and the entire required_status_checks rule block. Both carry bypass_actors: [], 2 approvals, code-owner review, required signatures, squash-only — which is why a human diffing casually reads them as "the same strict ruleset".

The design doc lists eight applier scripts (§7.4, seven of them slated for retirement). An applier pointed at a stale copy would silently weaken governance while reporting success. This is the estate's recurring shape: the failure looks like a success.

Inertness — what was measured, and what was not

Measured:

• GitHub does not read rulesets from repo files, so .github/rulesets/ is not a live surface.
• A bounded grep for \.github/rulesets, config/rulesets, rulesets/Optimus over standards/, .git-private-farm/, tools/, .github/, dev-notes/ (*.sh *.yml *.yaml *.py *.mjs justfile) returned exactly one hit: standards/tests/test_governance_reusable_shape.sh.
• That one consumer reads config/rulesets/gates.json — not Optimus-Branch.json — and the test is itself named by no workflow and no justfile (only by gates.json and a design doc). So the sole consumer is an inert guard, the defect class already tracked estate-wide.

Not measured, stated rather than assumed: the sweep was bounded to the governance and automation trees. The tree holds 1,000+ repos, so a consumer could exist in a repo I did not open. The claim is no consumer found in the places automation lives, not no consumer exists.

Two adjacent defects found while measuring

1. The design doc's canonical pointer does not resolve. §7.4 states "canonical lives in standards/rulesets/base.json". That path is MISSING. The real file is standards/config/rulesets/base.json (1,909B). A doc naming a canonical path that 404s is worse than naming none — it reads as authoritative. Same class as a dead resume pointer.
2. A case-duplicate pair with different content in the canonical directory: immutable-tags.json (542B, 104f0a5bdf41) and Immutable-Tags.json (332B, f2f337929e3c) — not a case-insensitive filesystem artefact, genuinely different bodies. Which is authoritative is undetermined. On a case-insensitive checkout one silently shadows the other.

Prior art, and why this is filed anyway

The 09-02 design doc already ruled committed ruleset directories "archive only". That ruling is correct and this issue does not dispute it. It is filed because the ruling was scoped to meta-repos/*/.github/rulesets/ — 79 of the 1,073 files, i.e. 7%. The other 993 were never in scope, and nothing stamps them non-authoritative, so nothing prevents an applier or a future agent from treating one as the source.

Requested fix — at the generator, not the 1,073 instances

1. Single-source the canonical and correct §7.4's path to config/rulesets/base.json so the pointer resolves.
2. Stamp or remove the replicas. Either delete them, or add a "_archive": true / header comment so a reader and a script can both tell a copy from the source. Deletion of 425 under archive/ is uncontroversial; the 517 under hyper-repos/ are live repos and are an owner call.
3. Make the appliers refuse an unstamped file — an applier must resolve the canonical by a single declared path and fail closed if it does not resolve, rather than accepting whatever JSON it is handed. This is the same fail-closed rule adopted for name-keyed ruleset guards (an id-keyed guard goes inert silently; 14285635 protected nothing once the ruleset was recreated).
4. Resolve the case-duplicate pair and assert one ruleset name maps to one file.

Read-only note on an open PR — not acted on

standards#789 deletes config/rulesets/Optimus-Branch.json — i.e. one of the two canonical copies — while all 1,073 stale replicas remain on disk. Flagging the interaction only; that PR is another session's surface, merge-nothing is in force, and nothing here touches its paths. Separately: deleting a declaration does not undeploy the live object. standards currently carries two active rulesets, 18110117 Immutable-Tags and 23359343 Optimus-Branch; removing a JSON file changes neither.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD

[hyperpolymath]

Four updates, two of which change what this issue asks for

1. The inertness finding is now confirmed by a second, independent grep

Another session (working config/rulesets/ hygiene) reports, and I verified both lines myself rather than relaying: there is no committed applier in standards that globs config/rulesets/. The only glob-ish matches iterate rulesets returned by the API, not files in the directory:

• scripts/cicd-census.sh:97 → for rs in r["rulesets"]["nodes"]:
• scripts/check-gate-tiers.sh:105 → for ID in $(gh api "repos/$R/rulesets" -q '.[].id' …)

So the inertness claim in the issue body rests on two independent sweeps now, not one.

This restates requested fix (3). "Make the appliers refuse an unstamped file" cannot land in standards, because standards contains no applier. The eight appliers named in the 09-02 design doc §7.4 live in other repos (git-scripts, personal-sysadmin, conative-gating, echidnabot, launch-scaffolder, .git-private-farm). The fail-closed assertion belongs there, and the doc's own plan to retire seven of the eight is the cheapest place to add it — one surviving applier, one canonical path, one assertion.

A second consequence, in the other direction: since nothing in-repo globs the directory, nothing in-repo will ever re-deploy a deleted declaration either. Removing a replica is safe hygiene; it is also not a cure. Both halves are true and the issue should not be read as claiming otherwise.

2. Open question (2) — the case-duplicate pair — is RESOLVED

config/README.adoc:32 documents only rulesets/immutable-tags.json (lowercase), and grep 'Immutable-Tags' config/*.adoc returns zero. Verified here.

So the repo's own canon names the lowercase file and has never named the capitalised one. immutable-tags.json (542B) is authoritative; Immutable-Tags.json (332B) is undocumented. That question can be struck from this issue — and standards#794 (another session's PR) deletes the capitalised file, which is the right direction.

3. A nuance that makes the stale-policy finding STRONGER, not weaker

config/README.adoc:119 documents that immutable-tags.json deliberately drops the live copy's required_status_checks, required_deployments and required_linear_history — "none can be satisfied at tag-creation time, which is why no workflow in the estate could create a tag."

That reasoning is correct for a tag ruleset. It does not transfer to Optimus-Branch, which is a branch ruleset ("target": "branch", ~DEFAULT_BRANCH) where required_status_checks is perfectly satisfiable by a pull request.

But the documented precedent is exactly what makes this dangerous: the estate now has a written, correct justification for omitting required_status_checks from a committed ruleset — so the same omission in the 1,073 branch-ruleset replicas reads as intentional to anyone who knows the tag case. A reviewer who has internalised §"Tags and the App credential" will see the 706B body and infer the omission was on purpose.

This is the argument for stamping the replicas machine-readably (requested fix 2) rather than relying on a reader distinguishing a deliberate omission from a stale one. A human cannot tell those apart by reading; a "_archive": true field lets both a human and a script tell.

4. A suspected grep coverage gap was measured and REFUTED — recorded so it is not re-raised

Carried into this window was a suspicion that a prior rulesets-consumer search had covered *.sh/*.py/*.mjs/*.ts but omitted *.yml, and had therefore possibly missed a consumer in a workflow file. It was going to be filed as a third discovery.

Measured: the gap does not exist. A single-pass grep -rIl 'rulesets' over standards + .git-private-farm returns 32 files — *.sh 10, *.adoc 8, *.yml 4, *.json 4, then singletons. All four *.yml hits are incidental prose, not consumers:

File	Line	What it actually is
standards/.github/workflows/codeql.yml	22	a # comment mentioning estate branch rulesets
standards/.github/actions/signed-push/action.yml	5	a description: mentioning required_signatures
.git-private-farm/.github/label-aliases.yml	129	a spot-read note in an alias description
.git-private-farm/.github/labels.yml	57	the governance label's description text

Zero of the four call the API or read the directory. A search omitting *.yml would have lost nothing. So there is no coverage-gap defect and none is filed.

It is recorded here rather than dropped silently because an unrecorded suspicion gets re-raised by the next session, and because the general rule is worth stating: a remembered coverage gap must be re-measured before it is filed. Filing this one on recollection would have produced a confident issue about a defect that does not exist — which is the same failure as asserting a stale number, just in the other direction.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD

---

5. Addendum — the bounded-sweep limitation named in the issue body is now CLOSED

The issue body states the inertness claim honestly as "no consumer found in the places automation lives, not no consumer exists", because the sweep did not cover the whole 1,000-repo tree. That widest search has now run (backgrounded, whole of developer/):

• *.sh 42 files reference the rulesets API (vs 10 in the bounded sweep) — consistent with the eight appliers named in design doc §7.4 living outside standards.
• *.yml 5 files — but these are five copies of one file: hypatia/.audittraining/prevention/branch-protection-enforcer.yml (plus two .claude/worktrees/ copies, one _GITHUB_INBOX_REMEDIATION_SET copy and one quarantined copy).
• *.py, *.mjs, *.ts, *.js, *.yaml, *.just, *.rb: zero.

That one candidate was examined and is not a consumer of the committed files:

31:  RULESETS=$(gh api "repos/$REPO/rulesets" --jq 'length' 2>/dev/null || echo "0")

It queries the API, never reads .github/rulesets/. So the inertness finding survives the widened sweep — nothing anywhere in the tree reads the 1,073 replicas.

A third instance of the inert-guard class fell out of this, and it is worth its own attention: branch-protection-enforcer.yml is not under .github/workflows/. It is under .audittraining/prevention/, so GitHub never loads it and it has never run. A workflow whose entire purpose is to fail when a repo has no branch protection has been sitting inert in hypatia and in four copies of hypatia. Same shape as a gate inside a startup-dead workflow, and as a just recipe named by no workflow.

To its credit it fails in the safe direction: || echo "0" means an auth failure yields 0 rulesets and it emits ::error::No branch protection or rulesets configured! — a false alarm, not a fake green. That is the correct polarity; the defect is purely that it never executes.