Two captures of the same animation disagree on frame counts by 1.947x, so
frames are not comparable across runs. Expressed as ratios to a long
in-capture baseline, both runs agree: loop period = 13.93 baselines (0.35%
apart), and the sweep starts 0.79-0.80 baselines BEFORE the plate (0.9%).
This answers F6: the sweep does not start at t=0 as the port has it, nor
exactly with the plate -- it leads the plate by about 40 title units, under
a second, which is consistent with what the human reported seeing.
Surfaces a conflict rather than smoothing it: unit 8's title rate of 1.0
units/frame (from ptcopyright) and the plate's 0.571 units/frame are 1.75x
apart in the SAME capture. Either an element's declared ramp is misread or
the two are not on one clock -- the port's clock:"shared" premise. The
ratios stand without a clock; the title-unit conversions are 🟡 pending F4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Applies the fix unit 9 named. Twice a probe printed "armed", carried on and
wrote no draw log -- once because the window lookup failed, once with the
window found and the key sent. Sending the keystroke is not evidence the
logger responded.
After arming, the probe now polls for xenia_re_ui_draws_*.log to exist and
be non-empty, for up to 20 s, and aborts loudly if it does not appear. A
probe that cannot confirm its own instrument is recording is a probe whose
negatives mean nothing.
Narrower fixes were tried and were not enough: making the window lookup
fatal caught the first failure and not the second.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Unit 8's rate (0.514 units/frame) rests on one wrap, a start-to-wrap span
rather than a period. Hardening it needs a longer capture with two or more
wraps. Two attempts, both failed on the harness rather than the game.
First launch never started: the pgrep && echo || { } guard took the wrong
branch, no output directory was created and no process ran, while a stale
emulator from the previous iteration was still up. It looked like a running
capture for several minutes.
Second launch started, armed, pressed A and wrote no draw log at all --
canary.stdout stayed at 0 bytes and no xenia_re_ui_draws log appeared,
despite the script printing "armed at 8s". Likely a race with the orphaned
emulator from the first failure, not confirmed.
Unit 8's numbers are unaffected; they came from the intact f6 capture,
which is still on disk. The offset has two independent supports; the rate
still rests on a single wrap and the port should not ship on it.
The lesson, and it is the second harness failure of this shape: "armed at
8s" printed while nothing was being logged. The arming step reports success
on SENDING the keystroke, not on the logger responding -- the same silent
failure that cost the first F1 probe a run, which I "fixed" by making the
window lookup fatal. That fix was too narrow: the window was found, the key
was sent, and the log still never appeared. The check that would have
caught both is to wait for the draw log to exist and be non-empty after
arming, and abort loudly otherwise. A probe that cannot confirm its own
instrument is recording is a probe whose negatives mean nothing, and I have
now written that bug twice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Question, look-at and not-covered written before the work, per PROTOCOL's
units section.
One boot, one A to skip the attract video, then no input so the title
builds in undisturbed. The sweeps are the two rotated 600%-scaled strips,
identified by size: NDC 1.38x3.15 and 1.39x3.15, matching the corpus's own
independently measured AABB height of 1134 px (2*1134/720 = 3.15).
Drawn alphas run 8, 24, 33, 50, 58, 74, 83, 100, 107 and 16, 41, 67, 91,
116, 128... pteff03's LEAF alpha is bounded below by 128 (keys 0:255
150:128 540:255 600:255). 8 < 128, so the leaf cannot produce it alone.
The parent's alpha is multiplied in.
That refutes the port's screen_view.gd decode that "the leaf runs on its
OWN timeline and the parent's alpha is NOT multiplied in" -- which is
exactly what that file asked for. It flagged honestly that every
observation behind it had parent alpha 0, so "the leaf wins" and "the
parent is ignored because it draws nothing" were never separated, and named
t=100..238 as the separating interval. This capture is in that interval.
Bears on F6's original report: the parent ramps 0->255 across t=70..100, so
if it multiplies in the sweep is invisible before ~70 and dim until 100. A
human reporting it starts late is seeing a real gate -- the parent's ENTRY
ramp, not the 238 cluster, which unit 1 showed is an exit.
Reach: one boot; quads identified by size against a previously measured
AABB, not by name, since the draw stream carries no names. The bound
argument needs only that the leaf minimum is 128, which is from the disc.
It does NOT establish the combination is plain leaf x parent rather than
some other one that also dips below 128 -- only that the parent
participates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
The port needs an initial delay and a repeat interval and has shipped the
mechanism with -1.0 rather than invent them. This builds the instrument and
does not get the numbers.
The vertex stream is the right instrument: C_PAD_DECODER has no timer on
any direction path, so the repeat is in the layer above and cannot be read
out of that function; a cursor move is a quad changing position, and the
guest's vertex buffer carries that with no Canary processing in the path.
tools/re-capture/menu_repeat_probe.sh arms the logger, drives the boot with
pad-file presses and holds a direction. It ran its whole sequence. But the
boot did not reach the menu: in the settled era every quad shape holds a
constant y, and the shapes are near-full-screen rects rather than a button
list. No cursor, so nothing to repeat.
Two instrument errors worth more than the failed run.
The first attempt ARMED NOTHING and said nothing -- xdotool search --class
... --window %1 F10 behind a || true. The run completed normally and only
the ABSENT log revealed it. The working form looks the window up by name,
activates it, and sends F10 to the window and globally; a missing window is
now fatal rather than tolerated, because a silent arming failure is
indistinguishable from a screen that draws nothing.
My first cursor detector measured the wrong change: presents where the SET
of quads changed, which fired on 157 of 161 adjacent pairs because during a
build-in everything animates. Tracking one quad shape's POSITION instead
correctly reports no motion. That is the play-test's own lesson landing on
me -- an instrument that measures change can still measure the change of
the wrong thing.
Next run must not drive the boot blind: gate the presses on a classifier or
join with boot_menu.sh, which reaches the menu but takes screenshots rather
than draw logs. Blind was chosen because screenshots cost ~10 s each while
xenia runs; wrong trade, since a mistimed press costs the whole run.
Reach: the negative is about this run, not the game. F1 stays open and the
port should keep its -1.0 constants.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Answers H1's first half with a negative, and decodes what the timing
constants are for.
C_PAD_DECODER's +0xB4/+0xB8 and +0xBC/+0xC0 (10 and 90, twice) are not a
key-repeat delay/interval pair. They are two identical channels of a
DOUBLE-TAP detector, on cfg +0x74 (LT) and +0x70 (LB), firing output bits
0x20 and 0x40.
The mechanism, from the image: both timers tick down once per update; a
press arms the short timer to 10; a RELEASE adds 1000 to it as a flag
stored inside the counter, which is why the tick watches for exactly 1000
and clears both there; a second press while the flag is set arms the long
timer to 90; and while the long timer runs the output bit is asserted on
EVERY update, with the short timer re-armed to 1010 each time.
So it is a latch, not a repeat: a double-tap opens a 90-update window and
the bit is held for its whole duration. That is a dash or barrel-roll
shape, which fits the buttons it is wired to.
H1: the directions have NO timer. The D-pad and left stick reach the output
word through bare mask tests -- the four left-stick literals at 0x8220C458,
C474, C490, C4AC, and DPAD DOWN through cfg +0xA4 -- with no counter
loaded, decremented or tested on any of those paths. On the evidence of
this layer a held direction does not repeat.
Reach: one layer. A menu could implement repeat on top of a held bit, and
this says nothing about that -- but it does establish the repeat is not in
the shared decoder, so it would have to be per-screen. "One step per
deflection" stays authored for the port; this narrows rather than settles.
Refutation of my own earlier note that a decoder "is where a game normally
puts its repeat timing, its edge detection and its button remap": remap
survives, edge detection survives, repeat timing is REFUTED. That clause
was a prior about how games are written, not a reading of this one.
Also commits tools/ppc-dis, the minimal PowerPC disassembler this corpus
has been rebuilding in scratch and losing to container restarts three times
in one session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
A human on a GPU at ~140 fps: "the logos just switch, there is no animation at
all." Measured from a real boot with --film at 0.05 s, then per-frame change:
splash moves 1.30 s of 7.95 s = 16.4 %
publisher splash 0.30 s of motion, then 3.20 s FROZEN
developer splash 0.35 s + 0.25 s, then 2.40 s FROZEN
distinct luma states in 7.95 s 26
A 45-unit build-in cannot be drawn in 26 states, and a fade does not hold one
picture for 3.20 s. The frame counter says 24.8 fps achieved; both are true --
the port is DRAWING 25 times a second and CHANGING almost never.
🔴 Why every check passed, which matters more than the bug:
frozen sweep drives the clock BY HAND -- proves the renderer can draw
pose N, never that the poses are drawn in sequence
settled compare 0.01 % against the capture -- a screen frozen 84 % of the
time matches a settled reference PERFECTLY, that is what
frozen means
achieved fps counts frames DRAWN -- the same pixels 25x/s scores
identically to animating
Every one measured throughput or a pose. None measured CHANGE. Same shape as
InputEventAction bypassing the input map: the instrument sat below the thing
that was broken, so the break could not appear in it.
tools/motion-census closes the class. It measures change and nothing else, and
its --selftest asserts it separates a fade (97.4 % moving) from a switch (2.6 %)
from a frozen film (0.0 %) -- a detector that cannot tell those apart would
report the same green line on all three.
Both briefs: this is the SOLE focus. The port reproduces before changing
anything and gates every fix on a film rather than a still. The decoder maps the
whole pipeline end to end -- disc bytes, the game's per-frame update (does it
interpolate between keyframes or hold?), what is submitted per frame, and what
Canary does to it before a capture records it -- delivered as a SERIES, not a
settled value.
The port should also record the refutation against itself: H2 reads ANSWERED on
the strength of the frozen sweep. The mechanism half stands, the blur is a baked
companion texture. The behaviour half does not.
Applying my own lesson to my own corpus rather than only stating it. I
exported the content-hash patch and stopped; auditing the docs for
"/canary sha" citations found three pages naming d90d14e02, and checking
/canary's history found the exposure is four commits deep, not one.
Bounded by measurement rather than guess: branch -r --contains puts
590912722 on origin/sylpheed-re and finds no remote for anything after it,
so the container-only stack is exactly these four.
0f920e645 blend= per draw <- the ENTIRE blend decode rests on this
fa1e4c221 vertex dump 8 -> 64 <- at 8 the log silently dropped four
quads of the EXTRAS 24-index batch
d90d14e02 RT state, resolves, PS constants
ab3203f79 h= content hash
The sharpest case is 0f920e645. Without it a draw log records no blend
state at all, so ui-blend-mode-decoded.md's 35-element oracle -- which
overturned a REFUTED entry and deleted the port's authored blend map --
could not be re-derived by anyone who cloned this repository.
The failure mode is silent: the recipe LOOKS complete and only fails for
someone on a different machine, long after its author could say what the
flag did.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
/canary is a separate checkout that lives only in the container and is
pushed nowhere. The content-hash field in the UI draw logger is what
separates "the buffer rotated" from "a frame was decoded", and two
committed findings -- guest-frame-rate-resolved.md and
clock-is-frame-based-one-unit-per-present.md -- cannot be reproduced
without it.
Committed in /canary as ab3203f79 on branch sylpheed-re for a nameable sha,
and exported here as a patch because that sha is not reachable from
anywhere outside this box.
Includes the rebuild recipe, since the build needs the /work/xenia-canary
symlink present and that is not obvious from the failure it gives without
it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Answered against the pre-registration committed before the capture.
Units per second was the last open number on the PRESS (A) plate, and both
prior measurements of it were wall-clock readings off an emulator that runs
the guest slow by an unknown factor. They disagreed by 2.9x, because a 30 Hz
guest at full speed and a 60 Hz guest at half speed look identical on a wall
clock.
The ruler here is not a clock. ADV.wmv declares 30.0000 fps in its own ASF
header, so a decoded movie frame is a tick the emulator's speed cannot
stretch. Presented frames per decoded movie frame is guest_fps/30 with no
wall clock in the chain.
predicted H_A 30 fps -> 60 units/s -> 1.0
H_B 60 fps -> 120 units/s -> 2.0
measured 1.0000
Both pre-registered guards pass. Guard 2: a perfect repeating 3-buffer
cycle, 52 uses each (exactly 156/3), 2 chroma planes per luma on 156 of 156.
Guard 1: run lengths are 156 runs ALL of length 1 -- no smear, so the
dropped-movie-frame bias that would have pushed the answer toward 120 is
measurably absent rather than argued away.
So H_A. The port keeps its 60 and changes nothing.
REFUTES the live H3 hypothesis that 120 units/s explains the play-test's
late plate. That hypothesis was well-formed and attractive precisely because
it would have explained the complaint, which is why it needed a ruler that
is not a clock.
Which means finding 3 still has no cause. The strongest remaining candidate
is decoded rather than speculative: the plate's declared onset is t=214, not
t=236 -- a 22-unit fade, matching the T=22 the oracle confirmed by measuring
+23 alpha per presented frame on that element.
The pre-registered control could NOT be run: this logger build emits vb=
addresses, not vertex contents, so there was no alpha to check +34 against.
A weaker control is substituted and labelled -- the splash shader/blend
census, which validates the log's structure (what this measurement uses) and
not alpha extraction (which it does not).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Both agents asked for this and neither could do it: the register is the file
they both read to decide what NOT to try, so two agents agreeing is not the
authority for changing it (RETRO-2026-08-31-agreed §7.1).
R1: a refutation whose instrument is one of our renderers is not a refutation,
it is "our renderer disagrees" -- 🟡, not ❌. The motivating case was not
careless work. "Blending those sprites additively worsens every measure against
the capture" killed a real disc field for weeks, and read exactly like a
publishable negative; the renderer behind it had a stale keyframe association,
no leaf geometry and no rotation. Nothing in the entry could have told you.
All 222 entries now end with ⟨instrument⟩, read off each entry's OWN stated
evidence -- never inferred. An entry that states none gets `unrecorded`, which
is 83 of them.
Ten moved ❌ -> 🟡, each naming what would settle it: 8 render-vs-capture,
1 our-reader, 1 harness.
Three things the pass turned up:
* The rest() question is OPEN and had been reading as settled in both
directions -- "rest = last keyframe" was refuted by a sibling argument, and
that refutation refuted by correlating our render against captures. Both legs
are our renderer. Which one you believed depended on which entry you found
first, and it decides the pose every plateau-less element is drawn at.
* A withdrawal never reached its sibling: "2 391 frames, max glyph 0" was
withdrawn because a long-lived x11grab stream freezes and repeats a stale
frame; the 1 674-sample negative three lines above it, same probe, was left
standing as a reinstated measurement.
* 83 of 222 -- 37 % -- record no instrument at all. Not disputed, not safe:
unauditable, and larger than every other group combined.
tools/stale-instrument is the --stale query the rule needs, because a colour
alone re-opens nothing: the failure was that nothing re-opened a claim when the
instrument that killed it improved. Its own --check found a real bug on the
first run -- sys.exit("text") exits 1, so three faults documented as exit 2
were reporting the same code as an ordinary miss.
R1 is now standing text in PROTOCOL.md, with R5's exception: our tool is the
right instrument for a question about our tool.
The Port's standing ask list is not in my loop brief, which BLOCKED.md itself
records as having cost three sessions. My brief does force HANDOFF.md open every
iteration and HANDOFF is mine to write, so the pointer lives there. One line in a
file I own; no brief change and no human needed.
R11 says a cross-agent pointer must fail loudly when it goes stale, because every
staleness incident here has been silent. peer_asks.sh exits 2, 3 or 4 with a
message for a missing remote, a renamed branch or a moved file, and lists the
branches it can see so the fix is obvious. A blank output is a failure, not an
empty ask list.
Its own first version was wrong in the way this retro is about. Written as
`git show ... || { echo missing; exit 4; }`, piping it into `head` closed the
pipe, git died of SIGPIPE, and the fallback printed 'the file is missing' for a
file it had just printed in full. An error path that fires on success is worth no
more than one that never fires. Existence is now checked with `cat-file -e` and
the content exec'd; all four paths were exercised before this commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sweep_leaf_ramp dumps the nested ptloop01/ptloop02 leaf keyframes -- position,
alpha, rotation, scale and time -- which is where the ramp the port asked for
actually lives.
sweep_positions now also pools alpha against position per strip and prints the
slope, with the quantisation stated: NDC prints to two decimals, so one frame's
dx is 6.4 px and alpha is one level, and at three or four frames the two
declared slopes (+0.0814 and -0.0651) are inside that noise. It is a direction
and magnitude check, not a discrimination.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
options_draw_capture.sh counted three DOWNs. A dropped press lands the cursor on
TUTORIAL, whose (A) starts the tutorial. My two attempts to avoid counting were
both worse: 'press until the cursor stops moving' is unreachable on a wrapping
menu, and an earlier version of it read the same row twice after a lost press
and pressed (A) on NEW GAME.
The wrap is the landmark. Press down until the row DECREASES -- the cursor is
then on item 1 whatever it started on -- and take three steps, retrying any
press that does not move the cursor, aborting rather than pressing (A) if one
never lands. Needs the row to be monotone in the item, not calibrated.
Also: 1200 s title deadline, and the emulator is killed at the end.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
REFUTED.md kills this claim: 'T8aD +0x04 bit 0x02 selects an additive blend ->
mine, and refuted. Blending those sprites additively worsens every measure
against the capture.' That refutation rests entirely on our renderer, which the
corpus's own rule calls a hypothesis under test. The blend is now measured off
the GPU, so the claim can be tested against the oracle.
35 elements over three screens, every label an RB_BLENDCONTROL0 value read from
the command stream: 16 bit-set and additive, 19 bit-clear and alpha-over, zero
false positives, zero false negatives.
The control that makes it a decode rather than a coincidence: of every bit of
the first 12 header words, EXACTLY ONE separates those 35 elements without
error. Nothing ties with it. A perfect partition on a small sample is worthless
if half the header partitions equally well, which is the mistake +0x08 = 0x8050
was.
And the pair no confound survives: ptbtn00 = 0x0110, ptbtn00f = 0x0112 -- the
PRESS (A) plate and its own highlight, same screen, differing in exactly this
bit, drawn alpha-over and additive respectively.
Committed alongside is a PREDICTION for GP_OPTIONS, written before the capture
that tests it: a different archive, a different element set, and a MIXED
prediction -- po_menu_eff01/02/03 additive, 592 elements alpha-over. Falsified
if those three draw alpha-over or anything else draws additive. The developer
splash was considered first and rejected as a test: both its elements predict
alpha-over, so it can fail but cannot discriminate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The four elements the port measured as the worst on EXTRAS, and which appeared
in no draw, were in a draw all along: the 24-index additive batch holds six
quads and Canary printed the first two. Cap raised to 64, screen re-captured,
all six named. Same draw as ptframe3, whose state was already measured -- the
one-way implication doing real work.
pteff10 is identified too, and it needed the resting SCALE: it ships as 409x144
and is drawn at 200 % x 500 % = 816x720. The matcher's 'try 1x and 2x' rule
could not name it at any scale and reported a near miss against something else,
which is a failure wearing the clothes of an answer. Candidates are now the
declaration's pivot*2 scaled by the resting keyframe as well as the texture at
1x and 2x, and the tolerance is the log's own NDC print quantisation rather than
a chosen number.
Flagged rather than buried: pteff10 measuring additive is in tension with the
port measuring it nearly exact under alpha-over. Both can be true for a dim
semi-transparent glow over a dark background, and it is the one row a rendering
check does not corroborate.
Also stated: the three full-screen alpha-over draws are NOT individually
identified -- four elements declare 1280x720 -- so the label on those rows is a
candidate, not an identification.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
'Press until the cursor stops moving' broke on its first comparison: one DOWN
was dropped, the row read the same twice, and it concluded the cursor had
stopped while sitting on the first item. It then pressed (A) on NEW GAME. No
harm this time -- neither press registered and the screen stayed put -- but that
is luck, not the design.
A stop test that cannot distinguish 'at the end' from 'the press was lost' is
the press-counting bug wearing a different hat. Now: a non-move ends the walk
only after at least one move has been observed, four consecutive dropped presses
abort, and (A) is pressed only if the cursor demonstrably moved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The blend map reports a quad's SIZE, which identifies an element and says nothing
about whether it is visible -- a parked quad is still a draw call. This prints
the NDC x/y range and per-vertex colour of every additive draw, per frame, so
movement between frames and overlap with the [-1,1] box are readable directly.
Written because sylpheed-port flagged exactly that conflation in my blend page:
the blend and the visibility arrived in the same artefact.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
menu_blend_capture.sh counted two DOWNs to reach EXTRAS, which is wrong twice
over -- EXTRAS is the fifth item, and on 2026-08-31 four DOWNs landed on OPTIONS
because one press was dropped. It now presses until the cursor stops moving,
which needs no item count and no row calibration. Its title deadline follows the
same change as title_blend_capture.sh, 1200 s not 420.
ui_blend_map.py takes a comma-separated build list, because the live title is
TWO builds composited -- 4 draws the art, 2 draws the PRESS (A) plate -- and a
one-build size table cannot name the elements of a title capture.
frame_alpha_census takes its builds from argv for the same reason.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Completes the reach of ui-blend-mode-measured.md, which was explicitly two
screens and one session and explicitly not the title.
Three things it does differently from menu_blend_capture.sh, each one paid for
yesterday: a 1200 s title deadline instead of 420 (the 420 fired while the game
was minutes from the settled title); the title arm is gated on the plate pulse
because build 2's PRESS (A) plate is part of what is being measured; and on
timeout it leaves the emulator up and says to attach rather than reboot.
Committed before it is run, per METHOD.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two traps this run paid for.
ring_row.py's ROW0/SPACING are x11grab constants. On a /sylph-home/re/shots/shot-0001.png grab of the
same live main menu the rows read 180.5/419.5/502.0 -- ROW0 is 45 px out, 0.57
of a step. The module refused rather than naming the wrong item, which is the
good failure, and is_main_menu() therefore returned False ON A REAL MAIN MENU. A
run gated on it would conclude 'not the menu' while sitting on the menu. Not
recalibrated: three rows from one session are not a calibration and other tools
share the constants; the module now says so where the numbers are.
menu_draw_capture.sh's 420 s title deadline fired, and the emulator left running
was at the settled title minutes later, took one A, and reached the menu first
try. A timeout is a measurement of the timeout. Leaving the emulator up after a
failed script rescued this run for one minute against a twenty-minute reboot.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes the one route t32-blend-mode-not-on-disc.md left open: the executable's
draw path. Canary's UI draw capture now logs RB_BLENDCONTROL0 per draw, and the
game was driven to the main menu and to EXTRAS with F10 at each.
The title-side UI uses two blend states and ONE pixel shader:
0x07010701 src=ONE dst=1-SRC_ALPHA alpha-over (premultiplied)
ptbase, pteff05, the fade quad, ptmsg, ptmsg2, pttitle, buttons
0x01010101 src=ONE dst=ONE ADDITIVE
ptframe1, ptframe2, ptframe3, pteff20, both rotated sweep strips
Two controls, both run before the result was read:
* the NDC->pixel conversion that identifies a draw by its quad size reproduces
1134 and 1303 px for the two rotated sweep strips -- numbers measured by a
different tool in a different session -- on BOTH screens. The tool prints
PASS/FAIL and disclaims its own output on FAIL.
* pixel shader 0xE59B2B3DA4AA9008 is used with BOTH states, 12 draws additive
and 18 alpha-over. ptframe1 and ptbase run the same shader; only the blend
register differs. So this is a blend result, not a shader result.
This confirms the port's independent measurement -- it solved the composite per
pixel from two backgrounds and found additive halves alpha-over's error on both
frames -- by a route with nothing in common with it.
So the blend is no longer authored: 'any blend you choose is authored' was true
of the disc and is not true of the game. What is still unknown is which field
selects it; elements sharing a mode are batched into one draw call, so the
selection happens before the draw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Identifies each draw by the pixel size of its quad -- NDC extents times the
1280x720 surface -- matched against sprite dimensions read off the disc, since
the log names no elements.
Carries its own control: build 5 draws two rotated sweep strips whose heights
were measured independently at 1134 and 1303 px in
docs/re/data/title-sweep-drawn-at-rest.txt. If the conversion does not reproduce
those, every size it prints is wrong and it says so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Canary's CaptureUiDrawForRE now logs RB_BLENDCONTROL0, RB_COLORCONTROL and
RB_COLOR_MASK per draw, raw and decoded, alongside the shader hashes and bound
texture it already logged. This script drives the game to the main menu and arms
it there.
Unlike menu_draw_capture.sh it does NOT pass --log_ui_draws: Canary's own source
records that arming is unconditional now and that launching with the flag
correlates with the title refusing (A), 0 of 7 runs against 4 of 5 without.
Committed before it is run, per METHOD.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The ja DIFFICULTY capture failed because focus_persistence.py's round trip --
menu, B to title, A back -- did not return, leaving the game off-menu, and the
sweep that followed timed out with nothing to work with. Arriving at the menu is
the cheap part; the round trip is that probe's own experiment and is not every
caller's.
--reach-only stops once the menu is reached, and the session script passes it
through REACH_ONLY.
Committed before running.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The byte comparison showed 2/3 differ in 2.77 % while sharing every element name --
what a language pair looks like -- but that they are ENGLISH and JAPANESE rested on
the disc's convention rather than on this screen. This captures it in ja.
Reuses submenu_focus_sweep.py with SWEEP_TARGETS=0 rather than a new probe, so the
JP capture is taken by the same navigation that produced the English one. The locale
is restored on ANY exit including a crash, and the probe never presses A inside a
submenu, so it cannot reach SELECT DATA and the guest throw.
Committed before running.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port named a gap in their own rule: the fourth aside of mine to reach their
authored data was a STRUCTURE, not a decoration, and 'the unchecked things carry no
weight' did not cover it because a wrong field order looks like a fact. It carried
no weight only by luck. The fix belongs at my end, so this is the control that
should have existed when I published the layout.
The obvious form fails, and its failure is the useful part: checking that all
records are type-plausible passes on the SHIFTED alignments too, 69 of 70 in both
directions. A homogeneous repeated table has the same field types in sequence, so
any window starting on a field boundary type-checks and the interior carries no
information about phase.
Only the BOUNDARIES do. A shifted reading must consume a word from outside the table
at one end, and that word does not obey the field's type -- which is exactly how the
original error surfaced, record 0's handler reading as 0x10000000. Two-sided: the
published alignment survives at both edges and both shifts fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found audit-kinds auditing 16 of 71 authored justifications and never
saying so -- a checker that fails correctly while describing a sixth of the corpus.
Their line is the one that generalises: 'I checked and it was fine' and 'I checked
the part that declared itself' read identically in a log, and only one of them is
what gets quoted.
Measured here: of 86 refutation-shaped bullets in REFUTED.md, 83 are in the
registered form. 97 %, which is better than their 16/71 but was equally unstated.
The three gaps are deliberate, not a bug. They quote their claim in backticks and
are bare identifiers -- +0x29d0, position = instance - 0x12c -- so registering them
would match every live mention of the same offset and train the check to be
ignored. Reported rather than forced to 100 %, for the same reason they report the
ratio instead of demanding it: forcing a counter invites mislabelling, which is
worse than the gap.
Selftest and the real run both still exit 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found three live stale claims in their own source, each already
retracted in their log days earlier. Their framing is the one that matters: a
correction that does not reach the artifact a consumer reads has not been made, and
a comment sits beside the thing it describes.
check_refuted.py scanned docs/ only. Running it over tools/ and crates/ for the
first time found one here too: jp_title_session.sh justified its own existence with
'a free-running clock lands somewhere else on a fresh boot' -- a claim I refuted
myself the day before, when I measured the plate-pulse gate phase-locking the
shutter to 1.6 % of the sweep traverse. The script's stated rationale rested on a
premise I had already killed.
Fixed the file with the correction in place, including what it means for what that
script actually measures: a second capture through the same gate is a second sample
at nearly the same animation phase, so its RMSE 0.32 is a phase-locked lower bound.
Taught the register to scan code behind --code, excluding crates/sylpheed-viewer,
which is the human's tool. Controlled three ways: a planted code revival exits 1
with --code, exits 0 without it -- which is the proof the gap was real -- and 0
again once removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
It scans all of docs/, which includes files sylpheed-port authors, and my copies of
those come from main -- six of seven are days behind their branch head and one I do
not have at all. So a verdict here about one of their files is a verdict about my
stale copy.
The direction that matters is the false positive, and it is not hypothetical: on
2026-08-31 I did it by hand, telling them a BLOCKED.md row was wrong when it had
been struck for days, with their live file one git show away in a ref already
fetched here.
Reported, not excluded. Skipping their files silently would hide the exposure, and
being behind a peer's topic branch is the normal state -- making it an error would
be scenery within a day, which is sylpheed-port's call on their own peer-head tool
and the right one.
Zero hits land in those files today, so this is latent rather than active. Selftest
and the real run both still exit 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port closed their last harness gap on a control that never asked whether
the measurement was LIVE -- an empty band list made identity and the real pair both
pass. Applying that to ring_row.py, which underpins every focus finding I have made
and had no self-test at all.
It found a real defect immediately: main_menu_item(ring_row(f)) is not None was
being used as a main-menu test, and on a TITLE frame the gutter carries a bright
cluster at y=243, inside tolerance of row 0, so the title reads as NEW GAME. Glyph
714 against the menu's 327 separates them cleanly; the ring row alone does not.
It never misfired in the sweeps, because B from a submenu goes to the menu rather
than the title -- the test was simply weaker than it was being trusted to be. Added
is_main_menu(), which requires the row AND the glyph signature, and the sweep's two
menu tests now use it.
The self-test asserts the defect it guards, and includes a liveness case: a blanked
frame must return None rather than a number.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
No new boot was spent: six runs had already captured the first menu entry of a
fresh boot, and all six read NEW GAME. Three of them follow a session that ended
with the cursor on EXTRAS or OPTIONS, which is what makes it a test of persistence
rather than a repeated observation.
Reach stated rather than implied: every session ends with the emulator KILLED, so a
game that writes menu state on a clean shutdown would never get the chance. This
measures 'does not survive a killed session'.
Refutation attempt on the port's extras/initial_focus: ptbtn11 -- it SURVIVES.
ptbtn11 is the top button on the EXTRAS build, with the main menu as a control
where ptbtn01 is top and is known to be NEW GAME.
Incidentally corrects ring_row.py's stated calibration. It cited capture_y = 49.5 +
1.060*design_y, fitted against menu_focus.py's row centres, which are NOT the
disc's button rows -- the disc says 162/242/322/401/482, spacing 80, and
menu_focus.py drifts up to 17 px against them. Re-fitted: 64.82 + 0.9919*design_y,
residuals under 0.7 px. No item assignment changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
DIFFICULTY opens on NORMAL, the second of four, so it is the screen that separates
'resets to the named item' from 'resets to the top item' -- the question
sylpheed-port has had open for several iterations.
The probe is safe on this path without modification: it presses A to enter, one
DOWN, then B to leave, and never presses A inside a submenu, so it cannot reach
SELECT DATA and the guest throw at PC 0x82307128. Noted in the source so nobody
adds one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's point: a control that runs where the tool does not look proves
nothing about the tool. Case 2 plants a revival INSIDE the scanned root and demands
exit 1; a new case plants the same text OUTSIDE it and demands exit 0. The pair
asserts the scan boundary is real rather than leaving it to be reasoned about --
which is how I had it, correctly but only in my head.
Verified first by hand: identical plant text gives exit 1 inside the root and 0
outside it. Five cases now, all passing, and the real corpus still runs clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Verifying it previously meant launching the script, which then waits ~150 s for a
main menu and opens x11grab captures -- so the question "did the self-test pass?"
could not be answered without disturbing whatever else was using the display. That
is how a check-the-tool step turned into competing load during a measurement once
already.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port closed this gap first: their controls asserted failure-on-perturbation
but nothing asserted that a BROKEN harness reports broken. Their stub is a check
that cannot fail; the equivalent here is a register that loaded no claims, which
reported clean forever.
The self-test drives the REAL machinery over synthetic corpora as subprocesses and
reads actual exit codes -- their first version reasoned about what the machinery
would do instead of running it, which is the error this whole thread is about
committed inside the tool built to prevent it.
Four cases, all passing: clean corpus 0, verbatim revival 1, marked revival 0, and
empty register 2. The fourth was a real hole, not a modelled one: the tool now
refuses instead of passing when it parses no claims. Exit convention is theirs --
0 fine, 1 a real check failed, 2 the harness is broken.
Also confirms the real corpus still runs clean at exit 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Sweep 1 failed because ring_row scans the MAIN MENU's gutter and these screens put
their cursors elsewhere; sweep 2 failed because a whole-frame identity test cannot
match once a crash dialog covers the centre. This rework fixes both: the decision
uses the region that CHANGED when the cursor moved, so no per-screen geometry is
assumed, and the back-on-the-menu test is the narrow ring row, which is what kept
reading correctly under the dialog.
The self-test is sylpheed-port's sharpened rule -- a control must construct the
failure it is named after. Mine was one-sided: I checked only that the rule reports
RESETS on a known-RESETS triple, so a rule biased entirely to RESETS would have
passed. It now constructs both verdicts from the same frames and exits 3 if either
is wrong.
Committed BEFORE running, which is the process fix: the previous run aborted
because I was editing and deliberately breaking this file while its own run was in
flight, and the sweep read the broken version.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found an asserting step in their suite that could not fail: a
swallowed the verdict. Tested the same thing here and both of mine had
it. check_refuted.py found a PLANTED unmarked revival, printed it, and exited 0.
impossibility_scope.py printed 'CONTROL FAILED' and exited 0 -- in a tool written
today, one message after they described the shape.
Now: unmarked assertions exit 1; a failed control exits 2. Suppressed mentions do
not fail, since they are unverified rather than wrong and failing on them would put
the clean state out of reach.
Controlled in both directions -- clean 0, planted revival 1, control passing 0,
control deliberately broken 2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The mission's third classification is 'undecodable, with reach', and a negative
written about the subject when it is about the method is the failure that put 'an
individual SE's audio is not extractable yet' at the head of a page whose own later
section located the waves.
The tool failed its control -- the one known instance -- twice. First the pattern
required a sentence-ending period, and headings do not end in periods, so it matched
nothing in any heading and a clean report would have been vacuous. Then the scoring
hid it, because 'yet' was in my list of scope words. It is not one: 'yet' and 'so
far' are temporal hedges naming no instrument, no search and no place looked, which
is exactly what made that heading read as bounded.
With the control passing, the two amplifier files are clean: every INDEX and HANDOFF
hit read, all legitimate. 130 unscoped candidates remain unread corpus-wide, and the
regex has a high false-positive rate -- recorded as reach, not as a clean bill.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
INDEX is read every iteration and is the first thing a new reader meets, and I had
admitted three times to never auditing it. Found by accident: I was about to spend
a boot measuring whether A skips a movie because INDEX said 🟡, when movie-binding.md
had it settled since 2026-08-28 with a three-boot baseline and a delivery counter,
and HANDOFF carried it correctly. The staleness was in the index alone.
Three stale rows fixed: movie skippability, SE audio extractability, and B leaving
the main menu. Five other hits read and left alone -- index and page were talking
about different clauses.
One of the three should have been caught by check_refuted.py: REFUTED holds the
same dead claim with a different second clause, and the register matches exact
wording. Its docstring documents that weakness; this is the first live instance.
Also flags a within-page contradiction not fixed here: menu-audio-cues.md line 81
still heads a section saying SE audio is not extractable, which its own line 189
refutes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Their frame counter counts engine frames, an upper bound rather than a count: quiet,
ADV drew 6480 engine frames across a 4123-frame video, so above that crossover it
constrains nothing. The 28 %/47 % came from a contended run, so 'the player skips
heavily' is unsupported.
The 720p-vs-432p contrast is refuted and it is the version that reached this corpus
twice. Quiet, both videos run +6.7 %..+6.9 %, 5 runs, resolution-independent. The
-0.5 % was contention, not resolution.
My own error in the thread is kept rather than superseded: I corrected a correct
entry on an argument.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
BGM_103's loop bounds are bit offsets in the decoder context, and each wave's
duration follows from its declared byte rate, cross-checked against decoded PCM to
0.007 %. Cycle media length 62.34 / 63.29 s against 61.87 s wall: ratio 0.985,
where a uniform 8.5 % slowdown predicts 1.085 -- 10 % away and on the other side
of 1.0.
The method's error bar is its own 1.5 % self-disagreement between two stems that
must have equal duration, which is why the loop page refused this conversion for a
finer question. It is adequate for an 8.5 % effect.
Does NOT settle the frame clock: audio can hold real time on a timer while
rendering lags, and 27.6 fps and the 8.5 % splash excess are both frame-clock
numbers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Sweep 1: ring_row.py scans x 500:542, the main menu's gutter. EXTRAS happened to
put its ring there; LOAD GAME, TUTORIAL and OPTIONS do not, so the reader found a
static element and all three voided on 'the ring did not move'. Differencing S1
against S2 shows the cursors moved at x 97..231, 338..1099 and 153..479.
Sweep 2: replaced the reader with a whole-frame comparison, controlled on the
EXTRAS frames whose answer is known. Then the guest crashed -- the already
documented STL map/set erase at PC 0x82307128, firing early in the boot, not
something B did -- and Xenia's crash dialog covers the screen centre, so a
whole-frame identity test can never match again. The narrow ring column the dialog
does not cover was reading correctly the whole time. I traded one blindness for
another, and did it because the first instrument had just failed.
Refutation attempt on 'B on a submenu restores the parent's focus' (4/4): it
SURVIVES, and the run I had written off is what corroborates it. The stuck frame
has the ring at y 303.5 = LOAD GAME, the item entered from. A fifth instance.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Now uses the shared measured reader, which refuses to name a row outside the
calibration rather than guessing. Replaying this run's stored frames through it
gives NEW GAME / TUTORIAL / TUTORIAL, which is what the corrected record says.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The doubt was my own artefact: the entry dump printed only the first two sprite
names in HashMap order, making 11 and 14 look like different studios. Full sets
are identical.
7 of 8 pairs declare identical sprite sets, control included. 4/7 does not: entry
7 carries nine sprites entry 4 lacks, including ptlogo_jp and ptlogo_jpeff, so the
Japanese title is a different element inventory rather than the same screen
localised. That matches the JP capture work from the other side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
menu_focus.py's row centres are design-space rows from screenshot output; my
probes fed it whole-display x11grab frames carrying Xenia's chrome and a surface
scaled 1.060. Caught by ground truth, not by a control: the probe announced 'on
EXTRAS', pressed A, and opened OPTIONS.
Measured directly with ring_row.py: initial focus on a fresh boot is NEW GAME,
2/2 fresh boots, both the first menu entry. That agrees with boot_menu.sh's own
line and menu-state-in-memory.md's four-downs, and withdraws this page's
'TUTORIAL 2/2' as the outlier.
Persistence stands and is now geometry-free -- 384.0 vs 385.5, 1.5 px apart. An
equality test is immune to a constant offset, which is why the conclusion survived
a broken reader when the published item names did not.
The control was structurally blind: 'two DOWNs move two items' tests relative
motion, and a constant offset preserves it exactly.
EXTRAS remains unmeasured; that run navigated to OPTIONS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
F1 TUTORIAL, two delivery-confirmed DOWNs to EXTRAS, B to the title, A back:
F3 is EXTRAS. Re-entry restores the item you left.
Reframes the initial-focus disagreement rather than settling it: if focus
persists, any 'initial focus' reading not taken on a fresh boot's first menu entry
measures history. It still says nothing about what the menu opens on -- this run's
F1 was itself carried over from a prior probe's press.
Reached on the plate-pulse gate, not boot_menu.sh, whose stillness test cannot fire
on this title -- TITLE at 422.7 s on a boot skip_intro could not gate at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
skip_intro.sh admits a static screen at d <= 1500 between grabs 0.6 s apart. Over
72 samples of the failing boot the MINIMUM was 1551 -- zero could ever pass. The
timeout is unreachable by construction, not bad luck about intro length.
The premise is in the script's own comment ('the resting title barely changes')
and it is refuted by this session's own draw capture: the title free-runs two
full-screen-height sweep leaves and pulses the plate. HANDOFF already said a
settled screen is not a static screen. wait_plate_pulse.py, which counts glyph
pixels instead of demanding stillness, reached TITLE SETTLED at 245.6 s on the
same game the same day.
Threshold deliberately NOT raised: 7 of 72 samples fall under 2000, so a gate loose
enough to admit this title would also admit movie frames -- the confusion the
script's own header records paying for once already.
Cost recorded: the focus-persistence question it was booted for is unanswered.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
