ci: mutation_survivors.json's free-text citations are unaudited, and at least 10 of 31 are stale

[Yaraslaut]

Found while fixing #608, which refreshed and gated the structured entries in
scripts/mutation_survivors.json. This is the other half of that file, which
the new gate structurally cannot see. Filed rather than folded in: it needs a
different mechanism, not a bigger version of the one #608 asked for.

Summary

Besides its 7 structured {file, line, mutator, source, reason} entries,
scripts/mutation_survivors.json cites source locations as prose — inside
representative_sites lists, site fields, and the runs / classification
narrative. scripts/check_mutation_survivors.py (added by the #608 fix) counts
31 such citations and audits none of them, because they carry no
verbatim source text to resolve against: the text after the -- is a
paraphrase ("backend.hpp:613 -- emitMetric(Metric::registerCount, 1.0)"), and
several use a bare filename with no directory ("bridge.hpp:1683",
"payload_schema.hpp:169").

At least 10 of the 31 are stale today.

Verification status

Reproduced by measurement, on this lane's branch off master @ a020e69c
(the citations and the headers are both unmodified by that branch, except the
five structured line hints #608 refreshed). Method: print the current text of
each cited line and compare it against what the citation claims is there. Not
an exhaustive pass — I measured the 18 citations that name a resolvable path,
not all 31.

Real output (<file> <line> -> current text at that line):

remote.hpp:718 -- false_positive_finding.results[0].site }
remote.hpp:818 -- same entry                   return;
forms.hpp:1981 -- results[1].site              /// how many decimals the derivation itself produced (a product of two 2-decimal
registry.hpp:709 -- results[2].site            
remote.hpp:1031 -- samples[].site              // re-test under the insert lock further below.
bridge.hpp:1683 -- samples[].site              // entry to fire later and find nothing (setValue/
forms.hpp:1794 -- samples[].site               
bridge.hpp:584 -- samples[].site               auto primaryCopy = primary;
forms.hpp:2356 -- classification narrative     annotateNestedAggregateRef<Member, Ancestors...>(dom, property);
wire.hpp:514 -- classification narrative       // why, and for how a test covers this arm anyway.
instance_constraints.hpp:156                   if (places > math::kMaxDecimalPlaces) {
payload_schema.hpp:218                         hash ^= static_cast<std::uint64_t>(static_cast<unsigned char>(byte));
remote.hpp:142                                 auto hi = static_cast<uint32_t>(counter >> 32);
remote.hpp:145                                 lo = hi ^ mix(lo, roundKey);
remote.hpp:148                                 return (static_cast<uint64_t>(hi) << 32) | static_cast<uint64_t>(lo);
backend.hpp:613 -- representative_sites        ///
backend.hpp:807 -- representative_sites        /// "Where does the blocking happen" is the only question this class exists to
remote.hpp:1038 -- representative_sites        // sharing is worth the most. `acquireSharedInstance` re-tests the

Read against what each citation claims:

Stale (10):

• classes.side_channel_metrics.representative_sites:
  "include/morph/core/backend.hpp:613 -- emitMetric(Metric::registerCount, 1.0)"
  and ":807 -- emitMetric(Metric::executeInFlight, ...)". Line 613 is ///
  and 807 is a doc comment. The substring emitMetric(Metric::registerCount
  does not occur anywhere in the file — every call site is written fully
  qualified now:

  1121:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::registerCount, 1.0);
  1140:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::registerCount, 1.0);
  1285:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::executeInFlight,
  

  So this pair is stale in two ways at once: wrong line, and quoting a spelling
  the code no longer uses.
• classes.side_channel_logging.representative_sites: remote.hpp:1031 -- logError on an undecodable envelope and :1038. Both now land on comments;
  the only logError in the file is at line 975.
• false_positive_finding.results[*].site: remote.hpp:718 and :818 (now }
  and return;), forms.hpp:1981 (a doc comment), registry.hpp:709 (blank).
• classification_2026_09_09.survivor_list_unreliable.samples[*].site:
  remote.hpp:1031, bridge.hpp:1683, forms.hpp:1794 (blank),
  bridge.hpp:584.
• The classification narrative's wire.hpp:514 (the kMaxEnvelopeBytes cap):
  now a comment; kMaxEnvelopeBytes occurs at 29, 522, 525, 537, 540, 542.
  Its forms.hpp:2356 ("the offender-list separator") is now
  annotateNestedAggregateRef<Member, Ancestors...>(dom, property);.

Still correct (6): remote.hpp:142, :145, :148 (the Feistel round),
registry.hpp:54, payload_schema.hpp:218, instance_constraints.hpp:156.

Unresolvable as written (1): the narrative's payload_schema.hpp:169 names
no directory, and there is no include/morph/forms/payload_schema.hpp — the
file is include/morph/core/payload_schema.hpp. A reader has to guess before
they can even check it.

Also worth recording, because it is the same rot in the other direction: the
prose at classification_2026_09_09 cited core/bridge.hpp:121 for the
HandlerKey hash-combine — which was correct — while the structured entry for
the same site said 119, which was wrong. #608's refresh has now made them agree
at 121.

What I did not verify: whether any of the stale citations' dispositions
are wrong. I only checked coordinates. I also did not attempt to find the
current line for every stale one — for several (the samples[].site rows) the
mutant description is too paraphrased to search for reliably, which is itself
part of this issue.

Why it matters, and why it is minor

Same cost as #608's, one step further out: no gate reads these, so nothing in
CI is wrong. The cost lands on a human who follows one during a future triage
pass and reads unrelated code — and, unlike the structured entries, they cannot
be mechanically re-resolved, so that human has to re-derive the site from
scratch.

It also narrows a claim that now looks broader than it is.
scripts/check_mutation_survivors.py prints note: 31 further citation(s) in this file are free text ... NOT audited here on every run precisely so this
gap is visible, but a green drift-guard tick still reads as "this file's
citations are fine" to anyone who does not read that line.

Options, none of them obviously right

1. Give the prose citations the structured shape — a source field with
   the verbatim line — so check_mutation_survivors.py audits them with no new
   mechanism. Most durable; also the most editing, and some of these are
   genuinely narrative sentences rather than records.
2. Delete the line numbers from the prose and keep the file/symbol name
   only. A citation that cannot rot is better than one that does, and for a
   historical narrative ("this survivor was sampled from remote.hpp's
   OpaqueIdGenerator::mix") the line number was never carrying much.
3. Refresh them once and accept they will rot again. Cheapest, and the
   thing ci: mutation_survivors.json's line hints are unaudited and 5 of 7 are already stale #608 argued against on the structured half.

What would change the verdict

• Close it if these citations are deliberately historical — a record of
  where the code was when the run was taken, not a pointer into current code.
  That is a defensible reading for runs and false_positive_finding, which
  describe a specific dated campaign. If so, say it in the file's _comment
  next to the note ci: mutation_survivors.json's line hints are unaudited and 5 of 7 are already stale #608 added, because the structured entries in the same file
  now use line the opposite way and nothing distinguishes them to a reader.
• Raise it if someone is actually misled by one during a triage pass, or if
  option 1 is taken and the prose becomes gate-covered.

Related: #608 (the structured half, fixed). Same defect class as #605 (a
hand-maintained list with nothing auditing it), different fix site.

[Yaraslaut]

Triage: parked

Premise reproduced independently on master @ a020e69c, against the
unmodified file (not the #608 branch), so this is not measuring the fix's own
output.

The headline pair, checked by reading the file rather than trusting the issue:

$ sed -n '613p;807p' include/morph/core/backend.hpp
    ///
/// "Where does the blocking happen" is the only question this class exists to

$ grep -c "emitMetric(Metric::registerCount" include/morph/core/backend.hpp
0

$ grep -n "emitMetric(::morph::observe::Metric::registerCount\|...executeInFlight" include/morph/core/backend.hpp
1121:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::registerCount, 1.0);
1140:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::registerCount, 1.0);
1285:        ::morph::observe::detail::emitMetric(::morph::observe::Metric::executeInFlight,
1330:            ::morph::observe::detail::emitMetric(::morph::observe::Metric::executeInFlight,

Confirmed on both counts, and the second is the sharper one: the citation
quotes a spelling that occurs nowhere in the file, so it cannot be
mechanically re-resolved even by hand-searching for its own text. That is a
real difference in kind from the structured entries #608 fixed, and it is the
part of this issue that earns its filing.

One figure I could not reproduce exactly. A regex sweep for
file.ext:NNNN over the whole document on master gives me 35 occurrences,
30 distinct, against this issue's 31. I did not chase the discrepancy — my
regex and check_mutation_survivors.py's enumeration are counting slightly
different things (mine catches backend.hpp:749, which is a structured entry
also mentioned in prose). The order of magnitude and the conclusion are
unaffected, but treat 31 as approximate rather than as a measured constant,
and re-derive it from the script if it is ever load-bearing. I did corroborate
the sub-claim that matters for the mechanism: 9 of the distinct citations use a
bare filename with no directory (bridge.hpp:1683, payload_schema.hpp:169,
instance_constraints.hpp:156, …), so they are unresolvable without a search
even in principle.

Why parked rather than valid or rescope

Not valid: the issue offers three options and says of them "none of them
obviously right." That is honest and correct, but it means no lane can be
handed this — the first step is a choice, and a batched PR cannot carry a
ticket whose first step is a choice.

Not rescope either, and this is the distinction worth recording. A rescope
verdict says the framing is wrong and someone should rewrite it. This framing
is right; what it is missing is a decision, and the issue has already
identified which one, in its own close condition:

Close it if these citations are deliberately historical — a record of
where the code was when the run was taken, not a pointer into current code.
That is a defensible reading for runs and false_positive_finding, which
describe a specific dated campaign.

That is the whole ticket. The file now mixes two kinds of line with
opposite semantics — structured entries where line points into current
code and is gated per-PR as of #608, and prose entries where line may be a
record of a dated campaign — and nothing in the file distinguishes them.
Every one of the three options is downstream of answering that; options 1 and 3
presume "pointer into current code" and option 2 presumes "historical record."

So this is real, reproduced, minor by the issue's own honest account ("no gate
reads these, so nothing in CI is wrong"), and gated on a decision rather than
on work. That is what parked is for.

Re-entry conditions

Adopting the issue's own, which are already well-formed, plus one:

• Raise if anyone is actually misled by one of these during a triage pass.
  That is the cost this issue predicts, and one instance of it converts this
  from a hypothesis to an incident.
• Raise if option 1 is taken and the prose becomes gate-covered.
• Raise if the count grows — new runs narrative is added with fresh
  line-number citations, which would mean the file is accreting the same rot
  faster than anyone is deciding about it.
• Close if the historical reading is adopted and written down.

The cheap partial, and why it is not being folded anywhere

The issue's close condition already names a one-line fix that is decision-free
given the decision, and removes the trap for a future reader:

If so, say it in the file's _comment next to the note #608 added, because
the structured entries in the same file now use line the opposite way and
nothing distinguishes them to a reader.

PR #614 is open right now and edits that exact _comment. It is not going in
there. AGENTS.md is explicit — "Do not fold an unrelated finding into the
current change. File it, link it, and keep the change you are making about one
thing" — and this is a different finding from #608 by the filing lane's own
correct judgement. It should ride on whichever future change touches this file
for its own reasons, or on this issue when it un-parks.

What I did not verify

• I did not check the dispositions behind any free-text citation — only
  that the coordinates no longer match. Whether each recorded mutant is still
  genuinely equivalent is untouched by this issue and by me.
• I measured the two backend.hpp citations and the bare-filename count
  directly; for the remaining stale entries I am relying on the filing lane's
  table, which I did not re-run.
• I did not check whether scripts/mutation_baseline.json or any other
  triage-record file carries the same prose-citation shape. If it does, that is
  a third instance of this defect class and belongs in its own issue.

Labels: triage: parked, plus the bug / documentation / area: ci the
filing lane applied. It correctly applied no triage: label itself.

[Yaraslaut]

Decision: both — and that is the answer, not a dodge. Un-parking to valid.

The question this ticket was parked on was: are these citations historical records, or pointers into current code? I said all three of its options were downstream of answering it. Measured on master @ a020e69c, the answer is that the file contains both kinds, in clearly separable places, and once you split them each half has an obvious and different fix.

The measurement

LIVE half (classes.* — dispositions and illustrations of a CURRENT classification):
   classes.equivalent.entries                        : 7 structured   <- already gated by PR #614
   classes.side_channel_logging.representative_sites  : 2 free-text, 2 citations
   classes.side_channel_metrics.representative_sites  : 2 free-text, 2 citations
   classes.unasserted.shapes_worth_naming             : 3 free-text, 7 citations
   classes.unasserted.by_file                         : 19 file keys, no line numbers  (nothing to rot)

HISTORICAL half (dated campaign records):
   runs                      citations= 2   carries_date=yes  pinned_to_a_revision=yes
   false_positive_finding    citations= 7   carries_date=yes  pinned_to_a_revision=NO
   mechanism_confirmed       citations= 0   carries_date=yes  pinned_to_a_revision=NO
   classification_2026_09_09 citations=11   carries_date=yes  pinned_to_a_revision=yes

11 live, 20 historical. That sums to 31, which confirms this ticket's count exactly.

(A correction to my own earlier triage comment, which put it at "35 raw / 30 distinct" and flagged 31 as approximate: my regex was the loose one — it swept the whole document and caught the structured entries too. 31 is right. The ticket's number stands and mine did not.)

Why the split is real and not a convenience

The runs entries each carry a date field. false_positive_finding.verification_status reads "measured, 2026-09-03, on lane/d-framework in the same build tree and configuration the run above used"; mechanism_confirmed's reads "measured, 2026-09-04, in an isolated WSL Ubuntu 24.04 environment, Mull-19 0.34.0 / LLVM 19.1.7". classification_2026_09_09 has the date in its key.

These are not pointers that happen to be stale. They are records of a dated campaign, written as such, and reading them as pointers into today's code is the reader error — not a defect in the data. This ticket's own close condition anticipated exactly this and it turns out to be the case for four of the file's five narrative sections.

classes.*, by contrast, describes a classification asserted to hold now — classes.equivalent.entries is gated by #614 precisely because it is a live claim. representative_sites and shapes_worth_naming sit inside that same live structure and illustrate it. A reader following one expects current code, and should get it.

So, the fix — different per half

Live half (11 citations) → give them the structured shape. This is the ticket's option 1, applied to the subset where it is right. Add {file, line, source} alongside the prose, and scripts/check_mutation_survivors.py audits them with no new mechanism — it already walks the whole document for file/line/source dicts, by deliberate design (#614's lane built it that way so a future triage class is covered without editing the script). Eleven citations is a small, bounded job.

Historical half (20 citations) → pin each section to a revision. Not option 2 (delete the line numbers): a line number plus a revision is a working pointer — git show <rev>:<file> lands correctly forever — whereas deleting it destroys information to stop it rotting. That is the wrong trade when the cheaper fix preserves the value.

Two sections already carry a revision-shaped hex; false_positive_finding and mechanism_confirmed do not, and that is the actual defect in this half. A date alone does not let a reader resolve a line number; a SHA does. Add the revision each campaign was run on, and state in _comment that citations under these sections are historical and resolve against that revision, not against HEAD.

The gate must not try to audit this half — and should keep printing its own narrowness, as it does now, so a green tick never reads as "all citations checked."

Why this is better than any of the three options as written

Option 1 applied to everything would gate historical records against current code, which would fail forever and correctly so — the records are not wrong. Option 2 applied to everything discards working pointers. Option 3 refreshes both halves once and re-rots. Splitting by what the citation is costs about the same as any of them and leaves the file self-describing, which is this ticket's real complaint:

the structured entries in the same file now use line the opposite way and nothing distinguishes them to a reader

After this, something does.

Scope for a lane

One ticket, two commits, scripts/mutation_survivors.json only (plus whatever _comment wording it needs):

1. Structure the 11 live citations; confirm check_mutation_survivors.py picks them up without modification — if it needs modification, say so, because that contradicts its design claim.
2. Pin the historical sections to revisions; add the _comment note distinguishing the halves.

Acceptance, per AGENTS.md: drift one of the newly structured citations and show the gate failing on it — a run that merely stays green proves only that nothing was added.

Blocked on PR #614 landing — it holds this file.

What I did not verify

• I did not check whether the two revision-shaped hexes in runs and classification_2026_09_09 are valid commits in this repository, only that a hex string is present. Whoever takes this should git cat-file -e them; if either is from a branch that was squash-merged away, pinning is harder than it looks and that is worth knowing early.
• I did not re-check the dispositions themselves, only the coordinates — unchanged from the previous triage.
• I did not look for this citation pattern in other triage-record files (e.g. mutation_baseline.json). If it is there too, that is a third instance and gets its own issue.