re: three boot-path failures that look like the emulator and are not

Spent a session getting to flight.  Each obstacle presents as "the emulator
died" and none of them is.

  * --audio prevents boot.  run-canary's header already says the flag is not a
    cvar in this tree and that an unknown argument blocks in a message box
    before logging starts.  Measured anyway, because the corpus also holds runs
    that passed it and booted: 3 trials each in BOTH orders, 67 565 bytes of log
    without the flag and 209 with -- and 209 is run-canary's own banner, not one
    line from xenia.  Order was reversed on purpose; this corpus has a standing
    lesson that an A/B from run order is noise.  Eight scripts on branch
    auto/idxd-unnamed-keys still pass it; main and this branch are clean, which
    reconciles August's successes with today's failures.

  * launch_mission.sh's skip_intro deadlocks.  It calls the attract loop a
    "movie" and refuses to tap, and waited out 600 s of unbroken movie verdicts
    before timing out.  nav_to_flight.sh, against the same running emulator,
    reached the main menu in 12 s and flight in 2 min 20 s by tapping A at the
    title.  The "wait it out" premise is wrong: the loop does not end.

  * "EMULATOR GONE at ~40 s" is this project's own Stop hook killing xenia when
    a Claude turn ends.  That is recorded further down this same file and I
    rediscovered it over three boots because I did not look.  Sequential tool
    calls within one turn are fine; ending the turn is what kills it.

The world unit is still unmeasured.  Flight was reached and the screen
classifier agrees, but entities2.py finds 0 unit definitions -- its committed VA
window does not match this run, the same run-dependent-address problem this file
documents for the OB counter.  Next attempt must hunt the range.
This commit is contained in:
Sylpheed RE agent
2026-08-26 11:02:15 +00:00
parent de1ff6ed76
commit b641034be7

View File

@@ -6,6 +6,52 @@ unknown, what evidence exists, and what the first step would be. Move an item in
---
## 🧰 The boot path — three failures that look like the emulator and are not (2026-08-26)
***`--audio` prevents boot outright.** `run-canary`'s own header says the flag
is not a cvar in this tree, and that an unknown argument makes xenia call
`ShowSimpleMessageBox` from `ParseLaunchArguments` *before* logging starts,
blocking forever. Measured anyway, because this corpus also holds runs that
passed it and booted fine: **3 trials each, in both orders**
| | log written |
|---|---|
| `run-canary --apu=sdl --log_mask=13` | **67 565 bytes** |
| `run-canary --audio --apu=sdl --log_mask=13` | **209 bytes** |
209 bytes is `run-canary`'s own banner and not one line from xenia. The order
was reversed deliberately — this corpus already has a lesson that an A/B from
run order is noise.
🔴 **Eight scripts on branch `auto/idxd-unnamed-keys` still pass it**:
`launch_mission.sh`, `boot_menu.sh`, `fly_stage.sh`, `challenge_probe.sh`,
`grab_tutorial.sh`, `find_partslot.sh`, `tutorial_capture.sh`, `nav_probe.sh`.
`main` and this branch are clean, which reconciles August's successes with
today's failures. Left unfixed here: they are another branch's files.
* 🔴 **`launch_mission.sh`'s `skip_intro` deadlocks on the attract loop.** It
classifies the screen as `movie` and declines to tap ("tapping breaks the
title"), and waited out **600 s of unbroken `movie` verdicts** before timing
out. `nav_to_flight.sh`, against the *same running emulator*, reached the main
menu in **12 s** and flight in **2 min 20 s** by tapping A at the title. The
"wait it out" premise is wrong — the attract loop does not end on its own.
**Use `nav_to_flight.sh` on an already-running canary.**
* ⚠️ **`EMULATOR GONE at ~40 s` is this project's own Stop hook**, which
`kill -9`s every `xenia_canary` when a Claude turn ends. Already recorded
further down this file — and rediscovered the hard way over three boots because
I did not search for it first. The rule is the one `fly_session.sh`'s header
states: **an emulator session must be one task; nothing may depend on surviving
between tool calls.** Sequential tool calls *within* one turn are fine; it is
ending the turn that kills it.
**The world-unit measurement is still not made.** Flight was reached and the
screen classifier agrees, but `entities2.py self` reports **0 unit definitions**
its committed VA window `0xBD00_0000``0xBE00_0000` does not match this run, the
same run-dependent-address problem this file documents for the OB counter. The
next attempt must hunt the range rather than trust the stored config.
---
## ❌ WITHDRAWN (2026-08-26, same day) — the Japanese voice banks are NOT a separate format
The `sound.pak` census (see