Did your test suite keep pace with the code your agents now write?

The same 536 faults were put to two versions of one suite, so neither row is a different sample. Both percentages are that one run counted twice: 82.5% is every site, and 87.7% sets aside 32 sites in a WebAssembly build and an example agent that cannot execute in the test environment, so were never catchable. Both are here because publishing only the flattering cut is the habit this work exists to catch.

In cmd/cmd_verify.go, the line that decides whether a chain verified reads:

if r.ChainPresent && r.ChainOK && !r.HeadMatched {

Change one && to || and the condition fires when it should not. On the first run the entire suite passed with that fault in place, which means nothing verified the logic that reports whether verification succeeded. On the second run a test failed, because by then one existed. The fault is the same fault; only the suite moved.

In a separate specimen, a third-party library I do not own and do not name here, one line executed 78 times during a single run of the suite. Coverage counted it as covered, correctly. A small fault injected into that line survived: every test still passed.

Exercised and unverified at once. That gap is invisible to a coverage report, and it is the gap a mutation baseline measures. The library is competent and widely used, which is the point rather than an aside.

• The specimen is my own repository. I knew where the suite was thin, which makes the second number easier to move here than it would be in code I had never read. The first number is the one nobody chose: 73.3% is what the suite scored before anyone went looking.
• It is evidence about the suite, not a grade for the code. A surviving fault says a test is missing, not that a bug is shipping.
• Some survivors are equivalent. A loosened comparison guarding a value nothing downstream observes behaves identically, and no compiler can prove which ones those are. A person still reads them.
• Scores do not compare across repositories. The mix of code shapes sets the denominator, so a parser and an orchestrator score differently for reasons unrelated to test quality.
• It says nothing about faults outside the operator set. A repository can score 100% here and still miss a race, a wrong requirement, or a fault shape never injected.

• What the number is. Whether your suite catches small injected logic faults, measured before and after. It is not a measure of developer productivity, output, or agent quality, and no number here should be read as one. The name of this engagement is broader than the instrument: what gets measured is verification, under a protocol we agree on first.
• One repository, up to three Go packages, and at most sixty faults, chosen together in writing the week before.
• First: a mutation baseline on the selected packages, read against your seat count and your weekly active users.
• Then: the worst-scoring package fixed in a branch your team reviews, using your own AI coding tools.
• Then: a written adoption plan for one champions cohort, with a named owner on every row.
• Day 28: one re-run on the same packages and a short written delta.
• Out of scope: anything that is not Go, additional repositories or packages, ongoing support, and any guarantee about adoption percentages or productivity outcomes.