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

docs/re: boot time refuted as the gate on (A); the flag correlates with no mechanism

Browse Source 
An interleaved A/B (arms alternating in one series, so cache warming cannot pose
as either variable) breaks the confound the last entry flagged — and not in the
direction the first table suggested. The LATEST title of every run recorded,
268 s, accepted (A); a 232 s title refused. "The title arrived late" is dead.

That leaves --log_ui_draws correlating at 0 of 7 against 4 of 5, with no
mechanism available: the cvar is read only when F10 arms a capture, F10 was never
pressed in those runs, the per-draw hook is one relaxed atomic load, and the two
arms' startup config dumps are byte-identical across 246 settings. A correlation
with no mechanism — and an arm that failed once — is not a finding; it is a
variable to remove. Removed: F10 now arms the capture unconditionally.

Also recorded: three boots this session ended on a permanent black screen, two of
them with no input at all. Not the pad, not the cache-flush crash, about one boot
in five.

Five candidate explanations for the (A) gate are now eliminated or refuted. The
next step is the guest's own state machine in sylpheed.db, not another guess from
outside.
This commit is contained in:
Sylpheed RE agent
2026-08-19 00:37:03 +00:00
parent 8dbfeb97df
commit 5145d973c2
2 changed files with 55 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/re/BACKLOG.md
View File

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

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

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