Repository navigation
Nothing notices when a repo gains CI that gates no merge #3
Description
Filed alongside #2, which documents the ruleset. This is the part the documentation cannot fix by itself.
The gap
blockspec, research and .github have rulesets requiring a pull request, but no required status checks, because none of them has CI of its own yet. That is correct today — requiring a check nothing produces blocks every merge forever.
It is a trap tomorrow. Adding a workflow to a repository does not add it to the ruleset. So the moment blockspec gains a conformance suite, it gains a suite that runs on every PR, goes green or red, and gates nothing. Nobody would notice: the tick appears, the merge proceeds, and the only difference between a passing suite and a suite whose results are ignored is invisible on the PR page.
That is §2.2 exactly — a check that cannot fail reporting a pass — relocated from the code into the repository settings, which is the one place this project has not been looking.
The second-order version
Required checks are matched by job name. Renaming a job does not fail the rule; it makes the rule match nothing. rowspec currently pins four names — conformance, xlsx-extra, passes-on-a-good-tree, fails-on-a-broken-total — and xlsx-extra is nine days old, so the vocabulary is not stable yet.
What would actually close it
Documentation will not, and #2 only writes the hazard down.
- A check that compares the ruleset against the workflows. For each repository, enumerate the job names the workflows define, enumerate the contexts the ruleset requires, and fail on a job that is not required or a required context no job produces. Run it on a schedule and on every change to a workflow file. It is a few lines against two API endpoints, and it is the only form of this that cannot silently stop working.
- An org-level ruleset would cover a new repository automatically, but not a new workflow, so it solves the smaller half.
Acceptance
- A check exists that fails when a workflow job is not in the ruleset, or a required context matches no job.
- Its red state is demonstrated in both directions: add an unrequired job and watch it fail; require a context no job produces and watch it fail.
blockspec,researchand.githubare picked up automatically when they gain their first workflow, rather than depending on someone remembering.
Activity
docs: record what the merge gate enforces, and what it does not
feat: add a check that every pull_request job is a required check (#10)
CameronBrooks11 commentedon Oct 7, 2026
scripts/check_required_checks.pylanded in #10, after three review rounds. Its self-test runs 59 of 59, and its mutation sweep catches 49 of 49 mutants with 0 broken. Live:--public-onlygives 0 findings, and default mode exits 2 because one repository's rules can't be read on the free plan.Still open here:
contents: readand--public-onlywould do it; the defaultGITHUB_TOKENpath hasn't been exercised in Actions.pull_requestwith bothbranchesandbranches-ignoreis read using onlybranches-ignore;activeis not detected, becauseactions/permissionsis never read.docs: bring the state of play to 2026-10-08 (#14)
fix: refuse uses with runs-on, and pin called-job gating in tests
feat: expand reusable workflow calls into their contexts (#15)
ci: run the required-checks audit daily (#12)
CameronBrooks11 commentedon Oct 8, 2026
All three acceptance bullets are met.
scripts/check_required_checks.py(feat: add a check that every pull_request job is a required check #10) fails both ways: on a workflow job that is not required (UNGATED), and on a required context that no job produces (ORPHANED). feat: expand reusable workflow calls into their contexts #15, feat: flag a required check that push also produces on a pr branch #17, feat: flag a required check that another workflow produces on push #19 and feat: flag a required check with a second pull request producer #21 extended it to called workflows, second producers, andpull_request_target.--loadfixtures. ci: run the required-checks audit daily #12 adds two jobs that run the audit in Actions:cleanexits 0 andfindingexits 1, on throwaway-branch run 37716690040..github/workflows/required-checks-audit.yml(ci: run the required-checks audit daily #12) runs daily against every public repository. Its first scheduled run, 37784299027, ran at 2026-10-08T13:26Z on main89672a6, about seven hours after the 06:17 cron slot. It printed6 repositories, 7 workflows, 7 pull request jobs, 7 required checks: 0 finding(s), 0 not evaluatedand succeeded.Still open in #22: producers the audit does not read yet (
pull_request_review,deployment, and two jobs of one workflow).