ci: branch_partial_allowlist.json carries stale line hints on master, and master's coverage leg passes anyway

[Yaraslaut]

Found while diagnosing PR #585's red Linux / clang-coverage leg. Filed rather than folded into that PR, which repoints the hints only because its leg cannot go green otherwise.

The finding

scripts/branch_partial_allowlist.json carries stale line hints on master, and master's own coverage leg passes anyway.

That file is the one resolve_allowlist_source_line() exists to harden — the mechanism cited in morph#349 and morph#419, and the precedent morph#608/#614 built on for mutation_survivors.json. So the gate designed to catch exactly this rot is not catching it here.

Verification status: the drift is reproduced; the reason it is not caught is not established

Measured on master @ 0e3b8823, by resolving each entry's source text against the file at that revision — the same method resolve_allowlist_source_line() documents:

include/morph/util/rational.hpp  hint 1542 -> text is at line 1498
include/morph/core/bridge.hpp    hint 1498 -> text is at line 1453

Both source texts still exist and are still unique, so no disposition is wrong — only the coordinates. A third entry (backend.hpp hint 1230) resolves correctly on master and drifted only on #585's branch, which adds 94 lines to that file; that one is not part of this finding.

And yet:

$ gh run list --branch master --workflow ci.yml --limit 1
35499909035  0e3b8823  success
$ # its Linux / clang-coverage job:
Linux / clang-coverage -> success

Meanwhile the same two entries did fail on #585's branch, with the resolver's own message:

error: include/morph/util/rational.hpp:1542 has moved to line 1498. The text still matches, so nothing is wrong with the disposition -- update the `line` hint.
error: include/morph/core/bridge.hpp:1498 has moved to line 1542. ...

Note #585 does not touch include/morph/util/rational.hpp at all. So the same allowlist entry is judged differently on two revisions whose content for that file is identical.

What I did not establish: why. I read scripts/check_branch_coverage.py far enough to see that resolve_allowlist_source_line() is called at :291 and the partial-line test happens afterwards at :295 — which reads as eager resolution of every entry, and would mean master should fail too. It does not. Candidate explanations I did not test:

• the entry loop is fed only files present in the coverage data, and the coverage configuration differs between the two runs (master's leg and qt: move QtWebSocketBackend onto the structural registration surface #585's leg enable different options);
• master's run was served a cached or partial report;
• the two runs resolve a different repo_root.

I did not instrument the script, did not re-run the coverage leg locally, and did not diff the two runs' configure steps. This is the open question and I am not asserting an answer.

Why it matters

Two separate costs, and the second is the larger one:

1. The coordinates are wrong, so a reader following one lands in unrelated code — the morph#608 cost, in the file that is supposed to be immune to it.
2. A gate that passes on master and fails on a branch that did not touch the file is not measuring what its name says. Whichever explanation above is right, the consequence is the same: drift accumulates on master unnoticed and surfaces as a red leg on whichever unrelated PR happens to trip it. qt: move QtWebSocketBackend onto the structural registration surface #585 paid that cost today — a chain-unblocking PR spent a CI cycle on two hints it did not move.

This is AGENTS.md's "verify rather than assert" case: "Ask whether the check would still pass if the feature did nothing." Here it demonstrably passes while two of its entries are wrong.

What would resolve it

1. Establish the mechanism — instrument or locally run check_branch_coverage.py against master and against qt: move QtWebSocketBackend onto the structural registration surface #585's head and compare which entries each actually resolves. That is the whole ticket; the fix follows from the answer.
2. If the entry loop is scoped by the coverage report, make the resolution unconditional — resolve every entry in the file regardless of whether it is consulted, the way scripts/check_mutation_survivors.py (morph#614) walks the whole document. An entry that is only validated when it happens to be needed is an entry that rots between needs.
3. Audit all 22 entries on master once the mechanism is known.

What would change the verdict

• Close if the two entries turn out to be correct under the resolver's real semantics and my line-matching is the thing that is wrong — in which case the resolver's docstring is misleading and that is the finding instead.
• Re-open if a PR that does not touch an allowlisted file is ever again failed by that file's entry.

Related

• morph#608 / ci: audit mutation_survivors.json's line citations instead of hoping (fixes #608) #614 — the same rot class in scripts/mutation_survivors.json, where the fix was to walk the whole document.
• morph#349, morph#419 — cited by resolve_allowlist_source_line() as why line numbers alone rot.
• qt: move QtWebSocketBackend onto the structural registration surface #585 — repoints the three hints so its leg can go green; does not address this.

[Yaraslaut]

Triage: invalid — the premise does not reproduce, at either revision

What I measured. Resolved every entry in scripts/branch_partial_allowlist.json against the source file at the same revision, by the resolver's own method (text.strip() == entry["source"].strip(), resolve_allowlist_source_line() at scripts/check_branch_coverage.py:230):

$ # at 0e3b8823, the revision this issue cites
entries=22 stale=0

$ # at a8511aa6, current master
total entries=22  stale=0

The two cited entries do not exist in the shape the issue gives them. At 0e3b8823:

include/morph/util/rational.hpp  line=1498
  source="if (ctx.begin() == ctx.end() || *ctx.begin() == '}') {"
  text found at [1498]

include/morph/core/bridge.hpp  line=1453
  source='if (_executeDeadline.count() > 0 && _timeoutScheduler) {'
  text found at [1453]

There is no rational.hpp entry with hint 1542 and no bridge.hpp entry with hint 1498. The issue reports "rational.hpp hint 1542 -> text is at 1498" and "bridge.hpp hint 1498 -> text is at 1453" — which are the two entries' correct line numbers, 1498 and 1453, paired with the other file's hint. The evidence looks like an allowlist from one revision cross-matched against files from another, rather than a drift on master.

So the anomaly the ticket is built on dissolves. master's coverage leg is green because nothing on master is stale — not because the gate skipped anything. The three candidate mechanisms the issue lists are also each falsified by reading the code, so none of them needs instrumenting:

• "the entry loop is fed only files present in the coverage data" — no. resolve_allowlist() (:285) iterates document.get("entries", []) unconditionally, before any partial_lines test. All 22 entries live in that one top-level list; a deep walk of the document finds 22, the same 22.
• "a cached or partial report" — would not matter: resolution happens before the report is consulted.
• "a different repo_root" — would not be silent: main() passes os.getcwd(), and a wrong root makes os.path.exists(source_file) fail with "names <path>, which does not exist" (:224).

failures is fatal on both paths out of check() (return 1 at the end of each branch), so a stale entry could not have been reported and survived.

Why #585's branch saw real errors. Those were genuine and branch-local: #585 adds ~94 lines to backend.hpp and also edits bridge.hpp, so its own entries moved and it repointed them. That is the design — a line is a hint that drifts with the branch's own insertions — not a master defect. The rational.hpp error in particular is unlikely to have come from #585, which does not touch that file; a branch that does (PR #561, which carries coverage: re-pin rational.hpp's branch-partial allowlist after the line shifts) is the likelier source of that line.

Not verified: I did not re-run the coverage leg or produce an lcov; this is a static resolution of the allowlist plus a read of the gate's control flow. That is sufficient to falsify "stale on master", which is the claim the ticket turns on, but it does not independently re-confirm that the leg executes the gate — scripts/coverage.sh:330 is the only caller that does, and drift-guard.yml:357 runs only --self-test.

What would change the verdict

Re-open if either holds:

• A run of python3 scripts/check_branch_coverage.py <lcov> on an unmodified master checkout exits 0 while an entry's source text resolves to a line other than its line — the actual "passes while wrong" shape, measured end to end rather than by static resolution.
• A PR that touches no allowlisted file is failed by an allowlist entry. (qt: move QtWebSocketBackend onto the structural registration surface #585 does not qualify: it edits bridge.hpp and backend.hpp, both allowlisted.)

Closing as triage: invalid.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW