ci: mutation_survivors.json's `line` hints are unaudited and 5 of 7 are already stale

[Yaraslaut]

Noticed while working #528, unrelated to that change. Filed rather than folded in.

Summary

scripts/mutation_survivors.json records each triaged equivalent mutant as {file, line, mutator, source, reason}. Nothing audits the line field, and 5 of its 7 line-carrying entries already point at the wrong line on master.

This is the exact rot that scripts/branch_partial_allowlist.json and scripts/error_path_allowlist.json were hardened against — check_branch_coverage.py's resolve_allowlist_source_line() resolves an entry by its source text and fails the gate when the line hint has drifted, citing morph#349 and morph#419 for why line numbers alone rot. mutation_survivors.json carries the same shape of citation with none of that auditing.

Verification status

Reproduced by measurement, on master @ 26bfdb8f (i.e. before the #528 branch, so none of this drift is that change's doing). Method: for each entry, search the file at that revision for a line whose stripped text equals the entry's source, and compare with the entry's line.

Real output:

entries with file/line/source: 7
include/morph/core/bridge.hpp:119 -- text now at line(s) [121] | source='return modelHash ^ (key.sharing.hash_code() + 0x9e3779b9U + (modelHash'
include/morph/core/backend.hpp:749 -- text now at line(s) [1226] | source='aware.reserve(_changeAware.size());'
include/morph/core/wire.hpp:302 -- text now at line(s) [307] | source='out.reserve(text.size());'
include/morph/forms/views.hpp:264 -- text now at line(s) [271] | source='ordered.reserve(propsObj.size());'
include/morph/forms/views.hpp:430 -- text now at line(s) [437] | source='ids.reserve(_providers.size());'
stale: 5 of 7

Every source text still exists and is still unique, so no disposition is wrong — only the coordinates are. backend.hpp:749 is the worst of them: it is off by 477 lines and now lands in the middle of an unrelated function.

What I did not verify: whether the two non-stale entries are non-stale by luck or because they were refreshed. I also did not check the plain-string citations in the same file (e.g. "include/morph/core/backend.hpp:613 -- emitMetric(Metric::registerCount, 1.0)" and ":807 -- emitMetric(Metric::executeInFlight, ...)" in the runs narrative), which are free text rather than structured entries; both look stale by inspection but I did not measure them.

Why it matters, and why it is minor

check_mutation_regression.py compares survivor counts against scripts/mutation_baseline.json; it never reads mutation_survivors.json, so no gate is currently wrong and no CI job fails because of this. The cost is entirely on the human the failure message sends here:

A new survivor means the suite stopped noticing ... triage into scripts/mutation_survivors.json

— who then follows include/morph/core/backend.hpp:749 to code that has nothing to do with the recorded reason. That is the same "a bare suppression is not a disposition" problem morph#404 named, one step removed: the disposition is sound but no longer findable.

Suggested fix

Reuse what already exists rather than inventing a second mechanism: check_branch_coverage.py:199's resolve_allowlist_source_line() is already written to be shared (its own docstring says so, citing morph#406 for the second caller). A small checker that walks mutation_survivors.json's structured entries through it, run in the same self-test job as the other allowlist gates, would fail on drift and print the corrected line — turning this into a mechanical fix-up instead of a silent rot. Refreshing the five current hints is the other half.

What would change the verdict

• Close it if the line fields in this file are deliberately historical — a record of where the survivor was when it was triaged, not a pointer to current code. If so, say that in the file's _comment, because nothing there says it today and the neighbouring allowlists use line the opposite way.
• Raise it if a future triage pass is actually misled by one of these — or if a gate is ever added that reads this file, at which point the drift stops being cosmetic.

[Yaraslaut]

Triage: valid — re-measured independently, and the proposed fix is the one the codebase already argues for

Re-measured on current master, not relayed

The issue measured on 26bfdb8f. Master has since moved twice (#603, #606), so I re-ran it myself on 91515ae5 with my own script rather than the issue's:

  ok    include/morph/core/registry.hpp:54  -> [54]
  STALE include/morph/core/bridge.hpp:119   -> [121]
  STALE include/morph/core/backend.hpp:749  -> [1226]
  ok    include/morph/core/logger.hpp:78    -> [78]
  STALE include/morph/core/wire.hpp:302     -> [307]
  STALE include/morph/forms/views.hpp:264   -> [271]
  STALE include/morph/forms/views.hpp:430   -> [437]
stale: 5 of 7 on 91515ae5

Identical to the report, including the line numbers. Every source text still resolves to exactly one line, so the dispositions are sound and only the coordinates rot — also as reported. backend.hpp:749 -> 1226 is off by 477 lines.

The severity claim holds — I checked the thing that carries it

The issue's own framing is that this is minor because no gate reads the file. That is the claim worth testing, since it is what keeps this off the critical path. Every mention in the tree is a comment or a message string, never a parse:

scripts/check_mutation_regression.py:52   comment
scripts/check_mutation_regression.py:140  failure-message text
scripts/mutation.sh:89, :216, :330        comments / a print

So: no gate is wrong today, nothing fails, and the cost is entirely on the human that check_mutation_regression.py:140 sends to a line number pointing at unrelated code. The report is right to call it minor and right not to inflate it. Good discipline — the easy version of this issue claims a broken gate.

The proposed fix is the right one, and the codebase says so in its own words

check_branch_coverage.py:199's resolve_allowlist_source_line() exists and is genuinely shared — check_error_path_coverage.py is the second caller, exactly as its docstring claims. And that docstring makes this issue's argument better than the issue does:

the "moved line"/"ambiguous match" resolution here is exactly the fix for a defect this repository has found three times over in an allowlist keyed by line number alone (morph#349, morph#355, morph#419), and a second, independently-maintained copy of the fix is how that class of defect gets a fourth chance.

mutation_survivors.json is a fourth allowlist keyed the same way with none of that auditing. So this is not a new mechanism to design — it is an existing, deliberately-factored-out resolver that this file was never wired into. That makes the fix small and the precedent unarguable.

One sequencing note for whoever takes it

PR #607 is in flight and changes include/morph/core/backend.hpp, which is where the worst-drifted entry lives. Refresh the hints after #607 lands, or the fix-up commit will itself be stale on arrival. That is an argument for landing the checker first and the refresh second, since the checker will then print the corrected lines.

Verification status

• Reproduced by me on 91515ae5: the 5-of-7 count, every individual line, the absence of any parser for the file, and that resolve_allowlist_source_line() exists with the two callers its docstring names.
• Not verified: whether the two non-stale entries are non-stale by luck or by refresh — the issue flags this too, and neither of us checked. Also unmeasured: the free-text citations in the runs narrative (backend.hpp:613, :807), which the issue says look stale by inspection. I did not measure them either, and they are outside the structured-entry fix.

What would change the verdict

Unchanged from the issue's own statement, which I think is correctly drawn: close it if these line fields are deliberately historical — where the survivor was when triaged, not a pointer to current code. If that is the intent it needs saying in the file's _comment, because the three neighbouring allowlists use line the opposite way and a reader has no way to tell them apart today.