coulomb/clay-borg
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Condense CB-WP-0005 T02's note to a pointer at CB-EV-0004
Some checks failed
ci / check (push) Failing after 3s
Details

Browse source 
loop-lint failed at 406 lines, third time this file has bumped the ~400
limit. Trimming again would have been the wrong fix: the T02 delivery note
duplicated CB-EV-0004 Test 2 almost verbatim, which is a duplicated fact
in the workplan that most recently added a duplicated-fact gate.

The workplan now holds task definitions and short outcomes; the evidence
file holds the analysis. 395 lines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-31 18:08:28 +02:00
parent 3f3d437417
commit 245d7fd3e5
1 changed files with 12 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

35
workplans/CB-WP-0005-assertion-coverage.md
View file

@ -140,31 +140,20 @@ unmet.**
SURVIVED 0 SURVIVED 0
``` ```
**First correction: there are 14 acceptance rows, not 12.** ADR-0005 and Two corrections, detailed in [CB-EV-0004](../evidence/CB-EV-0004-assertion-coverage.md)
this workplan both said twelve; AM-4 splits into a/b/c. The 9-of-12 (75%) Test 2. **There are 14 rows, not 12** — AM-4 splits into a/b/c, so the
prediction is evaluated as ≥10 of 14 on the same basis. Measured 4 (29%). 9-of-12 prediction is evaluated as ≥10 of 14. And **the first run's two
`SURVIVED` verdicts were my own no-op mutations**, either of which would
**Second correction, and the one that matters: my first run reported two have published a false accusation against working code; replaced with real
SURVIVED rows, and both were my own bad mutations.** inversions, after which both go red. T08's question is answered on the
first attempt.
- AM-8: `pub struct NullRng;` → `pub struct NullRng {}` — semantically
identical, a no-op.
- AM-12: renaming `max_age_days` in the price sheet — CA-17 reads it with
`.get("max_age_days", 90)`, so removing it changes nothing.
Both would have been published as *"this row asserts nothing"* — a false
accusation against code that is in fact fine. Replaced with real
inversions (inject a per-construction counter into the ChaCha seed;
revert the AC-9 output resolution to the first-wins bug it was fixed for),
after which both go red. **T08's question — "is writing a weak mutation
the new grep?" — is answered on the first attempt: yes, demonstrably.**
**The finding is larger than the workplan assumed.** 8 of 14 rows are **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 `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 instrument at all. AM-6 is the sharpest: **nothing compares any number to
compares any number to 100,000 events/s**, the headline throughput claim. 100,000 events/s**, the headline throughput claim. The problem is not
The problem is not three unimplemented rules; it is that **more than half three unimplemented rules; it is that **more than half the acceptance
the acceptance table has nothing behind it.** table has nothing behind it.**
Harness controls: a stale find-string reports `HARNESS-BROKEN` rather than Harness controls: a stale find-string reports `HARNESS-BROKEN` rather than
scoring the baseline as the mutant; a red baseline reports `inconclusive`; scoring the baseline as the mutant; a red baseline reports `inconclusive`;