clay-borg/tools/mutation-check.py

632 lines
31 KiB
Python
Raw Normal View History

CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
#!/usr/bin/env python3
"""M-D1-MUT: does anything fail when an acceptance row's property is false?
CB-WP-0005 T02, per ADR-0005 §1. Every other instrument in this project
counts **names** M-D1-COV counts `covers:` tags, M-D1-LNK counts rule-ID
strings. Both answer "is this rule mentioned?" Neither answers "does
anything fail if it is violated?"
Four of the seven defects found by CB-RES-0004 were named in the source
and inert. Two were mutation-proven: AM-7's `hash-identical` clause
survives folding a 100k-event log from an unrelated genesis state, and
K9's `through` field survives `Snapshot::take` discarding it.
So: for each acceptance row in `specs/GameKernel.md` §5, invert the
property and require the verifying command to go **red**.
adapted:mutation-testing the denominator is acceptance rows, not
source lines. Exhaustive tools (cargo-mutants, Stryker, PIT) score a
kill rate over lines; that is slow and measures something we do not
claim. Our claims are the AM-* rows, so those are the population.
## Verdicts
red baseline green, mutant red the row is enforced
SURVIVED baseline green, mutant ALSO green the row asserts
nothing; this is the defect being hunted
unmutatable no property to invert, with a stated reason **counts
against** the metric (ADR-0005 §1). A row nobody can
invert asserts nothing.
inconclusive baseline already red, so "mutant red" would prove nothing
## Positive controls
A mutation harness that silently fails to apply its mutation reports every
row as green-baseline/green-mutant and looks thorough. So each run
asserts, per row: the file content actually changed; the baseline command
passed **before** mutating; and the file was restored afterwards. This
project has seven harness-does-nothing instances and one was found in
`rule-coverage.py` an hour ago.
Usage:
python3 tools/mutation-check.py # run every row
python3 tools/mutation-check.py --row AM-1
python3 tools/mutation-check.py --self-test
"""
import argparse
import os
import subprocess
import sys
from repo import ROOT, cargo_env, enter_root
CARGO = ["cargo"]
class Row:
"""One acceptance row and the mutation that must break it."""
def __init__(self, id, claim, verify=None, mutate=None, unmutatable=None,
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
clauses=None, expect=None):
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
self.id = id
self.claim = claim
self.verify = verify # command that must be green, then red
self.mutate = mutate # (relpath, old, new)
self.unmutatable = unmutatable
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
# CB-WP-0005 T08 / the FA class: a mutation is only evidence if it
# fails FOR ITS STATED REASON. A no-op mutation produces no failure
# at all, and would otherwise be scored as a genuine SURVIVED —
# publishing the claim that working code is broken. When `expect`
# is set, the mutant's output must contain it.
self.expect = expect
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
# A row with several stated clauses is red only if EVERY clause has
# a mutation that goes red. AM-7 is the reason this exists.
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
#
# A clause is (name, enforced, why) or (name, enforced, why,
# (verify, mutate, expect)). The clause carries its own `verify`
# because a clause the row's command cannot reach is exactly the
# case this is for. With a mutation the `enforced` flag is
# MEASURED and cross-checked against the declaration; without one
# it is only the author's word, which is what it always was.
# CB-WP-0015 T01 added the fourth field because a hand-maintained
# boolean describing whether an assertion exists is the same shape
# of claim this whole tool was built to stop trusting.
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
self.clauses = clauses or []
def rows():
"""The acceptance table, with a mutation or a stated reason for none.
Ordered as in specs/GameKernel.md §5. AM-4 splits into a/b/c, so there
are **14** rows, not the twelve ADR-0005 asserted see the
correction note in the report.
"""
py = [sys.executable]
return [
Row("AM-1", "100% of GR-rules covered by >=1 passing scenario",
verify=py + ["tools/rule-coverage.py"],
mutate=("scenarios/ground/gr-r06-round-resolve.yaml",
"GR-R06, ", "")),
CB-WP-0006 T02: instrument AM-2; report AM-3 blocked, with the argument Both rows were unmutatable for the same stated reason. They resolved differently, and the difference is the point. AM-2 is instrumented and enforced — tools/size-metrics.py, in `make all`: AM-2: 27.2 LOC/rule [ok target <= 40] (1.47x headroom) 1,575 impl lines / 58 rules Tests are excluded because AM-2 asks what a rule costs, not how much it is exercised; lib.rs is ~18% test code and including it would have flattered the number. This matters because AM-2 is AM-1's anti-gaming pair: 100% rule coverage means nothing if the rules are trivially small, and AM-1 has been reported met since CB-WP-0001 with its pair uninstrumented. Verified red by a property mutation — ~800 lines of filler injected into the impl, pushing the ratio past 40 — not a threshold tweak. The expect string is the precise failure signature "FAIL target <= 40"; my first attempt used "AM-2", which also matches passing output and would have made the FA guard vacuous. AM-3 is BLOCKED, not uninstrumented, and that is a finding rather than a deferral. It measures LOC to express the CB-RES-0001 synthetic game on our kernel, against a boardgame.io baseline of ~36 LOC for a declarative 3p commit/reveal game object. That artifact has never been built: games/ contains only ground, and benches/synthetic.rs drives GROUND rather than defining a synthetic game. Measuring GROUND's 1,575 impl lines against a 36-line synthetic game object would compare two different games and call the difference a D1 result. So the tool ships the measurement — a marker-delimited region, self-tested — and reports the row blocked, naming the missing artifact. A number would have been worse than a blank. It stays unmutatable and still counts against M-D1-MUT per ADR-0005 §1: a row that cannot fail asserts nothing, however good the reason. M-D1-MUT: 5 -> 6 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:38:15 +02:00
# A PROPERTY mutation: inflate the implementation past the ratio.
# 58 rules x 40 = 2,320; the impl is 1,575, so ~800 lines of filler
# crosses it. Raising the threshold instead would only prove the
# comparison runs.
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-2", "<= 40 spec lines per rule in games/ground",
CB-WP-0006 T02: instrument AM-2; report AM-3 blocked, with the argument Both rows were unmutatable for the same stated reason. They resolved differently, and the difference is the point. AM-2 is instrumented and enforced — tools/size-metrics.py, in `make all`: AM-2: 27.2 LOC/rule [ok target <= 40] (1.47x headroom) 1,575 impl lines / 58 rules Tests are excluded because AM-2 asks what a rule costs, not how much it is exercised; lib.rs is ~18% test code and including it would have flattered the number. This matters because AM-2 is AM-1's anti-gaming pair: 100% rule coverage means nothing if the rules are trivially small, and AM-1 has been reported met since CB-WP-0001 with its pair uninstrumented. Verified red by a property mutation — ~800 lines of filler injected into the impl, pushing the ratio past 40 — not a threshold tweak. The expect string is the precise failure signature "FAIL target <= 40"; my first attempt used "AM-2", which also matches passing output and would have made the FA guard vacuous. AM-3 is BLOCKED, not uninstrumented, and that is a finding rather than a deferral. It measures LOC to express the CB-RES-0001 synthetic game on our kernel, against a boardgame.io baseline of ~36 LOC for a declarative 3p commit/reveal game object. That artifact has never been built: games/ contains only ground, and benches/synthetic.rs drives GROUND rather than defining a synthetic game. Measuring GROUND's 1,575 impl lines against a 36-line synthetic game object would compare two different games and call the difference a D1 result. So the tool ships the measurement — a marker-delimited region, self-tested — and reports the row blocked, naming the missing artifact. A number would have been worse than a blank. It stays unmutatable and still counts against M-D1-MUT per ADR-0005 §1: a row that cannot fail asserts nothing, however good the reason. M-D1-MUT: 5 -> 6 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:38:15 +02:00
verify=py + ["tools/size-metrics.py"],
mutate=("games/ground/src/lib.rs",
"impl Aggregate for GroundState {",
"fn _am2_filler() {\n" + " let _x = 0;\n" * 800
+ "}\n\nimpl Aggregate for GroundState {"),
expect="FAIL target <= 40"),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-3", "synthetic workload definition <= 50 LOC",
CB-WP-0006 T02: instrument AM-2; report AM-3 blocked, with the argument Both rows were unmutatable for the same stated reason. They resolved differently, and the difference is the point. AM-2 is instrumented and enforced — tools/size-metrics.py, in `make all`: AM-2: 27.2 LOC/rule [ok target <= 40] (1.47x headroom) 1,575 impl lines / 58 rules Tests are excluded because AM-2 asks what a rule costs, not how much it is exercised; lib.rs is ~18% test code and including it would have flattered the number. This matters because AM-2 is AM-1's anti-gaming pair: 100% rule coverage means nothing if the rules are trivially small, and AM-1 has been reported met since CB-WP-0001 with its pair uninstrumented. Verified red by a property mutation — ~800 lines of filler injected into the impl, pushing the ratio past 40 — not a threshold tweak. The expect string is the precise failure signature "FAIL target <= 40"; my first attempt used "AM-2", which also matches passing output and would have made the FA guard vacuous. AM-3 is BLOCKED, not uninstrumented, and that is a finding rather than a deferral. It measures LOC to express the CB-RES-0001 synthetic game on our kernel, against a boardgame.io baseline of ~36 LOC for a declarative 3p commit/reveal game object. That artifact has never been built: games/ contains only ground, and benches/synthetic.rs drives GROUND rather than defining a synthetic game. Measuring GROUND's 1,575 impl lines against a 36-line synthetic game object would compare two different games and call the difference a D1 result. So the tool ships the measurement — a marker-delimited region, self-tested — and reports the row blocked, naming the missing artifact. A number would have been worse than a blank. It stays unmutatable and still counts against M-D1-MUT per ADR-0005 §1: a row that cannot fail asserts nothing, however good the reason. M-D1-MUT: 5 -> 6 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:38:15 +02:00
unmutatable="BLOCKED, not uninstrumented — the distinction "
"matters. `make size-metrics` ships the measurement "
"(a marker-delimited region) and reports the row "
"blocked, because the artifact it measures has never "
"been built: games/ contains only ground, and "
"benches/synthetic.rs drives GROUND rather than "
"defining a synthetic game. The baseline is a "
"declarative 3p commit/reveal game object (~36 LOC, "
"boardgame.io); measuring GROUND's 1,575 impl lines "
"against it would compare two different games and "
"call the difference a D1 result. Still counts "
"against M-D1-MUT (ADR-0005 §1) — a row that cannot "
"fail asserts nothing, however good the reason."),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
# The literal here must track ADR-0008 D3's corrected target. It did
# not: this row reported BROKEN on the first full run after
# CB-WP-0013 moved it 250,000 -> 161,000, because no full
# mutation-check had been run in between. Positive control 1 doing
# exactly its job — a stale find-string reported, not skipped.
Row("AM-4a", "third-party LOC, shipped runtime <= 161,000",
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
verify=py + ["tools/dep-weight.py"],
mutate=("tools/dep-weight.py",
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
'"shipped-runtime": 161_000,', '"shipped-runtime": 1_000,')),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
CB-WP-0019 T01/T02: AM-4b asks what a contributor acquires The two AM-4 budgets had the SAME scope -- one package, no dev edges -- while claiming to bound different things. AM-4b now measures the workspace with dev edges: 57 crates / 725,258 lines where it read 29 / 317,021, having been blind to 28 crates and 408,237 lines, more source than its own target. Target 745,000, ~2.7% of room -- the same margin ADR-0008 D3 gave AM-4a, applied to a number that grew because the instrument was repaired, not because anything was added. The target moved to fit the measurement. T02: proc-macros are COUNTED here and excluded from AM-4a, on purpose. AM-4a asks what ships and a proc-macro never ships. AM-4b asks what is acquired, and ADR-0007 D3's acquisition rule counts what the build fetches -- 'it does not ship' is no answer to 'we downloaded it'. When the rules disagree, the question each budget asks decides. Measured share 109,585 lines / 15.1% against AM-4a's 36.2%, so ADR-0008 D2's refusal to borrow the ratio was right by more than a factor of two. Caught by this project's own earlier work twice: the mutation find-string went stale and --self-test reported it BUILD-FREE (the check CB-WP-0015 added after AM-4a's rotted for two passes), then the DFD gate caught facts.toml carrying the old numbers. CB-EV-0001 and ADR-0004 carried live fact: tags on historical readings. A dated record asserting a CURRENT value is a category error, so those occurrences are marked as-measured instead of retro-edited, and ADR-0004 gains a supersession note. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 19:04:54 +02:00
# CB-WP-0019 T01 widened this to the whole workspace with dev
# edges, and the literal moved with it. The stale find-string was
# caught build-free by `--self-test`, which is the check
# CB-WP-0015 added after AM-4a's mutation rotted unnoticed for two
# passes. Second catch, first one that cost nothing.
Row("AM-4b", "third-party LOC, what a contributor acquires <= 745,000",
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
verify=py + ["tools/dep-weight.py"],
mutate=("tools/dep-weight.py",
CB-WP-0019 T01/T02: AM-4b asks what a contributor acquires The two AM-4 budgets had the SAME scope -- one package, no dev edges -- while claiming to bound different things. AM-4b now measures the workspace with dev edges: 57 crates / 725,258 lines where it read 29 / 317,021, having been blind to 28 crates and 408,237 lines, more source than its own target. Target 745,000, ~2.7% of room -- the same margin ADR-0008 D3 gave AM-4a, applied to a number that grew because the instrument was repaired, not because anything was added. The target moved to fit the measurement. T02: proc-macros are COUNTED here and excluded from AM-4a, on purpose. AM-4a asks what ships and a proc-macro never ships. AM-4b asks what is acquired, and ADR-0007 D3's acquisition rule counts what the build fetches -- 'it does not ship' is no answer to 'we downloaded it'. When the rules disagree, the question each budget asks decides. Measured share 109,585 lines / 15.1% against AM-4a's 36.2%, so ADR-0008 D2's refusal to borrow the ratio was right by more than a factor of two. Caught by this project's own earlier work twice: the mutation find-string went stale and --self-test reported it BUILD-FREE (the check CB-WP-0015 added after AM-4a's rotted for two passes), then the DFD gate caught facts.toml carrying the old numbers. CB-EV-0001 and ADR-0004 carried live fact: tags on historical readings. A dated record asserting a CURRENT value is a category error, so those occurrences are marked as-measured instead of retro-edited, and ADR-0004 gains a supersession note. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 19:04:54 +02:00
'"dev-toolchain": 745_000,', '"dev-toolchain": 1_000,')),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
# Deliberately RETAINED in this denominator after its withdrawal
# from the acceptance table. Dropping it would move M-D1-MUT from
# 7/14 to 7/13 without enforcing anything — a score improved by
# deleting the question.
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-4c", "own source per third-party 100k lines",
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
unmutatable="WITHDRAWN from the acceptance table 2026-08-01 "
"(CB-WP-0006 T04, GameKernel §5a) and retained here "
"as a diagnostic. The ratio has no monotone better "
"direction — rising can mean owning semantics or "
"reimplementing what should be assimilated; falling "
"can mean leverage or dependency bloat — so it "
"cannot carry a threshold. It is also redundant: "
"AM-4a/AM-4b bound the denominator and AM-2 bounds "
"own-source density. Kept in this denominator on "
"purpose, so the metric cannot be improved by "
"deleting rows."),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-5", "clean release build <= 60 s",
Fix the AM-5 instrument to measure quietly; the breach was not real T03 reported AM-5 at 87.0 s / 61.3 s and called it a 45% breach of the 60 s target. Re-measured with the fixed instrument on a quiet machine: load before measuring: 0.14 per CPU over 8 CPUs — quiet dev toolchain (default features) 37.3 s [ok target <= 60 s] best of 3: 37.3, 42.9, 46.2 (spread 1.24x) shipped runtime (--no-default-features) 41.2 s [ok target <= 60 s] best of 3: 41.2, 50.8, 54.2 (spread 1.32x) AM-5 is MET with 1.6x headroom. The 87.0 s was measured while the machine was busy with mutation-check and cargo builds — a timing measurement under contention measures the contention. That is the same error class as AM-6's, committed two tasks later in the same session by the same author, in the row immediately after the one where it was diagnosed. Knowing the failure mode did not prevent it; only building the guard did. That is the InnerLoop v1.2 design-goal argument holding up under a third instance: optimize for cheap correction, because prevention keeps not converging. The instrument now refuses to measure above 0.5 load per CPU, takes the best of 3, and warns when the spread exceeds 1.25x. Best, not worst: a build-time ceiling asks whether the machine can do it in 60 s, the mirror of AM-6's best-of-N for a throughput floor. The spread warning fired on the shipped-runtime samples — consecutive clean builds degrade 37.3 -> 46.2 — so a quiet machine is not a uniform one either. The escalation to a maintainer decision is withdrawn: there is no breach. The build profiling done while the breach was believed real is recorded in the log rather than acted on — 174 s of CPU work at only 3.2x parallelism on 8 cores, a ~22 s serial proc-macro chain, lto=thin worth ~6 s, and pinning ppv-lite86 to drop zerocopy making it worse (23 -> 25 crates). With 1.6x headroom there is nothing to buy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:37:25 +02:00
unmutatable="now RECORDED (`make build-time`) and **met**: "
"37.3 s dev toolchain, 41.2 s shipped runtime, best "
"of 3 on a quiet machine, against a 60 s target on "
"bnt-lap001 (1.6x headroom). An earlier reading of "
"87.0 s was taken under contention and was wrong. "
"Still counts "
CB-WP-0006 T03: measure AM-5 and AM-9; AM-5 breaches AM-9 is met and gated: 13.4 MB peak RSS against a 64 MB target, 4.8x headroom, in `make all` via --fast. CB-EV-0001's "very unlikely to bind" was right, but it is now measured rather than assumed, and verified red by a property mutation (a 300 MB allocation in the workload). AM-5 is BREACHED on both readings, on the machine the spec names: dev toolchain (default features) 87.0 s [FAIL target <= 60 s] shipped runtime (--no-default-features) 61.3 s [FAIL target <= 60 s] bnt-lap001, 8 cores — a direct comparison, not a directional one. A row declared "recorded not gated" and never recorded fails its own target by 45% on first measurement. The tool reports and exits 0 because the spec says the row is ungated. Gating it is a spec change needing an ADR; a tool that promotes itself is how a target starts binding without anyone deciding it should. So AM-5 stays unmutatable — for the accurate reason now — and the breach is raised as a maintainer decision: speed the build, move the target by ADR (arguing why 60 s was wrong rather than why 87 s is convenient), or withdraw the row. The measurement itself had a real bug, found only by cross-validation. getrusage(RUSAGE_CHILDREN) is a high-water mark across every reaped child, so it attributed cargo's memory to the workload and reported 38.2 MB for a run that used 12.3 MB — a 3x over-report that was plausible, passed its target, and would have been published. Fixed with os.wait4, which returns that specific child's rusage, and the self-test now cross-checks against /usr/bin/time -v. That is the false-accusation shape in the measurement layer rather than the mutation layer: an instrument confidently reporting a number it had not earned. Also: the clean build measures into a throwaway CARGO_TARGET_DIR rather than running `cargo clean`, so measuring the metric does not cost several minutes of rebuild afterwards. A metric that punishes its own measurement gets measured once and never again. M-D1-MUT: 6 -> 7 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:59:32 +02:00
"against M-D1-MUT because GameKernel §5 declares the "
"row `recorded not gated` — a row that cannot fail "
"asserts nothing, and promoting it is a spec change "
"needing an ADR. The breach is a maintainer decision, "
"not something this tool should resolve by gating "
"itself."),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-6", ">= 100,000 applied events/s",
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
# Release: the gate runs where headroom is ~24x. In debug the
# test only asserts a sanity floor, so a debug mutation run
# would need a far larger slowdown to register.
verify=CARGO + ["test", "--release", "-p", "games-ground",
"--all-features", "am6_throughput", "--",
"--ignored", "--test-threads=1"],
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
# A PROPERTY mutation, not a threshold tweak: slow the fold hot
# path and require the gate to notice. Raising the target
# instead would only prove the comparison runs.
mutate=("games/ground/src/lib.rs",
" fn fold(&mut self, event: &Self::Event) {\n"
" match event {",
" fn fold(&mut self, event: &Self::Event) {\n"
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
" for _ in 0..100_000 { std::hint::black_box(0u8); }\n"
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
" match event {"),
expect="AM-6 UNMET"),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-7", "scaling >= 0.9x, and replay of 100k events <= 5 s, "
"hash-identical",
verify=CARGO + ["test", "-p", "games-ground", "--all-features",
"replay_100k"],
mutate=("games/ground/src/lib.rs",
'assert!(elapsed.as_secs_f64() < 5.0,',
'assert!(elapsed.as_secs_f64() < 0.0,'),
clauses=[
("timing <= 5 s", True,
"the elapsed assert is live; tightening it to 0.0 s goes red"),
CB-WP-0006 T06: K10 replay bundles, --replay, and AM-7 re-earned INTENT design decision 8 of 10, unimplemented for six passes. cb-sim had no flag parsing at all, so --replay had nowhere to go. The bundle is manifest + commands.log + initial.snapshot + expected.yaml, dev-only behind the scenarios feature and charged to AM-4b. The command stream goes through the K11 framing built in T05, so a truncated bundle is detected rather than replayed short — the two tasks compose rather than duplicating. The reviewer's D2 correction was real: this was not "a directory of four files". Pass carried only the end state, RunOutcome::Failed was a formatted String, and scenario.rs created an EventLog, appended to it and never read it. All three had to change. The first round trip failed to reproduce, and the cause is worth keeping: state_hash_hex over a serde_json::Value is a different canonical form than over the typed aggregate — Value's map is key-sorted, a struct serializes in declaration order. The bundle was written with one basis and verified with the other. A round trip written to recompute its own comparison value would have PASSED this bug; it failed because the recorded hash came from the producing process, which is control 2's entire purpose. make replay-test implements ADR-0005 §6's four controls, 14/14: a committed deliberately-failing fixture outside the corpus with covers: [] so it neither fails `make sim` nor inflates AM-1; a tampered recorded hash must fail; a log short by one byte and a corrupted length prefix must be rejected; and a mutated manifest seed must fail — which bites only because replay re-derives the initial state from seed+setup and checks it against the recorded snapshot, since restoring from the snapshot alone would leave the seed inert. Plus a control on the controls: the bundle must still replay after every mutation is reverted. AM-7's hash-identical clause is re-earned. The probe records a hash per per-game segment and replays each from its own genesis; folding from the wrong seed now fails. That is the clause ADR-0005 §4 withdrew as mutation-proven inert. The scaling >= 0.9x clause is still unenforced, so AM-7 stays PARTIAL — reported, not rounded up. Kernel coverage 15/18 -> 16/18. facts-check immediately caught the spec's copy of that number going stale, on a number that moved the same hour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 11:05:37 +02:00
("hash-identical", True,
"RE-EARNED (CB-WP-0006 T06): the probe now replays each "
"per-game segment from its own genesis and asserts its "
"recorded hash. Folding a segment from the wrong seed fails."),
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
# The first clause on any row whose `enforced` flag is
# MEASURED rather than declared. It needs its own mutation
# because the row's — tightening the 5 s budget — proves
# the *timing* clause and cannot reach this one.
#
# The mutation makes fold cost grow with the number of
# events already folded, which is precisely boardgame.io's
# measured defect: throughput halving as history doubled.
# Nothing in `GroundState` grows with log length, so this
# is the only way to make the property false — see
# CB-EV-0013 §2.
#
# CONTROL, measured: AM-6's mutation adds a CONSTANT
# per-event cost. It halves throughput (28M -> 15M ev/s)
# and leaves this ratio at 0.999x, green. So AM-7 is not a
# second AM-6 — a constant slowdown is AM-6's to catch and
# a history-proportional one is AM-7's.
("scaling >= 0.9x", True,
"LIVE (CB-WP-0015 T01): `make am7` interleaves a 5k fold "
"against a 100k fold, takes the ratio inside each sample, "
"and gates the median at 0.9. Measured 0.956-1.068 over "
"three runs; the mutation drives it to 0.751.",
(CARGO + ["test", "--release", "-p", "games-ground",
CB-WP-0021 T06: fix AM-7's measurement, not its floor The row folded a 5,000-event log against a 100,000-event log and compared throughputs, which confounds 'does cost per event grow with history' (the property it claims) with 'does streaming a 20x longer Vec cost more per element' (a memory-hierarchy fact true of any program). It measured the second and reported it as the first: importing the edition enlarged the aggregate and the ratio fell to 0.845 with the state bounded. Corrected to time the SAME 5,000 events on a state at depth 0 and on a state at depth 100,000. Equal windows, equal event mix, so the only difference left is history depth. corrected: clean 1.004, mutated 0.589 (red) old: clean 0.845 (red on healthy code), mutated 0.751 It also runs in 8.5s instead of timing out: the first version re-walked the 100k prefix every repetition, 200M untimed folds per sample, which under the mutation never finished. A control that cannot be run is not a control. It now advances to depth once per sample and clones. Two of my own measurements here were wrong and both were caught by measuring again. A 2-minute timeout killed the shell line before its restoring cp ran, so three readings were taken on MUTATED code -- I diagnosed an event-mix confound that did not exist and 'fixed' it. The fix is kept on its merits; the justification was fiction. And the probe that proved state was bounded had checked four of eleven collections. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-04 01:10:38 +02:00
"--all-features", "am7_cost_per_event", "--",
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
"--ignored", "--test-threads=1"],
("games/ground/src/lib.rs",
" fn fold(&mut self, event: &Self::Event) {\n"
" match event {",
" fn fold(&mut self, event: &Self::Event) {\n"
" if let Some(c) = self.solution_deck.last().copied() "
"{ self.solution_deck.push(c); }\n"
" for c in self.solution_deck.iter().step_by(4096) "
"{ std::hint::black_box(c); }\n"
" match event {"),
"AM-7 UNMET")),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
]),
Row("AM-8", "determinism: same-seed replays bit-identical",
verify=CARGO + ["run", "-q", "-p", "cb-sim", "--",
"scenarios/ground/gr-r06-round-resolve.yaml"],
mutate=("crates/cb-kernel/src/rng.rs",
"Self(rand_chacha::ChaCha12Rng::seed_from_u64(seed.0))",
"{ static N: std::sync::atomic::AtomicU64 = "
"std::sync::atomic::AtomicU64::new(0); "
"let n = N.fetch_add(1, std::sync::atomic::Ordering::Relaxed); "
"Self(rand_chacha::ChaCha12Rng::seed_from_u64(seed.0 + n)) }"),
clauses=[
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
# MEASURED, and the measurement is the argument for keeping
# N=10 rather than amending the spec down to K8's two.
#
# The row's own mutation perturbs the seed on EVERY RNG
# construction, so it diverges on run 2 and N=2 catches it.
# This one perturbs only from the fourth construction on:
# a late-onset divergence, deterministic rather than flaky.
# Measured on gr-r06 — `--runs 2` PASSES, `--runs 10` fails
# with "run 1 hash ... != run 4 hash ... (of 10)". That is
# a class the double-run structurally cannot see.
("N=10 same-seed replays", True,
"LIVE (CB-WP-0015 T02): `make am8` runs one scenario ten "
"times against the first hash. Not all 25 — see "
"scenario::run_n for why eight more runs of a deterministic "
"check is not worth 47 s a build.",
(CARGO + ["run", "-q", "-p", "cb-sim", "--", "--runs", "10",
"scenarios/ground/gr-r06-round-resolve.yaml"],
("crates/cb-kernel/src/rng.rs",
"Self(rand_chacha::ChaCha12Rng::seed_from_u64(seed.0))",
"{ static N: std::sync::atomic::AtomicU64 = "
"std::sync::atomic::AtomicU64::new(0); "
"let n = N.fetch_add(1, std::sync::atomic::Ordering::Relaxed); "
"Self(rand_chacha::ChaCha12Rng::seed_from_u64("
"seed.0 + u64::from(n >= 3))) }"),
"K8 divergence: run 1 hash")),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
("HashMap deny lint clean", True,
"clippy.toml denies HashMap/HashSet and `make check` runs "
"with -D warnings"),
]),
CB-WP-0006 T03: measure AM-5 and AM-9; AM-5 breaches AM-9 is met and gated: 13.4 MB peak RSS against a 64 MB target, 4.8x headroom, in `make all` via --fast. CB-EV-0001's "very unlikely to bind" was right, but it is now measured rather than assumed, and verified red by a property mutation (a 300 MB allocation in the workload). AM-5 is BREACHED on both readings, on the machine the spec names: dev toolchain (default features) 87.0 s [FAIL target <= 60 s] shipped runtime (--no-default-features) 61.3 s [FAIL target <= 60 s] bnt-lap001, 8 cores — a direct comparison, not a directional one. A row declared "recorded not gated" and never recorded fails its own target by 45% on first measurement. The tool reports and exits 0 because the spec says the row is ungated. Gating it is a spec change needing an ADR; a tool that promotes itself is how a target starts binding without anyone deciding it should. So AM-5 stays unmutatable — for the accurate reason now — and the breach is raised as a maintainer decision: speed the build, move the target by ADR (arguing why 60 s was wrong rather than why 87 s is convenient), or withdraw the row. The measurement itself had a real bug, found only by cross-validation. getrusage(RUSAGE_CHILDREN) is a high-water mark across every reaped child, so it attributed cargo's memory to the workload and reported 38.2 MB for a run that used 12.3 MB — a 3x over-report that was plausible, passed its target, and would have been published. Fixed with os.wait4, which returns that specific child's rusage, and the self-test now cross-checks against /usr/bin/time -v. That is the false-accusation shape in the measurement layer rather than the mutation layer: an instrument confidently reporting a number it had not earned. Also: the clean build measures into a throwaway CARGO_TARGET_DIR rather than running `cargo clean`, so measuring the metric does not cost several minutes of rebuild afterwards. A metric that punishes its own measurement gets measured once and never again. M-D1-MUT: 6 -> 7 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:59:32 +02:00
# A PROPERTY mutation: make the workload actually use memory.
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-9", "peak RSS <= 64 MB",
CB-WP-0006 T03: measure AM-5 and AM-9; AM-5 breaches AM-9 is met and gated: 13.4 MB peak RSS against a 64 MB target, 4.8x headroom, in `make all` via --fast. CB-EV-0001's "very unlikely to bind" was right, but it is now measured rather than assumed, and verified red by a property mutation (a 300 MB allocation in the workload). AM-5 is BREACHED on both readings, on the machine the spec names: dev toolchain (default features) 87.0 s [FAIL target <= 60 s] shipped runtime (--no-default-features) 61.3 s [FAIL target <= 60 s] bnt-lap001, 8 cores — a direct comparison, not a directional one. A row declared "recorded not gated" and never recorded fails its own target by 45% on first measurement. The tool reports and exits 0 because the spec says the row is ungated. Gating it is a spec change needing an ADR; a tool that promotes itself is how a target starts binding without anyone deciding it should. So AM-5 stays unmutatable — for the accurate reason now — and the breach is raised as a maintainer decision: speed the build, move the target by ADR (arguing why 60 s was wrong rather than why 87 s is convenient), or withdraw the row. The measurement itself had a real bug, found only by cross-validation. getrusage(RUSAGE_CHILDREN) is a high-water mark across every reaped child, so it attributed cargo's memory to the workload and reported 38.2 MB for a run that used 12.3 MB — a 3x over-report that was plausible, passed its target, and would have been published. Fixed with os.wait4, which returns that specific child's rusage, and the self-test now cross-checks against /usr/bin/time -v. That is the false-accusation shape in the measurement layer rather than the mutation layer: an instrument confidently reporting a number it had not earned. Also: the clean build measures into a throwaway CARGO_TARGET_DIR rather than running `cargo clean`, so measuring the metric does not cost several minutes of rebuild afterwards. A metric that punishes its own measurement gets measured once and never again. M-D1-MUT: 6 -> 7 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:59:32 +02:00
verify=py + ["tools/runtime-metrics.py", "--fast"],
mutate=("games/ground/src/lib.rs",
" fn replay_100k_events_is_linear_and_fast() {",
" fn replay_100k_events_is_linear_and_fast() {\n"
" let hog: Vec<u8> = vec![7u8; 300_000_000];\n"
" std::hint::black_box(&hog);"),
expect="FAIL target <= 64 MB"),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-10", "0 foreign types in cb-*-api-visible signatures",
unmutatable="the population is empty — there is no `cb-*-api` "
"crate, so the claim is true over nothing. What is "
"measured instead is a clippy deny of "
"HashMap/HashSet whose stated reason cites K6 "
"(determinism), reported under a D4 leak row. "
"Withdrawn by ADR-0005 §4."),
CB-WP-0006 T05: K9's assertion, K11's format, and the AM-11 suites K11 is implemented: crates/cb-events/src/store.rs, magic + version header, 4-byte little-endian length prefix, append-only. Reimplemented not assimilated per ADR-0005 §2 — no new dependency, and AM-4a/AM-4b are unchanged at 246,250 / 317,021 because nothing entered the graph. The operative clause is "detected", so corruption is tested rather than assumed: a tail short by one byte, a half-written length prefix, a length prefix corrupted to claim more than the file holds, foreign magic, and a future format version are each rejected with a distinct error. A reader that accepts a truncated tail is worse than no format, because it silently returns a short history that looks complete. AM-11 is earned. LogStore has two impls — MemLogStore and FileLogStore — driven through ONE conformance(). The trait carries raw/set_raw precisely so the corruption controls live in the shared suite: a format contract that only one impl enforces is not a contract. The same shape is retro-fitted to KernelRng, which is what AM-11 actually names: ChaChaRng and NullRng now pass one suite asserting bounds, draw(1) == 0, determinism across fresh instances, and shuffle preserving the multiset. They were previously exercised by two separate tests, which is why "met, narrow" was never earned and ADR-0005 §4 downgraded it. K9 gets the assertion it did not have: snapshot at seq N + events N+1..M must equal the from-genesis fold, hash-compared, on GroundState, single-seed on purpose — AM-7's probe folds a multi-seed log, which is not a replay of anything, and that defect is not repeated. Two positive controls: the log must exceed 50 events, and the mid-log snapshot must differ from the end state or "apply the remainder" is vacuous. Proof it works: the exact mutation that SURVIVED in CB-WP-0005 — making Snapshot::take discard its EventSeq — now fails on the K9 assertion. AM-11's mutation breaks NullRng::draw to return its bound and the shared suite fails. That is what M-D4-SWAP claims — either impl substitutable — and exactly what two separate per-impl tests could never demonstrate. M-D1-MUT: 7 -> 8 of 14. CB-EV-0001's scoreboard is refreshed: AM-2, AM-5 and AM-9 added, AM-6 moved to enforced, and the headline total corrected from 4 to 8 — it had gone stale inside the same workplan that produced it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:50:52 +02:00
# A PROPERTY mutation: break ONE impl and require the SHARED suite
# to fail. That is what M-D4-SWAP claims — that either impl can be
# substituted for the other — and it is exactly what two separate
# per-impl tests could never demonstrate.
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-11", "null + reference impls passing ONE conformance suite",
CB-WP-0006 T05: K9's assertion, K11's format, and the AM-11 suites K11 is implemented: crates/cb-events/src/store.rs, magic + version header, 4-byte little-endian length prefix, append-only. Reimplemented not assimilated per ADR-0005 §2 — no new dependency, and AM-4a/AM-4b are unchanged at 246,250 / 317,021 because nothing entered the graph. The operative clause is "detected", so corruption is tested rather than assumed: a tail short by one byte, a half-written length prefix, a length prefix corrupted to claim more than the file holds, foreign magic, and a future format version are each rejected with a distinct error. A reader that accepts a truncated tail is worse than no format, because it silently returns a short history that looks complete. AM-11 is earned. LogStore has two impls — MemLogStore and FileLogStore — driven through ONE conformance(). The trait carries raw/set_raw precisely so the corruption controls live in the shared suite: a format contract that only one impl enforces is not a contract. The same shape is retro-fitted to KernelRng, which is what AM-11 actually names: ChaChaRng and NullRng now pass one suite asserting bounds, draw(1) == 0, determinism across fresh instances, and shuffle preserving the multiset. They were previously exercised by two separate tests, which is why "met, narrow" was never earned and ADR-0005 §4 downgraded it. K9 gets the assertion it did not have: snapshot at seq N + events N+1..M must equal the from-genesis fold, hash-compared, on GroundState, single-seed on purpose — AM-7's probe folds a multi-seed log, which is not a replay of anything, and that defect is not repeated. Two positive controls: the log must exceed 50 events, and the mid-log snapshot must differ from the end state or "apply the remainder" is vacuous. Proof it works: the exact mutation that SURVIVED in CB-WP-0005 — making Snapshot::take discard its EventSeq — now fails on the K9 assertion. AM-11's mutation breaks NullRng::draw to return its bound and the shared suite fails. That is what M-D4-SWAP claims — either impl substitutable — and exactly what two separate per-impl tests could never demonstrate. M-D1-MUT: 7 -> 8 of 14. CB-EV-0001's scoreboard is refreshed: AM-2, AM-5 and AM-9 added, AM-6 moved to enforced, and the headline total corrected from 4 to 8 — it had gone stale inside the same workplan that produced it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:50:52 +02:00
verify=CARGO + ["test", "-p", "cb-kernel", "-p", "cb-events",
"conformance"],
mutate=("crates/cb-kernel/src/rng.rs",
" fn draw(&mut self, _bound: u32) -> u32 {\n 0\n }",
" fn draw(&mut self, _bound: u32) -> u32 {\n"
" _bound\n }"),
expect="outside 0.."),
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
Row("AM-12", "tokens and USD recorded per task",
verify=py + ["tools/cb-cost.py", "--self-test"],
mutate=("tools/cb-cost.py",
'toks["output"] = max(t["output"] for t in per_row)',
'toks["output"] = per_row[0]["output"]')),
]
def run(cmd, timeout=900):
"""(ok, tail) for one verifying command, run at the repo root."""
try:
r = subprocess.run(cmd, cwd=ROOT, env=cargo_env(),
capture_output=True, text=True, timeout=timeout)
except subprocess.TimeoutExpired:
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
return False, "TIMEOUT", "TIMEOUT"
out = (r.stdout + r.stderr).strip()
tail = out.splitlines()
return r.returncode == 0, (tail[-1][:70] if tail else ""), out
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
def check_row(row):
"""(verdict, detail). Restores the tree even when the command fails."""
if row.unmutatable:
return "unmutatable", row.unmutatable
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
verdict, detail = _run_mutation(row.verify, row.mutate, row.expect)
# Clause-level mutations, where a clause carries one. Each is measured
# the same way as the row's own mutation, and the measurement is
# cross-checked against the declared `enforced` flag — a declaration
# that disagrees with its own mutation is a DFD-class defect and must
# not be reported as either verdict.
for clause in row.clauses:
if len(clause) < 4 or clause[3] is None:
continue
name, declared, _why, (verify, mutate, expect) = clause
c_verdict, c_detail = _run_mutation(verify, mutate, expect)
if c_verdict in ("HARNESS-BROKEN", "EXPECT-VACUOUS"):
return c_verdict, f"clause {name!r}: {c_detail}"
measured = c_verdict == "red"
if measured != declared:
return "HARNESS-BROKEN", (
f"clause {name!r} is declared enforced={declared} but its "
f"mutation measured {c_verdict} — the declaration and the "
f"measurement disagree")
if not measured and verdict == "red":
verdict, detail = "PARTIAL", f"clause {name!r}: {c_detail}"
return verdict, detail
def _run_mutation(verify, mutate, expect):
"""(verdict, detail) for one mutation. Restores the tree regardless."""
path = os.path.join(ROOT, mutate[0])
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
original = open(path).read()
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
old, new = mutate[1], mutate[2]
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
# Positive control 1: the mutation must be applicable at all. A
# find-string that no longer matches would otherwise mutate nothing
# and report the baseline result as the mutant result.
if original.count(old) < 1:
return "HARNESS-BROKEN", (
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
f"mutation target not found in {mutate[0]}: {old!r}")
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
# Positive control 2: the baseline must be green, or "mutant red"
# proves nothing.
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
base_ok, base_tail, base_out = run(verify)
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
if not base_ok:
return "inconclusive", f"baseline already red: {base_tail}"
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
# CB-WP-0006 T08: the FA guard is only a guard if its `expect` string
# cannot appear in PASSING output. An expect of "AM-2" would match the
# normal report and accept any failure at all — which is how the guard
# goes vacuous without anyone noticing. My first attempt on AM-2 did
# exactly that.
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
if expect and expect in base_out:
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
return "EXPECT-VACUOUS", (
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
f"expect string {expect!r} appears in PASSING output, so it "
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
f"would accept any failure — the FA guard is inert for this row")
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
try:
mutated = original.replace(old, new, 1)
# Positive control 3: the file content must actually differ.
if mutated == original:
return "HARNESS-BROKEN", "replace produced no change"
open(path, "w").write(mutated)
if open(path).read() == original:
return "HARNESS-BROKEN", "write did not take effect"
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
mut_ok, mut_tail, mut_out = run(verify)
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
finally:
open(path, "w").write(original)
# Positive control 4: restoration must have worked, or every later
# row runs against a corrupted tree.
if open(path).read() != original:
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
return "HARNESS-BROKEN", f"failed to restore {mutate[0]}"
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
if mut_ok:
return "SURVIVED", "mutant is green — this row asserts nothing"
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
if expect and expect not in mut_out:
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
# The FA guard. The mutant went red, but not for the reason
# claimed — a compile error, a panic elsewhere, an unrelated
# assertion. Scoring that as `red` would credit the row with an
# assertion it does not have.
return "WRONG-REASON", (
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
f"mutant failed, but its output does not contain {expect!r}"
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
f"this is not evidence the row is enforced")
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
return "red", mut_tail or "verifier failed as required"
def report(only=None):
rs = [r for r in rows() if not only or r.id == only]
print("M-D1-MUT — does anything fail when the property is false?")
print(f" {len(rows())} acceptance rows in specs/GameKernel.md §5")
print(" NOTE: ADR-0005 and CB-WP-0005 both say 'twelve'. There are "
"**14** — AM-4\n splits into a/b/c. The 9-of-12 prediction "
"(75%) is evaluated below\n on the same basis: >=10 of 14.\n")
tally = {}
broken = []
for r in rs:
verdict, detail = check_row(r)
# A multi-clause row is red only if every clause is enforced.
if verdict == "red" and r.clauses:
unmet = [c for c in r.clauses if not c[1]]
if unmet:
verdict = "PARTIAL"
detail = (f"{len(r.clauses) - len(unmet)}/{len(r.clauses)} "
f"clauses enforced")
tally[verdict] = tally.get(verdict, 0) + 1
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
if verdict in ("HARNESS-BROKEN", "EXPECT-VACUOUS"):
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
broken.append(r.id)
mark = {"red": "red ", "SURVIVED": "SURVIVED ",
"unmutatable": "unmutatable", "inconclusive": "inconclusive",
"PARTIAL": "PARTIAL ",
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
"HARNESS-BROKEN": "BROKEN ",
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
"EXPECT-VACUOUS": "EXPECT-VOID",
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
"WRONG-REASON": "WRONG-REASON"}[verdict]
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
print(f" [{mark}] {r.id:<6} {r.claim[:52]}")
if detail:
for line in _wrap(detail, 66):
print(f" {line}")
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
for clause in r.clauses:
name, enforced, why = clause[0], clause[1], clause[2]
# `red*` marks a clause whose flag was measured by its own
# mutation this run, not asserted by the author.
measured = "*" if len(clause) > 3 and clause[3] else " "
print(f" - "
f"{('red' + measured) if enforced else 'NONE'} "
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
f"{name}: {why[:60]}")
if broken:
# The harness asserting it did the work it reports.
print(f"\nERROR — harness broken on {', '.join(broken)}; "
f"no verdict is valid", file=sys.stderr)
return 1
red = tally.get("red", 0)
total = len(rs)
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
withdrawn = sum(1 for r in rs if "WITHDRAWN" in (r.unmutatable or ""))
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
print(f"\n M-D1-MUT: {red}/{total} rows enforced")
CB-WP-0006 T04: withdraw AM-4c; and fix where AM-6 is measured AM-4c is withdrawn from the acceptance table and retained as a reported diagnostic. GameKernel §5a carries the argument. The ratio has no monotone better direction. INTENT's rule is "own the semantics, assimilate the implementation": rising can mean owning semantics properly or reimplementing what should have been assimilated; falling can mean leverage or dependency bloat. A target requires knowing which way is better. It is also redundant — AM-4a/AM-4b bound the denominator and AM-2 bounds own-source density, so AM-4c is a ratio of two already-targeted quantities. Measured at withdrawal: 1,426 own lines per 100k third-party (shipped), 1,107 (dev). make dep-weight now prints both, labelled diagnostic — the row was never actually reported before. M-D1-MUT keeps AM-4c in its denominator on purpose and says so in the output. Dropping it would move the score 7/14 -> 7/13 without enforcing anything: a score improved by deleting the question. Decided before Phase B deliberately, since ADR-0005 predicts own-source growth that will move this ratio; deciding after would be the retarget §Step 4 forbids. A T01 correction found here. The AM-6 gate failed inside `make all` at 38,753 ev/s against 341,280 in isolation — a 9x drop, because cargo test runs binaries and threads concurrently. A throughput assertion inside a parallel harness measures contention, not throughput. T01's measurement was valid; its gate placement was not. Fixed by running it only where valid — #[ignore] plus `make am6` in release with --test-threads=1, now 2.0M ev/s at 20.2x headroom — and not by lowering the target, which T01 forbade. My first attempt did drift that way, adding a debug "sanity floor" of 50,000, and was backed out: a second threshold is still a second chance to tune. The mutation then went SURVIVED on the first run after the move. 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. Raised to 100,000; back to red. A weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change. Tier S (amends one row, creates no capability), chaos d4=2, no override. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 10:06:00 +02:00
if withdrawn:
print(f" ({withdrawn} withdrawn row(s) retained in the denominator "
f"on purpose — a score\n improved by deleting the question "
f"is not an improvement)")
CB-WP-0006 T08: control loop — 4 of 14 to 8 of 14, and a cost regression Test 1: the enforced count rose. AM-2, AM-6, AM-9 and AM-11 moved from unmutatable to red; AM-7's hash clause was re-earned so it is 2/3 rather than 1/3. Kernel spec->code link 15/18 -> 18/18, names only. Both denominators are stated. 8 of 14 is 57%, but four rows cannot be enforced — AM-3 blocked on an artifact, AM-4c withdrawn, AM-5 declared ungated by the spec, AM-10 withdrawn — so it is 8 of 10 enforceable. The 14 stays the headline and AM-4c stays in it on purpose: a score improved by deleting the question is not an improvement. Test 2: one row regressed and was caught. Moving AM-6's gate from debug to release turned its mutation SURVIVED, because 4,000 black_box iterations were calibrated against debug's 3.4x headroom and are invisible against release's 20x. The generalizable finding is that a weak mutation is not a fixed property of a row — it can become weak when the row's measurement conditions change, without the row, the mutation or the code being touched. Final SURVIVED count: 0. Test 3 is now mechanical rather than asserted. mutation-check gained an EXPECT-VACUOUS verdict: if a row's expect string appears in PASSING output, the FA guard would accept any failure at all, so the row is reported broken rather than red. Final run: 0 vacuous expects across 14 rows. The control exists because the failure happened — my first expect for AM-2 was "AM-2", which appears in the passing report and would have accepted a compile error as proof of enforcement. The cost result is a refutation, not a win. Mechanical share rose to 50%, the highest ever recorded and above the 38% baseline that motivated CB-WP-0004. That is not a tooling regression: environment setup and task closes are still at zero two passes on. It is the other half of CB-WP-0004 T06's finding arriving in force — text patching (45 turns, $13.79) and orientation (19 turns, $10.97) never had their manual path removed, and a code-heavy pass is exactly where that spends. Mean context 493,486 against a 200,000 target, up from 315,170. SessionShape has stated SS-01..SS-05 since CB-WP-0003 and none has ever been enforced — the only acceptance-adjacent numbers in this project with no gate at all, in a pass whose entire subject was ungated numbers. Numbering corrected: the workplan said CB-EV-0004, which CB-WP-0005 already used. This is CB-EV-0005. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 13:39:12 +02:00
for k in ("PARTIAL", "SURVIVED", "WRONG-REASON", "EXPECT-VACUOUS",
"unmutatable", "inconclusive"):
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
if tally.get(k):
print(f" {k:<13} {tally[k]}")
if only:
return 0
print(f"\n prediction was >=10 of 14 (the ADR's 9-of-12, 75%). "
f"Measured {red}: "
f"{'MET' if red >= 10 else 'UNMET'}")
if red <= 3:
print(" CB-WP-0005 stop condition: at or below 3 of 12-equivalent, "
"the pass is\n under-scoped and must re-plan before Phase C.")
return 0
def _wrap(text, width):
words, line, out = text.split(), "", []
for w in words:
if len(line) + len(w) + 1 > width:
out.append(line)
line = w
else:
line = f"{line} {w}".strip()
if line:
out.append(line)
return out
def self_test():
"""Each assertion pins a failure this harness must detect."""
results = []
def check(name, ok, detail=""):
results.append((name, ok, detail))
rs = rows()
check("the acceptance table is enumerated", len(rs) == 14, f"{len(rs)} rows")
check("every row has a mutation or a stated reason",
all(r.mutate or r.unmutatable for r in rs))
unmut = [r for r in rs if r.unmutatable]
check("no unmutatable row has a token reason",
bool(unmut) and all(len(r.unmutatable) > 40 for r in unmut),
f"{len(unmut)} unmutatable; a bare 'unmutatable' is how a row "
f"escapes the metric")
check("every mutation target file exists",
all(os.path.isfile(os.path.join(ROOT, r.mutate[0]))
for r in rs if r.mutate))
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
# CB-WP-0015 T03. `check_row` already reports a stale find-string as
# HARNESS-BROKEN — but only on a full mutation-check, which is
# deliberately not in `make all` because it rebuilds per row. So a
# mutation could rot for passes at a time: AM-4a's did, from the moment
# ADR-0008 D3 moved the shipped-runtime target 250,000 -> 161,000 until
# the next full run. This asks the same question with no builds at all,
# which puts it in `make all` via `self-tests`.
stale_targets = []
for r in rs:
targets = [r.mutate] if r.mutate else []
# Clause mutations rot the same way and are checked the same way.
targets += [c[3][1] for c in r.clauses if len(c) > 3 and c[3]]
for relpath, find, _new in targets:
try:
if find not in open(os.path.join(ROOT, relpath)).read():
stale_targets.append(r.id)
except OSError:
stale_targets.append(r.id)
check("every mutation find-string still matches its source",
not stale_targets,
f"stale: {', '.join(sorted(set(stale_targets)))}" if stale_targets
else "checked without building — the cheap half of check_row")
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
# The control that matters: a mutation whose find-string no longer
# matches must be reported BROKEN, not silently skipped.
stale = Row("AM-X", "fixture", verify=[sys.executable, "-c", "pass"],
mutate=("Makefile", "this-string-does-not-exist", "x"))
v, _ = check_row(stale)
check("a stale mutation target is reported broken, not skipped",
v == "HARNESS-BROKEN", v)
# And a mutation that does apply must be detected as applying.
live = Row("AM-Y", "fixture",
verify=[sys.executable, "-c",
"import sys,os; sys.exit(0 if 'ZZMARKER' "
"not in open('Makefile').read() else 1)"],
mutate=("Makefile", "PY := python3", "PY := python3 # ZZMARKER"))
v2, _ = check_row(live)
check("an applied mutation that breaks the verifier reports red",
v2 == "red", v2)
check("the tree is restored after a mutation run",
"ZZMARKER" not in open(os.path.join(ROOT, "Makefile")).read())
CB-WP-0006 T01: assert the AM-6 throughput target Nothing in the workspace compared any number to 100,000 events/s while the evidence file reported "AM-6 | met, 16.5x". Now a test does — a test, not a bench, because Criterion reports throughput and asserts nothing, which is why this row measured nothing for six passes. Measured on bnt-lap001: 341,280 ev/s in debug (3.4x the target), ~2.4-3.1M in release. The spec target holds even in an unoptimized build, so the gate needs no cfg split and runs in the ordinary `make test`. The trap this task named — loosening a flaky timing assertion until it never fires — is avoided by construction. The threshold is the spec value, untouched; the constant says lowering it requires an ADR; and the failure message repeats that, states measured headroom, and names reference figures, so an agent hitting a red AM-6 is told not to tune it in the place they are actually reading. Robustness comes from best-of-N, not from a lower bar: a throughput floor asks whether the machine is capable, so transient load should not fail the build. Two positive controls in the test: a run that applied fewer than 50,000 events, or measured zero elapsed time, fails rather than scoring as infinite throughput. Verified by a PROPERTY mutation — 4,000 black_box iterations injected into GroundState::fold, the hot path — not a threshold tweak, which would only prove the comparison runs. And the FA class found last pass is now gated. mutation-check rows gained an `expect` field: the mutant's output must contain the row's stated failure string or the verdict is WRONG-REASON, not red. Without it a mutation that merely failed to compile would credit its row with an assertion it does not have. Verified by pointing expect at a string the verifier never prints and watching the verdict flip. This is remedy (2) from the CB-WP-0005 retrospective, built a task earlier than planned because the class it guards is the newest and most dangerous. M-D1-MUT: 4 -> 5 of 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 18:32:16 +02:00
# The FA guard: a mutant that fails for the WRONG reason must not be
# scored as red. Without this, a mutation that merely fails to compile
# would credit its row with an assertion it does not have.
wrong = Row("AM-W", "fixture",
verify=[sys.executable, "-c",
"import sys; sys.exit(0 if 'ZZW' not in "
"open('Makefile').read() else 7)"],
mutate=("Makefile", "PY := python3", "PY := python3 # ZZW"),
expect="a message the verifier never prints")
v4, _ = check_row(wrong)
check("a mutant failing for the wrong reason is not scored red",
v4 == "WRONG-REASON", v4)
CB-WP-0015: the two inert clauses, AM-7 scaling and AM-8 N=10 Provenance (tier S, one paragraph in lieu of survey and ADR): the two clauses mutation-check has reported inert since CB-WP-0005. AM-7's scaling ratio was held up by a test literally named replay_100k_events_is_linear_and_fast that computed both throughputs, printed both, and never divided one by the other. AM-8's N=10 was held up by a runner that does two. Both are now red. AM-7 3/3, AM-8 2/2, M-D1-MUT 10/14, and ADR-0005's >=10-of-14 prediction MET for the first time. Neither was closed by amending the question away, which was the live risk: the denominator is unchanged and the four unenforced rows are the four already unenforceable. AM-7 needed three estimators. Best-of-N per leg then divide (AM-6's, correct for a floor on one number) gave 0.581-1.085 on an unchanged binary; legs back-to-back gave medians 0.931-1.004; legs interleaved at fold granularity give 0.987/0.991/0.989, and 0.989 under 8-way CPU contention while absolute throughput fell 4x. The INDETERMINATE guard demanded unanimity and failed a good measurement over one sample 0.001 under the floor; it now requires a two-thirds majority. The control that matters: AM-6's constant-cost mutation halves throughput and leaves this ratio at 0.999x green, so AM-7 is not a second AM-6. AM-8 kept N=10 because the measurement said so. Perturbing the RNG only from its fourth construction on: --runs 2 PASSES, --runs 10 fails. A late-onset divergence is deterministic, not flaky, so it is a control rather than a coin flip. Ten runs live on one scenario (make am8, ~2s) rather than all 25 (47s a build). GameKernel 5b records it. The full run also found AM-4a's own mutation stale since ADR-0008 D3 moved the target 250,000 -> 161,000 in CB-WP-0013 -- reported HARNESS-BROKEN, no score published. The build-free half of that check is now a --self-test assertion, so make all catches the next one. mutation-check clauses may now carry their own verify and mutation, and then the enforced flag is measured rather than declared; a declaration disagreeing with its measurement is refused. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 14:07:08 +02:00
# CB-WP-0015 T01: clause-level mutations. A clause carrying a mutation
# gets its `enforced` flag MEASURED, so the control that matters is
# that a declaration disagreeing with its own measurement is refused
# rather than reported as either verdict — otherwise the fourth field
# would just be decoration on the same hand-maintained boolean.
ok_verify = [sys.executable, "-c",
"import sys; sys.exit(0 if 'ZZC' not in "
"open('Makefile').read() else 5)"]
noop = ("Makefile", "PY := python3", "PY := python3 ")
lying = Row("AM-C", "fixture", verify=ok_verify,
mutate=("Makefile", "PY := python3", "PY := python3 # ZZC"),
clauses=[("a clause that claims more than it can show", True,
"declared enforced, but its mutation changes "
"nothing the verifier looks at",
(ok_verify, noop, None))])
v5, d5 = check_row(lying)
check("a clause whose declaration contradicts its mutation is refused",
v5 == "HARNESS-BROKEN" and "disagree" in d5, f"{v5}: {d5[:40]}")
CB-WP-0005 T02: M-D1-MUT — 4 of 14 acceptance rows are enforced For each acceptance row in GameKernel §5, invert the property and require the verifying command to go red. adapted:mutation-testing, with the denominator changed from source lines to acceptance rows. M-D1-MUT: 4/14 rows enforced PARTIAL 2 (AM-7, AM-8 — some clauses live, some inert) unmutatable 8 (no property to invert, reason stated per row) SURVIVED 0 Two corrections to our own numbers. There are 14 rows, not the twelve ADR-0005 and CB-WP-0005 both asserted — AM-4 splits into a/b/c. And the prediction of 9-of-12 (75%) becomes >=10 of 14; measured 4 (29%), badly unmet. No target moved in this commit. The second correction matters more. My first run reported two SURVIVED rows and both were my own no-op mutations: `pub struct NullRng;` -> `pub struct NullRng {}` is semantically identical, and renaming max_age_days does nothing because CA-17 reads it with a default of 90. Both would have been published as "this row asserts nothing" — a false accusation against code that is fine. Replaced with real inversions (a per-construction counter in the ChaCha seed; reverting AC-9's output resolution to the first-wins bug it was fixed for), after which both go red. T08 asks whether writing a weak mutation is the new grep. It is, demonstrably, on the first attempt. The finding is larger than the workplan assumed. 8 of 14 rows are unmutatable — AM-2, AM-3, AM-4c, AM-5, AM-6, AM-9, AM-10, AM-11 have no instrument at all. AM-6 is the sharpest: nothing in the workspace compares any number to 100,000 events/s, the headline throughput claim. The problem is not three unimplemented rules, it is that more than half the acceptance table has nothing behind it. Harness controls: a stale find-string reports HARNESS-BROKEN rather than scoring the baseline as the mutant; a red baseline reports inconclusive rather than red; the tree is restored in a finally and the restoration is verified. Not in `make all` — it rebuilds the workspace once per row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 17:27:23 +02:00
# A verifier that is already red must not be scored.
dead = Row("AM-Z", "fixture", verify=[sys.executable, "-c", "raise SystemExit(3)"],
mutate=("Makefile", "PY := python3", "PY := python3 "))
v3, _ = check_row(dead)
check("a red baseline is inconclusive, not red", v3 == "inconclusive", v3)
print("mutation-check self-test (positive control)")
ok = True
for name, passed, det in results:
print(f" [{'ok ' if passed else 'FAIL'}] {name}"
+ (f"{det}" if det else ""))
ok &= passed
return 0 if ok else 1
def main():
enter_root()
ap = argparse.ArgumentParser()
ap.add_argument("--row")
ap.add_argument("--self-test", action="store_true")
args = ap.parse_args()
if args.self_test:
return self_test()
return report(args.row)
if __name__ == "__main__":
sys.exit(main())