screen_id.py called the main menu "other". Its menu rule required a near-white
fraction above 1.5%, measured in 2026-07; the menu reached from the boot title
measures 0.03% (mean 13,26,59 — dark, strongly blue, essentially green-free).
That is worse than a cosmetic miss: a script that waits for "menu" and never
sees it reports the navigation as failed while the menu is on screen, which is
exactly what happened here. Both measured signatures are now documented in the
code and both classify.
menu_draw_capture.sh now taps ONCE on the first title rather than up to 40 times:
repeating was measured to be useless (the attract title accepts nothing) and the
first title accepts a single press.
title_states_capture.sh is new — it captures the draw list in both title states
in one run, which is what refuted the "the attract title omits the button plate"
theory.
Boot -> title -> main menu -> arm the UI draw-order capture there. What it
encodes is what cost time to learn:
* it does NOT tap (A) during the boot. A version that did delivered 88 presses
over the intro and left the guest on a black screen that never came back —
no crash, no throw, emulator healthy. The intro is ~3.5 minutes and reaches
the title on its own.
* it taps at the title until the screen stops being the title, rather than
pressing once and concluding, because acceptance is intermittent.
* after F10 it clicks the game surface, because F10 also opens the emulator's
menu bar and any Xenia UI makes IsUIActive() true, which swallows every later
guest keystroke.
It does not currently reach the menu — see docs/re/canary-scripted-input-traps.md
for the measurements. Committed because the traps are worth keeping encoded, and
because the next experiment (capture the draws in each title state) needs the
same scaffolding.
