diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index f42ec884..fdd81402 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -764,10 +764,12 @@ fix, `tutorial_launch.sh` drives boot → title → menu → TUTORIAL and the mi
 **loads and renders** (flight HUD, "Go to the box on your screen"). It then
 freezes under 13 243 crash dumps, all at `0x82307128`, preceded by exactly one
 guest C++ throw — identical frames 6 s apart, no new dumps, 400 % CPU. So the
-blocker moved from "cannot reach a mission" to "the mission freezes". Cheapest
-next test: the crash page shows a **complete on-disc cache produces no throw**,
-and the cache is only 40 MB with `.partial`/`.cold-rebuilt` leftovers nearby —
-one boot to warm it, one to re-test. 🔴 The resume-refused lead (1 663 on one
+blocker moved from "cannot reach a mission" to "the mission freezes". 🔴 **The cache is REFUTED as the cure** (3 runs): the
+missing entry `\aab216c3\6` was real and got written, and the run with a complete
+cache stormed anyway — 11 497 dumps, all `0x82307128`. ✅ **But a usable window
+exists:** both post-cache runs ran the mission with exactly **2 crashes for
+56–80 s** before the storm, where the first run was at 641 by t+24 s. The ship
+capture needs `F10` armed *inside* that window. 🔴 The resume-refused lead (1 663 on one
 thread) is **REFUTED**: that thread did execute, and `KeWaitForSingleObject` /
 `NtWaitForSingleObjectEx` are `kHighFrequency`, which is unlogged unless
 `--log_high_frequency_kernel_calls=true` — so a parked thread is invisible and
diff --git a/docs/re/title-crash-stl-tree.md b/docs/re/title-crash-stl-tree.md
index 22762f70..7221a658 100644
--- a/docs/re/title-crash-stl-tree.md
+++ b/docs/re/title-crash-stl-tree.md
@@ -346,3 +346,44 @@ The cache directory is currently **40 MB**, and the tree still carries
 so it is quite possibly incomplete. Letting the game build a complete cache and
 re-running the tutorial is one boot to warm and one to test, and it would say
 whether the mission path is blocked by the crash at all or only by cache state.
+
+
+## 🔴 Refuted: completing the on-disc cache does not stop the mission crash (2026-08-19)
+
+This page's own reproduction — move the cache aside, get a throw ~100 s in;
+restore it, get none — made "the cache is incomplete" the obvious explanation for
+the mission-path crash. It is not the cure. Three tutorial runs, measured:
+
+| run | cache state | crashes early | storm begins | total dumps |
+|---|---|---|---|---|
+| `tut2` | subdir `6` **missing** | 641 by t+24 s | ~t+24 s | 13 243 |
+| `tut3` | missing → **gained `6`** during the run | **2** through t+80 s | ~t+96–112 s | 11 898 |
+| `tut4` | `6` present from the start | **2** through t+56 s | ~t+56–88 s | 11 497 |
+
+The missing entry was real: `\aab216c3\6` was requested and absent, and the game
+wrote it during `tut3` (11 → 12 files). `tut4` then ran with a complete cache
+**and stormed anyway**. Every dump in all three runs is `PC: 0x82307128` — one
+address, no others.
+
+So the cache is not what gates this. It may be what gated the *boot-time* throw
+this page originally documented; it does not gate the mission one.
+
+### ✅ What the runs did give: a usable window
+
+Both post-cache runs show the same shape — **exactly 2 crashes, then nothing, for
+56–80 seconds after the mission starts** — where the first run was already at 641
+by t+24 s. The mission renders and advances during it.
+
+That is the practical opening for the thing this crash has been blocking: the
+**second capital-ship capture** needs `F10` armed *inside* that window, not after
+it. It is not a guarantee — the storm began at t+24 s, ~t+96 s and ~t+56 s across
+the three runs, so the window varies and a run can lose it entirely — but two of
+three runs offered most of a minute of clean mission time.
+
+### What is still not settled
+
+* 🔴 What actually triggers the storm. Not the cache; not input; the crash PC is
+  invariant.
+* ❔ What the 2 early crashes are, as distinct from the storm.
+* ❔ Whether a capture taken inside the window is complete enough to be useful —
+  untried.