Documentation
¶
Overview ¶
Command verify-pr-checks answers one question about a pull request that GitHub's own merge state answers wrongly: did the checks this repository requires actually RUN and PASS?
The distinction is not pedantic. A pull request whose workflow runs are held at `action_required` — awaiting maintainer approval, which this repository imposes on every run whose actor is github-actions[bot], see the header of .github/workflows/frl-pin-bump.yml — reports `mergeStateStatus: UNSTABLE` and `gh pr checks` prints "no checks reported on the '<branch>' branch". Held runs are created, then never surface as check runs. Neither signal is an error, so a merge decision made from either reads "nothing failed" out of "nothing ran".
That inversion has already reached master: PR #637 (bot/frl-pin-bump) merged with zero concluded checks, and on 2026-08-05 the CI run for that same branch concluded FAILURE once it was allowed to run. The bot's PRs are not low-risk-by-construction; they were just never asked.
So the classification here is deliberately three-valued where GitHub is two-valued. PASSED and FAILED are the states everyone already models. ABSENT is the state that has been reading as safe, and it is the whole point of this tool: a check that is expected and simply is not there. A gate that folds ABSENT into "not failed" is the bug, not the fix.
Source Files