method: 'it did nothing' and 'it never happened' look identical from outside

An A press produced no screen change; the obvious reading was that the button did
nothing. The log said the press was never delivered -- two file-pad vk=5800 lines
across the whole run is ONE press -- because it was issued 0.8 s after a screen
appeared, while the guest was loading and not polling.

The pad driver reports what it emitted, so a script checking its own output sees
success either way. Confirm the receiving side.

Generalised: when an action produces no observable effect, the first hypothesis
is that the action did not occur, not that it had no effect. The corpus has paid
for this twice -- here, and in the sign-in swallow where thousands of delivered
keystrokes were discarded inside the emulator and looked exactly like a dead pad.

Companion to the control entries: a control proves the instrument reads
correctly; a delivery check proves the experiment happened at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/port/HANDOFF.md

@@ -2533,6 +2533,27 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
 fine from inside. Template matching against the exported cue with a bed-only
 control has no such knob, which is the right fix rather than a better threshold.
 
+## 🟡 2026-08-30 — the `.tbm` question is still open (two runs), and a driving trap you should know
+
+Not something you need — none of the 24 `.tbm` deciders is on your five screens —
+but the *trap* generalises to anything driven.
+
+Trying to reach a submenu carrying a `.tbm`, **the second Ⓐ was never delivered**:
+2 `[file-pad] vk=5800` lines is *one* press, one `[RE-INPUT]` delivery, and **zero**
+swallow lines so it is not the sign-in path. The tap came 0.8 s after the menu
+appeared, while the guest was still loading it, and a **0.12 s** press is missed
+outright if the guest does not poll in that window.
+
+⚠️ **"The press did nothing" and "there was no press" look identical from the
+screen.** Only the log separates them.
+
+📌 And the pattern: that was the **third** time in one iteration I timed something
+that had to be detected — the title→menu wait, the menu→submenu wait, and the press
+itself. Every fix is the same substitution — *watch for the thing instead of waiting
+long enough* — and each got written only after the timed version had produced a
+confident wrong answer.
+[`tbm-submenu-not-reached.md`](../re/structures/tbm-submenu-not-reached.md)
+
 ## ✅ 2026-08-30 (final) — the window is **`-ss 9.44 -t 61.87`**
 
 `loop_start` is **9.44 s**, measured. Your `loop_start_s` field — authored as 0.0

docs/re/METHOD.md

@@ -1459,3 +1459,26 @@ the stale text **still present**, because the replacement *quotes* the refuted
 sentences in order to name them — so a substring search matches them inside the
 paragraph saying they are false. The match was real and meant the opposite of what
 the search implied. This is "the tell is in the rows that agree" arriving as a grep.
+
+## "It did nothing" and "it never happened" look identical from the outside
+
+Driving the menu, an Ⓐ press produced no screen change and the obvious reading was
+that the button did nothing. The log said otherwise: **two** `[file-pad] vk=5800`
+lines across the whole run — one press, not two — and one `[RE-INPUT]` delivery. The
+second press was **never delivered**. It was issued 0.8 s after a screen appeared,
+while the guest was still loading and not polling, and a 120 ms press vanishes in
+that window.
+
+The pad driver reports what *it* emitted, so a script that checks its own output
+sees success either way. **Confirm the receiving side**, not the sending side:
+`[RE-INPUT] … -> user=0 vk=5800` is the guest saying it got one.
+
+⚠️ Generalised: whenever an action produces no observable effect, the first
+hypothesis is *"the action did not occur"*, not *"the action had no effect"* — and
+those need different evidence. This corpus has now paid for it twice: here, and in
+the sign-in swallow, where thousands of *delivered* keystrokes were being discarded
+inside the emulator and looked exactly like a dead pad.
+
+📌 Companion to the entry above about controls: a control proves your instrument
+reads correctly; a **delivery check** proves the experiment happened at all. They
+are different, and only the second one catches a null result that never ran.