rsr-template-repo Base ruleset repaired; 5-8 error-severity alerts remain (threshold semantics undetermined), and copilot_code_review may be a fifth unsatisfiable rule type

[hyperpolymath]

rsr-template-repo Base ruleset repaired — and what still blocks, measured

Closes the #16 workstream. Ruleset 23218684 on hyperpolymath/rsr-template-repo
has been repaired per the owner's ruling. This issue records what was written,
what it fixed, what it did not fix, and one new finding.

What was written — two writes, guard satisfied rather than bypassed

The owner's earlier ruling was "apply the planner output", but the sanctioned
planner refuses on this ruleset:

scripts/plan-ruleset-constraint-repair.rb:31:in 'plan':
  Missing pull-request protection (ArgumentError)

Ruleset 23218684 had no pull_request rule, and the planner requires one. The
owner chose to satisfy that precondition legitimately rather than hand-craft a PUT
around it:

#	Write	Effect
1	Add a pull_request rule, using the parameters from the committed config/rulesets/base.json verbatim	Planner precondition satisfied; live ruleset moves toward the committed template
2	Run the sanctioned planner (rc=0), then hand-trim code_scanning thresholds	code_quality + code_coverage stripped; thresholds lowered

Nothing routed around the guard. The planner validated the real post-write-1
live state, re-fetched from the API — it was not handed a locally-constructed
fiction.

Before → after:

BEFORE  deletion, required_signatures, code_scanning,
        code_quality, code_coverage, copilot_code_review

AFTER   deletion, required_signatures, code_scanning,
        copilot_code_review, pull_request

code_scanning thresholds, all three tools retained per the standing ruling
("keep all three tools, trim thresholds"):

CodeQL    alerts_threshold: all → errors   security_alerts_threshold: all → high_or_higher
Hypatia   alerts_threshold: all → errors   security_alerts_threshold: all → high_or_higher
Scorecard alerts_threshold: all → errors   security_alerts_threshold: all → high_or_higher

⚠ Correction to a figure I published earlier

I previously said the trim would clear "10 of 17 alerts, leaving 1 error + 4 high".
Measured, that was wrong. The repo has 17 open alerts; by the severity field
that alerts_threshold actually keys on, they split 9 warning / 8 error. So
the trim cleared 9, and 8 remain blocking — not 5.

What still blocks, and why that is correct

All four open PRs are still BLOCKED. The causes are now fully measured, and they
are not the ruleset defect:

#193 and #192 — unsigned heads. Both head commits are
verified: false, reason: unsigned, and required_signatures is active. This
block is independent of content and would survive any change. Both PRs are also
fully superseded (every file byte-identical to main), so they are for closing,
not fixing.

#197 and #194 — real security findings. Both heads are verified: true/valid
and both have zero unresolved review threads, so required_signatures and
required_review_thread_resolution are satisfied. What remains is the
8 error-severity code-scanning alerts:

Alert	Tool	Security severity	Rule
148	Scorecard	high	TokenPermissionsID
66	Scorecard	high	CodeReviewID
65	Scorecard	high	MaintainedID
6	Scorecard	high	BranchProtectionID
64	Scorecard	medium	SASTID
63	Scorecard	medium	FuzzingID
67	Scorecard	low	CIIBestPracticesID
147	Hypatia	—	hypatia/root_hygiene/missing

These are real findings and the gate is working. Per the standing instruction,
they are reported for triage — the trim was not widened further, and
code_scanning was not deleted to force green. A gate that blocks on genuine
findings is doing its job; the previous all threshold was the defect, because
9 warnings held the repo shut.

🆕 New finding — copilot_code_review may be a fifth unsatisfiable rule type

scripts/plan-ruleset-constraint-repair.rb:8 lists four retired types:

RETIRED = %w[update required_deployments code_quality code_coverage]

copilot_code_review is not among them, and it survived the repair. But
across the last 100 pull requests in this repository, Copilot has reviewed
zero of them:

coderabbitai              34
hyperpolymath             12
github-advanced-security   6
github-actions             2
Copilot                    0   ← never, in 100 PRs

I have not established whether copilot_code_review actually blocks merge or
merely auto-requests a review. That distinction decides whether this is a fifth
unsatisfiable gate of the code_quality / code_coverage class or harmless
noise, and it should be settled before the estate-wide pass — the census found
this rule type on other repos too.

Deliberately not guessing: code_scanning's 8 error alerts are already a
sufficient explanation for #197/#194 being blocked, so Copilot's contribution
is currently undetermined, not ruled out.

Reproduction

gh api repos/hyperpolymath/rsr-template-repo/rulesets/23218684 > live.json
ruby scripts/plan-ruleset-constraint-repair.rb live.json      # rc=0 after write 1
gh api "repos/hyperpolymath/rsr-template-repo/code-scanning/alerts?state=open&per_page=100" \
  --paginate --jq '.[]|select(.rule.severity=="error")|[.number,.tool.name,.rule.id]|@tsv'

Acceptance criteria

• Decide whether copilot_code_review blocks merge; if it does, add it to RETIRED and re-run the repair.
• Triage the 8 error-severity alerts (4 of them high: token permissions, code review, maintained, branch protection).
• Close feat(governance): add hypatia-scan-reusable.yml — biggest LOC leverage of the reusable trilogy #193 and feat(governance): add codeql-reusable.yml — consolidate 263-repo codeql.yml drift #192 as superseded (both commented with the byte-identical measurement).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR

[hyperpolymath]

⚠ Un-correction — "8 remain" is not established either. The honest figure is 5 or 8, undetermined.

I corrected "5 remain" to "8 remain" in the issue body above. That correction
was not justified by evidence, and I am withdrawing it rather than leaving it to
propagate. 5 is certain; 8 is the upper bound; which one is right turns on a
question I could not settle.

The exact measurement

All 17 open alerts, by the two fields that matter:

rule.severity	rule.security_severity_level	count
warning	NULL	9
error	high	4
error	medium	2
error	low	1
error	NULL	1

gh api "repos/hyperpolymath/rsr-template-repo/code-scanning/alerts?state=open&per_page=100" \
  --paginate --jq '.[]|[.rule.severity,(.rule.security_severity_level//"NULL")]|@tsv' | sort | uniq -c

What is certain

The 9 warnings clear under every reading — they are warning (below
errors) and carry no security severity, so neither axis can catch them. That
half of my correction stands: the all/all threshold was holding the repo shut
on 9 findings that no longer block.

Five alerts block under every reading:

Alert	Tool	severity	security	Rule
148	Scorecard	error	high	TokenPermissionsID
66	Scorecard	error	high	CodeReviewID
65	Scorecard	error	high	MaintainedID
6	Scorecard	error	high	BranchProtectionID
147	Hypatia	error	NULL	hypatia/root_hygiene/missing

What is disputed — exactly three alerts

Alert	Tool	severity	security	Rule
64	Scorecard	error	medium	SASTID
63	Scorecard	error	medium	FuzzingID
67	Scorecard	error	low	CIIBestPracticesID

Each is severity: error (≥ alerts_threshold: errors) but below
security_alerts_threshold: high_or_higher. The two readings:

• Union — an alert blocks if it meets either threshold. These 3 block. Total 8.
• Disjoint — an alert carrying a security_severity_level is a security
  alert governed only by security_alerts_threshold; one without it is
  governed only by alerts_threshold. These 3 clear. Total 5.

Why I could not settle it

The documentation does not say. Neither
available-rules-for-rulesets
nor
set-code-scanning-merge-protection
states which population each threshold governs. The latter lists the allowed
values of both dropdowns and stops there.

No API surface reports which alerts blocked. rulesets/rule-suites records
only push evaluations (every entry on this repo is result: bypass); it does
not decompose a pull request's BLOCKED.

And no threshold setting separates the two readings. That is the part worth
recording. Alert 147 is severity: error with NULL security severity, so
it blocks under every configuration where alerts_threshold != none — under
both readings identically. The 4 high Scorecard alerts block under every
configuration where the security axis is not none. So any experiment that would
isolate the disputed 3 is masked by 147, and the only way to unmask it would be to
dismiss a real finding to run an experiment. I am not doing that.

A structural argument leans toward disjoint — if the axes were a union, setting
Alerts: Errors would block on essentially every CodeQL security alert regardless
of the security dropdown, leaving that dropdown able only to add blockers and
never to relax them, which makes it close to useless. That is an argument, not
evidence, and I am not recording it as a finding.

What this changes

Nothing operational. Both readings agree that:

• the trim strictly shrinks the blocking set (it cleared at least 9);
• docs(audits): estate-wide documentation-debt audit 2026-05-26 #197 and tooling(scripts): add per-template sweep classifiers (#187/#190/#192/#193) #194 remain correctly blocked by real findings either way;
• the triage list is unchanged — the 4 high + Hypatia 147 are the priority,
  and SASTID / FuzzingID / CIIBestPracticesID are worth fixing whether or
  not they currently block.

The acceptance criterion below is amended accordingly.

• Determine empirically whether alerts_threshold and security_alerts_threshold are a union or govern disjoint populations — e.g. on a scratch repo with exactly one error+medium alert and nothing else, where 147's masking effect is absent.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR