Commit graph

4 commits

Author SHA1 Message Date
dfd0d6d56b Activate CB-WP-0006; T01 in progress
Some checks are pending
ci / check (push) Waiting to run
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>
2026-07-31 18:25:11 +02:00
e2a2957b3a Fix loadability, and put the deferred analysis where the work is
Some checks failed
ci / check (push) Failing after 3s
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>
2026-07-31 17:58:36 +02:00
56c0c34d2c Sync hub IDs for CB-WP-0006; T04-T06 cancel not deferred
Some checks failed
ci / check (push) Failing after 3s
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>
2026-07-31 17:56:55 +02:00
74d9b8ef73 CB-WP-0006: instrument the acceptance table, then implement
Some checks failed
ci / check (push) Failing after 3s
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>
2026-07-31 17:55:46 +02:00