FAILURE — 5b stopped at m5. Driver stopped correctly; I have not repaired or re-run anything. The defect is in MY registry entry, not in the cell and not in the product. Log: .spt/preserved/hertz-304-w2-traceability/5b-run.log

RESULT: 7 of 8 invocations satisfied every check. m1, m2, m3, m4 all VERDICT-green — each named cell RED at its own assertion, exit 100, summary 1 run / 0 passed / 1 failed, failing set exactly the selected cell, not a compile failure, test region byte-identical to the pre-mutation bytes and EOL-equivalent to the pin, restore exact_bytes/pinned_equivalent/tracked_clean all True between every mutation. Floor read before every one of the 8 producers: 124.47 down to 124.33 GiB, never near the floor.

m5_enforcement_disabled / an_unenforced_rule_is_refused_loudly_after_the_pair_matches:
  exactly 1 test run, 0 passed, 1 failed, failing set exactly that cell, exit 100, not a compile failure — ALL PASS.
  "its OWN expected assertion fired" — FAIL. Driver aborted inside the try, second producer never reached (m5 has only one cell, so nothing was skipped), restore exact_bytes=True pinned_equivalent=True tracked_clean=True. Worktree now at 53d625cd, tracked tree clean.

WHAT THE RAW ACTUALLY SAYS (windows.rs:1609):
  panicked at ... "a rule that is not fully enforced is refused: true"
That is the .expect_err at the TOP of the loop body. With the enforcement arm disabled, decide() returns Ok(true) where it must return Err, so expect_err panics THERE. The assertion I registered as m5's expected text — "the refusal names the enforcement arm" — is the assert! on the NEXT line, which under this mutation is never reached because the expect_err gates it.

So the cell IS sensitive to m5, at its first enforcement claim. My MUTATIONS entry named the cell's SECOND assertion. That is a registry error of mine, in the same family as the expected-text mistakes 5a cost us.

TWO THINGS THIS EXPOSES, and the second is not just bookkeeping:

1. The fix to the entry is one string: m5's expect becomes "a rule that is not fully enforced is refused". Re-running m5 alone would then be one mutation, one invocation.

2. HONEST COVERAGE GAP. m5 proves the cell notices that an unenforced rule is ACCEPTED. It does NOT exercise the cell's second claim — that the refusal's WORDING names the enforcement arm rather than reading as a generic non-match. No mutation in the registered five makes decide() still refuse while dropping "enforcement" from the message, so that claim currently has no sensitivity evidence at all. Covering it needs a sixth mutation of a different shape (refuse, but with a message that omits the word), which I have NOT written and am NOT proposing to run without your ruling.

I am holding. Asking for one of:
  (a) correct m5's expected text and re-run m5 only (1 mutation, 1 invocation), coverage gap in 2 recorded as-is; or
  (b) (a) plus a sixth mutation for the wording claim, designed and sent to you before any producer; or
  (c) accept 7/8 and record m5 unproven.

INSTRUMENT NOTE, mine: my launch command appended an echo, so the harness reported the background task as "exit code 0" while the driver itself exited 1. The exit code I was handed was the echo's. The log carried the truth and is why this reads as a failure report rather than an END. I will drop the echo from any further launch.

Raw for every invocation preserved in 5a-raw/ under 5b filenames; stub captures remain isolated in 5b-stoppath-stub-not-producer-output/ and were not touched by this run. No field action, no elevation, no firewall write.