diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 24b9a4e..3c38d3e 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -759,7 +759,19 @@ in `command_processor.cc` on `auto/re-ui-draw-order`, and F10 wrote a 2.9 MB
 `xenia_ship_capture_01.log` from this session's binary. No separate
 `capture-ship-placement` build is needed.
 
-What blocks it now is **the cache-flush crash**, not navigation — measured
+**Update 2026-08-19: the mission is now REACHABLE.** With the Canary threading
+fix, `tutorial_launch.sh` drives boot → title → menu → TUTORIAL and the mission
+**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. New lead recorded there too: the
+resume-refused diagnostic fires 1 671 times on this path, 1 663 on one thread,
+against ~7 on the menu path — specific, and explicitly not yet claimed as a bug.
+
+What blocked it before was **the cache-flush crash**, not navigation — measured
 2026-08-19. `tools/re-capture/tutorial_launch.sh` (which retries whole boots,
 because re-pressing the same title never works) gets all the way from the title
 through the main menu to **DIFFICULTY** and then **SELECT DATA**, and the guest
diff --git a/docs/re/captures/tutorial-mission-reached-then-crash.png b/docs/re/captures/tutorial-mission-reached-then-crash.png
new file mode 100644
index 0000000..a423ede
Binary files /dev/null and b/docs/re/captures/tutorial-mission-reached-then-crash.png differ
diff --git a/docs/re/title-crash-stl-tree.md b/docs/re/title-crash-stl-tree.md
index 1142faa..9c29d1d 100644
--- a/docs/re/title-crash-stl-tree.md
+++ b/docs/re/title-crash-stl-tree.md
@@ -256,3 +256,57 @@ some runs out earlier — it is not the crash, and it has no diagnosis yet.
 The cheap trigger from the top of this note (an incomplete on-disc cache) still
 stands as the fastest way to reproduce the throw for bisection; what is missing
 is a fix, and that is guest-race work in the emulator, not RE.
+
+
+## The mission is now REACHABLE — and freezes there instead (2026-08-19)
+
+**Status:** ✅ the blocker has **moved**, measured. 🔴 the crash is unchanged and
+still blocks a capture. 🔬 one new lead, deliberately not claimed as a cause.
+
+This entry has said a second capital-ship capture "needs that crash dealt with
+first", because the run died at **SELECT DATA** before any mission existed. That
+is no longer where it stops.
+
+With the Canary threading fix making the menu dependable
+([`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)),
+`tutorial_launch.sh` now drives boot → title → menu → TUTORIAL and **the mission
+loads and renders**: the flight HUD, the "Go to the box on your screen" prompt,
+the warship counters, the controller diagram
+([capture](captures/tutorial-mission-reached-then-crash.png)).
+
+### What still happens
+
+* **13 243 crash dumps, every one at `PC: 0x82307128`** — the same address this
+  page is about. Guest thread 9, `Access Violation: read at 0x000000010000000C`.
+* Preceded by exactly **one** `RtlRaiseException(E06D7363)` / "Guest attempted to
+  throw a C++ exception!", immediately after a `HostPathDevice::ResolvePath()`
+  with **empty arguments** — the cache-flush shape this page documents.
+* The game then **freezes**: two screenshots 6 s apart are identical (RMSE 0), no
+  new dumps accumulate, and the process still burns 400 % CPU. Xenia suspends the
+  crashing thread and the mission stops advancing.
+
+So the honest status is: reachable, renders, unusable for a capture.
+
+### 🔬 A new lead, not a claim
+
+The `XThread::Resume: host resume was refused` diagnostic added with the
+threading fix fires **1 671 times** on this path — and **1 663 of them are the
+same thread, `F80001D8`**, with 152 before the first crash. On the menu path it
+fires about 7 times.
+
+That is *not* asserted to be a bug. Resuming a thread that is not suspended
+legitimately returns false, and "call Resume to kick a worker" is a normal guest
+idiom that would produce exactly this. But 1 663 refusals on one thread,
+concentrated where the crash is, is specific enough to test: check whether
+`F80001D8` makes any kernel calls between refusals. If it does, it is the kick
+idiom; if it does not, it is a second lost resume.
+
+### The cheapest next test is the cache
+
+This page already establishes that an **incomplete on-disc cache** triggers the
+throw and that "with the cache complete, the same boot produces no throw at all".
+The cache directory is currently **40 MB**, and the tree still carries
+`aab216c3.partial-2131` and `aab216c3.cold-rebuilt-2145` from earlier surgery —
+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.