Tried to close out issue #1 with an actual draw-log measurement this
iteration: built f1_hold_capture.py to boot to the settled main menu via the
proven glyph-gated route, arm the F10 UI-draw capture, hold a direction, and
read cursor position per frame -- the instrument f1-menu-repeat-harness-
built-not-answered.md already validated but never got to run against a
reachable menu.
Four bugs found across four boot attempts:
1. tap() shelled out to pad.py without this script's own env, so the press
went to /tmp/xenia_pad.txt while Canary watched OUT/pad.txt -- an
unobserved press indistinguishable from a dead pad. Fixed with an
in-process tap() using the same pad() the hold uses; confirmed working
the next run (title 154.5s, menu 163.0s).
2. ui_draw_capture_frames/max were persisted at 3/20000 from a prior
session in xenia-canary.config.toml -- log_ui_draws is now a documented
no-op (F10 arms unconditionally) and these two cvars didn't visibly
respond to command-line overrides. Bumped to 600/400000 directly in the
config.
3. The real blocker: this container has no signed-in profile (no content/
directory at all -- a fresh container after a restart, which every
container is right after one). Without a profile the title's sign-in
dialog sets IsUIActive() true, which reproduces
structures/title-a-press-fault.md's already-diagnosed unbounded-
keystroke-queue crash -- verified byte-for-byte against that page's own
addresses (PC 0x868 past sub_82457038, 0x828F3xxx registers, identical
host/guest address arithmetic), looping continuously from before F10 was
ever pressed. Fixed by creating a profile (--create_profile_if_none) and
signing in (--logged_profile_slot_0_xuid), matching boot_menu.sh, which
already did this and so never hit it. Confirmed: zero crashes with the
fix, dozens per run without it.
4. Found but not re-verified: no xsetroot blank before launch, so a stale
X-root frame from a killed prior run gave a false "TITLE" read at 2.6s,
before any real window existed -- skip_intro.sh already blanks the root
for exactly this reason. Fixed in the script.
Ran out of budget before a clean end-to-end run landed. Still no number for
issue #1 -- the Port keeps -1.0. Flagged prominently (HANDOFF, REFUTED.md)
because bug 3 will hit any bare run-canary invocation in any fresh
container, not just this script.
