Estate census: 124 of 456 repos carry retired or unsatisfiable ruleset rules (report only)

[hyperpolymath]

Estate census: ruleset rules that are retired or cannot be satisfied

Owner ruling for this work was census the estate, report only. No ruleset was
written, updated or deleted. Every call was a GET.

Denominator

	Count
Non-archived repos across hyperpolymath + metadatastician	456 (389 + 67)
Rows measured	456
Rows UNKNOWN (unreadable)	0

⚠ A correction to an earlier figure. An earlier pass reported the estate as
366 repos. That number came from gh repo list --limit 300, which returned
exactly 299 for hyperpolymath — a silent truncation at the limit. Re-run at
--limit 1000 the true count is 456. The earlier 366 should not be used.

The census was designed to mark private repos UNKNOWN (never CLEAN) if the
rulesets endpoint returned 403. In practice zero rows were UNKNOWN, because
the credential can read private rulesets — verified directly against a private
repo scored CLEAN: HTTP/2.0 200 OK, 2 rulesets returned. That repo is
genuinely clean under the filters (its branch ruleset is disabled; its other
ruleset targets tags). So CLEAN here means measured-and-clean, not
could-not-look.

Scope filters (and why)

Only rulesets with target = branch and enforcement = active are
counted.

• update is legitimate on a tag ruleset, so counting it estate-wide
  would be a false positive.
• A disabled ruleset has no teeth and cannot block anything.

Results

Verdict	Repos
CLEAN	330
AFFECTED	124
NO_RULESETS	2

Positive control. hyperpolymath/rsr-template-repo is known-affected and was
carried through the run as a known-answer control. It is reported AFFECTED.
Had it come back CLEAN, every clean verdict in this table would be worthless.

The two populations are very different

Of the 124 AFFECTED, only 7 carry a genuinely retired rule type. The other
117 are affected solely by code_scanning at alerts_threshold: all.

A. Retired rule types — 7 repos

These carry one or more of code_quality, code_coverage,
required_deployments, update on an active branch ruleset. These are the four
types scripts/plan-ruleset-constraint-repair.rb lists as RETIRED.

Repo	Private	Retired/unsatisfiable rules present
hyperpolymath/conative-gating	no	update
hyperpolymath/-REPO-	yes	code_quality, code_coverage, required_deployments, code_scanning@all
hyperpolymath/rsr-template-repo	no	code_quality, code_coverage, code_scanning@all
metadatastician/burble	no	code_quality, code_coverage, code_scanning@all ×2
metadatastician/gossamer	no	code_quality, code_coverage, required_deployments, code_scanning@all ×2
metadatastician/large-language-michelangelo	no	code_quality, code_coverage, code_scanning@all ×2
metadatastician/_pathroot	no	code_quality, code_coverage, required_deployments, code_scanning@all ×2

(×2 means two separate active branch rulesets each contribute the flag.)

Why code_coverage and code_quality cannot be satisfied here. The binding
pipeline spec's coverage job uses no external coverage service — it appends a
markdown table to $GITHUB_STEP_SUMMARY. Nothing is ever uploaded to GitHub, so
a minimum_coverage threshold is unreachable by design. This is the vacuous
gate's mirror image: a gate that can never say yes.

B. code_scanning at threshold all — 117 further repos

alerts_threshold: all blocks a merge on any open alert of any severity,
including warning and note. This is not retired and is not invalid — it is a
policy choice — but at this threshold it will block merges on advisory findings
rather than on real defects, across a quarter of the estate.

This is flagged, not condemned. A gate that blocks on real findings is
working as intended; the question for the owner is whether all is the intended
severity floor on 117 repos.

C. No rulesets at all — 2 repos

Repo	Private
hyperpolymath/evil-weevil	yes
hyperpolymath/repo-guardian	no

These have no ruleset protection on any branch.

Method

Read-only script, GET only, one repo per iteration (no for loop — the shape
is denied by policy), carrying the positive control described above. Per repo:

gh api "repos/$slug/rulesets"                # list
gh api "repos/$slug/rulesets/$id"            # detail, per ruleset
  -> skip unless .enforcement == "active"
  -> skip unless .target      == "branch"
  -> collect [.rules[]?.type]
  -> flag code_scanning where any
     .parameters.code_scanning_tools[].alerts_threshold == "all"

Output rows: slug <TAB> {UNKNOWN|NO_RULESETS|CLEAN|AFFECTED} <TAB> private=… <TAB> flags <TAB> all-rule-types.
No duplicate slugs were emitted (checked with cut -f1 | sort | uniq -d).

Acceptance criteria

• Owner decides whether the 7 retired-rule repos should be repaired, and by
  what mechanism. Note that scripts/plan-ruleset-constraint-repair.rb
  refuses to plan a repair for a repo with no pull_request rule
  (ArgumentError: Missing pull-request protection) — see rsr-template-repo: no ruleset requires pull requests on any branch #1003. That guard
  is correct; the cure is to add the missing protection, not bypass it.
• Owner decides whether code_scanning alerts_threshold: all is the
  intended severity floor across 117 repos, or should be trimmed.
• Owner decides whether evil-weevil and repo-guardian should have
  branch protection at all.
• Any repair is applied by a sanctioned, tested applier — not by hand-crafted
  PUT bodies that bypass the planner's precondition.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR

[hyperpolymath]

Clarification: the blast radius of a code_scanning trim is 123 repos, not 117

The figures in the issue body are correct as written, but two different numbers
are in play and the decision hinges on which one you mean:

Figure	Meaning	Value
Repos affected solely by code_scanning@all	population B in the body	117
Repos carrying code_scanning@all at all	117 + 6 of the 7 retired-rule repos	123
Flag instances emitted by the census	4 repos emit it twice	127

So a decision to trim alerts_threshold would touch 123 repositories. The 6
overlapping repos are every retired-rule repo except conative-gating (whose
only flag is update).

Four repos emit the flag twice because they carry two active branch rulesets,
each independently at alerts_threshold: all:

metadatastician/burble
metadatastician/gossamer
metadatastician/large-language-michelangelo
metadatastician/_pathroot

A repair pass on those four must write both rulesets; fixing one leaves the
repo still blocked, and the second ruleset will not announce itself.

Derivation:

awk -F'\t' '$4 ~ /code_scanning@all/' census.tsv | wc -l        # 123 distinct repos
awk -F'\t' '$4 == "code_scanning@all"' census.tsv | wc -l       # 117 solely
awk -F'\t' '{n=gsub(/code_scanning@all/,"&",$4); if(n>1) print $1}' census.tsv

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR

[hyperpolymath]

⚠ Correction to two figures published in this issue

The estate-wide trim ruled on here has now been applied. Running it against a live
enumeration rather than census.tsv corrected two numbers stated above. Full results
and method: #1013.

Figure	Published here	Correct	Why
Estate denominator	456	459	The census missed 3 repos. One, metadatastician/canonical-ums, carried two affected rulesets and would have been left blocked indefinitely.
"Double-ruleset repos"	4	5, and the framing is wrong	The four named here plus canonical-ums. But every metadatastician repo inherits the org-wide EstateBranching ruleset, 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.

Why the miss was invisible

A repo absent from an enumeration produces no row, no error and no warning. The
positive control carried through the sweep (hyperpolymath/rsr-template-repo = already
at target) held on every pass — it proved the transform and was structurally incapable
of proving the population. Those are two different failures and a control only catches
one of them.

A census's denominator is itself a measurement, and it decays. Derive targets from
live GETs at the moment of the sweep; use a stored census only as a cross-check, and
diff the two.

Outcome

hyperpolymath/* is fully trimmed: 55 written, 22 already at target, 77/77, zero
failures. metadatastician/* is blocked by a single inherited org-level ruleset — see
#1013, which also records the read/write asymmetry that made the dry-run overstate its
own reach.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR