diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 9a2a5ce9..c605b6a4 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -171,8 +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. **Now routine**: the title that ends the boot sequence accepts a single Ⓐ (2 of
-2 runs); the title the attract loop returns to accepts nothing (Ⓐ, START, B,
+"Ⓐ 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 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
+accepts nothing (Ⓐ, START, B,
 BACK, X, Y — dozens of delivered presses). The proposed tell was refuted on the
 way: the two states draw **13 identical quads**, `ptbtn00` included, so they
 differ only to the guest. Recipe: first title after boot, one tap, and never tap
diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md
index 96d75455..3b2cafa6 100644
--- a/docs/re/canary-scripted-input-traps.md
+++ b/docs/re/canary-scripted-input-traps.md
@@ -158,3 +158,50 @@ reading that code.
 Not open any more, and worth stating because it was the thing blocking the RE:
 reaching the main menu is now routine (first title, one Ⓐ), and the second
 screen's paint order has been captured with it.
+
+## 2026-08-19 — the "first title accepts Ⓐ" rule is weaker than stated, and there is a confound
+
+The entry above says the boot title accepts a single Ⓐ, 2 of 2. Continuing to
+use that recipe, it failed four times running. The full record, every run with
+the press verifiably delivered:
+
+| run | `--log_ui_draws` | title appeared at | Ⓐ |
+|---|---|---|---|
+| crash-dir | off | ~83 s | **menu** |
+| boottitle | off | 147 s | **menu** |
+| A/B "off" | off | — | **menu** |
+| menucap 1 | on | 292 s | no (40 taps) |
+| menucap 2 | on | 177 s | no |
+| optcap 1 | on | 241 s | no |
+| optcap 2 | on | 219 s | no |
+| A/B "on" 1 | on | never (black screen) | — |
+| A/B "on" 2 | on | 186 s | no |
+
+**3 of 3 without the flag, 0 of 5 with it.** That is a strong correlation, and it
+points at *my own instrumentation cvar* — which would be a serious finding, since
+`--log_ui_draws` is what captures the paint order in the first place.
+
+**It is also completely confounded, and the table shows it.** Every success had
+its title inside 147 s; every failure had it at 177 s or later. Flag and
+boot-time are perfectly correlated across these nine runs, so this evidence
+cannot separate "the capture cvar breaks input" from "a title that arrives late
+is already in the attract state and does not accept input". Both stories fit all
+nine rows.
+
+**A mechanism is hard to see for the flag**: `log_ui_draws` is read only when F10
+arms a capture; the per-draw hook is one relaxed atomic load, and the swap hook
+another. Nothing there should reach the guest. That argues for the boot-time
+reading — but "I cannot see how" is not evidence, and the correlation is what was
+measured.
+
+**What would separate them**, cheaply and next: run the flag ON several times and
+record (boot time → outcome). A single ON run whose title arrives inside 147 s
+and which then accepts Ⓐ exonerates the flag outright.
+
+### A defect I introduced, recorded rather than left to bite
+
+Widening the menu signature (previous commit) made `screen_id.py` classify some
+**boot/attract frames** as `menu` — twice in one run, at t=54 s and t=146 s, long
+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.