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

re: RETRACT -- a Canary config dump is the FILE, not the run

Browse Source 
Refuted my own evidence with a direct test. The A-press fault page cited the
faulting run's dumped logged_profile_slot_0_xuid = "" as proof no profile was
signed in. Xenia prints its config dump BEFORE applying command-line overrides:
in a run launched with --apu=sdl --hid=file --mute=true --log_mask=13, the dump
says apu="any", hid="any", mute=false, log_mask=0. Four for four.

So the dump is a statement about xenia-canary.config.toml and nothing else, and
this page cannot know the faulting run's profile state. Anything in the corpus
citing a config dump as evidence of what a run did is making the same mistake;
to know a run's settings, record its argv.

Survives: the mechanism (swallow -> unbounded pump -> failed allocation ->
fault), which rests on the [RE-INPUT] counter and the crash dump's registers;
and canary-scripted-input-traps.md section 3's measured sign-in-dialog claim,
which has a capture behind it.

Also records the port's base-plus-glow mechanism for the plate, which explains
why the pulse floor is 714 rather than the plate-absent 159 -- ptbtn00's fade at
t=244 is an exit ramp so the base holds at 255 while the screen is held, and
ptbtn00f's 0->80->0 glow draws over it. Marked as agreeing with the measurement,
not confirming it: their renderer is not an oracle. It does rule out a glow-only
plate, which could not produce a non-zero floor.

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 07:52:14 +00:00
parent 3c004845fa
commit b6f0cf3fb2
3 changed files with 140 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/re/structures/plate-pulse-measured.md
View File

@@ -90,6 +90,24 @@ may already be an attract-loop title rather than the boot's first. Both windows
"the title, held, with no input", which is what was asked; neither is proof about
the *first* appearance specifically.
## ✅ Why the floor is 714 and not 159 — the port's mechanism, and it fits
The port agent implemented the pulse and reports the shape that reproduces these
two levels: a **steady base plus a pulsing glow**, not a glow alone.
* `ptbtn00`'s fade to 0 at t=244 is its **exit** ramp, so while the screen is
*held* the base sits at alpha 255 — it never leaves.
* `ptbtn00f` ramps 0 → 80 → 0 on its 120-unit cycle and is drawn **over** the
base, not instead of it.
That predicts exactly two levels — base-only and base-plus-glow — which is what
the counter sees as **714** and **1520**, and it explains why the floor is 714
rather than the plate-absent 159. ⚠️ Recorded as the port's mechanism agreeing with
this measurement, not as an independent confirmation of it: the port's renderer is
not an oracle, and its own figures (95.68 / 115.52 in the plate region) are its
render's, not the game's. What the agreement does rule out is a *glow-only* plate,
which cannot produce a non-zero floor at all.
⚠️ **The glyph count is a thresholded pixel count, not an alpha.** A dip to
714/1520 is 47 % of the *counted pixels*, not 47 % of the plate's alpha — pixels
near the green threshold drop out first. Do not read a duty cycle or an alpha ramp

41
docs/re/structures/title-a-press-fault.md
View File

@@ -151,16 +151,39 @@ connect to it. [`canary-scripted-input-traps.md`](../canary-scripted-input-traps
`tools/re-capture/boot_menu.sh`'s own header has carried the mechanism, **including
the 8.4 million figure**, since before this page was written.
### The run's own config dump says the profile was not signed in
### 🔴 RETRACTED — "the run's config dump says the profile was not signed in"
```
[Profiles]
create_profile_if_none = ""
logged_profile_slot_0_xuid = "" ← nobody logged in
...
i> FindProfiles: Adding profile B13EBABEBABEBABE to profile list
i> ProfileManager: Found 1 Profiles ← a profile EXISTS, it is just not signed in
```
This section read the faulting run's `[Profiles]` block —
`logged_profile_slot_0_xuid = ""` — as evidence that nobody was signed in.
**That inference is wrong, and I refuted it with a direct test.**
Xenia prints its config dump **before applying command-line overrides**. In a run
launched with `--apu=sdl --hid=file --mute=true --log_mask=13`, the dump says:
| dumped | actually passed |
|---|---|
| `apu = "any"` | `--apu=sdl` |
| `hid = "any"` | `--hid=file` |
| `mute = false` | `--mute=true` |
| `log_mask = 0` | `--log_mask=13` |
Four for four. **The dump is the config *file*, not the run.** So
`logged_profile_slot_0_xuid = ""` says only that the file is empty; the faulting
run may well have had the flag on its command line, and this page cannot tell.
⚠️ **Anything in this corpus that cites a Canary config dump as evidence of what a
run did is making the same mistake.** The dump is a statement about
`xenia-canary.config.toml`. To know a run's settings, record its **argv**.
What survives untouched: the *mechanism* (swallow → unbounded pump → failed
allocation → fault), which rests on the `[RE-INPUT]` log counter and the crash
dump's register file, neither of which is a config dump; and
[`canary-scripted-input-traps.md`](../canary-scripted-input-traps.md) §3's measured
claim that a profile-less Ⓐ pops the sign-in dialog, which is somebody else's
observation with a capture behind it.
What does **not** survive: this page's claim to know the faulting run's profile
state. It does not.
### And the call site is now located in the image, not only observed