diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 627d344..da3338d 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -216,11 +216,17 @@ shared checkout (202 files, no submodule churn), profile bootstrapped with the
 
 **Open, and cheap:**
 
-* 🔎 **`launch_mission.sh` does not finish unattended on restored state.** It now
-  reaches the READY ROOM and stops on **BRIEFINGS** — its `step up; tap A` for
-  TAKE OFF is swallowed because a fixed `sleep 28` precedes it. Replacing that
-  sleep with a wait for the screen (`screen_id.py`) is the whole fix. Both runs
-  on 2026-08-23 were finished by hand from where it stopped.
+* ✅ **`launch_mission.sh` finishes unattended again** (2026-08-23, later):
+  boot → title → LOAD GAME → slot 01 → READY ROOM → TAKE OFF → `IN FLIGHT at
+  34s`, pilot bound and engaging. Two defects, not one: the fixed `sleep 28` for
+  LOAD → READY ROOM (now `wait_screen.sh readyroom`), and the READY ROOM being
+  **drawn before it is usable** — `Preparing to Sortie`, TAKE OFF greyed, which
+  whole-image statistics cannot see (1.7 units of blue) so `take_off_armed.py`
+  tests the label. A third defect fell out of the same run: `wait_flight.sh` was
+  testing pixel (450,640) "inside the SHIELD bar" of a **1280×720** window, while
+  `screenshot` crops to the **1279×675** game surface — it lands between the
+  SHIELD and ARMOR bars. That is the long-standing "reported NEVER REACHED FLIGHT
+  while plainly in flight" note, now explained and fixed.
 * ❔ **Nothing guarantees this state survives the next container.** If it is
   meant to, the profile + save + `bin/` copies want a home inside a repo or a
   named volume; that is a call for the user, not for an agent.
@@ -236,9 +242,17 @@ the corrected method note (the scan takes **0.9 s** — the trap is the counter
 climbing `004 → 012` in four minutes, not scan duration) in
 [`structures/mission-objective-counter.md`](structures/mission-objective-counter.md).
 
+🟡 **A clean scan has now been run** (HUD confirmed `004` on both sides of it,
+filtered at a confirmed `012`): 17 candidates, one of which is **`0xbdb49668`** —
+the run-1 address minus exactly `0x10000`, same page offset `0x9668`, which only
+**2 of 39 596** candidates share. Amber, not green: the later sample landed
+during the GAME OVER flash with no HUD on screen, so the survivors are
+*unrefuted* rather than confirmed.
+
 **First step for whoever takes it:** a run whose pilot is still *engaging* when
-the scan happens, so a later transition exists to filter on — `pilot.py` had
-retired to hull 340/1500 and the counter then sat at `012` for five minutes.
+the scan happens, so a later transition exists to filter on. Both attempts so far
+died the same way — the escorted ACROPOLIS is lost while `pilot.py` sits in
+EVADE/RETIRE, and `REMAINING OB` then holds one value for ten minutes.
 The follow-on that the autopilot actually needs is unchanged and untouched:
 ❔ what the counter counts, and whether an `OB`-badged entity carries a flag in
 its entity object.
diff --git a/docs/re/dynamic-re-state-restore.md b/docs/re/dynamic-re-state-restore.md
index ef997bd..4281a64 100644
--- a/docs/re/dynamic-re-state-restore.md
+++ b/docs/re/dynamic-re-state-restore.md
@@ -124,9 +124,11 @@ lands one screen early — this run ended up sitting in **OPTIONS → GAME SETTI
 and `wait_flight.sh` correctly reported `NEVER REACHED FLIGHT`. The mission above
 was reached by driving the menus by hand from there.
 
-**Checked on the next boot: the dialog does not return** — the auto-save answer
-is kept in the profile. The launcher gets further (READY ROOM instead of
-OPTIONS) and still misses: it lands on **BRIEFINGS**, i.e. its
+**On the next boot the launcher gets further — READY ROOM instead of OPTIONS —
+but that run does NOT establish that the dialog is gone**, and the earlier
+wording here claiming it did is withdrawn: `wait_flight.sh` taps A every six
+seconds while it waits, so a dialog would have been dismissed by those taps
+without ever being seen. What run 2 does show is where it stopped: it lands on **BRIEFINGS**, i.e. its
 `step up; tap A` for TAKE OFF is swallowed by the READY ROOM transition, because
 what precedes it is a fixed `sleep 28` rather than a wait for the screen. So
 `launch_mission.sh` is **one wait away** from working unattended on restored