Four models for how the game advances the sweep leaf, four refutations.
Frame-locked predicts px/frame unchanged under --framerate_limit; measured
-4.348 -> -2.032. Wall-clock predicts px/frame LARGER at a lower limit; it got
smaller. sylpheed-port's alternative -- that my samples might be at a fixed
wall-clock rate while guest time slows, which would reproduce the direction --
checked rather than assumed: every capture reports 150 frames spanning 1..149, so
the capture is indexed by guest VdSwap submissions. And per UI-drawing frame,
which matters because at limit 15 only 99 of 150 frames carry draws against 131
at default, gives -5.773 vs -3.687, ratio 1.57, not invariant either.
Three measures of one slowdown -- 3.58x on the boot, 2.14x per submitted frame,
1.57x per appearance -- and no two agree. The clock is none of the four and the
absolute rate stays unpinned. Recorded as undecodable with the reach stated.
Two things the same data does establish.
The rotation is confirmed FROM THE ORACLE. The port's export carries rotation_deg
+30 on pteff03 and -45 on pteff03a, read from the file. The AABB height of a
rotated quad predicts from the declared scale alone: 400x1080 at +30deg -> 1135.3
against 1134 observed (0.12 %), and 400x1440 at -45deg -> 1301.1 against 1303
(0.15 %). Two angles, two scales, both under 0.2 %.
Which makes their inversion real. Height 1134 IS pteff03 -- the leaf whose
declared track is perfectly linear at +4.0000 px/unit across both segments -- and
that is the strip my sign-change gate FAILS. Height 1303 is pteff03a, the
slightly non-uniform one, and it passes. The curvature is in the strip whose
source is exactly straight, so it is not in the disc: it is in the measurement or
in how the game advances the record.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The frame-rate test sylpheed-port and I agreed was the only clean route left.
Same strips, same screen, --framerate_limit=15 against the default. The limit
demonstrably took effect: the title settled at 862 s against 241 s.
First, a gate this work should have had from the start. A slope is only a rate if
its residual is random, so count sign changes in the residual:
default 1299x1303 -4.348 rms 3.33 43/111 OK
883x1134 +4.284 rms 3.08 21/76 SYSTEMATIC
890x1134 +4.284 rms 3.19 15/54 SYSTEMATIC
limit 15 1299x1303 -2.032 rms 1.51 44/83 OK
883x1134 +2.003 rms 1.12 36/61 OK
890x1134 +1.999 rms 0.74 12/37 SYSTEMATIC
So one of the two strips I quoted as "agreeing to three significant figures"
FAILS the linearity gate at default fps: that agreement was between a rate and a
slope through a curve. The port had already caveated the claim for a different
reason; this weakens it further from my own side.
The result, on the one group passing the gate at both settings: -4.348 px/frame
at default against -2.032 at limit 15, a ratio of 2.14.
THE LEAF IS NOT FRAME-LOCKED. A fixed number of units per submitted frame
predicts px/frame unchanged; it changed by 2.14x. Dead.
A simple wall-clock model is dead too, in the other direction: fewer frames per
second means more wall time per frame, so a time-driven leaf should move MORE
px/frame at a lower limit. It moved LESS. Neither model fits and I have no third.
Reach: the effective frame rate was NOT measured. The timing instrument I added
polls for the capture log, which is created when the capture is ARMED rather than
when it finishes, so it reported 0.728 s and is void. The 3.6x boot slowdown says
the limit took effect, not that fps went 28 -> 15. The RATIO is measured; the
absolute rate still is not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's caveat on my 1.07 units/frame: two strips agreeing to three
significant figures constrains the strips to each other, not the absolute rate,
because both ratios come from one capture under one fps assumption. They are
right and I could not remove it. Recording the three attempts and why each fails,
since a closed route is worth as much as an open one.
Route 1, compare the leaf to a TOP-LEVEL clock in the same capture so fps cancels:
not available. On a settled title nothing top-level moves -- that is what settled
means -- and every varying quad in the capture is a leaf. The plate looked like a
candidate (538x76, clean ~56-frame pulse) but build 2's ptbtn00 is a one-shot fade
at t=0,214,236,238,244; the repeating pulse comes from its own nested .rat.
Route 2, fit the same strips in the transition captures, which DO carry a
top-level clock (the fade quad, 8 declared units at 2.0 units/frame). The strips
are present but the fits are not measurements: rms residuals of 26.70 and 16.75 px
against 147 px of travel, versus 3.59 px against 627 px in titledraw2. Scatter,
not a line. The apparent disagreement between captures is a NON-measurement, and
quoting 1.94 or 3.57 as a second sample would have repeated the 6-7 px/frame
eyeball error one message after withdrawing it.
Route 3, read fps from the emulator's own log: not printed.
So 1.07 rules out a per-record quirk and does not pin the absolute rate. The test
that would is measuring the same strips at a deliberately different emulator frame
rate -- unchanged px/frame means frame-locked, scaling with 1/fps means wall time.
Not run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port corrected the disc figure I compared against: the leaf's final
segment HOLDS, so a cycle length is not a motion duration. Verified from the
disc rather than accepted -- pteff03 moves over t=0..540 of a 600-unit cycle
(4.000 px/unit, not 3.600) and pteff03a over 0..630 of 720 (4.063, not 3.556).
Checking that sent me back to my own measurement, which was worse. "6-7
px/frame" came from eyeballing deltas between consecutive APPEARANCES in a
capture that skips frames, so a delta of 7 often spans two frames. A
least-squares fit of x against frame over all 132/112 points gives +4.287 and
-4.348 px/frame, with rms residuals of 3.6 and 3.3 px.
So the confirmation I reported was a prediction 20 % too low meeting a
measurement 50 % too high. Neither number was right and the agreement was an
artefact of both being wrong -- which is the most dangerous form of agreement in
this corpus, because nothing about it looked suspicious.
The corrected numbers say something larger than the claim they replace. Measured
against declared: 4.287/4.000 = 1.072 units per frame, and 4.348/4.063 = 1.070.
Two independent strips with different cycle lengths and different declared rates
agree to three significant figures. Q1 establishes 2 units per RENDERED frame for
top-level elements. So either a nested leaf record advances at about half the
top-level rate, or Q1's factor does not apply to nested records. Measured, not
explained, and flagged as deserving its own iteration because Q1 is load-bearing.
One untested candidate recorded: 1 unit per 1/30 s of game time against the
~28.5 fps this corpus measures for the idle title gives 1.053, close to 1.07.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Last iteration I hypothesised that the game might not draw pteff03/pteff03a on a
settled title, which would have explained three things at once: the flat --at
plateau, the 0.32 between-session in-box term, and part of the ~40 residual. The
oracle says no.
A draw capture of the settled EN title -- gated on the plate pulse, fired at
325.3 s, with exactly ONE emulator verified by count -- shows two quads taller
than the 720 px screen present in every one of 132 frames and sweeping in
OPPOSITE directions:
strip A h=1134 ROT x -109 -> +518 step +6..7 px/frame
strip B h=1303 ROT x +486 -> -154 step -6..7 px/frame
The rate matches the disc: the declared x track is -639..1521 = 2160 px over a
600-unit cycle = 3.6 px/unit, and at 2 units per rendered frame that predicts 7.2
px/frame against 6-7 measured. Both quads are flagged ROT, which is why their
axis-aligned bounding boxes are ~885 and ~1300 px wide where the declared quad is
400 -- consistent with rotation living in leaf records and with `screen render`
being axis-aligned only.
So the leaves ARE drawn and DO free-run on a settled title. My hypothesis is
refuted and sylpheed-port's reading of their `title` curve -- sweep present in a
title capture -- is confirmed by the oracle rather than by a render.
What this does NOT settle is the tension that prompted it. Both strips cross the
adjudication box in x and cover it in y, so two JP captures at different phases
should differ there, and they differ by 0.32. Two candidates, neither tested: the
two JP shutters happened to fall at similar phases (a ~1 % coincidence for a
600-unit cycle), or build 7's denser logo stack -- the katakana plus the
crystalline burst that jp-title-at-rest.txt records as absent from the English
title -- occludes the sweep inside that box. A draw capture of the JP title
distinguishes them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The withdrawal last iteration was caused by `rm -f /tmp/xenia-canary.lock` --
the obvious way past a lock orphaned by kill -9, which also disables the guard
for every later launch. Three instances ended up live at once, sharing
/tmp/xenia_pad.txt and display :98, and silently confounded an input experiment.
Care is not a fix, so this is tooling. ensure_single_emulator.sh counts live
instances, stops them (plain kill, then -9, each with a bounded wait), verifies
ZERO, and only then removes the lock -- refusing loudly if any remain. The lock
is never removed before the condition it guards against is verified absent.
FOUR scripts did the bare `rm -f`, and only two were mine from today:
menu_loop_session.sh, title_draw_capture.sh, poke_control.sh and
resume_reliability.sh. So the footgun was corpus-wide rather than introduced
this session. All four now route through the guard.
The guard is controlled rather than assumed: run against a deliberately started
live instance it reports "1 instance(s) live -- stopping them", ends at 0 with
the lock cleared, and exits 0. A guard that only ever passes on an already-clean
slate would prove nothing.
It also kills by process NAME. `pkill -f xenia_canary` matches the shell running
it -- that has now cost this corpus three commands, one of them a cleanup that
died halfway and left the very instances it was meant to remove.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
While chasing the draw-stream question I found THREE xenia instances running
simultaneously (started 15:39, 15:44, 16:12), which violates the "one emulator at
a time" hard rule and confounds the finding I recorded last iteration.
All three read the same /tmp/xenia_pad.txt and share display :98. A press written
to that file is delivered to EVERY instance, while `screenshot` grabs whichever
window is topmost -- not necessarily the one that acted on it. So "(A) was
delivered and the screen did not change" may simply be two different emulators,
and the keystroke-level confirmation proves only that SOME instance received it.
The navigation.md entry claiming the boot title's "2 of 2" is no longer 2 of 2 is
withdrawn as unsupported, pending a clean re-run.
The cause was mine. run-canary's lockfile is the IMPLEMENTATION of the one-at-a-
time rule; a kill -9 orphans it, and the obvious unblock -- rm -f the lock --
also disables the guard for every later launch. I did that more than once today.
METHOD gains two entries. A lockfile is the rule, not an obstacle to it: clear a
stale lock only after confirming zero live instances, and COUNT them rather than
trusting a kill landed, because a plain kill is asynchronous and a -9 on a stuck
process can take seconds. When a guard blocks you, the question is whether the
condition it guards against is present, not how to remove the guard.
And a third instance of pgrep -f matching the shell that runs it -- this time it
killed a cleanup command halfway through, leaving the emulators alive and the
lock in place. Already recorded for wait-loops; promoted to "reach for -C first".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port could not transfer the masking rule to their screens and inferred a
precondition: my free-running element is a localised plate I can crop around,
theirs is a wide sweep they cannot. Tested against my own screen, that is wrong.
The JP title carries the SAME sweep -- the leaves are identical on entries 4, 5
and 7, which I established last iteration -- and it crosses the box:
two renders of build 7 on the settled plateau, t=135 vs t=240
whole frame RMSE 12.135 95 791 px
in the box RMSE 11.923 57 981 px <- the sweep IS inside the box
differences span y 70..674, x 128..1140; the box is y 54..476, x 389..776
So the crop did not exclude the mover, and the in-box between-session term of
0.3215 has no explanation in the crop. Which leaves a tension worth stating:
two RENDERS one plateau-phase apart differ by 11.9 inside the box;
two CAPTURES of that screen from different sessions differ by 0.32 there;
and the --at sweep of renders against a capture is flat to 1.2 across
t=135..240, despite those renders differing from each other by 11.9.
A metric cannot be insensitive to an 11.9 change unless what changed is largely
absent from what it is compared against.
Hypothesis, recorded as untested: the game may not draw these leaves on the
settled title at all, while our renderer poses them wherever --at says. That
would explain the flat plateau, the tiny between-session term and part of the ~40
residual together. It would also mean the port's "the leaf free-runs in the game
too" is not established by their evidence -- their two minima come from two
DIFFERENT screens, which can differ for reasons other than phase, whereas my two
captures are of the same screen and barely differ where the sweep would be.
Not claiming the leaves are invisible; that needs a draw-stream check for
pteff03/pteff03a on a settled title, which is one run. What is established is
narrower and enough to stop the inference.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port overturned their own phase-0 result using the identical-leaves fact
I gave them: the same leaf minimises at phase 240 against a title capture and 0
against a main_menu capture, so the best-matching phase is a property of when the
shutter fell rather than of the game's rest state. A continuously sweeping
element has no canonical rest phase. They warned that any whole-frame score
against a single capture carries a phase term of ~1.0 RMSE.
Measured on my own two JP sessions, which certainly differ in sweep phase
(44 025 px differ in the band the leaf crosses):
whole frame 4.566
sweep band x721..1241 4.088
the adjudication box 0.3215
Their ~1.0 understates it for this screen: a whole-frame score against one
capture of the JP title carries ~4.6. Theirs is the leaf-phase component isolated
in a renderer; mine is everything that varies between sessions -- the plate pulse
alone contributes ~2.8, measured separately on the EN peak/trough pair -- and
includes theirs.
My margins are unaffected and now for a measured reason rather than an assumed
one. The era margin of 16.72 sits against an in-box term of 0.32, and
settle-vs-rest at 1.48 is 4.6x that term while remaining non-decisive against the
render-axis plateau of 1.2, exactly as stated.
Scoring the 388x423 box rather than the frame drops the between-session term from
4.566 to 0.3215, a factor of 14, because the sweep contributes at x 721..1241 and
the box is mostly clear of it. That was NOT why I cropped -- the crop was to stop
a local difference being diluted across 92 % of an identical frame -- so the
robustness is luck. The rule it earns: score inside a region that excludes the
free-running elements, and measure the residual term there rather than estimating
it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Attempted to refute sylpheed-port's leaf table by measuring it against the disc.
It SURVIVES to the digit: ptloop01 -> pteff03, cycle span 600, x track
-639..1521, scale (100, 600); ptloop02 -> pteff03a, span 720, x -839..1721,
scale (100, 800).
The existing ptloop_leaf_sweep_at.rs samples only t=340..540 -- a window chosen
to compare two competing fits -- so it could never have shown the extent. That
gap is what let my "ptloop01/02 do not free-run" claim stand: measured over the
parent's 200x90 pivot rect, which a leaf travelling -639..1521 is almost never
inside. ptloop_leaf_extent.rs sweeps the whole cycle instead.
New fact neither of us had: the leaves are IDENTICAL on entries 4, 5 AND 7 --
the title, the main menu and the JP title. Same leaf names, spans, x tracks,
scales and parent rest position. So the menu declares exactly the same sweep as
the title, and the still-open menu question is about the game's behaviour rather
than a different declaration.
The quad is 400 px wide at scale_x 100 % -- not widened -- and scale_y 600/800 %
makes it 1080/1440 px tall, taller than the screen. A full-height strip crossing
the frame and going off both sides, which is why a phase-to-phase diff covers the
union of two positions and looks frame-wide.
And my own "centre running x~921->1041" was a 30-unit window of a 600-unit cycle
whose centre spans -439..1721. A sub-range is not an extent -- the same caution
as a pivot not being a bounding box, one level up, and I made both errors within
a day.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port noted that build 5's ptloop parent can be static while the leaf
record animates, and asked me to check it against my table. My own corpus
refutes my claim outright.
ptloop-leaf-sweep-positions.txt -- written earlier in this same corpus -- records
ptloop01.rat's nested record at loop length 600, whose leaf pteff03.t32 sweeps a
400 px-wide quad with its centre running x~921->1041 over t=340..370. The
parent's declared rect is (441,270) 200x90. The leaf draws 300 px outside it: the
parent rect is a PIVOT ANCHOR, not the drawn extent.
Checked against the two JP captures: my measured rect differs by 0 px -- and so
does the whole dead region y 270..450 x 480..960 around it -- while the band the
sweep actually occupies (x 721..1241) differs by 44 025 px. The zero was measured
where nothing happens.
So the port's reading is right and now confirmed from the disc: parent static,
leaf animates, and the two nested records cycle at DIFFERENT lengths, 600 and
720. My "single static keyframe" described the parent only. The era adjudication
is unaffected -- its box overlaps the sweep band only at x 721..776, which shows
no between-session differences.
The menu-loop question is still unsettled after a second attempt, and the second
attempt's failure REFUTES my diagnosis of the first. menu_loop_probe.py gated on
the plate pulse (glyph in [500,2500] held 12 samples), fired at t=484.5 s with
glyph 1723 -- a verified settled BOOT title, not the attract one -- pressed A,
and the press was delivered ([file-pad] keystroke vk=5800 down/up, 8 RE-INPUT
lines). Twenty seconds later all five frames still classified as the title
(rmse ~67-70, margins 0.06-0.16, the "neither" signature; screen_id says title).
So "the attract title accepts nothing" does not explain attempt 1, and the
corpus's "the boot title accepts a single A, 2 of 2 runs" is no longer 2 of 2.
METHOD: a declared rect can be an anchor, not an extent -- confirm an element
draws in a region before diffing that region to ask whether it moves.
navigation.md: confirm the screen changed, do not infer it from a delivered
press.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found ptloop01/02 free-running in their renderer on the menu path,
pinned them, and was explicit that pinning picks one pose rather than the game's:
"a capture question, not a harness one". It is, and it lands in my lane.
On the title it is now answered. Those leaves rest at (441,270) 200x90, INSIDE
the box the ptlogo_eff3 era adjudication uses, and across my two JP captures from
different sessions they are byte-identical: 0 of 18 000 px, max |d| 0, against a
whole-frame contrast of 116 492 px differing. So they are static at rest, and the
in-box between-session noise of 0.32 is not theirs -- the 645 differing pixels
all lie in a 30-row band at y 99..128, nowhere near the loop rect. That also
closes the reach caveat on the EN->JP noise transfer.
The MENU is a different bundle and is not settled. Build 5 declares the same rect
with a single static keyframe, and that is where their row drifted.
menu_loop_rest.sh was written to capture five settled menu frames and diff the
rect; it did not complete. The run reached a title at t=146 s and (A) did not
take across six attempts -- the documented intermittency where the attract loop's
title accepts nothing, unlike the boot title. Recorded rather than re-rolled.
Two committed main-menu captures cannot substitute: they differ across 57 % of
the surface (different geometries and capture paths), so the 88 % differing on
the loop rect measures the mismatch, not the loops. The control fails and the
comparison is void.
navigation.md gains the trap that cost this iteration a run: kill -9 on xenia
orphans /tmp/xenia-canary.lock, the next run-canary refuses to STDERR where a
polling script never looks, and a probe then sampled a dead display for 484 s
reporting `other` every 4 s -- because screen_id.py on an empty screen returns
`other` and "not the title yet" is indistinguishable from "there is no emulator".
Kill plainly so it clears its own lock, and assert the emulator is alive before
entering any wait loop.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Last turn I transferred the EN title's capture noise to the JP box and flagged
the gap: build 7 carries ptloop01/02.rat which may animate inside that region
where the EN plate does not, and the era adjudication rests on a single capture.
Took a second, independent capture from a fresh boot in a separate session
(jp_title_session.sh -- sets ja, captures, always restores en; verified back at
language=1).
Within-run stability reproduces: 0 of 138 600 px in the ROI across four
comparisons, with 47k-73k px moving whole-frame as the contrast control.
BETWEEN SESSIONS, inside the box the adjudication uses: 645 of 164 124 px
differ, RMSE 0.3215, against 116 492 px whole-frame -- genuinely different
sessions. And the verdict reproduces to three decimals: stale 58.412 -> 58.413,
fixed 41.690 -> 41.692, margin 16.722 -> 16.721.
The shape is the useful part: capture noise moves both candidates together, so it
nearly cancels in a MARGIN. Absolute scores moved 0.001-0.002 while the margin
moved 0.001 against an in-box noise of 0.32. A margin between two renders scored
on one capture is far more robust than either score is.
CORRECTION to a claim I made earlier today and sent to the port: I said the
settle-vs-rest negative was STRENGTHENED because 1.48 sits below the whole-frame
capture spread of 2.8. Wrong comparison -- the measurement lives in the box, and
in-box between-session noise is 0.32, so 1.48 is well above it. The negative
rests on the render axis alone (1.2, ratio 1.2x), exactly as first stated. I
reached for a number that was to hand rather than the one that applies, which is
the same family as the errors we have both been cataloguing.
METHOD gains: match the noise floor to the quantity, including which noise
applies; and sylpheed-port's point that an instrument which rounds away the thing
being verified cannot verify it (they called a harness reproducible from an RMSE
printed to two decimals when the residual was 0.0565).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found their main_menu row drifting 13.25-13.30 across runs on a
free-running spin clock, and made the general point that a margin only means
something against the noise it sits on. My --at plateau measures the RENDER axis;
it says nothing about how much the score moves between two CAPTURES of the same
screen, which is what a single JP grab is exposed to.
Measured from two independent captures of the settled EN title at different
phases of its free-running plate pulse, scored against one render:
whole frame peak 31.302 trough 28.463 spread 2.839
inside the box peak 21.230 trough 21.230 spread 0.000
The zero carries its control: the two captures differ by 83 496 px whole-frame
(max |d| 174), so they are genuinely different grabs, and by 0 inside the box --
the screen's free-running element is the plate, which lies outside the logo
region the adjudication uses.
Margins re-stated: stale-vs-fixed 16.7 is 14x the render noise and >=5.9x the
whole-frame capture noise, so the era result survives on both axes. And the
settle-vs-rest negative is STRONGER than first stated: 1.5 is not merely inside
the render plateau's 1.2 flatness, it is below the whole-frame capture spread of
2.8 as well.
Reach recorded: this transfers the EN title's capture noise to the JP title's
box, and build 7 carries ptloop01/02.rat which may animate inside that region
where the EN plate does not. A second JP capture would settle it and has not been
taken.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port pointed out that classifying defaults "by inspection" is exactly
the method that cannot see an in-range fallback, and that correction applies to
my own sweep from an hour ago: I waved 64 sites through by reading them.
Counted instead, disc-wide over 965 builds and 24 811 keyframes:
ui_layout.rs:1681 untimed poses (would fabricate t=0): 0
ui_layout.rs:1010 pose_at queries 168 264, None (reads a=0): 0
Two zeroes, which is the result this corpus now distrusts most, so the detector
was made to prove it can see a hit: ask pose_at for a time no build declares.
The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was
blind and the :1010 zero measured nothing.
The failure is the finding. pose_at is TOTAL: reading the source, its only None
path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0
elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable
BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was
established by the control failing rather than by the count passing. Without the
control this corpus would have recorded a true conclusion resting on a
meaningless number.
:1681 stands differently: 0 of 24 811, and time really is Option<u32> with the
stale reader demonstrably producing None (its screen info prints a trailing -),
so the state is representable and a detector would see it. :973 is not a hazard
-- guarded two lines later by `if tmax == 0 { return false; }`, where reading is
sufficient because the guard is the proof.
METHOD gains both: a zero is worth nothing until the detector is shown able to
report non-zero; and the habit under several of this week's errors, which is
reading a PROXY for the thing when the thing itself is one command away -- a line
count for an era, a type name's spelling for its default, an ordinal for an
entry, a fallback's text for its firing rate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The mirror of sylpheed-port's sweep after their exit_ramp_units catch, where a
refuted 24.0 survived in a `get(..., 24.0)` fallback because the authored entry
had been deleted as progress and the deletion was a no-op.
112 fallback sites across sylpheed-formats and sylpheed-cli. 64 supply 0, false,
empty or Default -- sentinels asserting nothing. Of the 48 remaining most are
pass-through or an extent. Positive control: the filter found media.rs:314
unwrap_or(anchor), the voice-region start fallback landed earlier this session,
so the detector finds a known case rather than only reporting absence. The
mesh.rs cluster (1.0, 0.85, 0.5, 0.70, 0.45) is env-var tunables with defaults
documented in xbg7-mesh.md.
ui_layout.rs, the crate the port pins, has 8 sites; 6 sentinel or pass-through
and 2 that could fabricate a quantity. Both fabricate a value that is
LEGITIMATE, which is worse than the port's conspicuous 24.0:
:695 unwrap_or((DESIGN_W, DESIGN_H)) -- 1280x720, which is what every real
screen states, so no parser output can distinguish read from invented.
MEASURED: it fires 0 times in 965 builds disc-wide, so design_w/design_h
is read and the port can rely on it.
:1681 kf.time.unwrap_or(0) in the serialiser -- 0 is a real keyframe time
(pose 0's time IS 0). Unreachable today under the corrected record
layout, the same status as their exit_ramp_units branch, but a
fabricated 0 would be indistinguishable from a real one.
The measuring instrument failed its own control first: a version reading EVERY
RATC child reported all 965 builds stating a non-standard design size
(GP_TUTORIAL 12x3), where `screen list` prints 1280x720 for every one -- a T8aD
sprite header read at +0x18 is garbage that passes the range test. Filtered to
the .rat records, it reproduces screen list exactly.
METHOD: a fallback default is an authored value no reader can see, and the
dangerous ones are IN-RANGE -- the only way to know is to count how often they
fire, which no parser output reveals.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's harness grabbed main_menu at t=9.00 in one session and t=8.00 in
the next. One keyframe unit apart, mid-build-in, is 70 % of the picture, and it
read as "the change broke two screens" -- a real measurement of the wrong thing.
The instant was stable WITHIN a session and drifted BETWEEN them, so every cheap
reproducibility check said deterministic. Their flags are their harness's, not
sylpheed-cli's (checked: `screen` has only list/info/render), so the tool defect
is not in my crate -- but the hazard generalises to every live capture here.
It would void this iteration's ptlogo_eff3 adjudication if the JP capture had
been taken at an arbitrary moment. It was not, and for two independent reasons
recorded rather than assumed: the grab was gated on the plate pulse, the title's
own settled signature, with the gate and a contrast control written beside the
capture in jp-title-at-rest.txt; and the --at sweep shows the capture on a
plateau flat to 1.2 RMSE across 105 units against edges at 78, where a capture
caught mid-build would give a sharp minimum. The sweep was run for a noise scale
and answers this too -- which is luck, so METHOD now names both defences.
METHOD: pin a capture's instant explicitly, and do not infer stability from
repeat runs inside one session. Gate the grab on a settled signal prospectively,
and sweep --at retrospectively -- a broad flat minimum with sharp edges means at
rest, a sharp minimum means the instant is load-bearing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found that a shared CARGO_TARGET_DIR across two source trees
serves one binary to both: cargo fingerprints per source path, so building tree B
into a directory last written by tree A prints "Finished" in 0.15 s and changes
nothing. Their harness scored against a decoder from an unnamed tree for hours,
and it HAPPENED to be the correct era -- agreeing by luck, which is worse than
disagreeing because nothing prompts the check.
My own era comparison could have died the same way, so I audited it rather than
assuming it was fine: the two binaries have different md5s (7516bdac vs
8370e0e9), they were built into SEPARATE target dirs, and the era control still
distinguishes them live -- `rest t=70 [12 70 80 -]` against `rest t=12
[0 12 70 80]`. The result in ui-resting-pose.md stands, now with the evidence
that it stands.
Also raises main-is-the-stale-era.md from hygiene to a defect anyone can build.
Two things landed since it was written: the corrected association is now
confirmed against the running game (RMSE 41.69 vs 58.41 on a live title_jp
capture, a margin ~14x the noise floor), and the port confirmed their published
branch carries the stale ui_layout.rs, md5-identical to main's. So every
published ref except this branch ships the decoder the game disagrees with, and
nothing in a build warns you. Merging is a human's call; the page records the
cost of not making it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The era test left one element responsible for all 74 507 differing pixels on
title_jp -- ptlogo_eff3.t32, the corpus's named plateau-less rest() discriminator
-- with two candidate rest poses, (108,72) stale and (98,42) fixed. There is a
capture of that exact screen, so the oracle can choose.
Scored over the 388x423 box where the two renders differ, so the result is not
diluted by the ~92 % of the frame that is identical:
stale era rest (108,72) RMSE 58.412
fixed era rest (98,42) RMSE 41.690 <- the game agrees with the fixed era
fixed era --settle t=213 RMSE 40.210
Until now the keyframe record-layout fix rested on internal consistency: 0 of
1 042 multi-segment alpha ramps constant-rate under the old reading against 857
of 1 540 under the new. Strong, but not a measurement of the game. It now has
one, on the single screen where the two readings change pixels.
Three controls, all run first. Alignment found by sweeping the vertical offset
rather than assuming it -- 45 gives 32.41 against 56.37 and 53.08 either side, a
sharp minimum at the known game-surface offset. The scoring box discriminates:
the same box against a different screen's capture gives 98-103 against 40-58
here. And --black changes nothing (58.412/41.690 either way) because every pixel
in that box is covered by an element -- recorded because the flag's help says a
framebuffer capture must be compared against a black canvas, and here it happens
not to matter.
Sweeping the screen's own timeline with --at gives the noise scale: the capture
sits on a plateau from t~135 to t~240, flat to 1.2 RMSE across 105 units, rising
sharply outside (78 at t=0 and t=270). So the stale-vs-fixed margin of 16.7 is
~14x that flatness and decisive, while the settle-vs-rest margin of 1.5 is INSIDE
it and is not. This capture separates the eras and cannot separate the policies;
the settle-instant proposal stays unadopted.
Refutation attempted: sylpheed-port's adjudication that their shipped pose is
closer to the game than their reference. It SURVIVES, independently and by a
different metric, in the same direction.
Also concedes that my "your branch is the stale era" reasoning was invalid -- I
inferred era from a line count, which is the error they named -- while recording
that the conclusion holds for the ref I could see: origin/auto/port-p6-audio's
ui_layout.rs is md5-identical to origin/main's.
METHOD: two things that should differ producing identical output is a broken
experiment until proven otherwise, and a zero is its most dangerous form. Four
instances now. Verify the inputs differ before believing the outputs match, and
do not infer that difference from a proxy -- line count is not era.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The reach test I deferred twice. sylpheed-port tested three screens across the
stale and fixed ui_layout.rs eras, found 0 differing pixels, and concluded the
eras explain nothing. Built both eras from source and rendered EVERY composable
GP_TITLE bundle through each.
7 of 16 differ. Entries 0-6, 8 and 9 are byte-identical -- which includes title
(4), main_menu (5) and extras (6), so the port's result reproduces for the
screens they picked. Entry 7 (title_jp) differs by 74 507 px, RMSE 12.409; the
two loading bundles by 49 771 px, RMSE 10.078; the four splashes by 23-33k px at
RMSE 0.94-1.78.
So "the eras explain nothing" is true for three screens and false for the
archive. It is specifically false for title_jp, which is one of the two rows
their check-all now allows BY NAME with the reason "rest-pose sparkles". Their
measurement of that screen was 0 and mine is 74 507; recorded with exact flags as
a disagreement for them to check, not adjudicated. Noted that their branch's
ui_layout.rs is the stale one (20 ins / 488 del against the pin), so a binary
built from their workspace HEAD is the stale era.
Two controls, both run first. The binaries genuinely embody the eras: build 5's
pteff00.prm reads `rest t=70 [12 70 80 -]` stale against `rest t=12 [0 12 70 80]`
fixed. And the renderer is deterministic: same binary, same flags, twice, 0
differing pixels on entries 7 and 12 -- without which every number is noise.
Mechanism on entry 7 is a single element, ptlogo_eff3.t32, rest (108,72) ->
(98,42). That is the element MISSION.md and ui-resting-pose.md already name as
THE plateau-less rest() discriminator, so the era difference on the JP title is
our existing open question surfacing rather than a new one.
And a trap: entries 10-15 differ by up to 49 771 px with NO rest position change.
The rest selection moves to a keyframe at the same (x,y) with a different scale
and alpha. My first extraction compared only the rest (x,y) column and would have
reported a difference with no cause. A pose is position and scale and alpha.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's BLOCKED ask #2. The gap was the one quantity in the transition
with no rule: measured at 0, 3 and 2 frames across three transitions, and I had
proposed it might be a load, which would make it emulator- and storage-dependent
and unauthorable.
Leg 1, bundle size runs the wrong way. If the gap were the incoming bundle
arriving, the biggest bundle would gap longest. Build 4 is 12 278 666 B and gaps
ZERO frames; build 5 is 6 977 437 B and gaps 3 and 2.
Leg 2, ran title->menu a second time from cold. The outgoing ramp is
byte-identical (63, 127, 191, 255) and the gap is 3 frames in BOTH runs.
Leg 3, and the two runs are not a null comparison -- which is the objection leg 2
invites. The captures refute it themselves: press-to-first-change differs by ~12
frames between them (~25 against ~10). Something in this transition really is
cache-sensitive and moved by 0.4 s, while the gap did not move at all. The
control comes from inside the measurement rather than from an assumption that
conditions differed.
So the gap is deterministic to the frame and not a load. It is also not constant
across transitions (0, 3, 2, 3) and not in the fade group -- the port reports 866
keyframes across 16 screens with 0 untimed. A deterministic game quantity with no
rule found; black_hold_units stays 0, and "not a load" must not become a reason
to author a constant.
The load proposal in screen-transitions.md is marked refuted rather than deleted.
Also fills in docs/game/navigation.md, which the standing brief asks me to keep
and which I had not touched while measuring four transitions: a player-side
section on what a screen change looks like, and three scripting traps -- that
`pkill -f xenia_canary` kills the shell that ran it (cost a launch today, and the
same trap is already in METHOD for pgrep), that screen_id.py reports `menu`
during the attract loop, and that it cannot tell EXTRAS from the main menu.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Went to refute sylpheed-port's finding that their check-all allowance ("the pin
is not on main, so this compares two decoder eras") explained nothing, by
extending its reach past three screens. Found the premise is understated.
git rev-list --left-right --count origin/main...HEAD -> 0 171
main has nothing we lack; we are 171 commits ahead of it. Its tip is dated
2026-08-29, the pin tag is not an ancestor of it, and its ui_layout.rs still
reads "Keyframe time, or None for the group's last frame" -- the pre-fix
association that takes a pose's time from the NEXT record and leaves a group's
final pose untimed. That is the exact bug that left fade_quads.py stale and made
screen-transitions.md publish a 0.87-4.08 s fade-in for a 0.20-0.27 s ramp.
So "sync with main first" is currently backwards: main is the stale era, and
`git merge origin/main` is a no-op from any topic branch -- it says "Already up
to date" every iteration, which reads as "I am current" and means "main has
nothing". Do not pin to main.
The port's measurement stands: across their three screens the two eras render
identically, which is consistent with the association fix moving TIMES and not
pixels -- same signature as the .tbm and stale-sylpheed-cli findings.
Not settled: whether the eras render identically beyond three screens (the
disc-wide build-and-compare is not done), and why 171 commits are unmerged,
which is a human's call.
Also adds the METHOD entry the port offered: an allowance is a claim and it
decays; allow by NAME, never by COUNT, because a count cannot notice that a
different row started failing while the total held steady.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's BLOCKED.md ask #1. They declined to suppress their uniform
black_hold on the cancel path because (B) menu->title was one transition. The
test says they were right.
EXTRAS -> main menu, also via (B): the outgoing quad ramps frames 34-38 (5
frames, exactly build 6's declared 10 units), then frames 39 AND 40 are
completely empty -- 3 draws, zero textured, a harder black than either earlier
capture -- then the incoming menu's quad decays 41-45. So (B) does not imply a
cross-fade; menu->title is the outlier of three, and the generalisation I was one
step from publishing is false.
The screen was verified, not assumed. screen_id.py cannot separate EXTRAS from
the main menu, so which_title_screen.py checked the armed frame: extras 18.58 vs
main_menu 29.85, margin 11.27, inside the 9.9-11.7 band its control sets on four
known captures.
Three transitions now agree on one thing and disagree on another:
outgoing ramp = the declared final ramp, THREE FOR THREE, against three
different declared values (10u/5f, 8u/4f, 10u/5f), and exactly linear where
nothing overlaps it. Authorable from the file.
black gap = none / 3 frames / 2 frames. Not a per-button property, not a
per-direction property, not a constant. black_hold_units should not be
authored as one.
Build 5's incoming ramp is confirmed at 12 units by its RATE rather than its
count: the count came out 5 against a predicted 6 in both runs -- reproducible,
so not noise -- but capture 3's steps are -21, -42, -43, -42, i.e. 255/6 per
frame after a half-step start. Capture 2's decay does not fit that and is
unexplained.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's BLOCKED.md ask #1 -- does (B) from EXTRAS also show no black
interval, or is "(B) has no black" one screen pair -- needs the harness to know
it is on EXTRAS. screen_id.py cannot tell: both are dark blue GP_TITLE screens
and it reports `menu` for either.
which_title_screen.py correlates a grab against our build 5 / build 6 renders.
First version FAILED its control: it called live-main-menu.png "extras" and
live-extras.png "main_menu", both backwards, margins under 1.1 on RMSE ~33.
Cause: it applied the y=45 game-surface offset unconditionally, but only a full
1280x720 display frame has the menu bar -- a 1279x675 grab IS the surface, and
two of the three reference captures are surface-sized. Offset made conditional;
the control now passes 4/4 with margins 9.9-11.7 against ~18 within-class.
The tool is a navigation aid for driving the emulator and says so: it identifies
a screen by agreeing with our own renders, so nothing measured may rest on it.
Also records the METHOD entry sylpheed-port offered from their own wedged check
script: an absence of output is not a status. They reported "still running, two
lines, both ok" for three iterations while the first attempt had died silently
under its own timeout with block-buffered output -- zero information, reported
as patience. An orphan from an older form of the same script was found running
after 9.5 hours. Line-buffer and bound long jobs, and check the artifact rather
than the exit code: the artifact reached its correct duration while the process
never returned.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Last iteration left an unidentified full-screen untextured quad decaying
255->15 during a menu->title transition, which build 5's declaration does not
account for. Hypothesis: it is the INCOMING screen's own pteff00, which opens at
a255 and clears. 8 frames matching build 4's declared 16 units is a FIT, so the
test was a transition whose incoming screen declares something else: title->menu
brings in build 5, 0->12 = 12 units = 6 frames. Prediction recorded before the
run.
Measured: menu->title decay 8 frames (incoming build 4, declared 8), title->menu
decay 5 frames (incoming build 5, declared 6). Different incoming screen,
different decay, in the predicted direction. The second is one frame short of
prediction, inside the documented +-1.
The tell that clinches it: a screen contributes TWO primitives, pteff00 at 255
and pteff02 at 64. The settled menu's untextured set is [64]; at frame 34 it
becomes [64, 255, 64] -- build 4's opening pair, which no single element
explains.
Bonus, and it closes the alpha puzzle: in capture 2 the outgoing quad ramps with
no other untextured quad present -- 63, 127, 191, 255, steps of exactly 64, four
frames, against build 4's declared 261->269 = 8 units = 4 frames. Exact and
exactly linear. Capture 1's 102/127/255 was a composite of two overlapping
quads, as sylpheed-port proposed.
The thing neither of us predicted: the two directions are not the same shape.
(A) title->menu is SEQUENTIAL with a real black interval of 5 frames (~10 units,
against the port's authored 9). (B) menu->title is a CROSS-FADE with no black
interval at all -- the incoming title starts drawing at frame 34, before the
outgoing menu's quad begins ramping at 40. Authoring one hold for both directions
inserts black that (B) does not have.
Also fixed: fade_pair.py's automatic rising/decaying classifier worked on capture
1 and produced nonsense on capture 2, where the title has no full-screen
primitive at rest and the heuristic latched onto a transient. It now prints and
does not decide.
Refutation attempted: sylpheed-port's structural prediction of a 6-frame decay
for an incoming menu. Measured 5. Survives as direction, one frame short as
duration; recorded as both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port read the lead off the disc independently: content fade-outs start
at ptmsg 58, pteff10/pteff12/ptbtn05 60, against the quad's ramp at 70. That
reproduces my measured six-frame lead exactly (12 units = 6 frames) but has
content FINISHING two units before the quad starts, where I had published
overlap.
Checked which draws I had been watching. The content sprites are TEXTURED: they
fade over frames 34-37 and are gone by 39, and the black quad appears at 40 --
a one-frame gap, which is their two units. What overlaps the quad is a
different, UNTEXTURED full-screen quad decaying 255->...->15 across frames
34-41. It is unidentified: build 5 declares only pteff00.prm and a
single-keyframe pteff02.prm, neither of which is that decay. Recorded as an
open observation, not named from one capture.
So the shape is sequence, not overlap.
Also flagged, against my own interest: their "18 vs 19, one unit apart" compares
different intervals (content-start->black vs ramp-start->next screen), and the
capture's frame axis is not phase-locked to the file's unit axis -- the two
plausible alignments differ by two frames with nothing here to distinguish them.
So that agreement holds at one alignment and is not a confirmation. The quad's
alphas (102/127/255) also do not sit on a linear ramp across t=70->80, which is
unexplained.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
screen-transitions.md carried a 14-unit "black hold" that the page itself
flagged as arithmetic rather than measurement. Measured it against the running
game; the guess was wrong, and finding the instrument to measure it turned up a
second, larger error in the same page.
1. fade_quads.py was STALE. It read each pose's time from blk+36 -- the next
record's time word -- the association the keyframe record-layout fix retired in
the crate. sylpheed-cli was rebuilt at the time; the Python helper was never
swept with it. Signature: it cannot time a group's last pose, so it printed a
trailing `t=-`. Fixed, controlled against the rebuilt `screen info` ([0 12 70
80] for build 5's pteff00.prm).
2. Through it, the page labelled the quad's CLEAR-hold as its fade-in and
published 0.87 s / 0.97 s / 4.08 s for a ramp that is 0.20 s / 0.20 s / 0.27 s.
A port pacing its menu fade-in off that would run it 5x too slow.
3. The measurement. fade_decompose.sh boots to the main menu, arms the UI draw
capture there, then presses (B), so one 260-frame window holds the whole screen
change. The fade quad is identified rather than guessed: a .prm carries no
tex[base=] and paints last, so it is the last full-screen untextured quad of a
frame. Control first -- the quad's ramp is decoded at 10 units = 5 frames, and
measures 4 submitted-frame steps with one unlogged frame in the span.
Result: content elements begin fading at frame 34; the black quad first appears
at 40 and is opaque by 43; the menu's last frame is 45; frame 46 has 6 draws
against 12. So the ~14 extra units are the content's own fade-outs OVERLAPPING
the quad's ramp, not a hold after it, and the inter-screen black is one frame.
Refutation attempted: sylpheed-port's entries 13/14 twins. Re-derived off the
disc -- 3.06 / 4.33 / 47.91, identical to two decimals. Recorded as confirming
their addressing and arithmetic, NOT as independent support: same renderer,
same disc, which is their own rule.
Reach: one transition, one run; the frame axis has gaps (232 headers over frames
3..260), so every span is +-1 frame.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Last iteration I retracted three claims because `--build 10/11` on GP_TITLE are
entries 12/15, and named the untested remainder in my own report: how much else
in the corpus used a build ordinal as an entry index. This is that sweep.
`screen --build N` indexes a predicate-filtered list, so every rejected entry
shifts every later ordinal. Disc-wide: 21 of 24 build-bearing archives diverge,
18 of them at ordinal 0 -- `--build 0` is entry 108 in each GP_MAIN_GAME_*2D,
24/26 in GP_HANGAR_ARSENAL/GP_READY_ROOM. GP_TITLE is the ONLY archive whose
first ten ordinals are the identity, which is the sole reason 207 of the
corpus's 226 build citations are safe. Second foot-gun: `--all` swaps the
predicate and renumbers 18 archives, so `--build N` and `--build N --all` are
not the same object.
The instrument failed its control first. A version using parse_build as the
predicate reported GP_TITLE as 16 builds, ordinal == entry throughout -- it
would have certified the exact bug it was built to find. The shipped version
uses the same predicates screen_builds() uses and reproduces `screen list` on
GP_TITLE exactly.
Audited all 226 citations. One real defect: a five-row table in
ui-keyframe-time-unit.md headed "declared element (build 11)" spans builds 10
and 11 -- palogo_sqex is in 10. All five placements re-verified and correct, so
the linear-ramp measurement is untouched; only the label was wrong. Fixed with a
per-row bundle column. GP_DIALOG --build 0 and GP_DEBRIEFING_PILOTLOG --build 10
re-run and reproduce.
Refutation attempted: sylpheed-port's corrected mid-ramp test rests on
ptlogo_all_eff holding a=127 from t=112 to t=246. Their quote is exact and it is
a plateau. The refutation fails; their correction stands.
METHOD already carried the rule I broke, and ui-splash-addressing already said
the splashes need --all. The failure was not missing knowledge -- it was
addressing a bundle by index without grepping for the index first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Marks the two void splash rows in the capture-comparison data file, withdraws the
three claims in HANDOFF, and corrects the METHOD entry -- whose 'a gradient across
buckets is not a mechanism' near-miss was itself resolved by a counter-example
taken with the wrong index.
General form recorded: an index that silently means something else produces
well-formed output for the wrong object, and this project has now been bitten
twice from opposite directions with 'everything still validates' both times.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port recomputed the publisher splash's widest keyframe-free gap as 190 units
against my 8 and said one reading must be wrong. Mine was, and the library was
never wrong -- only my invocation.
From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest
gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both
match the port exactly.
The cause is that screen render --build N takes a BUILD ORDINAL. screen list says
[10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not
screen builds at all, so my --build 10/11 rendered the LOADING screens. This is
the foot-gun HANDOFF already documents, which the port caught months ago in the
mirror direction.
Three retractions:
1. 'Width does not predict quality' -- withdrawn. It rested entirely on the
splashes being width 8 while winning 75x. They are the widest of the five, so
width and mid-ramp are perfectly confounded across every screen either of us
has measured and the width hypothesis is NOT refuted.
2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never
near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket,
the worst at 45.1 %.
3. The splash rows of settle-vs-rest-against-captures -- void. They scored
loading-screen renders against splash captures. I discarded them for a railed
gamma fit; the real reason is that they were the wrong screens, and the railing
was that mismatch surfacing where my instrument could report it.
Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which
iterate pak entries directly and never touch the ordinal path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The under-10-units filter was documented and reasonable and wrong both ways: it
admitted the 10-19 bucket, the worst at 45.1 % mid-ramp, and excluded the two
splashes at width 8, the strongest evidence for the proposal it was serving. One
--settle invocation per screen would have shown this in seconds.
Plus the near-miss: the bucket gradient made 'narrow window means bad settle
pose' look obvious, and it is refuted by two screens inside the excluded band
that win by 75x and 33x. A gradient across buckets is not a mechanism.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port found ptmsg, the main menu's footer, at alpha 127.5 at that screen's
settle instant. Verified: build 5's window is [44,56] = 12 units and
screen render --settle already prints 'narrow -- this bundle may never settle'.
Disc-wide, elements caught mid-ramp at their screen's settle instant: 25.5 %
overall, 40.9 % on windows under 10 units, 45.1 % on 10-19, falling to 11.7 % and
15.0 % on wide ones.
The obvious reading of that table -- narrow window means the settle pose is bad --
is REFUTED by the screens that motivated the proposal, and I nearly published it.
The two splashes have an 8-unit window, narrower than the main menu's 12, and the
settle pose beats rest() there by 75x and 33x. Width does not predict quality.
The predictor is the port's own statement: the settle pose wins decisively where
rest() lands on a transient's peak, and loses slightly where rest() is already
sound and an element arrives after the window closes.
And my own rest_vs_settle filter was wrong in both directions: dropping bundles
under 10 units admitted the 10-19 bucket, the worst at 45.1 %, and excluded both
splashes at width 8 -- the strongest evidence FOR the proposal. A threshold taken
from a documented rule of thumb and applied without checking which screens it
admitted and which it threw away.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The entry said a candidate-vs-incumbent comparison is the wrong shape of
experiment. Too strong. Two iterations later the same comparison adjudicated with
no new oracle, once a structural property was added that says which side is wrong
per disagreement -- does the chosen run contain the settle instant. Control 3072
of 3072; disagreements attributed 1036 of 1036.
Corrected rule: a bare comparison cannot adjudicate because a disagreement is
symmetric; it becomes decisive the moment a property breaks the symmetry per
case. Reach for an oracle when no such property exists, not as the first move.
With the tell that I had one available and did not look: I recorded the residual
as 'ambiguous by construction' and moved on TWICE without asking what would make
it un-ambiguous.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
rest_plateau() selects the LONGEST run of identical adjacent poses, which need
not be the run covering the screen's settle instant. rest_vs_settle left a 21.9 %
disagreement that I recorded as ambiguous by construction. It is not.
CONTROL exactly one plateau, covering the settle instant:
3 072 / 3 072 agree (100.0 %)
TEST more than one plateau, at least one covering:
1 622 elements, agree on 586 (36.1 %)
of the 1 036 disagreements, rest() landed on a run NOT covering the
settle instant: 1 036 -- all of them, no exceptions
Both poses are genuinely held in these cases -- they are plateau cases, not
transients -- so this is rest() returning a pose the screen has ALREADY LEFT by
the time it settles.
This corrects my own METHOD entry of two iterations ago, which said a candidate
cannot be adjudicated against the incumbent it replaces. Too strong. The bare
comparison cannot; the comparison plus a structural property that independently
says which side is wrong in each disagreement can. What I lacked was not an
oracle but a discriminator.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes the gap the port named: it ran my proposal against captures 3/3 in favour,
but tested ITS OWN settled pose rather than UiBuild::settle_time().
Geometry established first, because my first attempt got it wrong: a 1280x720
render meets a 1279x675 capture by CROP, not scale -- crop rows 0..675 gives RMSE
14.07 against 68.89 resized and 79.61 for the 45-row crop. The 45-row offset
holds for a full display frame; these captures are already the game surface.
Gamma fitted per pose so neither candidate can win on the fit:
title settle g=0.84 RMSE 8.17 15.28 % >8
title rest g=1.04 RMSE 20.92 70.84 % >8
The two splashes DO NOT ADJUDICATE and are not counted: their gamma fit rails at
the edge of the search range, still railing when widened to 0.30..3.00, so the
photometric model is wrong for them -- and with gamma railed their margins
collapse to 1.16x and 1.06x.
title adjudicates at an interior gamma and does so decisively, 4.6x on differing
area and 2.6x on RMSE. So the IMPLEMENTATION and not merely the direction is
supported.
Absolute agreement is poor -- the port's settled title row is 0.21 % where mine
is 15.28 % -- so the ordering is what this table carries, not the values. The
port's three-screen result remains the stronger evidence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Plus the two companions: any statistic keyed on where an element's visibility
ends is near information-free here (87.8 % end at a=0 from the screen's exit
ramp, which bit both agents within an hour), and the port's mirror -- my
threshold-free 'nothing is held on this path' criterion is correct on the
fallback path and fails outright on the plateau path, so a cleaner definition
that fails a control is worse than an ugly one that passes.
HANDOFF carries the proposal with its evidence, its failed control, and an
explicit refusal to change rest() in a crate the port pins on the strength of
something I cannot validate from my own side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The proposal: pose every element at the SCREEN's settle instant rather than
asking each element for its own resting pose. On the 2 249 fallback elements in
settling bundles the visible-pose rate falls 73.6 % -> 34.7 %.
But the control fails twice. Naive, over every plateau element: 46.6 %. That one
was misspecified and I caught it by asking what the number means physically --
rest() finds *a* held pose and many elements hold one during the build-in then
move on, so it answers a different question and disagreement proves nothing.
Restricted to elements HOLDING ACROSS the settle instant: 78.1 %, still not a
pass.
And the residual is ambiguous by construction: rest_plateau() picks one plateau,
so an element with two whose settle instant falls in the other will disagree --
and there pose_at(settle) is RIGHT. The control cannot separate 'the candidate is
wrong' from 'the incumbent is wrong'.
Recorded as the general point: comparing a candidate to the incumbent cannot
adjudicate when the incumbent is the thing under suspicion. It is the wrong shape
of experiment, not a tuning problem.
What does adjudicate is the oracle and it is the port's measurement, not mine --
publisher splash against a committed capture, settle-instant pose RMSE 2.17 /
0.01 % differing against --pose=rest 9.05 / 0.75 %. My numbers describe the
proposal's effect; they do not establish it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Applying the port's physical-story rule to my own number. '1 697 fallback fires
return a visible pose' was published as if it were a defect count; it is not, since
an element that genuinely ends visible should rest visible.
The first correction split the 1 697 by whether the element's LAST keyframe is
visible: 347 correct, 1 350 transient peaks. Plausible, arithmetic fine, and
WRONG -- 12 278 of 13 991 elements (87.8 %) end at alpha 0 because a screen's exit
ramp drives everything to zero, so the split carries almost no information. The
1 350 is not published.
What survives needs no such split: the fallback runs only when no two adjacent
poses are equal, i.e. only when no pose is held, so every pose it can return is
un-held by construction -- and 1 457 of the 2 305 times it returns the element's
MAXIMUM alpha, the brightest un-held pose.
I ran that control only because the port had just been bitten by the same exit
ramp, its census calling ptmsg -- the main menu's permanent footer -- 'a 2-unit
flash'. Without its message the 1 350 would have shipped.
METHOD gains the sharpened form: the physical-story test catches confident FALSE
claims, not just nulls. A wrong number usually still has a story, just an absurd
one. Plus the tell that its fix was right -- re-keyed on the screen's span, the
false positives fell out on their own, and a definition that stops needing
hand-maintained exceptions is usually the correct one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
From the port, and a better generalisation than mine. I had been filing my
failures under 'an external quantity caught it', which prescribes finding an
anchor; anchors are not always available. The port's title_jp error had none --
every control passed because the metric was fine and the error was which frame it
scored. What caught it was asking why rest produced that light, which exposed a
4-unit sparkle whose rest.t is its own peak.
So: state what the number means physically and see whether the story survives
contact with the data. A wrong frame yields a number with no physical story
behind it, which is detectable from the inside. It subsumes the null-as-result
cases too.
And a control does not test this: a control proves the INSTRUMENT and says
nothing about the SAMPLE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port listed palogo_gamearts_eff and palogo_seta_eff among GP_TITLE's four
visible dwell-fallback fires; this census listed only palogo_sqex_eff and
palogo_anima_eff. Checked, and the census is right: gamearts_eff and seta_eff
hold a=255 at identical x, y and scale from t=15 to t=30, which is a plateau at
pair index 1, so rest_plateau() handles them and t=15 is the CORRECT answer. They
are not fallback cases.
The distinction is not cosmetic -- a plateau is a pose the element genuinely
holds, and only the dwell fallback is the unsound path.
But the refutation makes the port's underlying point STRONGER. Its rest pose for
those two really is the flash's peak, reached by the SOUND path. So 'a rest
render is not a frame to score against a capture' does not follow from the
fallback being unsound: a plateau can itself be the held peak of a transient. The
rule covers both paths, and the fallback census understates the exposure rather
than bounding it.
Also records the port's oracle number for the rule -- publisher splash against
the committed capture, timeline RMSE 2.17 / 0.01 % differing against --pose=rest
9.05 / 0.75 %, 75x the differing area.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
ui-resting-pose.md built its dwell-fallback section on GP_TITLE build 7's
ptlogo_eff3.t32, listing keyframes [46, 61, 103, -] -- the STALE PARSER's output.
Corrected they are [0, 46, 61, 103], the longest gap moves from 61->103 to 0->46,
and BOTH ends of the new longest gap are a=0. The element no longer selects a
visible pose under either indexing, and build 7 renders byte-identical under the
corrected and legacy readings (0 px differ). MISSION lists this element as the one
case a Japanese capture was needed to discriminate; it is not.
But losing an example is not closing a question, so: disc-wide census. The
fallback fires on 2 305 of 13 991 elements and returns a VISIBLE pose in 1 697 of
them -- 74 %.
GP_TITLE is 5 fires, 4 visible, and all four are on the SPLASH screens:
palogo_sqex_eff and palogo_anima_eff, each [0:a0 15:a255 30:a212 45:a0], a flash
peaking at 15 and dead by 45 where the fallback returns t=30 a=212.
Independently converged on from the other side: the port, working from the JP
capture and knowing nothing of this census, found ptlogo_back2eff1's rest.t at the
peak of its own 4-unit sparkle with six staggered across the logo, so --pose=rest
fires every sparkle at once -- a frame the game never shows.
Consequence recorded as a rule: a render posed at rest is a legitimate common
reference for comparing two DECODERS and is not a frame to score against a
capture of the game.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Asked for by the port: its title_jp row drifted, localized to a 350x396 block at
(405,74) -- the logo stack -- and with no JP capture in the corpus it could say
the renderers moved apart but not which one moved.
Three earlier attempts failed to reach the interactive title in either locale.
The reason is now known and was never the locale: A at the title needs a
signed-in profile, and no run had one.
Locale set through canary's own persisted XConfig and restored afterwards,
verified back at language=1. INDEPENDENT confirmation it took: the XMA probe
logged a different voice-context set from every English run (ja 1112064 /
1150976 / 1177600 against en 1294336 / 1118208 / 1171456), so the switch reached
the guest rather than being a menu-language cosmetic.
'At rest' is demonstrated rather than assumed. Five frames ~1.5 s apart after the
plate pulse says the screen has settled: the port's ROI is byte-identical across
all of them, max |delta| 0 over 138 600 px, while the WHOLE FRAME moves 39 584 to
71 927 px -- the plate pulse and sweeps. That contrast is the control: the
instrument can see motion and the ROI still shows none.
The capture shows what the English title does not -- the katakana subtitle, and a
crystalline burst behind the wordmark, the ptlogo3a/b/c + ptlogo_back2eff* stack
that this corpus records as transparent at rest in English. Exactly the region
the port's drift is localized to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the
keyframe-record-layout fix. The old parser shifted every time by one slot and
could not time a group's final pose, printing a trailing '-':
stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0]
fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0]
Both outputs are well-formed and neither announces its age.
That refutes the premise of screen-transitions.md's 2026-08-29 section, which
argued from 'there is exactly one untimed keyframe, and every element has it'.
There is no untimed keyframe, so the question it answered -- is 0.4 s the missing
duration of that keyframe -- has lost its subject. The ratio test in the same
section is untouched.
And it decodes the number the port asked about: pteff00.prm's final ramp is
70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to
refute the port's 10 against the bytes and could not.
So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10
decoded. That the remaining ~14 units are exactly the black hold is arithmetic
that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a
measurement; the decomposition stays open.
CONTAINER-NOTES gains the trap. Renders are byte-identical across the two
binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element
identity, pivots, keyframe counts and screen render output are unaffected -- it
is the times that move.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
1. NO AUTO-REPEAT. A 2.0 s held DOWN moves the cursor exactly once. The counter
passes its control first: a single 0.12 s tap gives exactly 1 spike and the
hold gives 1, with the move spike at 0.0202-0.0220 against a 0.0003-0.0038
noise floor. The port had flagged that the hedge 'at the durations tried' was
carrying the claim, and it was -- nothing recorded a HELD direction.
2. B ON THE SETTLED TITLE DOES NOTHING. Twenty seconds after a
delivery-confirmed B the screen is still the title with PRESS (A) BUTTON up,
read off a capture that names itself. This is the run the previous attempt
could not be: it waited for the plate pulse, the title's own settled
signature, instead of pressing during the build-in.
3. THE PLATE IS RE-DRAWN after B from the menu -- pressed at 351.2 s, pulse
detected at 358.5 s. That was the other unevidenced half of the B-on-menu row.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
