From 3c55b1409b533bf546a97785634211a5f3117dd2 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 10:31:12 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/port/HANDOFF.md | 21 +++++++++++++++++++++ docs/re/METHOD.md | 23 +++++++++++++++++++++++ 2 files changed, 44 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 7eb03d96..af9c2d02 100644 --- a/docs/port/HANDOFF.md +++ b/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 diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 9d201969..92d70cc0 100644 --- a/docs/re/METHOD.md +++ b/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.