From 4ee7971340d44e3965d7d0f938678db2f0d86c7d Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 19:43:40 +0000
Subject: [PATCH] re: the post-take-off state is measurably neither a menu nor
 flight

wait_flight.sh carries the corpus's best discriminator, and it is a whole-image
statistic rather than a named pixel: the flight HUD paints green over the frame
at 1.3-1.5% green fraction, against <0.1% on every menu.

Measured on the post-take-off state: green=0.0022, mean (1.6, 45.6, 50.1).  That
is 0.22% -- an order of magnitude above a menu, an order of magnitude below
flight, on a dark blue-green frame.  screen_id.py files it under "menu" because
that is the closest bucket it has; the state is neither.

wait_flight.sh then tapped A for 280 seconds and never saw the HUD.

With the 12 \dat\movie accesses, the reading is consistent: this is the cutscene,
it does not end on A, and it does not reach the flight HUD within five minutes.

Open, cheapest first: how the movie path signals completion (the corpus already
decoded the movie handler for the intro video and found a software-decode
deadline); whether a mission can be started by a route that skips the launch
cinematic; or whether the cutscene simply needs far longer under lavapipe.

Oracle status overall: boot, menus and take-off are reliable and reproducible;
only the cutscene->mission step is unsolved -- a much smaller and better-defined
gap than the freeze it replaced.
---
 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 97c92f4a..c5ebed1c 100644
--- a/docs/re/mission-freeze-signin-dialog.md
+++ b/docs/re/mission-freeze-signin-dialog.md
@@ -171,3 +171,35 @@ is not skippable by the obvious buttons.** Either it must be played out (long,
 under lavapipe), or the right skip input has not been found, or it is waiting on
 something the movie path never delivers. That is the next question, and it is now
 a question about *one* identified sequence rather than about a mysterious hang.
+
+## 🟡 The post-take-off state is measurably neither a menu nor flight
+
+`wait_flight.sh` carries the best discriminator in the corpus, and it is a
+whole-image statistic rather than a named pixel: the flight HUD paints green over
+the frame at **1.3–1.5 %** green fraction, against **< 0.1 %** on every menu.
+
+Measured on the post-take-off state:
+
+    menu green=0.0022 white=0.0001 mean=(1.6, 45.6, 50.1)
+
+**0.22 %** — an order of magnitude above a menu, an order of magnitude below
+flight, and a dark blue-green frame. `screen_id.py` files that under `menu`,
+which is simply the closest bucket it has; the state is neither.
+
+`wait_flight.sh` then tapped Ⓐ for **280 seconds** and never saw the HUD:
+`NO FLIGHT HUD within 280s (last: menu)`.
+
+Taken with the 12 `\dat\movie` accesses, the reading is consistent: this is the
+**cutscene**, it does not end on Ⓐ, and it does not reach the flight HUD within
+five minutes of trying.
+
+❔ What that leaves, in order of cheapness: (1) how the movie path signals
+completion — the corpus already decoded the movie handler for the intro video and
+found a software-decode deadline, so the same machinery may say what "done" looks
+like; (2) whether a mission can be started by a route that skips the launch
+cinematic; (3) whether the cutscene simply needs far longer than five minutes
+under `lavapipe`.
+
+**Status of the oracle overall: boot, menus and take-off are now reliable and
+reproducible; only the cutscene→mission step is unsolved.** That is a much
+smaller and better-defined gap than the freeze it replaced.