diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index c605b6a..140a8ce 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -171,10 +171,14 @@ available in the container.
 **And a second screen is NO LONGER BLOCKED, but it is not routine either.** The
 main menu has been reached (screenshot in
 [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)), so the
-"Ⓐ is dead" reading is withdrawn. **Not routine after all** — see the 2026-08-19 table in
-[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md): 3 of 3
-successes without `--log_ui_draws` and 0 of 5 with it, perfectly confounded with
-how long the boot took (every success ≤147 s, every failure ≥177 s). Until that
+"Ⓐ is dead" reading is withdrawn. **Not routine after all** — see the 2026-08-19 tables in
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md): 4 of 5
+successes without `--log_ui_draws`, 0 of 7 with it. An interleaved series
+**refuted the boot-time confound** (the latest title of all, 268 s, accepted Ⓐ;
+a 232 s title refused), and no mechanism exists for the flag — it is read only
+when F10 arms a capture, and F10 was never pressed. The variable has been removed
+rather than believed: F10 now arms the capture unconditionally, so navigation
+runs need no flag. Until that
 is separated, capturing a screen *and* navigating to it in the same run is not
 dependable. The earlier claim, kept: the title that ends the boot sequence
 accepts a single Ⓐ (2 of 2 at the time); the title the attract loop returns to
diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md
index 3b2cafa..a69d6f2 100644
--- a/docs/re/canary-scripted-input-traps.md
+++ b/docs/re/canary-scripted-input-traps.md
@@ -205,3 +205,50 @@ Widening the menu signature (previous commit) made `screen_id.py` classify some
 before any menu exists. The menu and a dark-blue movie frame are not separable
 from a single grab. Scripts that navigate on this must require the classification
 to hold across two grabs a second apart; the classifier itself cannot fix it.
+
+### The confound was broken, and it did not go the way the table suggested
+
+An **interleaved** series (same script, arms alternating, so cache warming cannot
+masquerade as either variable) settles the boot-time question and leaves the
+other one open:
+
+| arm | title at | Ⓐ |
+|---|---|---|
+| `--log_ui_draws` on | 252 s | stuck |
+| off | **268 s** | **menu** |
+| on | 254 s | stuck |
+| off | 232 s | stuck |
+
+**Boot time is refuted.** The *latest* title of every run recorded — 268 s —
+accepted Ⓐ, and a 232 s title refused. Whatever gates the button, it is not "the
+title arrived late".
+
+**The flag still correlates and still has no mechanism.** Over all twelve runs it
+is 0 of 7 with the flag and 4 of 5 without. Against that:
+
+* `log_ui_draws` is read in exactly one place — when F10 arms a capture — and
+  **F10 was never pressed** in any of those runs;
+* the per-draw hook is one relaxed atomic load, the swap hook another;
+* the two arms' startup config dumps are **byte-identical** (246 settings, zero
+  differences).
+
+A correlation with no mechanism, and an arm that failed once, is not a finding.
+It is a variable to remove, which is what was done: **F10 now arms the UI capture
+unconditionally**, like the ship capture beside it, so no run needs the flag at
+launch. Verified by artifact — F10 with no capture flags writes the log.
+
+### A third failure mode, recorded because it is now frequent
+
+Three boots have ended on a **permanent black screen**: one after 88 scripted Ⓐ
+presses, and **two with no input at all**. No crash, no guest throw, the emulator
+healthy and still resolving cache paths. It is not caused by the pad, and it is
+not the cache-flush crash. Roughly one boot in five in this session.
+
+## Still open, restated honestly
+
+What gates Ⓐ at the title. Four candidate explanations have now been eliminated
+or refuted — Xenia UI swallowing the keystroke, the driver filter, a sign-in or
+content call on the press, and the age of the title — and the fifth (the capture
+flag) has a strong correlation and no possible mechanism. The next honest step is
+not another guess from outside: it is the guest's own state machine, and that
+means reading the title code in `sylpheed.db`.