Ring at 347.5 on entry, 427.5 after one confirmed DOWN, 347.5 on re-entry with the
frame 0.0 % different from the first entry. sylpheed-port asserted non-persistence
when nothing had measured it; the assertion was right and is now measured.
MISSION SELECT is therefore a genuine initial focus, because this screen resets --
unlike the main menu, where a single-entry reading measures history.
Every control here exists because run 1 failed without it: absolute row checks
after every navigation press (a constant offset passes a differential control),
screen identity against an in-run reference frame (main menu 327, EXTRAS 324 and
OPTIONS 317 all sit in the same glyph window), and raw ring rows inside the
submenu so no three-item geometry is assumed. The screen was also confirmed by eye.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port caught that a reader counting the Q2 row gets twelve entries with no
slot for the boot splashes -- in a row already corrected once for an
ordinal-versus-entry error.
Verified off the disc: the splashes are 10/13 (palogo_sqex, publisher) and 11/14
(palogo_gamearts/seta/anima, developer). The row said 'in entry space 10/11 are
the publisher and developer splashes', which names one half of each of two
different pairs rather than a pair. All eight screens now enumerated, with the
per-entry names committed as reference data.
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
Coherence on BGM_103, the menu's bank, with controls run first: a real linear
filter of wave 0 reads 0.93-0.94 in every band, a different bank reads 0.001, and
wave 0 misaligned by 1 s reads 0.004-0.057. The measurement reads 0.027 at 1-4 kHz,
so the 'wave 1 is wave 0 filtered' model is refuted.
The frequency structure is inverted relative to any mic-pair or reverb model:
coherence rises with frequency (0.169 -> 0.827) while energy falls (71 % -> 0.2 %),
and a rear pair decorrelates fastest at HF. In the midrange the two waves are 13x
further apart than the two channels of one wave.
But the L-R control is what limits the tool and it is recorded as such: within one
wave, genuinely one performance in two channels, coherence is only 0.221-0.497. So
'same performance' does not imply high coherence here, my positive control was the
wrong model of the rear-pair reading, and the 🟡 is NOT settled. The tool tests for
linear filtering and neither surviving reading requires it.
Also corrects MISSION's Q10 row, which still carried the refuted three-sub-wave
premise and had directed work at a dead question for days. Its gate is in fact met.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The occlusion hypothesis is refuted: build 7 draws the same three ROT strips at
higher alpha than English, so there was never an absence to explain.
The 0.32-vs-11.9 tension that motivated it was an artefact of my own instrument.
Both JP captures were shuttered on the plate pulse, and the plate's pulse is part
of the animation -- so the gate synchronises the shutter to the animation's phase.
Measured at the shutter instant, the sweep sits 25-26 px apart across two runs in
different locales and different sessions: 1.6 % of a ~1600 px traverse.
So the 0.32 I recorded as between-session capture noise measures my trigger's
repeatability, and I read it as evidence the title is still when it is evidence
the gate works. The era adjudication is unaffected -- margin 16.72 clears even the
un-locked 11.9 -- and unaffected for the reason that file already gave: correlated
noise cancels in a margin.
Refutation attempt on sylpheed-port's positional-mechanism rejection: FAILED, the
claim stands. Its residual sits inside lit logos, and the logo ROI is
byte-identical across five differently-phased frames in two sessions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two iterations ago I corrected MISSION.md's stale "🔴 Emulator-side questions are
blocked" banner and wrote, in its place, that the two items it named were
"unblocked, not answered ... both need a running menu, both now have one, and
neither has been attempted". I wrote that without reading either page.
Reading them:
8AX vs ptbase was RESOLVED on 2026-08-29. Its status line says so -- both its
questions closed, page kept for the evidence.
The gamma control was attempted and half-answered, and its page records that
the run "needed the emulator only to BOOT, not to reach a menu ... parked behind
the title-screen blocker for no reason".
So neither item ever needed a running menu, and the section's premise was wrong
independently of whether the menu was reachable.
All three clauses false. The failure is specific and worth naming precisely:
replacing a stale status with an UNCHECKED one, in the same edit that criticised
the document for carrying unchecked status. sylpheed-port wrote a dead instruction
inside the commit fixing dead instructions; this is that shape, one document over.
METHOD: a correction is a new claim and needs the same check as the claim it
replaces. The urge to correct supplies confidence the correction has not earned --
check a replacement as hard as the thing it replaces, and hardest when the edit is
about checking.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
I have been reading MISSION.md every iteration as instructed and never once
audited it, while auditing headings, instructions, env vars and fallbacks
everywhere else. It carried three false section headings, each superseded in
HANDOFF.md and nowhere else:
"🔴 Emulator-side questions are blocked -- the title is not reachable here"
False. Twelve emulator runs on 2026-08-30 reached the settled title, gated
on the plate pulse, and drove it into the menu, EXTRAS and out of the
archive. The two items the section named -- the gamma control and
separating 8AX from ptbase -- are UNBLOCKED, not answered, and neither has
been attempted. That distinction is kept.
"🟡 Needs one more run -- a Japanese-locale capture", describing "one capture we
cannot take". Taken twice, both committed, via jp_title_session.sh. And both
questions it blocked are closed, one of them confirmed against that very
capture. ⚠️ I noticed this section was stale several iterations ago, said so
in a message, and did not fix it.
"🔵 Needs a human decision -- rotation". Decided and implemented the day it was
raised: HANDOFF records "OPTION A IS DONE. The reference renderer rotates",
and ui_layout.rs carries the rotated blit with a control test pinning 0° and
360° byte-identical to the unrotated path. The field is now confirmed from
the ORACLE too -- +30/-45 predicting AABB heights of 1135.3 and 1301.1
against 1134 and 1303 measured, both under 0.2 %.
All three corrected leading with the correction, originals quoted and demoted
beneath. Only FACTS were changed; the questions and their gates are untouched,
since keeping the document true is maintenance and changing what it asks would be
overstepping.
METHOD: audit the document that defines the objective, because it is the one
nobody audits. A document read only for instructions is never read for review, and
the more central it is the more often it is consulted and the less often checked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two things in one run, on the screen that motivated both.
First, the effective-config guard I had flagged as "not yet verified" -- leaving a
doubt in my own file, which is the shape sylpheed-port had just caught themselves
in. Verified now:
arming on = menu [screen_id: cannot separate menu/EXTRAS]
discriminator = extras rmse=18.94 (other main_menu 30.09, margin 11.15)
Before the fix this run would have announced "arming on = menu" while armed on
EXTRAS. The ambiguity is visible instead of hidden.
Second, a replicate of the table's weakest cell. Second EXTRAS -> menu: outgoing
quad 229, 255, 255 across frames 29-31, then TWO empty frames at 32 and 33. Gap =
2, identical to the first.
Eight transitions now say something sharper than the outgoing-screen story, which
is superseded a second time:
title -> menu 3, 3, 3 n=3 repeats agree
EXTRAS -> menu 2, 2 n=2 repeats agree
menu -> title 0 n=1
menu -> EXTRAS 1 n=1
menu -> other 1 n=1
EXTRAS -> other 3 n=1
Every repeated pair is identical -- five replicates, no variation -- and every
differing value comes from a different pair. The same origin gives different
values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3). So the origin
CONSTRAINS the gap and the ORDERED PAIR determines it, reproducibly.
For the port: a constant black_hold_units is excluded and keying on the outgoing
screen is excluded too. Any keyed version must be keyed on the ordered pair, with
a measured value per pair -- six known, two replicated, none predicted by anything
declared.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
I recorded EXTRAS as able to supply only one gap measurement because "its sole
exit is (B) to the menu", and called that n=1 STRUCTURAL -- a word that retires a
question. The disc refutes it in one command: build 6 declares three buttons,
ptbtn11/ptbtn12/ptbtn13, all kind 0x3002. The cap was an unverified assertion I
had already written into HANDOFF twice.
Measured EXTRAS -> a screen outside GP_TITLE via (A): outgoing quad rises across
frames 36-40 (4-5 frames, matching build 6's declared 10-unit close), then THREE
empty frames at 42, 43, 44, then a different archive builds (23-28 draws/frame
against GP_TITLE's 11-14). Gap = 3.
So EXTRAS as outgoing gives {2, 3}, and seven transitions now group as:
menu {0,1,1} n=3, EXTRAS {2,3} n=2, title {3,3,3} n=3.
A pairwise control that holds the destination class constant: menu -> another
archive gives 1, EXTRAS -> another archive gives 3. Same kind of destination, gap
differs by outgoing screen. That is the strongest support yet for the
outgoing-screen dependence because it removes the destination as the variable.
But the clean ordering is GONE: EXTRAS {2,3} and title {3,3,3} overlap at 3, so
"menu < EXTRAS < title" no longer separates them. What survives is weaker -- the
outgoing screen constrains the gap to a ~2-wide band and the bands are not
disjoint.
METHOD: a structural limit is a claim and needs checking like any other.
"Structural" and "impossible" are the two words most worth distrusting in your own
notes, because they retire a question rather than answering it and nothing later
re-opens them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's BLOCKED row asks for a second value on one outgoing screen --
what would make "the gap tracks the outgoing screen" predictive rather than a
restatement of the data.
First, a correction their ask surfaced without needing a run: THE MENU ALREADY
HAD TWO VALUES AND THEY DIFFER -- 0 leaving for the title, 1 leaving for EXTRAS.
So "the outgoing screen determines the gap" was too strong and is withdrawn; what
holds is an ordering, not a determination. Also recorded: their ask is answerable
only from the menu, since the title's sole exit is (A) to the menu and EXTRAS's
sole exit is (B) to the menu.
Then took a third menu-outgoing measurement, to a screen outside GP_TITLE.
Confound named in advance rather than after: that transition leaves the ARCHIVE,
so a pak load could inflate the gap for reasons unrelated to the outgoing screen.
Result: outgoing quad rises across frames 24-28 (4-5 frames, matching build 5's
declared 10-unit close), then ONE empty frame at 30. Gap = 1, identical to
menu -> EXTRAS. So the confound is measured ABSENT -- leaving the archive costs no
extra black, which is worth having on its own.
Six transitions now group as: menu {0, 1, 1} over three different destinations
including another pak, EXTRAS {2}, title {3, 3, 3}. The ordering rests on 3+1+3
measurements and the menu's three agree to within one frame.
Still not predictive: outgoing closes are 5, 5, 4 frames against gaps {0,1}, {2},
{3}, and EXTRAS has n=1 with no way to obtain a second value.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Applied my own log-line rule to my own instrument first, which is the "rule
written down is not a rule applied" failure I have on record three times. Every
branch of fade_decompose.sh now announces its EFFECTIVE configuration -- derived
from the variables in force, not from $WHERE, per sylpheed-port's sharpening --
and the run REFUSES if no branch announced itself. That is the guard that would
have caught last iteration's silent fall-through at a glance.
With it in place, took the measurement that failed last time: menu -> EXTRAS, the
reverse of the pair measured at a 2-frame gap. Navigation verified both ways
(extras margin 11.23, back on menu 11.60) and the config block confirmed the right
branch.
Result: outgoing quad rises across 5 frames matching build 5's declared 10-unit
close, then ONE logged empty frame. Quoted as 1 with an upward uncertainty, since
its two neighbours carry no frame header at all.
Five transitions now order by the screen being LEFT:
menu -> title (B) 0 outgoing menu
menu -> EXTRAS (A) 1 outgoing menu
EXTRAS -> menu (B) 2 outgoing EXTRAS
title -> menu (A) x3 3,3,3 outgoing title
Direction is ruled out: EXTRAS->menu (2) and menu->EXTRAS (1) are the same pair
both ways and differ. Button is ruled out: (B) gives 0 and 2, (A) gives 1 and 3.
Incoming screen is ruled out: an incoming menu takes 3 from the title and 2 from
EXTRAS.
NOT a rule, and recorded as such. Three outgoing screens with one value each means
"each outgoing screen has its own gap" restates the data rather than predicting,
and nothing declared predicts it -- outgoing closes are 5,5,5,4 frames against
gaps 0/1,2,3, inverted if anything, on three points.
What it changes for the port: a UNIFORM black_hold_units is now positively
excluded rather than merely unsupported.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port refined my ranking: rank silent instructions above loud ones. All
of theirs were loud -- wrong paths that error out and announce themselves --
while mine was silent: an inert env var returning a clean, wrong result. Only the
silent kind manufactures evidence.
The silent surface is enumerable, so this is a sweep rather than a sample: every
environment variable the docs name, checked against the code.
SYLPHEED_KF_TIME_SHIFT was still live in FIVE doc files after I fixed one last
iteration. Two of the five were genuine hits rather than historical quotes:
ui-resting-pose.md -- a RESULTS TABLE ROW labelled "with
SYLPHEED_KF_TIME_SHIFT=1". Re-running it sets an inert variable, produces the
DEFAULT row, and lets a reader conclude the two readings agree. A stale
instruction inside a results table is the purest form of the evidence-
manufacturing class.
HANDOFF.md -- "experiment reachable via SYLPHEED_KF_TIME_SHIFT=1", a live
instruction in the delivery contract.
And a live gate exists under a DIFFERENT NAME that the docs never pointed at:
SYLPHEED_KF_TIME_LEGACY, verified read at ui_layout.rs:595 -- the parser itself,
not only the tests, so it does reach screen info and screen render. Both hits now
redirect there.
Beware the proxy, which is the trap the port named about their own "parsed"
check: absent-from-code also flags SYLPHEED_DISC, XENIA_SRC and SYLPH_ISO, which
are container paths the brief sets and no code reads. Absent-from-code is
necessary, not sufficient, and I checked each rather than reporting the seven raw
hits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
check counted more than the others
An answer not reachable from HANDOFF is not delivered, and this thread lived in
messages and docs/re/. Delivering it: the leaves ARE drawn and free-run on a
settled title, so a settled screen is not a static screen; the leaves are
identical on entries 4, 5 and 7; how the game advances them is undecodable with
reach, four models each refuted by a measurement; and keyframe_units_per_second
should stay put because the port's 1.87x table has an input now known to be wrong
rather than merely unpinned.
METHOD gains the lesson sylpheed-port named, which outlives the thread. Almost
every cross-check here runs disc -> exporter -> export against disc -> our reader:
two paths that agree because they read the same bytes with the same
understanding, and that agree anyway when the understanding is wrong. That is how
this corpus produced a build-ordinal error where everything still validated, a
two-era comparison with the same binary on both sides, and a rate confirmation
that was a prediction 20 % low meeting a measurement 50 % high. The chain that
counts ends at the ORACLE, and the single instance this week was the leaves'
rotation: +30 / -45 from the file predicting AABB heights of 1135.3 and 1301.1
against 1134 and 1303 in the draw stream. Before quoting an agreement, ask where
the two paths diverge -- if it is after the fact in question they are one witness
wearing two coats.
Also records that a refuted model is a result: four refutations, each with the
measurement that closed it, is firmer than any one of them fitting would have
been, because the failure this corpus keeps hitting is a model that fits for the
wrong reason and nobody checks.
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
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
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 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 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
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
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's authored/flow.json stamped title/on_cancel_why = 'MEASURED, HANDOFF
Q5' for a clause whose evidence cell in the source table reads 'none'. It did not
invent that: HANDOFF's Q5 row opened with one **measured** covering six clauses of
different strength, and HANDOFF is the document it authors against.
Split per clause. Measured: initial focus varies; up/down move one item per press
and wrap both ends; left/right do nothing; B on a submenu restores focus 4/4; B on
the main menu goes to the title in <= 0.4 s with no loading screen. NOT measured,
evidence cell empty: 'no auto-repeat at the durations tried', and 'B on the title
-> nothing'. Both marked do-not-stamp.
Also splits the source table's own up/down row, which bundled 'one item per press'
(indirectly but soundly evidenced by the 4-press wrap count) with 'no auto-repeat'
(nothing behind it, and the hedge was carrying the claim).
METHOD entry: the failure is in summarising, not at either endpoint. The source
table was honest and the consumer cited its source; flattening six claims into one
adjective created a provenance nothing supports. A strength label is not
distributive.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Applying my own METHOD entry one iteration after writing it found four refuted
statements still asserted unmarked where a reader lands:
* envelope correlation 'has no resolving power' -- in three places including
HANDOFF. The port controlled the same estimator on a single track and got
r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing
timing. I agreed to this in a message and never landed it.
* '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different
section from its own correction.
* 'r9 is a wild pointer, never a guest address' -- still asserted inside the
kept-for-the-record section.
* the ALSA channel permutation, stated without scope, when a later capture
measured the identity and labelling from it put the silent channel on the
wrong name.
All four marked in place, striking the sentence and pointing forward.
Two lessons added: a 'kept for the record' section still asserts, so labelling
the heading is not enough; and naming a refuted claim keeps it greppable, so the
audit returns its own corrections as hits and every hit needs reading.
The first item is the one worth admitting: I acknowledged that correction in a
message, wrote the entry about corrections that never land, and then did not land
my own for a full iteration.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
An A press produced no screen change; the obvious reading was that the button did
nothing. The log said the press was never delivered -- two file-pad vk=5800 lines
across the whole run is ONE press -- because it was issued 0.8 s after a screen
appeared, while the guest was loading and not polling.
The pad driver reports what it emitted, so a script checking its own output sees
success either way. Confirm the receiving side.
Generalised: when an action produces no observable effect, the first hypothesis
is that the action did not occur, not that it had no effect. The corpus has paid
for this twice -- here, and in the sign-in swallow where thousands of delivered
keystrokes were discarded inside the emulator and looked exactly like a dead pad.
Companion to the control entries: a control proves the instrument reads
correctly; a delivery check proves the experiment happened at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port found its exporter still shipping 'no loop-point field has been
identified anywhere' in the field manifest.json concatenates, days after the
correction existed in other fields. Auditing this corpus the same way found the
same failure here: the refuted sentence was still standing untouched in
bgm-two-stems.md -- where anyone looking up BGM behaviour arrives -- and in
HANDOFF.md, the one page the port is told to read. My correction had gone into a
NEW page only.
Both fixed in place, each naming the refutation rather than quietly deleting the
old claim, and each carrying the measured window [9.44, 71.31] s at 61.87 s.
METHOD entry: writing a correction down is not landing it. Grep the corpus for
the CLAIM, not for the file you were working in. Plus the port's trap in doing
that audit -- a replacement that quotes the refuted sentence in order to name it
will match a substring search from inside the paragraph saying it is false.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Tailing the log from BEFORE the music starts cut the unsampled backlog from 616
samples spanning offsets 32..2,559,033 to 125 spanning 32..515,239, so the first
pass is sampled like any later cycle. Offsets below loop_start play exactly once,
which is why the previous run could not measure them.
Wraps at 96.46 / 158.33 / 220.21 s, gaps 61.87 / 61.87, both contexts together.
Two derivations, neither converting bits to seconds:
(a) time to read_offset crossing loop_start, plus a 1.33 s head correction at a
rate measured on 748 timestamped samples of that same stretch
(b) first pass (offset 32 -> loop_end) minus the cycle
Both give 9.44 s on both contexts -- four numbers, one value.
So the loop region is [9.44, 71.31] s of an 87.744 s wave, cycling every 61.87 s.
The first 9.44 s is an intro played once; the last 16.4 s, the fade-out
bgm-two-stems.md documents, is never played at all.
The decoder reads ahead of playback, but both endpoints are read_offset events so
the lead cancels in the difference. One boot, one bank.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
My locator validated on slices cut from the wave itself -- found exactly, control
passed perfectly -- and the measurement was still ten seconds wrong, because
matching an exact copy is a different problem from matching a real capture and
music with repeated sections is where a locator aliases. Its clean +5.00 s
stepping showed self-consistency, which is also what an aliased lock looks like.
Paired with the port's mirror image the same day: an awk that read 0 for every
span produced a perfectly structured result agreeing with the hypothesis under
test, and its tell was that the CONFIRMING rows were impossible too.
Both point the same way: the tell is in the rows that agree with you. Checking
the disconfirming half harder is the intuitive discipline and it is the wrong
half.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
No Canary patch was needed: UpdateLoopStatus already logs loop_start/loop_end,
they just need the Apu category (--log_mask=13 --log_level=3).
Decoded, from the menu, 8734 records all after BGM_103's contexts appear:
ctx0 (wave 3876864) loop_start 3605682 loop_end 25640423 loop_count 255
ctx1 (wave 3930112) loop_start 3539158 loop_end 26216351 loop_count 255
The movie's three ADV streams log NO loop records -- they do not loop.
Semantics visible in the trajectory: read_offset runs from 32 upward and 20 % of
samples sit below loop_start, so the stream plays from the beginning and
loop_start is where it returns AFTER loop_end. No wrap was observed -- the 45 s
hold ended with read_offset at 17 M against a loop_end of 25.6 M.
Two registered predictions REFUTED. loop_start is not ~0 but 11.6 % in. And a
linear bits-to-seconds conversion is invalid: it gives 62.34 s and 63.29 s for
two stems that must play sample-synchronously, which is impossible, so the data
refutes the assumption on its own.
That leaves a conflict I am not resolving: the field implies a cycle of roughly
[10 s, 72 s]; my audio tracking reported offsets 0.25..57.18 s. Recorded as
contested, with the likely weak link named as mine -- that locator's control used
slices cut from the wave itself, exact copies, which is an easier problem than
matching a real capture, and a control easier than the measurement does not bound
its error.
The port is told to change nothing: its trimmed 61.93 s loop is verified in its
own output, and the length survives better than the placement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Pays the debt from the truncated audit. The census prints population, coverage
and skips in the same output, and ends with an explicit END line, so a cut-short
run cannot be read as a complete one.
POPULATION 104 movies; COVERAGE 95 resolved, 9 unresolved, 0 unreadable
70 one-chunk regions, 25 three-chunk regions
The port's 25 was right; my '8 of 10' was not a count.
Cross-referenced against the fix's own sweep, which also ran to completion
(78 + 17 + 9 = 104): all 17 changed regions are three-chunk, none is one-chunk,
and 8 three-chunk regions were never affected -- which the 1.5 MB cap predicts,
since a region only trips the filter if its span exceeds it.
So 'the defect is specific to the multichannel regions' survives with complete
populations on both sides, while 'all three-chunk regions were broken' does not.
The original 8-of-10 was wrong in its denominator and coincidentally shares a
digit with the 8 that are unaffected, which is the kind of resemblance that
carries a dead number into a later document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
240 s parked on the main menu, reached by using the XMA probe log as the screen
oracle instead of video -- the route the previous iteration wrote down. Menu in
26.8 s against never-in-378 s for the video rig, guest at 0.92x, capture at
0.08 % silence against the recipe page's own best of 0.31 %. BGM_103's contexts
verify the screen and no ADV context appears afterwards, so the attract loop
never took over.
Three results, two instruments.
NO SEAM: zero runs >= 0.3 s below median-18 dB in 232 s. The port's 3.4 s
near-silence is a property of its authored loop, not of the game.
NOT THE WAVE LENGTH: autocorrelation r at 87.750 s is -0.009 on four independent
windows; the top lag is 61.909 s with a 2x harmonic. Estimator controls recover
87.750 and 60.000 exactly.
61.93 s, INDEPENDENTLY: locating 30 s slices of the capture inside the decoded
summed waves shows playback advancing exactly +5.00 s per 5 s and wrapping at
61.93, from three wraps. Control: slices cut from the wave itself at 10/45/70 s
are found at 10.00/45.00/70.00. Two points mis-lock where the slice straddles a
wrap and they carry the two lowest scores in the table.
Offsets span 0.25..57.18 s of an 87.744 s wave, so the loop is [~0, 61.93) and
the final ~25.8 s is never played -- exactly where bgm-two-stems.md found the
fade-out and trailing silence. The game loops before the fade, which is why
there is no seam.
Also corrects my own '8 of 10 three-chunk regions start mid-stream'. The port
counts 25 three-chunk regions; it is right that both numbers cannot describe the
same set. My audit run was CUT SHORT -- the committed file ends mid-list with no
summary line -- so that was a ratio over an unknown fraction of the population,
and the claim that the defect is specific to multichannel regions is now
unsupported. The ADV verification and the fix's own sweep are unaffected; that
sweep ran to completion and printed its totals.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The voice-region truncation survived every test because there was nothing to
catch: the region parsed, the chunks decoded, the durations were self-consistent.
A missing third of a stream is smaller VALID output, and no check written against
our own output distinguishes that from correct output. What caught it was a
number from outside -- the running decoder's byte_sizes not fitting the region.
So: prefer at least one test per decoder pinned to something we did not produce,
and say so in the test, because the obvious maintenance of such a test is to
re-baseline it against current output, which deletes the only thing it was for.
Plus the port's corollary: it was checkable only because the identifier happened
to be a byte count. Index a handed-over result by a quantity the recipient can
test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
