[estate] audit Base ruleset across repos for unsatisfiable rules that force bypass merges

[hyperpolymath]

Context (estate-scope)

hypatia's Base ruleset was found to be 100% bypassed on every merge (decorative) because it contained several structurally-unsatisfiable rules that blocked normal PRs, so everything was force-merged via bypass. Fixed in hypatia today by pruning/replacing those rules; first genuine non-bypass merge confirmed (#469).

The same Base ruleset pattern is very likely replicated across many estate repos. Each unsatisfiable rule forces bypass merges, which silently defeats the ruleset's protection.

Unsatisfiable-rule patterns to audit per repo

1. required_deployments: [github-pages] — the pages deploy only runs post-merge, so it can never be satisfied pre-merge → blocks all PRs.
2. code_scanning rule requiring a tool that produces neutral on non-code PRs (CodeQL) → blocks all docs/config PRs. Prefer gating via required_status_checks contexts.
3. code_scanning requiring Scorecard — Scorecard uploads 0 analyses (estate-wide startup_failure).
4. copilot_code_review — only satisfiable if Copilot code review actually runs.
5. code_quality (preview) — only if it emits results.

Action

Audit each repo's active rulesets for the above; remediate per-repo with owner sign-off (this is governance config — do not blanket-change). Track which repos were 100%-bypass before/after via the rule-suites API (result: bypass vs pass).

[hyperpolymath]

Governing principle for this audit (process/product plane split)

This audit now has a conceptual backbone. The bypass-forcing rules all share one defect: a gate (merge admission) asserting a product outcome. The rule to apply repo-by-repo:

A gate may assert only what is true of the candidate change at decision time. Outcomes are reconciled out-of-band; they never block admission. Forbidden edge: Gate → Outcome.

Mechanically lintable (turns this from manual audit → recurring check)

Flag any active ruleset rule whose satisfaction depends on post-merge or repo-wide state:

• required_deployments (deploy is post-merge)
• code_scanning as a rule where the tool returns neutral on non-code PRs (CodeQL) → move to required_status_checks contexts instead (neutral-tolerant)
• code_scanning requiring a tool that uploads 0 analyses (e.g. Scorecard / startup_failure)
• copilot_code_review / code_quality unless those features actually produce results
• any rule satisfied by repo-wide state (e.g. "zero open alerts") rather than diff-scoped state

Triage signal per repo

gh api repos/OWNER/REPO/rulesets/rule-suites — if every recent entry is result: bypass, the ruleset is decorative (every merge bypassed). Compare before/after remediation; target a genuine result: pass.

Caveats (carry these into every repo)

• Owner sign-off per repo — this is governance config; do not blanket-change.
• Owner pushes always show bypass (RepositoryRole bypass actor), so you cannot read per-rule pass/fail from owner merges — probe with a real green PR's mergeStateStatus.
• Diff-scoped product checks (e.g. CodeQL-on-changed-lines) are legal gates; only repo-wide / post-merge assertions move to reconciliation.

Full write-up + alternative mental models (control/data plane, hermetic-build, ToC; why supply-chain is a partial fit): dev-notes/2026-06-13-process-product-plane-split.adoc. Companion board change: Project 35 now carries a Plane field (Process/Product/Bridge).

[hyperpolymath]

Production recurrence confirmed (2026-07-03)

The code_scanning unsatisfiable-rule pattern from this audit (items 2–3) is still live and actively deadlocking PRs on estate repos. Verified today via the rulesets API:

Repo	Base ruleset id	code_scanning_tools
odds-and-sods-package-manager	14285488	CodeQL only (already remediated)
standards	14285635	CodeQL + Hypatia + Scorecard ⟵ deadlocked
rsr-template-repo	10892905	CodeQL + Hypatia + Scorecard ⟵ deadlocked

Any PR on the two lagging repos sticks on "Waiting for code scanning results from Hypatia/Scorecard for the commit …" — Hypatia is gated via a status-check context (not a per-PR code-scanning upload) and Scorecard uploads 0 analyses, so neither can ever satisfy a code_scanning rule. This matches the mechanism already fixed on hypatia in #470.

Root-cause note (source is already clean): the canonical provisioner hyperpolymath/git-scripts → scripts/branch-protection-apply.sh builds the Base ruleset with a code_scanning rule listing CodeQL only (thresholds errors/high_or_higher), and its git history never contained Hypatia/Scorecard. The live bad rulesets carry thresholds all/all, so they predate the current script and are stale live state, not a bad template. Re-running that script estate-wide (it PUTs Base in place) would itself remediate the residue. Neither rsr-template-repo nor standards defines rulesets in-tree, and rulesets are not copied by template instantiation — so there is no template file to fix.

A parallel remediation pass is trimming the affected live rulesets to CodeQL-only now; this comment is to (a) confirm the recurrence for the estate audit and (b) record that the durable guardrail already exists in git-scripts (keep the provisioner CodeQL-only; gate Hypatia via required_status_checks contexts as done in #470). No new issue filed — this is fully covered by #470 + #473.

[hyperpolymath]

Status (2026-09-30 issue sweep): reviewed and kept open as a live meta-tracker. Feature/RFC issues were consolidated into the roadmap #886. Root-cause fixes in flight: #883 (scanner build + npx precision), #888 (workflow_audit path anchoring, 0-AI-MANIFEST.deed), standards#1084 (harden-runner in standards-only workflows). Ledger: dev-notes/audits/hypatia-issue-sweep/2026-09-30.md.