standards/main has no required status checks — every gate this repo ships is advisory here

[hyperpolymath]

Summary

hyperpolymath/standards — the repository that defines the estate's CI policy — has no required status checks on main, and no rule requiring a pull request at all. Every gate this repo ships and enforces elsewhere is advisory here.

This is why six consecutive PRs merged over a red governance / Debt ratchet (#955) without anyone needing an admin bypass: nothing was ever blocking.

Measured

The authoritative endpoint for what actually applies to a branch is /repos/{owner}/{repo}/rules/branches/{branch} — not /rulesets, which lists rulesets that may target other refs.

$ gh api repos/hyperpolymath/standards/rules/branches/main --jq '[.[].type]|unique|join(", ")'
deletion, non_fast_forward

$ gh api repos/hyperpolymath/standards/branches/main/protection
404 "Branch not protected"

So on standards/main: no required_status_checks, no pull_request, no required_signatures, no classic protection. The only rules are "don't delete it" and "don't force-push it".

Comparison across the estate

repo	effective rules on main	requires checks?
hyperpolymath/standards	deletion, non_fast_forward	no
hyperpolymath/rsr-template-repo	code_coverage, code_quality, code_scanning, copilot_code_review, deletion, required_signatures	no
metadatastician/stapeln	code_coverage, code_quality, code_scanning, copilot_code_review, deletion, merge_queue, pull_request, repository_delete, repository_transfer, repository_visibility, required_deployments, required_signatures, required_status_checks	yes
hyperpolymath/a2ml	deletion, non_fast_forward	no
hyperpolymath/marid	deletion, non_fast_forward	no
hyperpolymath/hypatia	deletion, non_fast_forward	no

stapeln shows the pattern already exists and works:

CodeQL
SonarCloud Code Analysis
governance / Code quality + docs
scan / Hypatia Neurosymbolic Analysis
governance / Validate Hypatia Baseline
analyze (actions, none)

Five of the six sampled repos have no required_status_checks. standards is the least protected of the three policy repos.

Why this matters now — it changes the ci-pipeline rollout

The agreed rollout shape is "repos whose pipeline is green at adoption get the caller blocking; red repos are seeded into a shrink-only ledger."

Adding a caller workflow does not make it blocking. A workflow only blocks a merge when a required_status_checks rule names its check context. Without that rule, the "blocking" arm and the "ledgered" arm are behaviourally identical — both just produce a red X that anyone can merge past. The ratchet would be measuring debt no one is obliged to pay.

This is the vacuous-gate condition: a gate that cannot fail anything is decoration.

Proposed cure

Two parts, both owner decisions:

1. Decide the policy. Should standards/main require (a) a pull request, (b) a named set of status checks, (c) signatures? The stapeln ruleset is a working template. Note that requiring a PR on standards changes the owner's own direct-push workflow, which is a real cost — this is a judgement call, not an obvious yes.
2. Decide what "blocking" means for the rollout. Either the rollout includes adding a required_status_checks rule naming the pipeline context on adopting repos, or the plan should stop using the word "blocking" and describe both arms honestly as advisory-with-a-ledger.

⚠ Both parts are configuration changes to live repositories. Nothing here should be applied without an explicit ruling.

Acceptance criteria

• An owner ruling is recorded on Owner decision sheet D1–D72: one answerable place for #637 + #715 + #709 + #658 and this week's unfiled decisions #787 stating whether standards/main gains a required_status_checks rule, and which contexts it names.
• If yes: gh api repos/hyperpolymath/standards/rules/branches/main --jq '[.[].type]' includes required_status_checks, and a PR with a deliberately failing gate cannot be merged without an explicit bypass.
• The ci-pipeline rollout plan's "blocking where green" language is either implemented via a ruleset rule or reworded to match what it actually does.
• The estate-wide question is measured, not assumed: a full sweep of rules/branches/main across all repos, reporting how many have required_status_checks. The six-repo sample above is not a census.

Related: #955 (the Debt ratchet failure this explains), #787 (decision surface).

[hyperpolymath]

main is gated — 18 required contexts, derived from real runs

Ruleset 23787415 on hyperpolymath/standards now carries a required_status_checks rule. Before this it declared only deletion and non_fast_forward, i.e. zero required checks.

types=deletion, non_fast_forward, required_status_checks
contexts=18

Every context was derived from an actual default-branch run (/actions/workflows/{file}/runs?branch=main&per_page=1 → /actions/runs/{id}/jobs, keeping jobs with integration_id == 15368) — none was typed by hand. All 18 verified integration_id=15368 by read-back:

#	Context
1	analyze-actions / analyze
2	analyze-js / analyze
3	governance / Actions lockfile verify
4	governance / Check Workflow Staleness
5	governance / Debt ratchet
6	governance / Exemption ratchet
7	governance / Guix packaging policy (Nix retired)
8	governance / Language / package anti-pattern policy
9	governance / Licence consistency
10	governance / Security policy checks
11	governance / Trusted-base reduction policy
12	governance / Well-Known (RFC 9116 + RSR)
13	governance / Workflow security linter
14	scan / gitleaks
15	scan / Hypatia Neurosymbolic Analysis
16	scan / rust-secrets
17	scan / shell-secrets
18	SPARK Theatre Gate

Command:

./scripts/apply-branch-gates.sh --repo hyperpolymath/standards --require-green 10 --apply

What was deliberately left out, and why

Excluded by never_required_contexts (3) — governance / Allowlist Preflight, governance / Code quality + docs, governance / Live Actions policy (credentialed advisory). These are advisory by policy; gates.json names them.

Excluded by --require-green 10 (1) — governance / Validate Hypatia Baseline. It is genuinely red on main and is tracked separately. Requiring a check that is already failing would deadlock the branch, so it is held back until it is green rather than trimmed away permanently.

code_quality, code_coverage, required_deployments and update are never emitted — the applier refuses to recreate the retired set that blocked rsr-template-repo#195.

⚠ The first write of this gate was wrong, and the way it was wrong matters

The initial apply wrote 16 contexts, not 18: analyze-actions / analyze and analyze-js / analyze were missing. Not excluded, not filtered — absent.

The cause was a swallowed API error in the derivation loop (2>/dev/null plus .jobs[]? plus an unread exit status), so a transient failure appended nothing and the gate was built from the short list. The run still reported GATED in green. Nothing anywhere said the gate was two checks weaker than intended.

What cracked it: both paths that legitimately drop a context name what they dropped (excluded=[…], not_green=[…]), and neither list mentioned codeql. Absent is not excluded — when a filter built to announce its removals announces nothing, the item died upstream of the filter.

Fixed in #1016, which makes every derivation fetch fail closed and adds a control plus a mutant that writes the shortened gate (18 → 23 controls, 0 failures). The production ruleset has already been re-applied and verified at 18.

A dry-run and an apply run are two independent samples of a flaky API. The dry-run's output is never evidence about the write — only reading back what was written is.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ji1bq3TypfycfUPAR7hSxR