What
#637 was a comment in ci.yml that named a job check-workflow-option-coverage when the job is option-coverage and check_workflow_option_coverage.py is the script it runs. That is fixed. Nothing stops the next one.
#638's scripts/check_workflow_job_banners.py pairs a # ── … ── banner to the job it introduces. A job id appearing inside a comment body is not a banner, so it is outside that gate by construction — rule A only inspects the line after a banner, rule B only inspects whether a job has one.
Verification status
Measured on c55ea5b7, by scanning every # comment line in .github/workflows/*.yml for the token immediately preceding the word "job" and asking whether that token is a job id declared in any workflow in the tree.
Restricting to tokens that could plausibly be a job id (lowercase, hyphenated) gives seven across the tree:
ci.yml:954 automoc-include-lint -> job in drift-guard.yml
ci.yml:1313 scenario-coverage -> job in drift-guard.yml
ci.yml:1820 ladder-tests -> job in ci.yml
ci.yml:1838 check-workflow-option-coverage -> NO SUCH JOB (this was #637)
ci.yml:2207 linux-all-features -> job in ci.yml
ci.yml:2475 option-coverage -> job in ci.yml
drift-guard.yml:28 dependency-free -> not a reference: "its own fast, dependency-free job"
drift-guard.yml:258 ladder-tests -> job in ci.yml
drift-guard.yml:339 linux-coverage -> job in ci.yml
So on that revision the rule "a hyphenated lowercase token before the word job must resolve to a job id in some workflow" would have flagged exactly two lines: #637's, and one false positive (dependency-free, a compound adjective). One exemption with a written reason is the same shape as check_workflow_option_coverage.py's EXEMPT and check_workflow_job_banners.py's UNBANNERED, both of which already carry the two staleness rules that keep such a list honest.
Unhyphenated tokens (This job, The job, a sanitizer job) are English and cannot be distinguished from a reference without a dictionary; the hyphen restriction is what makes the rule cheap. It would therefore not catch a stale reference to a job whose id happens to be a single word, e.g. valgrind or windows.
Not verified: nothing was implemented or run as a gate. The numbers above come from an ad-hoc scan, not from a script in the tree. Cross-workflow resolution matters (three of the nine references point at a job in the other file), so the gate has to load all workflows, not one.
Why it was not folded into #637's fix: the repository requires a gate to carry a self-test (test_check_workflow_option_coverage.sh, test_check_workflow_job_banners.sh), so closing this is a script plus a self-test plus a CI step — its own change, not a line in a one-word comment fix.
What would change the verdict
Close this when a check in .github/workflows/ fails on a comment naming a job that does not exist, and its self-test asserts that failure — a gate that reports green over a tree with every reference deleted is worth nothing here. Close it as won't-fix if the false-positive rate on a wider corpus turns out to need an exemption list long enough that the list itself becomes the thing that goes stale.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW
What
#637 was a comment in
ci.ymlthat named a jobcheck-workflow-option-coveragewhen the job isoption-coverageandcheck_workflow_option_coverage.pyis the script it runs. That is fixed. Nothing stops the next one.#638's
scripts/check_workflow_job_banners.pypairs a# ── … ──banner to the job it introduces. A job id appearing inside a comment body is not a banner, so it is outside that gate by construction — rule A only inspects the line after a banner, rule B only inspects whether a job has one.Verification status
Measured on
c55ea5b7, by scanning every#comment line in.github/workflows/*.ymlfor the token immediately preceding the word "job" and asking whether that token is a job id declared in any workflow in the tree.Restricting to tokens that could plausibly be a job id (lowercase, hyphenated) gives seven across the tree:
So on that revision the rule "a hyphenated lowercase token before the word job must resolve to a job id in some workflow" would have flagged exactly two lines: #637's, and one false positive (
dependency-free, a compound adjective). One exemption with a written reason is the same shape ascheck_workflow_option_coverage.py'sEXEMPTandcheck_workflow_job_banners.py'sUNBANNERED, both of which already carry the two staleness rules that keep such a list honest.Unhyphenated tokens (
This job,The job,a sanitizer job) are English and cannot be distinguished from a reference without a dictionary; the hyphen restriction is what makes the rule cheap. It would therefore not catch a stale reference to a job whose id happens to be a single word, e.g.valgrindorwindows.Not verified: nothing was implemented or run as a gate. The numbers above come from an ad-hoc scan, not from a script in the tree. Cross-workflow resolution matters (three of the nine references point at a job in the other file), so the gate has to load all workflows, not one.
Why it was not folded into #637's fix: the repository requires a gate to carry a self-test (
test_check_workflow_option_coverage.sh,test_check_workflow_job_banners.sh), so closing this is a script plus a self-test plus a CI step — its own change, not a line in a one-word comment fix.What would change the verdict
Close this when a check in
.github/workflows/fails on a comment naming a job that does not exist, and its self-test asserts that failure — a gate that reports green over a tree with every reference deleted is worth nothing here. Close it as won't-fix if the false-positive rate on a wider corpus turns out to need an exemption list long enough that the list itself becomes the thing that goes stale.🤖 Generated with Claude Code
https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW