diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md
index 680ff023..92f8cbe5 100644
--- a/docs/re/mission-freeze-heap-exhaustion.md
+++ b/docs/re/mission-freeze-heap-exhaustion.md
@@ -452,3 +452,63 @@ allocated at **boot**, before any menu, so 171 MB of the 379.5 MB is fixed
 regardless of route. The remaining ~208 MB is where a route difference could
 live, and the ledger can measure it: capture live-bytes at the moment TAKE OFF is
 pressed, for two different navigation paths, and compare.
+
+---
+
+# 🔴🔴 It is not a *stage-load* freeze at all — it freezes at MISSION SELECT
+
+**2026-08-26.** Everything above calls this a stage-load or take-off freeze. That
+is **wrong**, and the evidence was in the run's own screenshots the whole time.
+
+`nav_to_flight.sh` saves a shot at each step. Comparing them **consecutively**
+(not all against the first — see the mistake below):
+
+| transition | rmse | pixels changed |
+|---|---|---|
+| `01-extras` → `02-missionselect` | 51.07 | 99.42 % |
+| `02-missionselect` → `03-selected` | **0.00** | **0.00 %** |
+| `03` → `04` → `05` → `06` → `07` → `08-flight` | **0.00** | **0.00 %** |
+
+Shots **02 through 08 are pixel-identical**. The screen stops at MISSION SELECT
+and never changes again. Every step the script then reports — *selected*,
+*after-A*, *readyroom*, *takeoff-hl*, *flight* — is it pressing buttons at a
+frozen image, and `screen_id.py` classifying a static frame.
+
+[`captures/freeze-at-missionselect.png`](captures/freeze-at-missionselect.png) is
+the frame it dies on.
+
+## 🔴 So several claims on this page are withdrawn
+
+* **"`MISSION SELECT` and the stage list worked, and the failure came later,
+  during the take-off load"** — withdrawn. It froze *entering* MISSION SELECT.
+* **`challenge-mission-gate.md` §5.6 was right and I contradicted it.** It says
+  entering `MISSION SELECT` fails on a 128 MB request and Xenia surfaces a *"Disc
+  Read Error"*. That is exactly this. I read my own runs as getting further
+  because the navigation script said so.
+* **Every "reached flight" in this session's runs is false**, including the ones
+  where `screen_id.py` returned `flight`. A single-frame classifier cannot tell a
+  live screen from a frozen one — already noted on this page, and it still fooled
+  me because I trusted the *script's* progress log instead of the frames.
+
+## ⚠️ The comparison mistake, recorded because it nearly buried the result
+
+The first pass compared every shot against **shot 1**, and got
+`rmse=51.07, changed=99.42%` for all seven — identical to two decimals across
+seven supposedly different images. That is not a result, it is a tell, and I
+briefly took it as "all frozen", then talked myself out of it when `md5sum`
+showed eight distinct hashes. The hashes differ only in PNG metadata. **Compare
+consecutive frames, and treat a suspiciously constant statistic as a bug in the
+measurement, not a finding.**
+
+## ❔ What this changes about the oracle
+
+The allocation failure happens *while the display is already frozen*, so it is
+downstream of whatever wedges the game, not the cause — consistent with the three
+runs that froze with the allocation succeeding, stopping at 16 MB, 32 MB and
+128 MB respectively.
+
+The actionable consequence: **MISSION SELECT is the thing to avoid.** Every route
+this session has used goes EXTRAS → MISSION SELECT. The 2026-08-10 run that flew
+for 500 s did not necessarily; `newgame_path.sh` and `tutorial_launch.sh` reach a
+mission by other menus. Testing a non-MISSION-SELECT route is the next
+experiment, and it is now the most promising one available.