tools: a working route to the menu, and the classifier that could not see it

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.

tools/re-capture/menu_draw_capture.sh

@@ -41,16 +41,14 @@ while [ $SECONDS -lt $deadline ]; do
 done
 [ "$s" = "title" ] || { echo "NEVER REACHED THE TITLE"; exit 1; }
 
-# 2. tap until it takes
-taps=0
-while [ $taps -lt 40 ]; do
-  python3 "$SD/pad.py" tap A 0.2; taps=$((taps+1))
-  sleep 1
-  s="$(screen)"
-  if [ "$s" != "title" ]; then
-    sleep 3; s="$(screen)"
-    [ "$s" = "menu" ] && { echo "MENU after $taps taps"; break; }
-  fi
+# 2. ONE tap on this title. Measured: the title that ends the boot sequence
+# accepts a single (A) (2 of 2 runs); the title the attract loop returns to
+# accepts nothing at all, and 40 taps at 1/s do not change that. So the tap must
+# land on the FIRST title, and repeating is pointless.
+python3 "$SD/pad.py" tap A 0.3
+for _ in 1 2 3 4 5 6; do
+  sleep 4; s="$(screen)"; echo "  after A: $s"
+  [ "$s" = "menu" ] && { echo "MENU"; break; }
 done
 shot "$OUT/menu.png"
 [ "$s" = "menu" ] || { echo "NO MENU after $taps taps (screen=$s)"; exit 2; }

tools/re-capture/screen_id.py

@@ -61,8 +61,19 @@ def classify(f):
     # Flight first: the HUD paints far more green than any menu.
     if f["green"] > 0.004:
         return "flight"
-    # The main menu is dark and strongly blue, with the five white labels.
-    if f["b"] - f["r"] > 30 and f["r"] < 45 and 0.015 < f["white"] < 0.075:
+    # The main menu is dark and strongly blue. TWO measured signatures, not one:
+    #
+    #   white 3.5%   mean (25, 38, 70)   the 2026-07 reference at the top
+    #   white 0.03%  mean (13, 26, 59)   measured 2026-08-18, twice, on the menu
+    #                                    reached from the boot title
+    #
+    # The second one classified as "other" under the original rule's
+    # `0.015 < white` floor, which is worse than it sounds: a script that waits
+    # for "menu" then never sees it reports the navigation as FAILED while the
+    # menu is plainly on screen. Both variants are dark, strongly blue and
+    # essentially green-free, so key on that and let the near-white fraction be
+    # anything below the title's 3.8%.
+    if f["b"] - f["r"] > 30 and f["r"] < 45 and f["white"] < 0.075:
         return "menu"
     # The title is brighter, still blue-ish, and carries the green PRESS A text.
     if f["green"] > 0.0004 and f["b"] > 60 and f["white"] > 0.03:

tools/re-capture/title_states_capture.sh

@@ -0,0 +1,59 @@
+#!/usr/bin/env bash
+# Capture the UI draw list in BOTH title states, in one run:
+#   (1) the title that appears at the end of the boot sequence, and
+#   (2) the title the attract loop comes back to.
+#
+# The question is whether they composite differently — specifically whether the
+# interactive one draws `ptbtn00` (the PRESS (A) BUTTON plate, GP_TITLE build 2)
+# and the other does not. That would give an observable tell for the state in
+# which (A) is accepted, which is currently a matter of luck.
+#
+# NO pad input at all: a press is what we are trying to explain, and tapping
+# through the boot has ended a run on a permanent black screen before.
+set -u
+export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
+SD="$(cd "$(dirname "$0")" && pwd)"
+OUT="${1:-/sylph-home/re/titlestates}"
+mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
+shot(){ screenshot "$1" >/dev/null 2>&1; }
+screen(){ shot /tmp/tsc.png; python3 "$SD/screen_id.py" /tmp/tsc.png | awk '{print $1}'; }
+alive(){ ps -o pid=,stat= -C xenia_canary 2>/dev/null | awk '$2 !~ /^Z/ {print $1}'; }
+
+( cd "$OUT" && nohup run-canary --mem_watch=false --log_ui_draws=true \
+    --ui_draw_capture_frames=4 --ui_draw_capture_max=4000 \
+    --logged_profile_slot_0_xuid=B13EBABEBABEBABE \
+    >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
+sleep 8
+until xdotool search --name "Xenia-canary" >/dev/null 2>&1; do
+  [ -n "$(alive)" ] || { echo "EMULATOR GONE"; exit 4; }; sleep 1
+done
+win="$(xdotool search --name "Xenia-canary" | tail -1)"
+
+arm(){   # arm the capture and dismiss the menu bar F10 also opens
+  xdotool windowactivate --sync "$win"; sleep 1
+  xdotool key F10; sleep 3
+  xdotool mousemove 900 400 click 1; sleep 2
+}
+
+wait_for(){  # wait_for <screen> <timeout>
+  local want="$1" deadline=$(( SECONDS + $2 )) s
+  while [ $SECONDS -lt $deadline ]; do
+    s="$(screen)"; echo "  t=${SECONDS}s $s (want $want)"
+    [ "$s" = "$want" ] && return 0
+    sleep 4
+  done
+  return 1
+}
+
+echo "== phase 1: the boot title"
+wait_for title 420 || { echo "NO BOOT TITLE"; exit 1; }
+shot "$OUT/title-boot.png"; arm
+echo "== phase 2: wait for the attract movie to take over"
+wait_for other 240 || echo "  (never left the title)"
+echo "== phase 3: the attract title"
+wait_for title 420 || { echo "NO ATTRACT TITLE"; exit 2; }
+shot "$OUT/title-attract.png"; arm
+
+ls -l "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null
+grep -i "UI-CAP" "$OUT/canary.stdout" | tail -6
+echo "TITLE STATES CAPTURE DONE (emulator left running)"