b6f0cf3fb2
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
119 lines
5.7 KiB
Markdown
119 lines
5.7 KiB
Markdown
# The `PRESS Ⓐ` plate **pulses**, continuously — it does not blink once
|
||
|
||
**Classification: measured.** Xenia Canary, 2026-08-30, one no-input boot, two
|
||
separate title windows. Answers the port agent's ask #1, and the answer **deletes
|
||
nothing** — it says the port is currently wrong on the boot's end state.
|
||
|
||
## The question, and why it mattered
|
||
|
||
The port had removed a speculative `looping_focus_records` pulse, leaving a
|
||
renderer that *"shows a flash and nothing after"* — reasoning from `ptbtn00`, whose
|
||
keyframes make it opaque for 8 units (t=236–238, gone by 244). It asked for the
|
||
observed shape, saying this was the one ask that could **delete** an authored entry
|
||
rather than confirm one.
|
||
|
||
It confirms one. **Keep the pulse.**
|
||
|
||
## What the running game does
|
||
|
||
Held at the title with **no input at all**, the plate oscillates continuously for as
|
||
long as the title is up — 58 s in one window and 57 s in another, ~23 cycles each,
|
||
with no decay and no settling.
|
||
|
||
| | window | duration | glyph px | period |
|
||
|---|---|---|---|---|
|
||
| run 1 | t = 254…312 s | 58 s | **714 … 1520** | **2.530 s** |
|
||
| run 2 | t = 83…140 s | 57 s | **714 … 1520** | **2.540 s** |
|
||
|
||
Two windows of one boot, agreeing to **0.4 %**. Evidence:
|
||
[`../data/plate-pulse-timeseries.txt`](../data/plate-pulse-timeseries.txt) ·
|
||
[peak frame](../captures/title-builds/live-title-plate-pulse-peak.png) (1520) ·
|
||
[trough frame](../captures/title-builds/live-title-plate-pulse-trough.png) (714).
|
||
|
||
## The instrument, and its controls
|
||
|
||
`tools/re-capture/plate_timeseries.py` counts the green Ⓐ-glyph pixels — the same
|
||
counter as `is_title.py`, byte-identical. **Controls run before it was pointed at
|
||
anything unknown**, on committed captures:
|
||
|
||
| capture | counted | documented |
|
||
|---|---|---|
|
||
| `live-title-press-a.png` | **753** | 753 ✅ |
|
||
| `live-main-menu.png` | **327** | 327 ✅ |
|
||
| `live-title-build4-no-plate.png` | **159** | — |
|
||
|
||
⚠️ That third one is the reason the result is readable at all: **the plate-absent
|
||
floor is 159, not 0** — the title art carries green pixels of its own. During the
|
||
pulse the count never goes below **714**, four and a half times the floor, so *the
|
||
plate is never absent*. It dims and brightens; it does not blink off.
|
||
|
||
### 🔴 One estimator replicates and one does not — and the failing one says so
|
||
|
||
| | run 1 | run 2 | agrees? |
|
||
|---|---|---|---|
|
||
| upward mid-crossings | **2.530 s** | **2.540 s** | ✅ 0.4 % |
|
||
| single-sinusoid least squares | 2.553 s | 2.413 s | ❌ 5.8 % |
|
||
|
||
Both were controlled on synthetic sinusoids at 2.24 / 2.55 / 3.10 s laid on the
|
||
**actual sample timestamps**, and both recovered every one exactly — so neither is
|
||
broken. The sinusoid fit is **misspecified**: the waveform is a fast rise and slow
|
||
decay, not a sinusoid, and its own variance-explained ($r^2$ = 0.468 and 0.228) is
|
||
the tell. **Take 2.535 s**, from the estimator that does not assume a shape.
|
||
|
||
⚠️ Indexing by sample position rather than timestamp is the documented trap here
|
||
([`ui-clock-freezes-at-settle.md`](ui-clock-freezes-at-settle.md), where it returned
|
||
48 against a true 51); both estimators use the timestamps.
|
||
|
||
## 🟡 The wall-clock is 13 % longer than the corpus's, and that is expected
|
||
|
||
[`ui-record-loop-length.md`](ui-record-loop-length.md) decodes the plate's cycle as
|
||
**120 units declared**, and earlier runs measured 2.12 / 2.19 / 2.34 / 2.31 s
|
||
(mean **2.24**). This run gives **2.535**.
|
||
|
||
| | implied units→seconds factor |
|
||
|---|---|
|
||
| declared 120 units at a nominal 60 units/s | 2.000 s |
|
||
| corpus's earlier runs | ×1.12 |
|
||
| **this run** | **×1.27** |
|
||
|
||
Same declared number, different emulator pacing — this container was under load.
|
||
✅ **This corroborates the existing instruction rather than disturbing it: author
|
||
the 120 units, never a second count.** Any wall-clock figure from this container is
|
||
pacing-dependent and is not comparable across runs without an independently
|
||
measured pacing factor, which this run does not have.
|
||
|
||
## Reach
|
||
|
||
⚠️ **Boot title or attract title — this does not say.** The first window opens at
|
||
t≈255 s from launch, and Q9's no-input baseline puts the title at ~193 s, so run 1
|
||
may already be an attract-loop title rather than the boot's first. Both windows are
|
||
"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
|
||
off these numbers; the shape (periodic, non-decaying, never absent) is what is
|
||
measured.
|
||
|
||
⚠️ **One boot.** Two windows inside it are not two boots, and the pacing factor is a
|
||
property of the run.
|