re: F1 harness built and committed; the run did not reach the menu

The port needs an initial delay and a repeat interval and has shipped the
mechanism with -1.0 rather than invent them. This builds the instrument and
does not get the numbers.

The vertex stream is the right instrument: C_PAD_DECODER has no timer on
any direction path, so the repeat is in the layer above and cannot be read
out of that function; a cursor move is a quad changing position, and the
guest's vertex buffer carries that with no Canary processing in the path.

tools/re-capture/menu_repeat_probe.sh arms the logger, drives the boot with
pad-file presses and holds a direction. It ran its whole sequence. But the
boot did not reach the menu: in the settled era every quad shape holds a
constant y, and the shapes are near-full-screen rects rather than a button
list. No cursor, so nothing to repeat.

Two instrument errors worth more than the failed run.

The first attempt ARMED NOTHING and said nothing -- xdotool search --class
... --window %1 F10 behind a || true. The run completed normally and only
the ABSENT log revealed it. The working form looks the window up by name,
activates it, and sends F10 to the window and globally; a missing window is
now fatal rather than tolerated, because a silent arming failure is
indistinguishable from a screen that draws nothing.

My first cursor detector measured the wrong change: presents where the SET
of quads changed, which fired on 157 of 161 adjacent pairs because during a
build-in everything animates. Tracking one quad shape's POSITION instead
correctly reports no motion. That is the play-test's own lesson landing on
me -- an instrument that measures change can still measure the change of
the wrong thing.

Next run must not drive the boot blind: gate the presses on a classifier or
join with boot_menu.sh, which reaches the menu but takes screenshots rather
than draw logs. Blind was chosen because screenshots cost ~10 s each while
xenia runs; wrong trade, since a mistimed press costs the whole run.

Reach: the negative is about this run, not the game. F1 stays open and the
port should keep its -1.0 constants.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

tools/re-capture/menu_repeat_probe.sh

@@ -0,0 +1,57 @@
+#!/usr/bin/env bash
+# F1 -- MEASURE THE MENU REPEAT RATE, as a count of presents between cursor moves.
+#
+# The human watched the real game: a held direction repeats. `C_PAD_DECODER` has
+# no timer on any direction path (pad-decoder-double-tap-not-key-repeat.md), so
+# the repeat is in the layer above and can only be MEASURED here.
+#
+# Instrument: the guest's own vertex stream via the UI draw logger -- the same
+# instrument that settled the splash, and the one with no Canary processing in
+# it. A cursor move shows up as the focused quad's NDC rect changing.
+#
+# ⚠️ Drives the boot BLIND on timings rather than classifying frames. That is
+# deliberate: the classifier route costs a screenshot per poll, and screenshots
+# cost ~10 s each while xenia runs. The draw log records what actually happened,
+# so a mistimed press is visible in the result rather than silently assumed.
+#
+#   menu_repeat_probe.sh [out_dir] [hold_button]
+set -u
+export HOME=/sylph-home/re SDL_AUDIODRIVER=dummy DISPLAY=:98
+export XENIA_PAD_FILE=/tmp/xenia_pad.txt
+OUT="${1:-/sylph-home/re/f1}"
+HOLD="${2:-DOWN}"
+mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*.log
+
+pad() { printf '%s' "$1" > "$XENIA_PAD_FILE.tmp"; mv "$XENIA_PAD_FILE.tmp" "$XENIA_PAD_FILE"; }
+tap() { pad "press=$1"; sleep 0.40; pad ""; sleep 0.30; }
+
+pad ""
+( cd "$OUT" && nohup run-canary --log_ui_draws=true \
+    --ui_draw_capture_frames=4000 --ui_draw_capture_max=900000 \
+    >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
+sleep 8
+# Arm the capture. ⚠️ Copied verbatim from ui_draw_capture.sh, which works.
+# A first attempt used `xdotool search --class xenia_canary key --window %1 F10`
+# and armed NOTHING -- it failed silently behind a `|| true`, the run completed,
+# and only the ABSENT log revealed it. Window lookup is by NAME, the key goes to
+# the window AND globally, and a failure is now fatal rather than tolerated.
+win="$(xdotool search --name "Xenia-canary" | tail -1)"
+[ -n "$win" ] || { echo "FATAL: no Xenia window to arm"; pkill -x xenia_canary; exit 1; }
+xdotool windowactivate "$win" 2>/dev/null
+xdotool key --window "$win" F10
+xdotool key F10
+echo "armed at ${SECONDS}s (win=$win)"
+
+# The boot, driven blind. Splashes ~8 s, then the attract movie; A skips it.
+sleep 12; tap A ; echo "A #1 (skip video) at ${SECONDS}s"
+sleep 6;  tap A ; echo "A #2 (reveal plate) at ${SECONDS}s"
+sleep 3;  tap A ; echo "A #3 (accept plate) at ${SECONDS}s"
+sleep 5
+echo "HOLDING $HOLD at ${SECONDS}s"
+pad "press=$HOLD"
+sleep 12
+pad ""
+echo "released at ${SECONDS}s"
+sleep 3
+pkill -x xenia_canary
+echo "done at ${SECONDS}s; log:"; ls -la "$OUT"/*.log