From 0274b2936843f3ea4555eb12a0cb67c85f480e65 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 19:07:25 +0000 Subject: [PATCH] re: the sign-in fix must be applied at launch, not by the navigator nav_to_flight.sh contains no run-canary invocation -- it drives an already-running emulator -- so whether a profile is signed in depends entirely on how the caller launched it. Every nav_to_flight run in this session was launched with a bare run-canary, which is why they froze. Worth stating plainly because the script prints "signing in profile B13EBABEBABEBABE", which comes from the emulator's startup rather than from the script arranging it. Refuted: "each screen loads its own GP_*.pak", a plausible route to a real screen identity. With full file logging the only names that appear are at boot (sound.p0x, tables.p00, hidden) and nothing new opens as the UI moves between screens -- the paks are opened once and read by offset, so file I/O carries no per-screen signal. Also recorded: one launch this iteration never reached the title -- progress counter stuck at 0, black screen, guest churn 0.001%. That is a DIFFERENT failure from the sign-in freeze, which stalls after the main menu with the counters already advanced, and it matches the boot flakiness canary-scripted-input-traps.md already documents. The counters distinguish them: sign-in freeze stalls past the title, a bad boot never leaves 0. --- docs/re/mission-freeze-signin-dialog.md | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md index 32d819bf..9115d8c6 100644 --- a/docs/re/mission-freeze-signin-dialog.md +++ b/docs/re/mission-freeze-signin-dialog.md @@ -67,3 +67,35 @@ Checking that distinction is what led to the dialog mechanism. scans are still 0 at screen 10, so the remaining screens are menus (mission select, briefing, ready room). That is now ordinary navigation work, not a blocker. + +## ⚠️ The fix must be applied at LAUNCH — `nav_to_flight.sh` cannot do it + +`nav_to_flight.sh` contains **no** `run-canary` invocation: it drives an +*already-running* emulator. So whether a profile is signed in depends entirely on +how the caller launched it, and every `nav_to_flight` run in this session was +launched with a bare `run-canary --apu=sdl …`. + +**That is why those runs froze**, and it is worth stating plainly because the +script prints `signing in profile B13EBABEBABEBABE` — which comes from the +emulator's own startup, not from the script arranging it. + + run-canary --apu=sdl --logged_profile_slot_0_xuid=B13EBABEBABEBABE # then nav_to_flight.sh + +## 🔴 Refuted: "each screen loads its own `GP_*.pak`" + +A plausible way to get a *real* screen identity — watch which pak the game opens +— does not work. With full file logging, the only names that appear are at boot +(`sound.p0x`, `tables.p00`, `hidden`), and nothing new is opened when the UI +moves between screens. The paks are opened **once** and read by offset +thereafter, so file I/O carries no per-screen signal. + +## ⚠️ Boots are flaky, independently of this bug + +One launch in this iteration never reached the title at all: progress counter +stuck at `0`, screen black (mean `0,0,0`), guest churn **0.001 %**. That is a +*different* failure from the sign-in freeze — which stalls *after* the main menu +with the counters already advanced — and it matches the flakiness +`canary-scripted-input-traps.md` already documents ("(A) at the title is accepted +on roughly half of boots and nothing observable predicts which"). **Distinguish +them by the counters**: sign-in freeze stalls with counters advanced past the +title; a bad boot never leaves 0.