# The boot-nav title gate — my own diagnosis, measured and withdrawn Status: ❌ **the previous diagnosis is WITHDRAWN.** 🟡 the real failure is narrowed but not settled. ❔ the measurement has a limitation that matters, and it is stated below rather than buried. ## What I claimed last iteration `launch_mission.sh` failed to reach the mission: 381 s of `skip_intro.sh` printing "movie … waiting it out", 18 times, and the ready room never arrived. `skip_intro.sh` only tests for the interactive title when the frame is **static**, gated at `rmse <= 1500`, and that run logged **1503 at 104 s** and **1549 at 139 s** — just above the cut. I wrote that the gate had therefore blocked the title test and eaten the run. I also wrote, correctly, that the fix was *not* to nudge 1500, and that the first step was to measure both signals through a whole boot. That is what this is. ## The measurement `tools/re-capture/boot_trace.sh` logs, without pressing anything, the two signals `skip_intro.sh` decides on: the frame-to-frame RMSE (two grabs 0.6 s apart) and the green-glyph pixel count from `is_title.py` — independent tests for "is this static" and "is this the interactive title". One clean boot, no input at any point: [`captures/boot-signal-trace.tsv`](captures/boot-signal-trace.tsv). ``` 29 samples spanning 484 s 8 samples with rmse <= 1500 (the gate OPENED eight times) 0 samples with glyph > 0 (the title was never seen) ``` The eight low-RMSE samples: `t=12, 29, 62` (rmse 0), `t=99` (1486), `t=115` (1350), `t=145` (**1205**), `t=316` (0), `t=484` (0). ## ❌ Why the old diagnosis is wrong The gate is not what stopped it. It **opened eight times**, and at `t=145` the RMSE was **1205** — comfortably inside the threshold — so `is_title.py` was called and answered **0 glyph pixels**. A frame can be perfectly static and still not be the title; the intro movie has long quiet stretches, and three samples read an RMSE of exactly 0. So `1503`/`1549` in the failing run were almost certainly *also* not the title, and raising the threshold to admit them would have admitted two more movie frames, not the title. The instinct to leave the constant alone was right; the reason I gave for it was wrong. ## 🟡 What the failure actually is Narrowed, not settled: **the interactive title never appeared at all** in 484 s of a no-press boot — not "appeared and was missed by the gate". The glyph count was 0 in all 29 samples, including the last one at 484 s where the frame was completely static (rmse 0). A static frame with no glyph at 484 s is consistent with the attract loop having returned to a title that, per `menu_draw_capture.sh`, "accepts nothing at all" — but this run never pressed anything, so nothing can have broken it. That points at the boot itself, not at the navigation. ## ❔ The limitation, stated plainly **The intended sampling rate was 1 s; the achieved rate was 16.9 s.** Each iteration takes two screenshots, runs ImageMagick `compare` and starts a Python interpreter, and that costs ~15 s per loop in this container. So 29 samples cover 484 s with big gaps between them. That means this run does **not** prove the title never appeared — only that it was absent from every one of 29 samples. A title window shorter than ~17 s could fall between two samples. Before concluding anything stronger, the tracer needs to get cheap enough to sample at the rate it claims: keep one Python process alive and compute the RMSE and the glyph count in it, instead of forking `compare` and a fresh interpreter every second. ## What this does not settle * Whether the title ever appears on this boot path at all. * Whether the earlier "readyroom at 9 s, IN FLIGHT at 37 s" run (recorded 2026-08-25 in `BACKLOG.md`) used a warm shader cache that this run lacked — this one was started after `rm -f /dev/shm/xenia_*`, which the fast run may not have been. * The live test this was all for — whether the trigger container and the coroutine list both collapse at a phase terminator — remains unrun.