The problem
scripts/ci/self-index-coverage-gate.sh check 4 compares a live measurement against a number checked into scripts/ci/parse-partial-baseline.txt. The measurement is taken on the merge of the PR into current main, but the number is a constant.
So the number goes stale on its own. Any merge to main that adds a file the tree-sitter grammar cannot fully parse raises the real count, and from that moment every open PR is red on check 4 — including PRs that touch none of this.
The PR that turns the gate red is never the PR that caused it.
It already happened
The ceiling was measured at 58 on 2026-08-30. main then gained src/daemon/runtime.c, whose line 47 the C grammar cannot parse:
static _Atomic(cbm_daemon_runtime_containment_hook_t) runtime_containment_hook_seam;
The function-style _Atomic(type) fails to parse; the keyword form _Atomic uint32_t parses fine. That is one line out of 3291 in that file, 0.03% of it — a real grammar gap, correctly flagged, and nothing to fix in the source.
The count went 58 → 59. PR #1968 went red on a check about a file it does not touch. Measured three ways with one binary to be sure:
| tree |
parse_partial |
| the gate branch alone |
58 |
origin/main alone |
59 |
| the two merged |
59 |
The merged list and main's own list name the identical files. The rise came from main.
The fix in #1968 is to hand-edit the number to 59. That works once and does not stop the next one.
Suggested fix
Compare against the merge base rather than a constant: measure the count at the merge base as well as at the merge, and fail only when the PR's own merge raises it. A PR then goes red for what it did, and a rise that arrives with main reddens nothing.
That removes the file entirely, or leaves it as an advisory high-water mark rather than a gate.
This is CI policy, so the call is the maintainer's. Filing it rather than changing the gate's shape inside a PR that is already about something else.
Related
Same class as #1963 — a checked-in number that drifts against a moving target.
Part of #963.
The problem
scripts/ci/self-index-coverage-gate.shcheck 4 compares a live measurement against a number checked intoscripts/ci/parse-partial-baseline.txt. The measurement is taken on the merge of the PR into currentmain, but the number is a constant.So the number goes stale on its own. Any merge to
mainthat adds a file the tree-sitter grammar cannot fully parse raises the real count, and from that moment every open PR is red on check 4 — including PRs that touch none of this.The PR that turns the gate red is never the PR that caused it.
It already happened
The ceiling was measured at 58 on 2026-08-30.
mainthen gainedsrc/daemon/runtime.c, whose line 47 the C grammar cannot parse:The function-style
_Atomic(type)fails to parse; the keyword form_Atomic uint32_tparses fine. That is one line out of 3291 in that file, 0.03% of it — a real grammar gap, correctly flagged, and nothing to fix in the source.The count went 58 → 59. PR #1968 went red on a check about a file it does not touch. Measured three ways with one binary to be sure:
origin/mainaloneThe merged list and main's own list name the identical files. The rise came from
main.The fix in #1968 is to hand-edit the number to 59. That works once and does not stop the next one.
Suggested fix
Compare against the merge base rather than a constant: measure the count at the merge base as well as at the merge, and fail only when the PR's own merge raises it. A PR then goes red for what it did, and a rise that arrives with
mainreddens nothing.That removes the file entirely, or leaves it as an advisory high-water mark rather than a gate.
This is CI policy, so the call is the maintainer's. Filing it rather than changing the gate's shape inside a PR that is already about something else.
Related
Same class as #1963 — a checked-in number that drifts against a moving target.
Part of #963.