Required checks have not fired since 2026-08-24 11:06; every PR since is permanently BLOCKED

[gHashTag]

Every pull request opened since 2026-08-24 11:06 is permanently unmergeable, because the four checks the master ruleset requires have stopped firing.

Measured

The ruleset t27-master-protection (id 14813367, active) requires:

check-now-freshness
validate
check
check-linked-issue

NOW Sync Gate, which provides check-now-freshness, last ran:

$ gh run list --workflow=now-sync-gate.yml --limit 3
  08-24T11:06  success  master
  08-24T10:54  success  w699-assert-ceiling
  08-24T09:19  success  dependabot/cargo/thiserror

Nothing since, on any branch. Repository-wide, the only workflows that have run in the last day are NotebookLM Gate, NotebookLM Auto-Sync, PR Dashboard and auto-merge-ready-prs.

Concretely, on #2720 (a four-commit change to bootstrap/src/compiler.rs):

$ gh run list --branch w699-t27c-fixes
  success  NotebookLM Gate          ← 1 run, total

$ gh pr view 2720 --json mergeStateStatus
  BLOCKED

For comparison, w699-sticky-guard — a branch from earlier the same week — has 23 runs.

The same is visible on fix/struct-field-brace, another session's branch: one NotebookLM run and nothing else. This is not specific to one PR or one author.

What is NOT the cause

Each of these was checked rather than assumed:

hypothesis	measurement
Actions disabled	{"enabled":true,"allowed_actions":"all"}
workflows disabled	all 45 report state: active, including NOW Sync Gate and Issue Gate
files deleted from master	45 workflow files on master; both gates present
workflows changed recently	last commit touching .github/workflows/ is #2602
a branches: filter	now-sync-gate.yml deliberately has none, and says so in a comment
a paths: filter	it has none either
repo archived / disabled / private	private:false fork:false archived:false disabled:false
the trigger shape	notebook-gate.yml has the identical pull_request: trigger and DOES run

That last row is the sharp one: two workflows with the same trigger, one fires and one does not, so the trigger is not the difference.

What I could not check from here

Anything at the account level — Actions minutes, a spending cap, a partial GitHub incident, or a per-workflow disablement that the API still reports as active. Naming one of those as the cause would be a guess, and the point of this issue is the measurement, not the diagnosis.

Why it matters beyond the queue

Both of the silent gates carry a comment saying exactly what is now happening to the whole repository:

An absent check is not a passing check.

gh pr checks currently shows a green list on #2720 — two successes, zero failures. A reviewer reading that list cannot tell it from a PR that passed 33 gates. The repository already fixed this failure mode once for stacked PRs (the branches: filters were removed on purpose, and scripts/ci/check_pr_branch_filters.py enforces it); it is now happening one level up, where no check in the tree can see it.

What is blocked right now

#2720 — four measured t27c defects, three of them silent (empty match for every switch, dropped body for every for loop, the inclusive range, paren-less if in expression position). Parse count 603 → 609 with zero regressions, and a generated Rust program that compiles and prints the right answer.

It is ready and cannot merge. I have not used --admin and will not.

[gHashTag]

Withdrawn — I was wrong, and the way I was wrong is the point.

The checks were not missing. They had not started yet. Check Now Freshness ran on both branches this issue said it could never run on:

08-26T17:22  pull_request  w699-unscar       success
08-26T17:13  pull_request  w699-t27c-fixes   success

I looked at 16:56 and filed this at 17:0x. Both PRs now show 30+ checks.

What produced a confident wrong answer

Two instrument errors compounding:

1. gh run list --limit N is a recency window, not a census. The last 10–60 runs were dominated by NotebookLM Gate and NotebookLM Auto-Sync, which fire on every push. I read "the only workflows running" off a list that had simply not reached back far enough. gh api .../actions/runs?created=>2026-08-25 returns 103 runs over the same span — pull_request: 39, push: 31, schedule: 14.

2. I queried the wrong workflow. --workflow=now-sync-gate.yml returned runs ending 08-24, and I took that as "the required check stopped firing". The required context check-now-freshness is also produced by seal-staleness-warn.yml, and the run that actually satisfies it displays as "Check Now Freshness" — a name I never searched for. One file answered; the check came from elsewhere.

Every row in this issue's "what is NOT the cause" table was correct. The cause was not in the table because the premise was false.

The measurement that would have caught it

Waiting. The two branches differ in when I looked, not in what they trigger — and a check that has not started is indistinguishable from a check that will never start, until you wait.

The generalisable half: a query that returns "the most recent N" cannot answer "has X happened since T". For that question the API's created=> filter is the instrument, and gh run list is not.

The one true observation buried in here is worth keeping: gh pr checks on a PR whose checks have not started shows a short green list, and a reader cannot tell it from a PR that passed everything. That is real, and it is what made an outage the plausible reading. But it is a UI hazard, not an outage.

Closing. Nothing here needs owner action.