From 66f552b95109a19e3150fb89e0e6caed519fdf45 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 19 Aug 2026 04:17:36 +0000
Subject: [PATCH] docs/re: eh_dispatch is untested, and the black screen
 follows a content load
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The run with --eh_dispatch=true produced zero crashes and zero throws, which is
not the result it looks like: the crash path was never reached, so the flag is
UNTESTED. Recording that rather than banking a false pass.

What the run did establish, with screenshots: TUTORIAL leads to a lesson list
(a fifth screen nobody had captured, committed), and selecting BASIC CONTROLS
puts the guest on a permanent black screen — no crash, no GUEST-THROW, emulator
healthy. That gives the black screen a trigger it did not have before: it follows
a CONTENT LOAD, which also fits the earlier black screens.

So the two blockers on the way to a mission are distinct and both unbeaten: the
SELECT DATA crash when the path goes through save-slot enumeration, and the
black-screen hang on loading content. The eh_dispatch test needs a run that
actually reaches SELECT DATA.
---
 docs/re/canary-scripted-input-traps.md | 37 ++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md
index e3a9d394..6d421f57 100644
--- a/docs/re/canary-scripted-input-traps.md
+++ b/docs/re/canary-scripted-input-traps.md
@@ -315,3 +315,40 @@ arms under whatever load was present, and the latest title of all (268 s)
 window is a live hypothesis that the data collected so far cannot exclude, and
 the honest next measurement is the one now being taken — the same navigation on
 an **idle** box, with nothing else running.
+
+## The black screen has a trigger: loading content (2026-08-19)
+
+Running the same navigation with `--eh_dispatch=true` (to test whether
+dispatching the guest's C++ exception to its catch handler survives the
+`SELECT DATA` crash) produced **zero crashes and zero throws** — and that is not
+the good news it looks like, because the crash path was never reached.
+
+What happened instead, with screenshots at every step:
+
+```
+main menu → TUTORIAL → the LESSON LIST (BASIC CONTROLS / HEADS-UP DISPLAY /
+            RADAR / SUPPLY AND SPECIAL MOVES / RADIO ORDERS / ADVANCED
+            CONTROLS / BACK)     captures/tutorial-lesson-list.png
+          → Ⓐ on BASIC CONTROLS
+          → BLACK SCREEN, permanently, for the remaining 160 s
+```
+
+No crash dump, no `GUEST-THROW`, the emulator healthy and the guest still
+running. So **`--eh_dispatch` is untested** — the experiment it was set up for
+did not occur.
+
+**What it did establish**: the black screen this session has hit four times is
+not random. It follows a **content load** — here, selecting a tutorial lesson.
+Earlier black screens fit that too: one came after 88 scripted Ⓐ presses through
+the boot (which would have selected *something*), and one after a boot that was
+never touched but had reached the attract loop. The two failure modes on the way
+to a mission are therefore distinct:
+
+* the **`SELECT DATA` crash** — the cache-flush `std::map` erase, when the path
+  goes through save-slot enumeration;
+* the **black-screen hang** — no crash, no throw, on loading content.
+
+Neither has been beaten, and this run tested neither: it took a different branch
+through the menus than the run before it (TUTORIAL leads to a lesson list, and
+the DIFFICULTY screen captured earlier came from a different selection). The
+`--eh_dispatch` test needs a run that actually reaches `SELECT DATA`.