Pin three claims the code was keeping by accident

[stan-ely]

Three issues from the dev.to thread, all raised by @superfunicular. None is a bug report. Each names a promise the code currently keeps by accident rather than by construction, and asks for the thing that makes it survive the next edit.

test(room) — the secret never appears on the wire (#2)

The room-ID bug had a shape the suite could not see: the transfer completed, the file arrived, and the only casualty was a claim in the README. This file's two existing invariants are both feature-shaped and neither would have noticed it.

So the promise is written down, checked against every encoding it could plausibly leak as — base64url, the qrdrop: code form, standard base64, hex in both cases, and a raw byte-run scan over the binary payloads. fake-network.mjs grows sent (every namespace, taken before target filtering, since a relay sees a send regardless of who it was addressed to) and joins (the Trystero config, previously discarded as _config, and the one place a derived value could be swapped for the secret with no payload changing). announced is untouched — it is load-bearing in a passing test that asserts a count.

It passes trivially today, which is the point: it exists for whoever later reads deriveTopic, notices it is hashing 32 bytes that were already random, and concludes the hash is ceremony.

Verified it can fail. Injected both halves of the bug in turn — deriveTopic returning the secret, then derivePassword returning it — and in each case this test failed alone while the other four stayed green.

feat(web) — name the mismatch, pin the invariant (#3)

Four symbols out of 64 is 24 bits, and that is strength only at one attempt per secret. Bits × shots, where the shots are a property of how the screens are wired.

We already had one roll per secret, emergently: cancel → _reset() → choose, and the only way back is _startSend(), which mints fresh bytes. Nothing stated it and no test pinned it. The screen also never said "they don't match" at all — one primary and a neutral Cancel, so a user staring at four symbols that differ had nothing to press meaning what they saw.

• verifyStatus gains "They don't match" → new verify:reject intent → _rejectVerification, which ends the session and lands on done with a new mismatch outcome. Not _reset() (the silent bounce being fixed) and not _failTransfer() (nothing failed; an error sheet is the wrong register for a decision made correctly).
• Restart reads "Start over with a fresh code", not "Send another file" — which would be true, and would quietly invite the one thing that must not happen.
• Reusing state.outcome rather than adding a screen keeps SCREENS, builders, STEP_INDEX and the vdom's positional child matching untouched.
• The button is deliberately not .primary: e2e/transfer.e2e.mjs clicks #verify-status button.primary, and a second one is a strict-mode throw in the suite that needs two browsers and a relay to run. New .btn.danger is outlined rather than filled and reuses the --bad pair already defined in both palettes.

test/view.test.mjs is new, and is the first Node unit coverage src/web/view.js has ever had — render() is pure and h() builds plain objects, so the tree walks in bare Node with no jsdom and no new dependency. It fires every onclick on verify at a recording dispatch and fails on any pairing intent by name.

Verified it can fail. Added exactly the "Try again" button the issue warns about; it failed alone, quoting the reason.

One thing only the screenshots could show, with check-layout green throughout: the mismatch screen drew the "Local network" path badge directly beside "something is relaying between them" — accurate about the route to the peer we paired with, and reading as reassurance about the connection the user has just been told not to trust. _rejectVerification clears path, alone among the outcomes.

Sender-only, matching the issue's scope. The receiver sees the same symbols and a mismatch means the same thing there, but its verify screen already carries Accept and Decline and the copy is a separate question — worth its own issue.

docs(security) — the exposure window (#4)

The docs answered this with an instruction, and an instruction is the weakest control available. The threat model now states it precisely: the topic is HKDF(secret, "topic") and does not expire; pairing latches on first arrival, so a code is spent for pairing purposes once a pairing settles; that latch is the only thing closing the window, and first-to-arrive can be the attacker; there is no TTL, so the window is the sender's unpaired tab lifetime.

Net, stated plainly because it is the sentence someone needs before hitting record: a QR in a recording is a live code precisely while the sender is still waiting for someone to scan — the same moment a screen share is typically running.

SECURITY.md gains one sentence pointing at it rather than a second copy of the reasoning. Out of scope, deliberately: rotating the code on a timer. It would close the window properly, at the cost of tearing down and re-establishing a room mid-screen with a race if a peer arrives during rotation — worth its own issue rather than a paragraph promising it. Happy to open one.

CLAUDE.md's existing "two safety gestures cannot be softened" invariant absorbs the one-roll rule, rather than a second bullet elsewhere.

Verification

• npm test — 161 pass (was 158)
• npm run typecheck — both passes clean
• check-layout.mjs — both deployed trees, both engines, all four viewports with the pointer axis crossed, including the new done-mismatch fixture
• Screenshots reviewed at 390px and 800×360, then deleted

Not run: test:e2e needs public relays and is out of CI; test:e2e:interop is known-flaky. The new #verify-status single-.primary assertion is the cheap stand-in for the e2e selector.

Closes #2
Closes #3
Closes #4