# 5b m5 — the mismatch, preserved, and doyle's adjudication

hertz, 2026-09-12. This file exists because the original mismatch must survive alongside the ruling
that accepted it. Nothing below is a repair: `controls_5b_v2.py` keeps its original m5 entry, wrong
expected text and all, and m5 was NOT re-run.

## What the driver measured

Mutation `m5_enforcement_disabled` — `decide()`'s ActiveStore enforcement arm replaced with
`if false {`. One cell selected:
`bootstrap_firewall::windows::tests::an_unenforced_rule_is_refused_loudly_after_the_pair_matches`.

Every check PASSED except one:

    summary line parsed                            PASS
    exactly 1 test run                             PASS
    exactly 0 passed                               PASS
    exactly 1 failed                               PASS
    failing set is exactly the selected cell       PASS
    nextest test-failure exit (100)                PASS
    its OWN expected assertion fired               FAIL
    not a compile failure                          PASS

Raw: `5a-raw/m5_enforcement_disabled__an_unenforced_rule_is_refused_loudly_after_the_pair_matches.raw.txt`
(sha256 `332f62ffcc596c3b8212a58f716d80616e1e743a6763a3f7aa7818fef7307935`).

The driver aborted inside the try, restored (`exact_bytes=True pinned_equivalent=True
tracked_clean=True`), and launched no further producer.

## Why the check failed, from the raw

    Compiling spt-daemon v0.69.0 ... Finished `test` profile ... in 11.62s
    panicked at crates\spt-daemon\src\bootstrap_firewall\windows.rs:1609:18:
    a rule that is not fully enforced is refused: true

Line 1609 is the `.expect_err("a rule that is not fully enforced is refused")` at the top of the
cell's loop body. With the enforcement arm disabled, `decide()` returns `Ok(true)` where it must
return `Err`, so `expect_err` panics THERE. The assertion this registry entry named — "the refusal
names the enforcement arm" — is the `assert!` on the following lines, which under this mutation is
never reached because the `expect_err` gates it.

The error was in MY registry entry, not in the cell and not in the product. An expected-assertion
entry must name the assertion that fires FIRST under that specific mutation, not the one that best
describes the cell's claim.

## Doyle's adjudication (2026-09-12, msg EKWFRFR4), verbatim in substance

- He read the preserved raw himself: compilation finished; the selected test failed at `expect_err`
  because `decide` returned true.
- **m5 is ACCEPTED as regression-sensitivity evidence for rejecting unenforced rules.** The registry
  expected the wrong assertion; no m5 rerun needed.
- The original mismatch is preserved and this adjudication appended.
- **No sixth wording mutation authorized.** Do not expand the battery.

## Recorded limitation, not a pass

**Diagnostic-wording sensitivity was NOT exercised.** m5 establishes that the cell notices an
unenforced rule being ACCEPTED. It does not establish that the cell notices a refusal whose message
fails to name the enforcement arm — that is the cell's second claim, and no mutation in the
registered five makes `decide()` still refuse while dropping "enforcement" from the message. A sixth
mutation of that shape was proposed and explicitly NOT authorized. This claim carries no sensitivity
evidence and is not to be counted as covered.

## 5b battery outcome as adjudicated

Eight invocations, five mutations. Seven satisfied every check; m5 satisfied all but the expected-text
check and is accepted on the raw. Between every mutation the test region was byte-identical to the
pre-mutation bytes and EOL-equivalent to the pin, and restoration was verified by exact bytes, pinned
equivalence, and a clean tracked tree. Free space was read before each of the eight producers:
124.47 → 124.33 GiB.

## Mechanism worth carrying (NOT a tagged requirement)

A mutation that makes a function return `Ok` where the test expects `Err` fires the `expect_err`
first; every later assertion in that cell is unreachable. A registered expected-assertion string must
therefore be the FIRST-firing one under that specific mutation. Recorded here as a mechanism only —
no `REQ-*` id was minted and no traceability tag was added, because registering a new requirement is
not authorized in this lane and an untagged id would fail `traceable-reqs check`.