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

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

View File

@@ -233,11 +233,37 @@ blend — needs a screen behind an Ⓐ press.
the existing profile in, and the state-0 branch never fires. That is the launcher
Q4 and Q5 used, and it has been in the tree the whole time.
⚠️ **This is a prediction retrodicted, not an A/B I ran.** The mechanism is measured
and the launcher difference is documented, and Q4/Q5 are the oracle evidence that
Ⓐ works under `boot_menu.sh` — but I have not myself booted both ways and pressed Ⓐ.
Until someone does, treat "signing the profile in prevents the fault" as strongly
supported rather than demonstrated.
### ✅ The A/B has now been run (2026-08-30), and it confirms the mechanism
Two boots, same binary, same ISO, one Ⓐ 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 (see the retraction above).
| leg | profile flag | swallow lines | crash dumps | final glyph | outcome |
|---|---|---|---|---|---|
| **A** | *none* | **3 811** and climbing | 0 (I stopped it) | — | swallow storm |
| **B** | `--logged_profile_slot_0_xuid=B13EBABEBABEBABE` | **0** | 0 | **327** | **main menu** |
**327 is the documented main-menu glyph count** (`live-main-menu.png`), reproduced
by this instrument's own control. So leg B's Ⓐ opened the menu:
[capture](../captures/title-builds/live-ab-signedin-menu-after-press.png).
Series for both legs: [`../data/a-press-ab-legs.txt`](../data/a-press-ab-legs.txt).
⚠️ **Leg A demonstrates the SWALLOW, not the crash.** I stopped it at 3 811 report
lines — ~2.3 M swallowed calls — because kernel tracing at `log_level=3` was eating
the 300 MB size budget the crash dumps need. The crash arrives at ~13 982 report
lines, and that part remains as it was: measured once, historically. **One run per
leg.**
🔴 **A void pair came first, and it is the reason the detector is what it is.** The
first attempt used a single frame over a glyph threshold and fired on the **intro
movie** — which throws green flashes of 1 298…5 433 lasting under a second — about
6 s before the title. Both legs pressed into the movie, both showed zero swallow,
and the pair meant nothing. (The presses were real: each skipped the rest of the
movie, which is Q9's behaviour.) The detector now requires 12 consecutive samples
inside a band the movie overshoots, and that rule 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.
If it ever needs a belt-and-braces second route, patching `xam_input.cc:217` to
return `X_ERROR_EMPTY` instead of `X_ERROR_SUCCESS` terminates the pump immediately