8bea94a47f
Two separate reasons the scripted route stopped, both measured rather than guessed: * LOAD -> READY ROOM is not 28 s. Both runs on 2026-08-23 overran it, so the next press was eaten by the transition and the run ended up in OPTIONS once and BRIEFINGS once. wait_screen.sh now waits for the screen, with an optional --tap that clears a dialog the caller cannot know about (a freshly restored profile inserts "Auto-Save is active. OK?" here). * The READY ROOM is DRAWN long before it is USABLE: it comes up with a "Preparing to Sortie" spinner and TAKE OFF greyed out. The two states differ by 1.7 units of blue whole-image, so screen_id.py cannot separate them and should not try. take_off_armed.py tests the label instead: 0.0000 bright pixels while preparing, 0.1633 once armed, on three captures from two runs. It carries its own position check - the always-enabled BRIEFINGS label below reads 0.1027 in all three, to four decimals, so if that reference is dark the boxes are off the labels and the answer is "unknown", not a confident wrong one. screen_id.py gains a "readyroom" class from the same measurements; nothing else reclassifies. Verified end to end and unattended: boot -> title -> LOAD GAME -> slot 01 -> READY ROOM -> TAKE OFF -> "IN FLIGHT at 34s", pilot bound and engaging. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE