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

re: the A-press A/B is run -- signed-in profile, no swallow, menu opens

Browse Source 
The debt from two iterations ago. Two boots, same binary and ISO, one A tap
each, fired only after the plate's pulse had been seen for 12 consecutive
samples. ARGV recorded per leg, because the config dump provably cannot say.

  leg A  no profile flag        3811 swallow lines and climbing
  leg B  --logged_profile_...   0 swallow lines, final glyph 327 = MAIN MENU

327 is the documented main-menu glyph count, reproduced by this instrument's own
control, so leg B's press opened the menu. Capture committed.

Leg A demonstrates the SWALLOW, not the crash: I stopped it at ~2.3 M swallowed
calls because kernel tracing at log_level=3 was eating the 300 MB budget the
crash dumps need. The fault itself remains measured once, historically. One run
per leg.

A void pair came first and is recorded, because it is why the detector is what
it is. The first version fired on a single frame over a glyph threshold and hit
the INTRO MOVIE -- green flashes of 1298..5433 lasting under a second -- about
6 s before the title, in both legs. The presses were real (each skipped the rest
of the movie, which is Q9's behaviour) but the pair tested nothing. The fixed
detector requires 12 consecutive in-band samples, and was replayed against the
void runs' own series as its control: it declines the movie flash at 84.8/85.5 s
and fires at 93.9/94.7 s inside the sustained pulse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 08:05:43 +00:00
parent 6072d216a8
commit e0de5c6f22
3 changed files with 2784 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/port/HANDOFF.md
View File

@@ -2698,9 +2698,26 @@ none is signed in — so Ⓐ takes the state-0 branch of `sub_821D03A0` and call
handler, and nothing in an unattended run dismisses it.
**The route out was already in the tree:** `tools/re-capture/boot_menu.sh` signs the
existing profile in, which is why Q4 and Q5 pressed all five menu buttons. ⚠️ Not an
A/B I have run myself — treat it as strongly supported rather than demonstrated
until someone boots both ways.
existing profile in, which is why Q4 and Q5 pressed all five menu buttons.
✅ **A/B RUN 2026-08-30 — confirmed.** Two boots, one Ⓐ each, pressed only after the
plate's pulse was seen for 12 consecutive samples:
| leg | profile flag | swallow lines | final glyph | outcome |
|---|---|---|---|---|
| A | none | **3 811** and climbing | — | swallow storm |
| B | `--logged_profile_slot_0_xuid=…` | **0** | **327** | **main menu** |
327 is the documented main-menu count. ⚠️ Leg A shows the **swallow**, not the
crash — I stopped it before the ~13 982 report lines the fault needs, because
kernel tracing was consuming the log budget. One run per leg.
🔴 **And a retraction inside the original diagnosis:** I had cited the faulting
run's dumped `logged_profile_slot_0_xuid = ""` as proof no profile was signed in.
**Xenia's config dump is the config FILE, printed before command-line overrides** —
in a run launched with `--apu=sdl --hid=file --mute=true`, it prints `apu="any"`,
`hid="any"`, `mute=false`. So it cannot say what any run did, and I do not know the
historical run's profile state. If you ever cite a Canary dump, cite argv instead.
🔴 **And the honest part: the corpus already knew this and my page did not read it.**
`canary-scripted-input-traps.md` §3 names the sign-in dialog with a capture, and