Commit Graph

4 Commits

Author SHA1 Message Date
sylph-decoder
6f87ecc4db re: the pulse floor gets a second witness, and two METHOD entries
The port reproduced the floor exactly (159) once the predicate was named, and
counted an independent capture from a different session: 753 against this run's
714, a ratio of 4.7x against 4.6x. 'Never goes off' is no longer single-run.

Two METHOD entries.

A detector that can fire on a single frame will fire on the wrong one. The A/B's
first pair was void because the title detector tested one frame against a glyph
threshold and the intro movie throws sub-second green flashes of 1298..5433. The
presses were real and skipped the movie, so both legs returned a clean,
symmetric, meaningless result -- a void test that looks like it ran is worse than
one that errors. Same shape the corpus already recorded for screen_id.py calling
the SQUARE ENIX logo 'title'. Twice paid for. The rule is that a screen detector
matches a signature over time, and a broken run's own series is the cheapest
control for its replacement.

A demand for reproducibility can surface a defect that is not the one demanded.
The literal answer to 'your figures are unverifiable' was 'here is the
predicate', after which they verified exactly -- but writing the method down is
what exposed the cross-geometry floor comparison, which nobody was looking for.
And both sides were wrong at once: the challenger's counts were the wrong
measurement AND the published figure had a real flaw.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:07:51 +00:00
sylph-decoder
6072d216a8 re: name the region and the threshold -- and the floor was cross-geometry
The port agent could not reproduce this page's 159/714/1520 from the capture it
holds: counting green>150..200 over a plate box it got 3-5x at every threshold.
The page named neither the region nor the predicate.

Stated now: the whole 1280x720 frame, and is_title.py's three-channel predicate
(g>130 & g-r>45 & g-b>45), which is why it counts far fewer pixels than a bare
green>N. That reproduces 1520/714/159 exactly.

Writing the method down exposed a defect the prose had hidden. The 159 floor
came from live-title-build4-no-plate.png at 1279x675 -- the game surface --
while the pulse frames are 1280x720, the whole display. Different crops,
silently compared.

Replaced with a same-run, same-geometry floor that was in the series all along:
154, flat for ~2 s immediately before the plate ramps in. So 'it never goes off'
now rests on one run in one geometry, at 714 against 154, which is where it
should have rested from the start. The port's independent ratio of 1:10.4-10.9
brackets this page's 1:9.6 and is the part robust to how anyone counts.

Two METHOD entries: a pixel figure needs its region and its predicate, and a
comparison between two counts needs them to share a geometry; and the port's
observation that a fix which overshoots leaves no symptom until a third change
needs the part it disabled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:59:00 +00:00
sylph-decoder
b6f0cf3fb2 re: RETRACT -- a Canary config dump is the FILE, not the run
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
2026-08-30 07:52:14 +00:00
sylph-decoder
3c004845fa re: the PRESS A plate PULSES -- measured, and it keeps an authored entry
Answers the port's ask #1, which it had flagged as the only one of its four
that could delete an authored entry rather than confirm one. It confirms one.

Held at the title with no input, the plate oscillates continuously: two windows
in one boot, 58 s and 57 s, ~23 cycles each, no decay. Periods 2.530 and 2.540 s
by upward mid-crossings -- 0.4 % apart.

It never goes off. The plate-absent floor is 159 green pixels, measured on the
committed live-title-build4-no-plate.png; the pulse bottoms at 714, 4.5x that.
So the port's 'flash and nothing after', reasoned from ptbtn00 expiring at
t=244, is wrong on the boot's end state -- ptbtn00f's 120-unit cycle is what
runs.

Instrument controls were run before it was pointed at anything unknown: the
glyph counter reproduces the documented 753 on live-title-press-a.png and 327 on
live-main-menu.png exactly.

Two estimators, and only one replicates. Mid-crossings agree across the two
windows to 0.4 %; a single-sinusoid least-squares fit does not (2.553 vs 2.413),
because the waveform is fast-rise/slow-decay rather than sinusoidal -- its own r2
of 0.468 and 0.228 is the tell. Both were controlled on synthetic sinusoids at
2.24/2.55/3.10 s laid on the ACTUAL timestamps and recovered every one exactly,
so neither is broken; one is misspecified. Recorded as such.

The wall-clock is 13 % longer than the corpus's earlier 2.24 s mean. Same
declared 120 units, different emulator pacing (x1.27 here against x1.12), so
this corroborates 'author the units' rather than disturbing it.

Reach stated: one boot; does not distinguish the boot title from an attract-loop
title; and the glyph count is a thresholded pixel count, so 714/1520 is not an
alpha ratio and no duty cycle can be read off it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:37:49 +00:00