re: the .tbm submenu is not reached -- and the second tap was never delivered

Two runs, neither answering whether a .tbm draws pixels.

Run 1 TIMED the title->menu transition and was still on the title 8 s later
(glyph 714, the plate's pulse trough), so the second tap did the transition and
the 'submenu' capture is the menu. Void.

Run 2 DETECTED the menu instead -- glyph 327, matching live-main-menu.png
exactly -- tapped 0.8 s later, and 12 s after that was still on the menu. The
log says why: 2 file-pad vk=5800 lines, i.e. ONE press, and one RE-INPUT
delivery. The second tap was never delivered, with zero swallow lines so it is
not the sign-in path. A 0.12 s press issued while the guest is still loading a
screen is missed outright.

So 'the press did nothing' and 'there was no press' look identical from the
screen, and only the log separates them.

Worth more than the run: this is the third time in one iteration that timing was
used where detection was required -- the title->menu wait, the menu->submenu
wait, and the press itself. Each fix is the same substitution, and each was
written only after the timed version had produced a confident wrong answer.

Also records that no focus detector is needed for this question, since every
main-menu destination except EXTRAS carries a .tbm decider.

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

docs/re/structures/tbm-submenu-not-reached.md

@@ -0,0 +1,67 @@
+# 🟡 Does a `.tbm` draw pixels? Still open — two runs, and the third timing bug in a row
+
+**Classification: not an answer.** Recorded per *"do not improvise around a
+blocker"*, and because the *reason* both runs failed is the same mistake three
+times over.
+
+## The question
+
+[`ui-forced-backdrop.md`](ui-forced-backdrop.md) has **24** of its 62 deciding
+verdicts on `.tbm` elements. `compose` draws **nothing** for a `.tbm` — no
+resolvable sprite — so those verdicts are *"correct or inert"* and the two cannot
+be separated. A capture of a screen carrying one would separate them.
+
+✅ **And no focus detector is needed**, which is what makes this cheap now.
+[`s00a-drive-blocked-by-focus.md`](../s00a-drive-blocked-by-focus.md) records that a
+per-row brightness statistic **failed its own control**, and that wrap-around makes
+counting presses useless. But *every* main-menu destination except `EXTRAS` lands on
+an archive holding a `.tbm` decider — `GP_SYSTEM` (`pqbase`), `GP_TUTORIAL`
+(`pubase`), `GP_SAVE_LOAD` (`px_replay_base`), `GP_DIALOG` (`pcbase`). So press Ⓐ on
+whatever is focused and identify the screen **from the capture**.
+
+## What happened
+
+| run | approach | result |
+|---|---|---|
+| 1 | **timed** the title→menu transition (tap, wait 8 s) | 8 s later still the **title** — glyph 714, the plate's pulse trough. The second tap did the transition; the "submenu" capture is the menu. **Void.** |
+| 2 | **detected** the menu (glyph 250–420 for 6 samples; menu is 327, plate is 714–1520) | menu found at 357.2 s, glyph **327** exactly. Tapped at 358.0 s. 12 s later: **still the menu.** |
+
+## 🔴 The second tap was never delivered
+
+| | |
+|---|---|
+| `[file-pad] vk=5800` lines | **2** — that is *one* press, down and up |
+| `[RE-INPUT] -> user=0 vk=5800` | one down, one up |
+| `swallowed by IsUIActive` | **0** — not the sign-in path |
+
+The tap came **0.8 s after the menu appeared**, while the guest was still loading
+it. A **0.12 s** press is missed outright if the guest does not poll during that
+window. The pad driver reports what *it* emitted; the guest never asked.
+
+⚠️ **So "the press did nothing" and "there was no press" look identical from the
+screen**, and only the log separates them. Any driven run that presses and waits
+must **confirm delivery in the log** before interpreting the result — otherwise a
+missed press reads as a screen that did not respond.
+
+## The pattern worth more than the run
+
+This is the **third** time in one iteration that timing was used where detection was
+required — the title→menu wait, the menu→submenu wait, and the press itself
+(assumed delivered rather than confirmed). The first two were caught because the
+screen was recognisable; the third only because the log records deliveries.
+
+📌 Each fix has the same shape: **replace "wait long enough" with "watch for the
+thing".** The title detector, the menu detector and the delivery check are all that
+substitution, and each was written only after the timed version had already produced
+a confident wrong answer.
+
+## What is now validated, and what the next run needs
+
+✅ Working: the plate-pulse title detector (three runs); the **menu detector**, glyph
+**327**, matching `live-main-menu.png` exactly; and delivery confirmation from
+`[RE-INPUT]`.
+
+**Next run:** hold Ⓐ longer than 0.12 s, **confirm the `[RE-INPUT]` line appears**,
+retry if it does not, then detect the submenu **by change** rather than by timer —
+a submenu load may also pass through a `pgloading_*` screen, so "different from the
+menu" is the signal, not a fixed wait.