Mutation Testing History

A dated record of full-workspace mutation sweep results, so the surviving-mutant count has a durable history rather than only living in GitHub Actions artifacts (retained 90 days — see CI/CD) or transient CI logs.

Why this page exists

mutants.yml runs a full sweep weekly and fails the workflow on any surviving mutant, but a failing scheduled workflow is a notification, not a record: it says this week had a survivor, not when the score last changed or what the trend looks like. Nothing before this page captured that — a real gap this project should not let recur, in the same spirit as docs/official-tck-findings.md's conformance history.

Every score before 2026-09-23 counts some uncompilable mutants as caught

Until 2026-09-23 mutants.yml passed --all-features after --, which hands it to the test command only. Each mutant was therefore built without the crate's features, so a mutant inside feature-gated code (postgres, sqlite, grpc, websocket, otel, …) compiled trivially — the mutated code was not compiled at all — and was then compiled with every feature in the test step. A mutant that does not compile failed there, and cargo-mutants scores a failing test step as caught. Measured on one diff that day: 14 mutants reported 14 caught; with the flag given to cargo mutants itself the same 14 were 6 caught and 8 unviable.

What this does and does not change in the rows below. Missed counts are unaffected: a mutant that compiles is built and tested with every feature either way. Caught counts, and so the percentages, are overstated by the number of feature-gated unviable mutants in each sweep, which the old artifacts cannot recover. The unviable column is correspondingly understated. Read the rows' missed figures as measurements and their scores as upper bounds. Recorded as audit N8 in docs/adopter-audit-2026-09-22.md.

How to add an entry

After a full sweep completes (mutants-summary job in mutants.yml), copy the aggregated table from that run's GITHUB_STEP_SUMMARY output into a new row below, dated to the run, with the commit it ran against. A clean sweep (zero missed) is still worth recording — "still zero" is signal too, not a no-op.

Copy the Timeout column too, and read it as unfinished business rather than a footnote. mutants.yml scores caught / (caught + missed): a timeout is in neither term, so it is not a mutant the score counts against — it is a mutant the score does not describe. "Zero missed" and "zero timeouts" are different statements. The 2026-08-14 row below is what it costs to read one as the other.

How the ledger came to be empty for so long

The first row below was recorded on 2026-08-07. Every sweep before it produced no number at all — not "an incomplete number", none — and the reasons are worth keeping, because each was a gate reporting success over work it had not done.

An earlier revision of this page blamed two cancelled shards for the false green. That diagnosis was wrong, and the correction matters more than the original finding, so it is recorded here rather than quietly edited away.

What the 2026-07-27 run actually did

Run 30236603180 (2026-07-27, against b416c1a) is the first scheduled run in mutants.yml's history. An earlier revision of this page called it "the only scheduled run", which was wrong when it was written — a second scheduled run on 2026-08-03 had already happened and had already reported the same false green. It is analysed below under "A second scheduled run told the same lie". Its Mutants Summary job concluded success and printed:

COMBINED MUTATION SCORE: 100%
Caught: 0  Missed: 0  Timeout: 0  Unviable: 0

Its own uploaded artifacts — still retrievable, and re-counted directly on 2026-08-06 — contain 200 surviving mutants out of 2,286 examined. A real score of 91%, reported as 100%.

Nine of the eleven jobs ran to completion and every one of them reported Missed: 0 while holding a missed.txt with up to 40 lines in it. The two cancelled shards were real, but they were not the cause — the nine that finished contributed zero as well.

The actual mechanism

Two independent path defects, both verified against the artifacts:

1. --output mutants.out does not write to mutants.out/. cargo-mutants creates a directory named mutants.out inside whatever --output names ("Create mutants.out within this directory"), so reports landed in mutants.out/mutants.out/ while every count read mutants.out/. A missing file counts zero lines, and zero missed mutants reads exactly like a clean sweep.
2. The artifact upload absolutised every path. upload-artifact was given mutants.out/ and /tmp/mutants-run.log; with two paths it uses their least common ancestor, which is /. That run's log says so verbatim: "The least common ancestor is /. This will be the root directory of the artifact". Every file was stored under home/runner/work/…, where the summary job did not look.

Then one line converted "measured nothing" into a passing grade: with an empty denominator the aggregator set SCORE=100.

This affected the incremental PR gate identically — same --output, same reader — so the required check that is supposed to block a PR on a surviving mutant could not fail either.

What is fixed

• --output ., so the report is where the readers look. Verified empirically against cargo-mutants 27.1.0 in both forms, not inferred from the docs.
• A single upload path, so artifact entries sit at the root of mutants.out/.
• A missing or malformed report is a hard error, not a zero.
• The aggregate refuses to publish a score over an empty denominator — a whole-workspace sweep that examined no mutants has not passed, it has not run.
• set -o pipefail, so tee stops masking cargo-mutants' exit status.
• count() no longer emits "0\n0" for an empty-but-present file, which would have broken the arithmetic the moment the paths were corrected.
• The shard-completeness gate and 12-way a2a-server sharding from 2026-07-31 remain: they address a real second hazard (shards cancelled at the 120-minute timeout), they were simply not what made that run green.

Do not backfill a number from run 30236603180. The 91% above is recorded as forensics, not as a measurement of the workspace: two of its shards were cancelled, so its denominator is short by roughly two-elevenths of a2a-server.

A second scheduled run told the same lie

Added 2026-08-09. The section above missed one, and the omission mattered: it made a recurring defect look like a single incident.

Run 30783745696 (2026-08-03, scheduled, against a3c8c0f0 on main) concluded success — workflow and Mutants Summary job alike — and printed the identical signature:

COMBINED MUTATION SCORE: 100%
Caught: 0  Missed: 0  Timeout: 0  Unviable: 0

All fifteen crate shards concluded success too, after doing real work: the a2a-types job alone ran for 1h49m. So this was not a run that failed to start. It was a run that measured 3,430 mutants and reported none of them.

Its artifacts had not expired, and were re-counted directly on 2026-08-09:

Plus 2 timeouts and 1276 unviable. A real score of 91%, reported as 100%.

The mechanism was the same pair of path defects, still visibly present in the downloaded archives: every report sits at home/runner/work/a2a-rust/a2a-rust/mutants.out/mutants.out/… — the --output double-nesting and the least-common-ancestor absolutisation, both in one path. The fixes listed under "What is fixed" landed between 2026-08-03 and 2026-08-07, which is why the 2026-08-07 sweeps could score themselves.

Two things are worth keeping from this:

• The 2026-07-27 postmortem was correct but under-scoped. It diagnosed the mechanism precisely and then asserted a fact about frequency — "the only scheduled run" — that nobody checked. A correct diagnosis attached to an unchecked count is still a claim, and this one was false at the time.
• Unlike 2026-07-27, this run's denominator is sound. No shard was cancelled and all fifteen reports are complete, so unlike the 91% above, this 91% is a measurement of the workspace at a3c8c0f0 and is recorded in the History table as such.

One more gate defect, found by the first working sweep

Run 31193107921 was the first sweep in which all 15 shards ran to completion and the gates functioned. It still could not score itself: Mutants Summary failed at Require every shard to have completed and skipped aggregation entirely, because that check read the matrix result, which was failure — 13 shards had correctly failed on surviving mutants.

The check conflated "a shard did not finish" (score is not a measurement) with "a shard finished and did its job" (score is exactly what we want). Each shard now writes a COMPLETED marker inline at the end of its run step, so it exists if and only if cargo-mutants returned; the summary requires one per matrix entry (21 since a2a-types and a2a-client were sharded) and ignores the matrix conclusion. The marker cannot live in an always() step — those still run on cancellation, as run 30236603180 proved by uploading artifacts from cancelled shards.

The score in the older of the two rows below was produced by running that fixed aggregation by hand over run 31193107921's 15 complete reports. The newer row is CI's own output on the 21-shard matrix — same 183 survivors from a different partitioning, which is what makes the figure trustworthy rather than merely produced.

A seventh gate defect: the PR gate was blind to 41 of 141 source files

Found 2026-08-12 while re-measuring at 6ebf821. This one is not about the weekly sweep — it is the incremental, per-PR gate in mutants.yml's Build PR source diff step, and it had been silently scoping out roughly a third of the library.

The step read:

git diff -M "${BASE}...HEAD" -- 'crates/*/src/**/*.rs' > pr-src.diff
ADDED=$(grep -cE '^\+[^+]' pr-src.diff || true)
if [ "${ADDED:-0}" -eq 0 ]; then echo "skip=true" ...

A git pathspec is matched by fnmatch without FNM_PATHNAME unless it carries :(glob) magic, so * crosses / freely and the **/ in the middle collapses to "one or more directories" — the literal slash after it still has to match something. crates/*/src/**/*.rs therefore matched only files in a subdirectory of src/, and was blind to every file sitting directly in crates/<crate>/src/.

Measured at 6ebf821 with git ls-files, not deduced:

41 of 141 tracked sources — 29% — were invisible, among them server/src/rate_limit.rs, server/src/serve.rs, server/src/builder.rs, server/src/executor.rs, types/src/method.rs, types/src/signing.rs, client/src/client.rs, client/src/retry.rs, and all four lib.rs. rate_limit.rs is one of the eight largest survivor clusters in the table below, and serve.rs is one of the three weakest-covered files in ROADMAP.md.

When ADDED came out 0 the mutation step was skipped by its own if:, the job went green, and the summary printed "No Rust source files changed in crates/*/src/ — nothing to mutate", which was false. That is this page's oldest theme in a new place: not a gate that failed to fail, but a gate that declared there was nothing to measure and was believed.

Proven against real history rather than a synthetic case. Of the last 120 commits, nine changed crates/*/src sources exclusively in the invisible set, so each would have produced ADDED=0 as a PR. Replaying the CI step on three of them:

Two behavioural fixes to rate_limit.rs and a feature commit carrying 376 added source lines, none of it mutated, all three reported as nothing to mutate.

The fix is the :(glob) prefix, which gives ** the "zero or more directories" meaning readers already assume. It means "the incremental gate was green" has been a weaker statement than it looked for every PR touching only top-level modules.

A guard now exists, and it is itself proven able to fail. Fixing the pathspec fixes today's tree and nothing else; the next person to edit that line has the same trap waiting. So scripts/check_mutation_scope.sh reads the pathspec out of mutants.yml — not a copy, or it could drift from the thing that runs — and asserts it matches exactly the tracked .rs files under crates/*/src/, failing in both directions (a missed file hides code from the gate; an over-matched one can balloon a PR run past its timeout). It is gate 40 in ci.yml's fmt job, costs two git ls-files calls, and prints 141 of 141 tracked sources … are reachable by the PR gate.

It is registered in scripts/prove_gates_fail.sh as the mutation_scope injection, whose defect is the historical bug restored verbatim — drop the :(glob) prefix — and whose marker is MUTATION SCOPE GAP. Verified: with the prefix removed the check exits 1 and names all 41 files; with it, exits 0.

Worth being precise about why this is a ci.yml gate and not a probe in scripts/prove_workflow_gates_fail.py, since that harness owns the other workflows. That harness proves a step can fail on bad input. This step's input was fine — it read its git range correctly, asked for the wrong files, and reported success. It also never exits non-zero (it writes skip=true to $GITHUB_OUTPUT), so it matched neither discover()'s EXPLICIT_FAIL regex nor the curated registry, and fell through the drift guard in both directions. "Can this gate fail?" and "is this gate pointed at everything it claims to cover?" are different questions. Only the second one catches a pathspec, and nothing in the repository had been asking it.

The weekly full sweep is not affected, and that is checked rather than assumed. mutants.toml's examine_globs carry the same crates/…/src/**/*.rs shape, which is the obvious next place for this bug to live — but those are consumed by cargo-mutants' glob crate, not by git's pathspec matcher, and there **/ does mean "zero or more directories". The evidence is in the table below rather than in a reading of the semantics: run 31352927429 reported 6 survivors in rate_limit.rs, a file sitting directly in src/. A sweep blind to top-level files could not have found them. The full sweep also never passes --in-diff, so it takes no scoping from the PR diff at all. Both halves had to hold, and both do.

The conclusion stands; half the reasoning did not. See the next section: examine_globs is not consumed by cargo-mutants' glob crate or by anything else, because mutants.toml is never read. What actually keeps the sweep pointed at the whole library is -p <crate> on the command line, and what proves it is the rate_limit.rs evidence above — which is why that evidence was worth gathering instead of resting on the semantics.

An eighth gate defect: mutants.toml is not read at all

Found 2026-08-14 while chasing the EventQueueManager::destroy timeout in the 2026-08-14 row. cargo-mutants 27.1.0 discovers .cargo/mutants.toml; this repository's file is at the root. Three keys had already been documented as "silently ignored" — test_tool, profile, exclude_re — each with its own note. The cause was never per-key.

Two independent proofs, both reproducible in a checkout:

$ cargo mutants -p a2a-protocol-types --all-features --list | grep -c 'src/proto/'
155
$ cargo mutants -p a2a-protocol-types --all-features --list --no-config | grep -c 'src/proto/'
155

exclude_globs names crates/*/src/proto/** and those mutants are listed anyway — and --no-config, which disables the file, changes nothing. Disabling something that is not being read is a no-op, and that is the tell.

$ cargo mutants --config mutants.toml --list
Error: parse toml from mutants.toml
Caused by: TOML parse error at line 1, column 1
           unknown field `cap_timeout`

Pointing at the file explicitly does not run. cargo-mutants 27.1.0 rejects unknown fields outright, so a discovered mutants.toml would abort every sweep rather than configure one. No sweep has ever aborted on it, which is the second proof.

What this changes about reading the table below:

• Generated protobuf code is mutated. Every score on this page includes src/proto/ mutants. They are not excluded and never have been.
• The per-mutant budget is cargo-mutants' default 5.0x baseline with no cap, not the 3.0x / 300s the config states. Measured the same day: Unmutated baseline in 50s build + 65s test → Auto-set test timeout to 328s. 328 exceeds the 300s cap_timeout, which settles it without needing to agree on the multiplier — a cap that was applied could not be exceeded. Only the mutants-incremental job passes --timeout 300 on the command line, so the PR gate is capped and the full sweep is not.
• What does govern a sweep is the command line in mutants.yml: -p <crate> --shard --jobs 4 --test-tool=nextest --profile=mutants -- --all-features --run-ignored all, plus .config/nextest.toml, which nextest reads normally and which now supplies the per-test kill described in the 2026-08-14 row.

Not fixed here, deliberately: activating the config changes what the sweep measures, in both scope and budget, and that belongs on a sweep of its own rather than at the tail of a release. ROADMAP.md carries the plan and the numbers it would move.

Known equivalent mutants

Mutants that no test can kill, because the mutation does not change observable behaviour. Each is listed with the argument for its equivalence, so the claim can be checked rather than taken on trust. Per ADR 0006 the burden is "no test can distinguish it", not "no test occurred to me".

Superseded 2026-08-09 — this list is now empty, and nothing is excluded. The two evict mutants below were real equivalents, and they were briefly excluded by an --exclude-re pattern. Both the exclusion and the mutants are gone: the equivalence turned out to be a property of the operator, not of the logic, and rewriting the guard removed it at the source. See "How the last equivalents were retired" below. The analysis is kept because the reasoning is what makes the retirement checkable.

Neither was marked with #[mutants::skip]: that attribute resolves through the mutants crate, which this workspace did not then depend on, and adding a regular dependency to a published crate is a decision to take deliberately rather than in passing. It was taken on 2026-09-10 for the three equivalents named in the 2026-09-07 row (see ADR 0006).

How the last equivalents were retired

evict computed store.len() - max under an if store.len() > max guard, at two sites. Weakening > to >= differed only at len == max, where the mutant entered with overflow of 0, collected, sorted, and then take(0) removed nothing — unkillable by construction.

The earlier note here argued this guard could not simply be deleted the way messaging.rs's was, because it skips an O(n log n) collect-and-sort and deleting it would pay that sort on every write sitting exactly at capacity. That argument was correct, and the fix respects it: the guard is kept, and only its spelling changes.

#![allow(unused)]
fn main() {
let store: Vec<u8> = Vec::new();
let max = 10;
let overflow = store.len().saturating_sub(max);
if overflow != 0 { /* collect, sort, evict */ }
}

saturating_sub is zero exactly when len <= max, so this is the same predicate and the same short-circuit — the sort is still skipped at or below capacity. But != mutates only to ==, which inverts the guard and is caught, where > mutated to an equivalent >=.

Measured rather than asserted:

The generalisable part: an equivalent mutant is usually a branch guarding a no-op, or an operator whose weakened form reaches the same state. Both are often fixable in the source, and deleting the mutant beats teaching the gate to ignore it.

While it existed it was passed on the command line, not as a mutants.toml exclude_re entry. That detail outlives the exclusion and still governs any future one, because cargo-mutants 27.1.0 silently ignores that config key — verified with --list on 2026-08-09, after a precise pattern added there still produced the mutant it named. The same version ignores test_tool and profile identically. The pre-existing ^tracing:: and ^log:: entries in that file are therefore inert, which nothing had noticed because neither ever matched a real mutant. If you add an exclusion, confirm it took effect with cargo mutants --file <path> --list | wc -l before and after; an exclusion you believe in but that does nothing is the same class of defect as a gate that cannot fail.

Both are the same shape: a branch whose only purpose is to skip work, whose two arms coincide at the boundary the comparison tests. That pattern is worth recognising, because it will recur wherever a hot path avoids work, and because it is genuinely different from an untested branch.

Two of these were retired by deleting the branch, not by testing harder

This table held four rows until 2026-08-08. The two that left were both in handler/messaging.rs, and neither was killed — the code that generated them was rewritten so the mutation no longer exists:

The reasoning is the same in both cases and generalises. A guard of the form if len > n { trim_by(len - n) } is unkillable at len == n because the body does nothing there. Write the amount first — let excess = len.saturating_sub(n) — and the branch has nothing left to decide. drain(..0) is genuinely free: Drain::drop skips its memmove when the tail does not move, so this is O(1) rather than an O(n) shift.

This does not generalise to every guard, and the two survivors above are where it stops. evict's guard skips an O(n log n) collect-and-sort, not a no-op. Deleting it to retire a mutation-testing artefact would put a sort on every write that is exactly at capacity — paying real cycles to improve a score, which is the wrong trade and the reason those two rows remain.

The rule worth carrying forward: when the guarded work is a no-op at the boundary, delete the guard; when it is expensive, keep it and record the equivalence. The mutant is a symptom either way — sometimes of redundant code, sometimes of a deliberate optimisation.

It is not a reason to relax the target, and the equivalence rate is nowhere near uniform. messaging.rs went from 17 survivors to 0, eviction.rs from 13 to 2, dispatch/grpc/native.rs from 11 to 0, and handler/lifecycle/list_tasks.rs from 10 to 0. native.rs produced no equivalents at all because its survivors were not boundary conditions: ten of its eleven were whole-method replacements, and a method survives being replaced by Ok(Response::new(Default::default())) only when nothing calls it.

Of the 51 survivors across those four files, 49 were ordinary test gaps or removable branches. Two remain, both in eviction.rs, both for the deliberate reason given below.

Whole-method survivors name an untested layer, not a missing edge case

dispatch/grpc/native.rs is worth separating from the other two files. Its survivors were not > versus >=; they were ten of the eleven methods of the A2aService trait impl, each replaceable in its entirety by an empty Ok.

grpc_dispatch_tests.rs did exist and did pass. It covers GrpcConfig's builder, into_service, and binding a listener — it never issues an RPC. The gRPC binding had test files, test names, and no test that called it, which is exactly the state a line-coverage number is worst at revealing and a mutation score is best at.

Two things made the difference when killing them:

• Assert on content, not on is_ok(). The mutation returns a successful empty response, so assert!(result.is_ok()) passes against a method whose body has been deleted. Every test asserts a field that a default cannot carry — a task id, the configured card's name, the registered URL.
• Some methods can only be caught by their side effect. Both mutations of delete_task_push_notification_config return exactly the Ok(Response::new(())) the real method returns on success; the response cannot distinguish them at all. Only deleting a config and then listing it can.

Redundant code can be what makes a mutant killable

Worth recording because it is counter-intuitive and it cost a wrong claim.

eviction.rs originally guarded its fallback with if removed < overflow && store.len() > max, where removed counted the terminal tasks actually evicted. Four of the file's thirteen survivors were on that counter, and they survive for a provable reason: every evicted id comes from store.entries, so every removal lands, and len is max + overflow on entry — which makes removed < overflow and store.len() > max the same predicate. The counter was dead weight, so it was deleted.

Deleting it was behaviour-preserving, and it did remove those four mutants. It also turned a caught mutant into a missed one: overflow = store.len() - max → len / max had been killed by a test that only asserted the store's final size. The && short-circuit was what made that work — with a too-small overflow, removed == overflow switched the fallback off and the store was left above the cap. Without the counter the fallback re-checks the size and quietly mops up the difference, so the store lands at the cap either way and a size assertion cannot see the bug.

The mutant was still killable, just not by that test: a too-small overflow evicts one fewer terminal task and then lets the fallback take the oldest entry overall, which can be an in-flight task that should have been spared. The fix was a test that pins which tasks survive rather than how many (evict_prefers_terminal_tasks_over_an_older_in_flight_one), and it covers a policy — terminal-first eviction — that nothing had tested.

Two things generalise. Redundant logic can carry mutation-detection strength that the non-redundant version does not, so simplifying can lower the score without changing behaviour. And an assertion on a quantity is weaker than an assertion on identity whenever a later stage can compensate for an earlier stage's arithmetic. Neither is an argument against the simplification — the file ended simpler and better tested — but both are arguments for re-running the sweep after a refactor rather than assuming the score can only improve.

Per-file measurements

A full workspace sweep needs 21 CI runners; a single 4-core machine projects to well over a day for a2a-server alone (measured: 37 of 2113 mutants in ~40 minutes). Per-file sweeps are the practical unit for burning down a cluster, and they answer the question a stale survivor list cannot: is this still true of HEAD?

All rows below were run on 2026-08-09 against this branch, with a live Postgres and --run-ignored all. Exit codes are quoted because they are the only reliable signal — 0 all caught, 2 survivors, 4 baseline failed.

Across these a2a-server files: 57 survivors addressed, none remaining. Every one of the nine reports exit 0, and nothing was excluded anywhere in the project at the time — no --exclude-re, no #[mutants::skip], no baselined exception. (Since 2026-09-10 there are exactly three #[mutants::skip] attributes, none in these nine files; see ADR 0006.)

What that sentence does not cover. Nine files is not the crate. a2a-server has 2113 mutants; these nine account for 487 of them. Treat "zero survivors" as a claim about the nine rows, not the crate.

The weekly sweep ran on 2026-08-10 (scheduled 03:33 UTC, 041c3666 on main) and is the current whole-repo figure:

It exited 1, which is the workflow working: 125 survivors, reported rather than rounded away. Ten of the twelve a2a-server shards carried survivors; shards 3 and 8 came back clean.

The per-crate split, recovered 2026-08-10 by re-counting run 31352927429's 21 shard artifacts with the workflow's own counting rule (non-empty lines). This closes the gap the paragraph here previously described — the ledger now states a whole-crate a2a-server score:

The combined row reproduces the CI figure exactly, which is what makes the split trustworthy: the same arithmetic that yields 94% yields these four rows. a2a-server's 2113 total (1225 + 107 + 2 + 779) also matches the count quoted in "What that sentence does not cover" above.

The 125 is measured on a commit that predates PR #103

Read the headline with this attached. 041c3666 is 44 commits behind af7a1f8; the scheduled sweep ran at 03:33 UTC and PR #103 merged later the same day. So the 125 describes a tree that no longer exists.

Quantified rather than asserted: 61 of the 125 survivors (48%) sit in files that changed between 041c3666 and af7a1f8.

Seven of those eight are files the per-file sweeps above already took to zero survivors on 2026-08-09 — against the branch that became PR #103, which the weekly sweep had not yet seen. The counts line up closely with that table's Was column but not exactly (in_memory.rs 8 vs 7, rate_limit.rs 6 vs 5), so the two were not measured at the same commit and the overlap must not be treated as an identity.

What this does and does not license. It does not license subtracting 61 and claiming 64: the per-file runs and the sweep are different commits, and rewritten code generates new mutants as readily as it retires old ones. The only honest statement is that the current-main survivor count is not measured, that 125 is an upper bound carried from a superseded tree, and that the next scheduled sweep is what settles it. That sweep, not this paragraph, is the thing to check.

The remaining 64 survivors are in files unchanged since 041c3666, so those are valid against current main and are the ones worth triaging today.

Re-checked 2026-08-12 at 6ebf821 — and the sweep was NOT re-run

Stated plainly, because the distinction is the whole point of this page: the mutation sweep was NOT RUN in the 2026-08-12 session. Not "unchanged", not "still 125" — not measured. The machine had 4 cores (nproc), and a sweep that needs 21 CI shards does not fit there in a session; running a partial one and reporting it beside a full one is how denominators move silently. So the headline row below is still 041c366's, and git rev-list --count 041c366..6ebf821 puts it 91 commits behind main — up from the 44 recorded above against af7a1f8.

What was re-measured is the staleness itself, which is cheap and does not need a sweep:

• All eight named survivor-cluster files still changed between 041c366 and 6ebf821, so the "61 of 125 sit in changed files" half holds unchanged.
• The set of changed crates/*/src sources grew from 9 files at af7a1f8 to 13 at 6ebf821 — four more files entered it. Since the 64 "still valid" survivors were never enumerated per file, it cannot be said which of them those four touch. 64 is therefore an upper bound at 6ebf821, not a current count, and the same refusal to subtract applies as above.

The honest position is unchanged and now further from its evidence: the current-main survivor count is not measured, 125 is an upper bound carried from a tree 91 commits back, and the next full sweep settles it.

Triage of the 64 still-valid survivors (2026-08-10)

Eight of these were killed on 2026-08-10 (see the commit adding the tests): three in signing.rs canonicalization depth, four in handler/capability.rs::activated_extensions, one in parse_iso8601_to_unix_millis. Each was verified by re-applying the mutant by hand and confirming the new test goes red — a test written to kill a mutant, without checking that it does, is the unverified green this page is about.

Two are classified equivalent rather than fixed. Both days_from_civil mutants sit on the y < 0 branch of let era = if y >= 0 { y } else { y - 399 } / 400;. That branch is reachable only for year 0 with a January/February date, and every input reaching it is pre-epoch — which parse_iso8601_to_unix_millis rejects afterwards via (total >= 0).then_some(total), under the mutant as much as under the original. No observable difference through the public API, so there is nothing to test. Checked, not assumed: both mutants were reasoned through to a returned None either way.

The remaining caution on the combined row stands: it was measured on main, not on any branch in progress.

An earlier revision of this section said the honest statement was "not measured since 2026-08-03". That was true when written and false within hours — the Monday sweep it did not account for had already run. A ledger whose freshness claims are hand-maintained will keep going stale like this; the run date above is the thing to check, not the prose.

The two whole-crate rows are current and were produced on this branch: a2a-protocol-types on 2026-08-09 (674 mutants, exit 2) and a2a-protocol-client on 2026-08-10 (804 mutants, 37 minutes, exit 2). Both still carry survivors; they are listed below rather than left implicit.

Both reproduce the 2026-08-03 recovered counts exactly — a2a-client 357/10 and a2a-types 605/8, matching the table above to the mutant. Two things follow. The recovered figures were not an artefact of the archaeology: an independent sweep a week later, on a different machine, agrees. And these survivors are long-standing rather than newly introduced — neither crate's tested behaviour has moved in the interval.

Standing survivors outside a2a-server

Recorded so the count is visible rather than inferred from a missing table. Neither crate has been burned down; these are the live lists as of the sweeps above.

a2a-protocol-client — 10:

a2a-protocol-types — 8:

The last three fell to the same move rather than to cleverer tests: each was a decision buried behind machinery a test cannot drive, so the decision was moved somewhere it could be reached.

Equivalent is not the same as unkillable

The last one to fall, sync_collector.rs:240, had been recorded here as a provably equivalent mutant: the append revert runs only when a store save fails, both callers of process_event propagate with ?, and the CollectState the revert repairs is dropped without being read. Correct code and code that reverted the wrong artifact were observationally identical.

The proof was sound and the conclusion was too narrow. The revert was untestable because it was welded to an error path, not because its logic is unobservable. As a free function — revert_artifact_append(task, id, len, meta) — it is an ordinary transformation with an ordinary assertion, and the mutant dies.

Two artifacts are what make that test bite, which is the same lesson as the axum routing tests above: with one artifact != finds nothing and the revert is a no-op, indistinguishable from correctly reverting an untouched artifact. With two it truncates the bystander and leaves the intended artifact holding the failed append.

The revert was not deleted, and the contrast with the websocket size guard is the point. That guard was redundant with a cap enforced by the same constant one layer up, so deleting it lost nothing. This one is the only thing that would repair in-memory state if a caller ever handled a process_event error instead of propagating it. Deleting it would have traded a survivor for a latent correctness hole. "Delete the dead branch" and "extract the buried decision" are both available; which one applies depends on whether the code would still be wrong if it ever ran.

A refactor can manufacture a survivor

Worth recording, because it cost a round trip. Splitting check for clippy's too_many_lines originally extracted the read-lock fast path. That handed mutation testing an unkillable target: the fast path is a pure optimization, so replacing the whole function with None still reaches the same decisions through the slow path, and only lock contention differs. The sweep duly reported a survivor that had not existed before the refactor.

Extracting the slow path instead fixes it — stub that and no bucket is ever created, so every caller is admitted forever, which the enforcement tests catch at once. The rule generalises: when splitting a function for length, extract the half whose absence changes behaviour.

Two of these settle open questions:

• a2a-protocol-types 605/8 matches the 2026-08-03 artifact recount and the 2026-08-07 CI figure exactly. Three independent measurements agree, so that crate's contribution to the survivor total is confirmed at 8.
• agent_card/caching.rs is at zero, which the 2026-08-03 artifacts (7 survivors) contradict. The artifacts are simply older than the three commits that fixed it. This is the trap the survivor list sets: a cluster list is only meaningful against the commit it was measured on.

Five of the ten files above now report exit 0 — every mutant caught, and no exclusions anywhere. state_machine.rs was verified by --list only (12 mutants → 7) without a full sweep.

Three things this burndown is worth remembering for:

• The same bug wore four hats. if len > CAP { len - CAP } appeared in messaging.rs, sync_collector.rs, background/state_machine.rs and eviction.rs. Found by grepping for the shape rather than by waiting for a sweep to rediscover it, and fixed with saturating_sub — which deletes the operators rather than excluding their mutants. rate_limit.rs was the same defect in a different dress: one predicate written twice, where only the copy on the reachable path was ever tested.

• A passing test is not a killing test. The first axum_adapter routing tests asserted 404 for an unknown id — green, and worthless, because every mutant routes the request somewhere that also 404s. Seven survivors became five, not zero. The fix was to seed the task so a correct parse answers 200 and each wrong parse answers 404. 404 is the most common answer that router gives, which made it the worst possible thing to assert against a routing bug.

• A survivor can mean the code is wrong to exist. Three websocket.rs survivors lived in an oversized-message guard that cannot execute: tungstenite is configured with the same constant and rejects during the read, which ws_oversized_message_rejected already proves. It was deleted, not tested. Conversely push/sender.rs:730 looked like a latent underflow — max_attempts - 1 on a public unvalidated usize — and is not one, because the enclosing loop is for attempt in 0..max_attempts. Checked rather than reported as a bug; its five survivors were a missing retry-boundary test, which now measures the backoff on the clock.

History

Every sweep in this table ran without a database. True until the 2026-08-10 row was added on 2026-08-11; that row is the first sweep with one. Established 2026-08-09: the services: block and A2A_TEST_POSTGRES_URL were added to mutants.yml by 4b68ac4 (2026-08-09), which takes the file from 0 to 19 mentions of postgres, and that commit is an ancestor of none of b416c1a, a3c8c0f, or 803a139. The whole Postgres suite is #[ignore]d behind that variable, so in each of those runs it did not execute and its mutants survived for want of a server rather than for want of a test.

4b68ac4 is an ancestor of 041c366, and mutants.yml at that commit carries 20 mentions of postgres, so the 2026-08-10 sweep ran against a live server. The effect is visible in its survivors: the Postgres-file cluster is down to 3, all in tenant_postgres_store.rs. The 12 in pg_migration.rs and 3 in postgres_store.rs that every earlier row carries are gone — they were never test gaps, only missing infrastructure, which is what the paragraph below predicted and this row confirms.

Measured on the 2026-08-03 artifacts, that accounts for exactly 18 survivors: pg_migration.rs 12, postgres_store.rs 3, tenant_postgres_store.rs 3. pg_migration.rs in particular is not a test gap — migrations_apply_in_order_and_are_idempotent has covered it since 2026-06-10 and pins the pending_migrations boundary explicitly.

One consequence for the row below: its note that "Postgres-file survivors fell 18 → 3 once the sweep got a live database" cannot describe run 31193107921, because 803a139 has no database wiring at all, and its 18 is exactly the no-database count. The f54f33e row could not be checked the same way — that commit is not reachable in a fresh clone of main, so whether the second 2026-08-07 run had a server is unverified here, and the 3 is left unattributed rather than reassigned on a guess.