SAFETY-38: record the CI-06 false red, and where each mutation lands

All ten mutations of `site_standing` are red in test_watchdog.py and in nothing
else - the other 19 files are green under every one of them, which is the
measurement of how unpinned the line was.

One exception, recorded rather than dropped: in the batch run M10
(`sorted(standing.values())[-1]`) also reported FAIL test_peakguard.py. Re-run
in isolation three times and once more through tools/mutation_run.sh - four
clean passes. The batch script had discarded the failure detail so the check
cannot be named; what can be said is that it did not reproduce in four attempts
and that no claim in this card rests on it. That is CI-06's file behaving the
way CI-06 records.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
This commit is contained in:
2026-09-05 19:42:06 +02:00
committed by glenn schrooyen
co-authored by Claude Opus 5
parent 0f0e767f42
commit 2cd094a0fe
2 changed files with 20 additions and 2 deletions
+5 -2
View File
@@ -91,8 +91,11 @@ shipped `sum` is correct and must not be "fixed".**
300 W gate. Closed by part 9a's device-clamped counterfactual.
* **10 mutations of that one line, each on a fresh full-repo copy mounted `:ro`,
bytecode purged by `tools/mutation_run.sh`, the edit re-read from disk and the
byte delta printed. All 10 red.** Ledger and the honest gaps in
`DECISIONS/SAFETY-38-site-standing-pin.md`.
byte delta printed. All 10 red — every one of them in `test_watchdog.py` and
in nothing else.** ⚠️ One **false red** from `test_peakguard.py` on M10 did
not reproduce in four subsequent runs; it is CI-06's known flakiness, no claim
here rests on it, and it is recorded rather than quietly dropped. Ledger and
the honest gaps in `DECISIONS/SAFETY-38-site-standing-pin.md`.
**Inverter B gets its own MQTT device, and inverter A keeps the one it has
(TEL-07).** MQTT discovery announced **one** device, and every entity hung off
@@ -189,6 +189,21 @@ fingerprint, and verifies no cache appears during the run). The mutated line was
| M9 | `sum(standing.values()) * 2.0` | +6 | **RED** |
| M10 | `sorted(standing.values())[-1]` — largest signed | +7 | **RED** |
**Every one of the ten is red in `test_watchdog.py` and in nothing else** — the
other 19 files are green under all ten, which is the measurement of how
unpinned this line was: before part 9 existed, three of these left the whole
suite green and the remaining seven were caught by SAFETY-32's structural pin or
by SAFETY-30's own N≥2 checks, none of which grade the *quantity*.
⚠️ **ONE FALSE RED, AND IT IS [[CI-06]]'s.** In the batch run M10 also reported
`FAIL test_peakguard.py`. Re-run in isolation **three times** and once more
through `tools/mutation_run.sh` — **four clean passes, zero failures**. The
batch script had discarded the failure detail, so the failing check cannot be
named here; what can be said is that the red did not reproduce in four attempts
and that **no claim in this card rests on it**. `test_peakguard.py` is the file
CI-06 records as flaky, and this is the behaviour it records. Believe no red
from it without three isolated re-runs.
M3 is listed for completeness only. SAFETY-32 already closes it **structurally**
and this card does not claim it; that the behavioural fixture also catches it is
a free consequence of the same discriminating numbers, not a second pin.