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>
Workplan status proposed -> in_progress, T01 (assert the AM-6 throughput
target) todo -> progress. Local files are source of truth; the hub
reflects them after sync.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
loop-lint failed: CB-WP-0005 was 401 lines against a ~400 limit, one over,
after the status-vocabulary note. Pushed before checking — my error; the
gate caught it on the next run.
The fix is not a trim. The gate exposed a circular reference I had
created: CB-WP-0005's cancelled tasks held the full analysis while
CB-WP-0006 pointed back at them for detail, so the live workplan deferred
to a cancelled one. The analysis now lives in CB-WP-0006 Phase B next to
the work, and CB-WP-0005 keeps a forward pointer per task. One copy,
single source of fact, and the reference points forward.
CB-WP-0006 T05 and T06 gain the detail that moved: K9's mutation proof and
what its acceptance property actually is, K11's detection clause and
budget attribution, and the D2 correction the reviewer forced — the bundle
is not "a directory of four files" but a change to the runner's data flow,
because scenario.rs creates an EventLog, appends to it and never reads it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The hub's task status vocabulary is wait|todo|progress|done|cancel, so
'deferred' was rejected by fix-consistency. 'cancel' is the accurate one:
these task records are superseded and equivalents live in CB-WP-0006
T05-T07. The work is deferred, not abandoned, and the workplan says so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Scoped to what CB-WP-0005 T02 measured rather than what CB-RES-0004
predicted. The survey diagnosed three absent kernel rules; M-D1-MUT found
that 8 of 14 acceptance rows have no instrument behind them at all.
Phase A instruments the unmeasured rows, starting with AM-6 — nothing in
the workspace compares any number to 100,000 events/s, the project's
headline throughput claim, reported as "met, 16.5x". Phase B carries the
kernel work deferred unstarted from CB-WP-0005 Phase C. That order is the
point: the previous pass built a fix before its instrument existed and
the instrument then contradicted the fix's premise.
T01 names its own trap up front: a timing assertion in CI is flaky by
nature and the usual response is to loosen it until it never fires, which
would reproduce exactly the defect being fixed. The threshold is pinned
far below measured, states its headroom in the failure message, and
loosening requires an ADR.
T04 notes an incentive worth blocking early: ADR-0005 predicts own-source
growth from Phase B, so AM-4c will move against us. Setting its threshold
after seeing that movement is the retarget InnerLoop §Step 4 forbids, so
it is set before Phase B or not at all.
T09 asks the question this pass is positioned to answer: M-D1-MUT does
not remove a manual path — writing a weak mutation is exactly as easy as
writing a strong one and the harness cannot tell them apart. CB-WP-0005
produced two no-op mutations on its first attempt, so the failure mode is
demonstrated. And it fails in the dangerous direction: a weak mutation
does not miss a defect, it indicts working code.
CB-WP-0005 T04-T06 are marked deferred rather than deleted, with their
analysis intact, so the trail from prediction to contradiction to re-plan
stays readable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
