code_scanning trim applied to hyperpolymath (77/77); metadatastician blocked by ONE inherited org ruleset, not 67 repos

[hyperpolymath]

Summary

The estate-wide code_scanning threshold trim ruled on in #1004 has been applied to
hyperpolymath/* in full. It cannot be completed for metadatastician/* by this
session, for a reason that turned out to be structural rather than incidental, and
that also corrects two published census figures.

Ruling implemented: trim code_scanning thresholds from all / all to
errors / high_or_higher, keeping every tool and changing nothing else.

Results

Owner	Outcome	Rulesets	Distinct repos
hyperpolymath (User)	TRIMMED	55	55
hyperpolymath (User)	ALREADY at target	22	22
metadatastician (Org)	TRIMMED (repo-level)	4	4
metadatastician (Org)	BLOCKED — 404 on repo endpoint	67	67
metadatastician/canonical-ums	BLOCKED — 403, repository archived	2	1
		150 rows

Repos enumerated live: 459. Zero refusals by the exactness guard; zero drift; zero
partial writes.

⚠ The 67 failures are not 67 problems — they are one

Every 404 carries the same ruleset id, 18225024. That is the signature of an
organisation-level ruleset inherited by every repo:

$ gh api users/metadatastician --jq .type
Organization

$ gh api repos/metadatastician/burble/rulesets/18225024 \
    --jq '"\(.name) source=\(.source) source_type=\(.source_type)"'
EstateBranching source=metadatastician source_type=Organization

EstateBranching is scoped repository_name: ~ALL / ref_name: ~DEFAULT_BRANCH and
carries code_scanning with CodeQL at alerts_threshold: all,
security_alerts_threshold: all — precisely the blocker being trimmed. It governs
68 repos and is writable only at /orgs/metadatastician/rulesets/18225024.

hyperpolymath is a User account, not an org, so it has no org-level rulesets —
which is why its 77 repo-level rulesets all wrote cleanly. The split is exact and
explains 100% of the failures.

🪤 The trap this exposes, which is the reportable part

An inherited org ruleset is READABLE through the repo endpoint and NOT WRITABLE
there. GET /repos/{o}/{r}/rulesets/{id} returns it, in full, with a repo-shaped
URL — so a dry-run that exercises only GET reports WOULD-TRIM for all 68 repos
and is wrong about every one of them.

That is exactly what happened: the dry-run reported 128 WOULD-TRIM across 123
repos, and 67 of those were a single org ruleset counted once per inheriting repo.
The write, not the read, is where inheritance becomes visible.

A dry-run that only reads cannot prove the write is permitted. The discriminator
is free and should have been in the scope filter from the start:

gh api "repos/$O/$R/rulesets/$ID" --jq 'select(.source_type=="Organization") | .source'

Census corrections (supersedes figures published in #1004)

Figure	Published	Correct	Why
Estate denominator	456	459	Census missed 3 repos, incl. metadatastician/canonical-ums, which carries two affected rulesets. A repo absent from an enumeration produces no row, no error and no warning.
"Double-ruleset repos"	4	5 … but the framing is wrong	burble, gossamer, large-language-michelangelo, _pathroot and canonical-ums each hold a repo-level ruleset in addition to the org-wide one. But every metadatastician repo inherits EstateBranching, so "double-ruleset" was counting inheritance as duplication. The real distinction is repo-level ruleset present: yes/no.

Denominator history for this campaign: 366 → 456 → 459. It is a measurement and it
decays; it should be re-derived live at each sweep rather than carried forward.

What remains, and why I have not done it

1. One org-level write. The payload is built and passes the exactness guard —
normalised diff shows only the two threshold values changing; bypass_actors (9)
preserved, rule types preserved (deletion, required_signatures, pull_request, code_scanning, copilot_code_review), enforcement: active preserved:

$ gh api -X PUT orgs/metadatastician/rulesets/18225024 --input org-put.json

This single call cures all 68 repos. I did not run it: an org-wide settings write is
blocked by the session's auto-mode classifier, and I have not attempted to route
around that. The ruling covers the policy; the mechanism changed from 68 repo
writes to one org write, and the blast radius per call changed with it, so this is
put to you rather than assumed.

2. metadatastician/canonical-ums is archived and read-only (HTTP 403 on both its
rulesets). Trimming it requires unarchiving, which is your call, not mine. Left as-is
and reported.

Method

• Targets derived from live gh repo list enumeration, not from census.tsv —
  which is how the 3-repo gap was caught at all.
• Scope filter: target=="branch" and enforcement=="active", carrying any
  code_scanning tool at all.
• Transform flips only the literal "all"; every other value is passed through.
• Exactness guard before every write: the live body and the payload are both
  normalised with the threshold fields blanked, and the write is refused unless the
  normalised forms are byte-identical. Proven by four killed mutants before the
  first live call.
• Post-write re-GET asserts the rule-type set, bypass_actors, and that zero
  all thresholds remain.
• Positive control carried throughout: hyperpolymath/rsr-template-repo (already at
  target) reported ALREADY on every pass. ⚠ Note the control proved the transform
  and could not prove the population — the missing repos were invisible to it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR

[hyperpolymath]

✅ Complete — both blockers cleared

1. The org-level ruleset

One PUT /orgs/metadatastician/rulesets/18225024, and all 68 inheriting repos are
cured.

$ gh api orgs/metadatastician/rulesets/18225024 --jq '.rules[]
    | select(.type=="code_scanning") | .parameters.code_scanning_tools[]
    | "\(.tool) alerts=\(.alerts_threshold) sec=\(.security_alerts_threshold)"'
CodeQL alerts=errors sec=high_or_higher

Verified after the write: enforcement: active unchanged, bypass_actors still 9,
all five rule types intact (deletion, required_signatures, pull_request, code_scanning, copilot_code_review), scope still ~ALL / ~DEFAULT_BRANCH, zero all thresholds
remaining. Propagation confirmed by reading it back through an inheriting repo —
metadatastician/burble reports the trimmed values.

2. canonical-ums

Unarchived → trimmed → verified → re-archived. Only one of its four rulesets was
repo-level (20999299 Optimus-Branch); the other three are org-inherited and were
already cured by the write above.

  CodeQL   alerts=errors  sec=high_or_higher
  Hypatia  alerts=errors  sec=high_or_higher

archived=true re-confirmed by GET after the sequence. bypass_actors 9 and all ten
rule types preserved.

Final state

Owner	Repos	Outcome
hyperpolymath (User)	77	55 written + 22 already at target
metadatastician (Org)	68	cured by one org-level write
metadatastician repo-level	5	burble, gossamer, large-language-michelangelo, _pathroot, canonical-ums

Zero all thresholds remain on any active branch ruleset in the estate. Zero
exactness-guard refusals, zero drift, zero partial writes.

⚠ Flagged, not acted on

canonical-ums's Optimus-Branch carries three of the four retired rule types —
code_quality, code_coverage and update — alongside a merge_queue rule. Stripping
retired rules was ruled for rsr-template-repo specifically (#195), not for this
sweep, so I trimmed the thresholds only and left the rule set alone. Raising it here
rather than widening scope on my own judgement.

Note code_coverage on that ruleset is unsatisfiable by construction: the estate
pipeline appends its coverage table to $GITHUB_STEP_SUMMARY and uploads nothing to
GitHub, so no coverage figure can ever be observed. See the new
docs/PIPELINE-AND-HOOKS-SUMMARY.adoc (#1012).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR