608a0cc710
Last iteration I said launch_mission died because skip_intro only tests for the title on a static frame, gated at rmse <= 1500, and that run logged 1503 and 1549 just above the cut. I also said the fix was NOT to nudge 1500 but to measure both signals through a boot first. Measured, and the diagnosis does not survive. boot_trace.sh logs the two signals skip_intro decides on -- frame-to-frame RMSE and the is_title.py green-glyph count -- through a clean boot with no presses at all. One run, 29 samples over 484 s: 8 samples had rmse <= 1500, so the gate OPENED eight times 0 samples had glyph > 0, so the title was never seen At t=145 s the RMSE was 1205, comfortably inside the threshold, and the glyph test was called and answered zero. A frame can be perfectly static without being the title -- the intro movie has long quiet stretches, three reading RMSE exactly 0. So 1503/1549 were almost certainly movie frames too, and raising the constant would have admitted two more of them. What is left is narrower and honest: the interactive title never appeared, rather than appearing and being missed by a threshold. The limitation is recorded rather than buried: the tracer intended 1 s sampling and achieved 16.9 s, because each iteration forks two screenshots, ImageMagick compare and a fresh Python. So this does NOT prove the title never appeared -- only that it was absent from 29 samples. A window shorter than ~17 s falls between them. The recorded next step is to make the tracer sample at the rate it claims before concluding anything stronger. Artifact: docs/re/captures/boot-signal-trace.tsv. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
4.0 KiB
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.
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 afterrm -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.