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

🟡 Does a .tbm draw pixels? Still open — but a submenu is now REACHED

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 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 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.

✅ Run 3 — all three fixes applied, all three needed, submenu reached

[ 288.6s] TITLE (glyph 1520)
[ 289.7s] A delivered (attempt 1)      ← confirmed from [RE-INPUT], not from the pad
[ 295.4s] MENU (glyph 327)             ← detected, not timed
[ 299.3s] A delivered (attempt 1)
[ 303.4s] SUBMENU: 87.1 % of pixels differ from the menu, glyph 314

The capture is 99.7 % inked, uniformly top to bottom — a full-screen background (capture, numbers).

Our renderer, on the archives carrying a .tbm decider:

archive	builds	inked
GP_SAVE_LOAD	19	1.9 – 3.0 %
GP_TUTORIAL	3	6.0 – 6.4 %
GP_SYSTEM	0, 1	78.4 %

So two of the three render essentially nothing where the game draws a full screen.

🔴 But which screen this is, is NOT established — and the reason is a method point

Correlation cannot discriminate when the candidate renders are near-blank. An almost-empty image has no structure to correlate against, so all 19 GP_SAVE_LOAD builds score −0.004 … −0.010 — a ranking with no information in it. ⚠️ A matching statistic is useless against a hypothesis that predicts an empty image, and that is precisely the hypothesis under test. The instrument is disabled by the thing it was brought in to detect.

🔴 And the focus could not be read either. Against the two labelled menu captures the whole-frame mean absolute difference is 2.52 (NEW GAME) and 2.48 (OPTIONS) — 1.6 % apart, far too weak to call. s00a-drive-blocked-by-focus.md already records a per-row brightness statistic failing its control; this is a second statistic failing on the same problem, which makes focus identification a real open item rather than an oversight.

✅ One thing worth keeping regardless: the game surface sits at y = 45 in the 1280×720 display frame — m[45:45+675, 0:1279] fits the committed 1279×675 captures to a mean absolute difference of 2.5. That is the alignment the earlier cross-geometry floor comparison got wrong.

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.