fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

docs/re: the boot-title recipe is 3/3 without my capture flag and 0/5 with it — and confounded

Browse Source 
Using last iteration's recipe (first title, one (A)) four more times, it failed
every time. The nine-run table splits perfectly on --log_ui_draws: 3 of 3
successes without it, 0 of 5 with it. That would indict my own instrumentation
cvar, which is the one that captures paint order.

It is also perfectly confounded and the entry says so rather than picking the
exciting reading: every success had its title inside 147 s, every failure at
177 s or later. Flag and boot-time move together across all nine runs. A
mechanism is hard to see for the flag (it is read only when F10 arms a capture;
the per-draw hook is one relaxed atomic load), which argues for the boot-time
story — but "I cannot see how" is not evidence.

The separating experiment is named: ON runs with a fast boot. One that accepts
(A) exonerates the flag.

Also recorded: widening the menu signature last commit made screen_id classify
some boot frames as "menu", twice in one run before any menu existed. A dark-blue
movie frame and this menu are not separable from a single grab — navigation
scripts need the classification to hold across two grabs, which is a caller-side
fix, not a classifier one.
This commit is contained in:
Sylpheed RE agent
2026-08-19 00:00:43 +00:00
parent 673fdaaf56
commit 8dbfeb97df
2 changed files with 55 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/re/BACKLOG.md
View File

@@ -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

47
docs/re/canary-scripted-input-traps.md
View File

@@ -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.