I called their video timing the skippable kind. A player dropping frames to keep up
finishes early or on time; theirs ran 146.6 s for 137.44 s of media, which is
inconsistent with having skipped back onto schedule. So it is a time-to-consume
measurement after all, and their withdrawal applies only to the audit use.
Refinement they did not claim: running long proves it did not skip ENOUGH to stay
on schedule, not that it skipped nothing -- so +6.7 % is a lower bound on the
deficit, which favours their conclusion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
A real revival planted inside a paragraph that merely discussed corrections was
missed: the words 'refuted' and 'withdrawn' in the surrounding prose vouched for it.
Measured reach: 100 % of registered-claim mentions in the corpus are suppressed by
marker language, so the reported 0 was 0 regardless of whether any was live, and I
had been reading it as a pass.
sylpheed-port's token-based hook has the opposite bias -- it over-reports on
well-written corrections, which is the safe direction. Under-reporting is disguised
as success.
Fixed by making the suppression visible rather than removing it: suppressed mentions
are counted and listed with --show-marked as not verified, only vouched for.
Controlled -- the planted revival moves the suppressed count 8 -> 9 and appears in
the listing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Three refutations written as prose under ### headings never entered the register:
check_refuted.py parses * "claim" lines, so the count stayed at 188. Registered
them properly (188 -> 192). A register that parses one syntax silently ignores
every other, and it is invisible from the author's side -- ask the register what it
holds, do not re-read what you wrote.
Both standing false positives were bullets under a header that retracts the whole
list, with no marker in the +-4-line window: scope marks them, not proximity. The
scan now includes the nearest preceding header and matches markers
case-insensitively ('An earlier version' was missed by the marker 'an earlier
version'). Controlled by planting a real revival and confirming it is still caught;
register now runs clean at 0.
Also records sylpheed-port's diagnosis of the phase-lock fallout: a number can be
inapplicable rather than wrong, and a tension built on one is manufactured. Plus
their point that some claims are not registrable in a substring register at all.
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
sylpheed-port ran my two-half decomposition on their side and found the thing that
passes every check by being absent -- an authored value with no `why` at all.
Their first pass flagged 35 of 131; ancestor-aware, the real number was 0. The
analogue here is a page citing NO reference data, which my previous gate audit
would score "0 missing" and pass.
42 pages carry a measured/decoded/CONFIRMED status; 3 cite no data/ or captures/
path. INSPECTED BEFORE PUBLISHING, per their rule, and all three are false
positives, each verified rather than waved through:
slb-bank-header-not-a-wave.md cites tests/slb_leading_segment_disc.rs, and that
file exists in crates/sylpheed-formats/tests/ -- its evidence is a disc-wide
check over 9 519 sound.pak entries plus regression tests.
ui-screen-runtime.md carries 26 rows of inline evidence, live guest-memory reads
matched field by field against the file.
five-screens-acceptance.md is a consolidation page; its evidence is the six
pages it links and the numbers it tabulates.
3 -> 0.
The real finding is about the EARLIER audit. This corpus carries evidence in at
least three forms -- committed data files, inline tables, committed disc tests --
and both checks look for exactly one. "48 citations, 0 missing" is a statement
about the data-file form, not about whether the gates are evidenced. The gates are
evidenced; the audit was narrower than its wording suggested.
METHOD gains their formulation with all four instances -- a first count from a new
detector is a measurement of the detector, and all four were caught by inspecting
the flagged items before publishing the number -- and the corollary that an audit
is narrower than its wording: name the form you checked, not the property you hope
it stands for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found P0 complete-but-unindexed: the work existed, the artifact
existed, the gate record did not. They named it as the argued-versus-indexed split
one level up from the refutation register, which is a shape worth checking on my
own objective rather than only agreeing with.
MISSION's gate has two halves -- "a written docs/re/ result with the evidence, and
reference data committed alongside it" -- and all ten questions read answered.
Half one: all ten cite a docs/re/ result.
Half two: every data/ and captures/ path those nine pages cite was resolved
against the tree. 48 citations, 0 missing. Spot-checked six for substance rather
than existence, since the gate's PURPOSE is that the port can work without a disc
-- 1.2 KB to 20.7 KB, 15 to 324 numeric lines each. No stubs.
CLEAN, and unlike the port's P0 also indexed: HANDOFF's status table cites the
page and the page cites the data.
Reach stated, because a clean audit is worth exactly its checks. This tests that
CITED files EXIST and carry content. It does not test that the data supports the
claim, and it cannot see data a page should have cited and did not -- a page
citing nothing would have passed as "0 missing". None did, but the check would not
have caught it. Existence and substance, never sufficiency.
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
sylpheed-port's check-claims fails their run when a refuted claim is quoted
without an explicit token, and feeding it four withdrawals flagged three still
asserted unmarked -- each inside a correction they had written. REFUTED.md
publishes deaths without enforcing them, which is the gap I named last iteration
and did not close.
check_refuted.py is the prose equivalent: for each quoted claim in REFUTED.md it
searches docs/ for that text and reports occurrences whose neighbourhood carries
no refutation marker. Controlled first -- a claim planted unmarked in a scratch
file is detected, so a clean run means something.
9 raw hits, ZERO real revivals. All false positives, and the kinds are the
finding: 2 were text explicitly DECLINING to revive a claim; 1 a duplicate report;
4 were BACKLOG.md entries under a 2026-08-12 header, an append-only log recording
what was believed then; 2 were the claim quoted inside its own correction.
The structural limit is worth more than the clean result. A neighbourhood-language
detector cannot separate "asserted now" from "recorded as believed then", because
a dated log entry and a revival read identically. The port's design avoids this by
testing for a token an author must PLACE rather than for language -- theirs fires
correctly inside a correction, which is what caught their three, while mine fires
incorrectly there and would miss a revival reworded.
Stopped tuning at two remaining. Each marker phrase added fits the detector to this
corpus's habits of expression and away from being a test of them; tuning until it
reads zero would be fitting the instrument to the answer. Left over-reporting,
which is the safe direction.
Reach: it matches a claim's exact wording, so "no verbatim revival" is not "no
revival".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port audited the documents their brief names and found two stale
blockers in a table they are instructed to consult, having audited everything
else. Mine names eight documents; I had audited MISSION.md and never PROTOCOL,
REFUTED, INDEX or CONTAINER-NOTES.
REFUTED.md is the dangerous one, because a wrongly-dead entry stops someone
re-investigating something live. Checked the keyframe cluster first for the
opposite failure -- entries refuted USING the stale time association, which would
make their deaths unsound. They are sound: the additive-blend and pivot entries
rest on scale values and capture measurements that the association does not move,
and the one entry that did depend on it is already struck through.
The real gap is the other direction. EIGHT claims died this session -- the
fade-out duration "not in the file", the ~14 units as a black hold, the black
interval as a load, "(B) has no black interval", ptloop01/02 not free-running,
the splash dwells running 8.5 % long, EXTRAS's "structural" n=1, and the gap being
determined by the outgoing screen. Every one was recorded in its own page at the
time. NONE of them reached REFUTED.md, the file the brief says to grep before
proposing anything.
Added as a dated section with the true answer after each arrow, following the
file's stated format, and each carrying what made it wrong rather than only that
it was.
METHOD: a refutation that lives only where it was made is not reachable by the
person about to repeat it. The pages are where a refutation is argued; the index
is where it is found -- the same split as docs versus tool, and only the second
one saves anyone. The check is mechanical: after withdrawing a claim, grep
REFUTED.md for its noun.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's caveat on the ninth transition: the destination is identified
after the fact by draw signature, which establishes THAT the two screens differ
but not WHICH either is, so the gap is attributed to a pair whose second member is
known only as "not the other one". Worth trying to remove.
Both runs saved a screenshot of the destination. Scored against the archives the
menu's non-EXTRAS buttons plausibly reach:
m2o best GP_OPTIONS 43.30, margin 5.88
m2o2 best GP_SYSTEM 45.74, margin 2.28
REJECTED against this corpus's own calibration. which_title_screen.py's control
puts a true match at RMSE ~18-20 with margin ~10, and a "neither" at ~34 with
margin under 1. These best fits are roughly double a real match. Accepting "m2o is
GP_OPTIONS" on a margin of 5.88 would be the same weak-margin acceptance that a
threshold was added to the navigation search to prevent three iterations ago.
Reach of the negative: one build per archive was rendered -- the default, which is
the largest -- and the screen a button opens need not be the largest build. So
this fails to identify rather than refuting those archives, which is a different
statement. The port's caveat stands and the ninth pair keeps it.
METHOD: a calibrated instrument can reject its own answer, and should. Without the
calibration, "best match, margin 5.88" reads like an identification -- a ranked
list always has a winner, and nothing in the ranking says whether the winner is
good enough. Any nearest-match report needs a known-good score beside it or it
will name something every time it is asked.
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
sylpheed-port promoted my unverified "EXTRAS is stuck at n=1, a structural limit"
out of a message into DECISIONS.md as an established fact, while holding the file
that refuted it -- their own authored/flow.json, recording ptbtn11 ->
GP_MISSION_SELECT. Their corollary is sharper than my original entry: distrust
"structural" and "impossible" hardest when SOMEONE ELSE writes them, because they
arrive without the doubt the author would have had.
Swept this side for the same shape. It is clean: port-supplied figures are
attributed in the text ("port reports 866 keyframes ... 0 untimed"), the
ui_layout.rs comment on the unreachable fallback cites MY OWN measurement of 0
untimed of 24 811 across 965 builds rather than their 866, and their quantisation
floor of 0.41 appears in no document of mine at all.
Reach stated: this tests attribution WORDING and the port-supplied figures I could
enumerate, not every reliance. A negative from a naive check is not proof of
absence, and saying so is the point of recording it.
What protected it was a habit rather than vigilance -- writing the source into the
sentence. That is now the third instance of one remedy: state what the number is a
number of; write the index space into the token (e10 rather than "build 10"); write
the source into the claim. Put the qualifier in the text, never in the reader's
memory.
Also fixes the half-guard the port called out. The effective-config block reported
`arming on` from screen_id.py, which cannot separate the main menu from EXTRAS --
so it announced "menu" while the run was armed on EXTRAS, a field the guard could
not resolve for exactly the two screens in question. It now prints both that value
AND the discriminator with its margin, so the ambiguity is visible rather than
hidden. NOT yet verified in a run -- per the port's own --no-hold lesson, parsed
and edited is not working.
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
Set out to measure menu -> EXTRAS, the reverse of the pair measured at a 2-frame
gap, to test whether the black gap is a property of the screen pair or of the
direction. The run did not do that.
A three-part patch to fade_decompose.sh asserted two of its three replacements
and left the third -- the branch condition -- unchecked. It silently failed, so
WHERE=menu2extras fell through to the `title` branch. The capture is well-formed
and is of a different transition than intended, which is the build-ordinal error's
shape again: right-looking output for the wrong object. What caught it was the log
LACKING the navigation lines the intended branch prints; the data itself looked
entirely fine.
Salvaged, because the accidental transition is one already measured twice:
run outgoing ramp black incoming decay
1 67-70: 63,127,191,255 3 73-77
2 64-67: 63,127,191,255 3 70-74
3 92-95: 63,127,191,255 3 98-103
Three independent runs, gap = 3 frames every time, outgoing ramp byte-identical
in all three. That takes "the black gap is not a load" from two replicates to
three, and makes the 4-frame outgoing ramp as solid as anything measured here.
menu -> EXTRAS remains open; the condition is fixed (with an assertion this time)
and the run has not been taken.
METHOD gains two entries. Assert every edit, not most of them -- and have each
branch announce itself in the log, so a run that took the wrong path says so
before its numbers are read. And: "appears nowhere in crates/" is a claim about a
TREE. sylpheed-port found SYLPHEED_KF_TIME_SHIFT live at ui_layout.rs:497 on their
branch, which carries the stale era; both statements are true of different trees.
With main 145 commits behind and each agent on a topic branch, any claim about
what the code contains needs its ref attached.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port inverted my documented->exists sweep into parsed->documented and
found three live undocumented flags, with the framing that a capability existing
only in an 11 000-line record is, to a reader of the interface, a capability that
does not exist. The mirror on my side is env vars the CODE reads, checked against
the docs. Like theirs it enumerates, so it completes rather than samples.
41 read by crates/, 19 documented, 22 not. The 22 split cleanly: 7 are read only
in examples/ (per-example filters and dump paths, reachable only by editing an
example's command line), and 15 are read in src/ -- live capabilities of the
library and CLI. Ten are mesh/3D toggles and five are XPR_* texture-decode
toggles.
FOR THE PORT: none of the 15 is in the UI path. Every env var ui_layout.rs and
the screen commands read is documented -- SYLPHEED_REST_RULE and
SYLPHEED_KF_TIME_LEGACY. The menu lane is clean in this direction. But the five
XPR_* are texture-decode toggles and the port consumes textures, so if a sprite
comparison ever disagrees those are the knobs and they are invisible from the
interface.
LIMIT, stated rather than glossed: I verified NONE of the 15 end to end.
`texture export` takes a loose file and the disc keeps its textures inside paks,
so the check cost more than the answer was worth here. That matters because the
port found --no-hold parsed, documented AND INERT under an interaction with
--time: "parsed and reachable" is not "works". The honest claim is that 15
undocumented env vars are READ, not that 15 capabilities exist.
METHOD: sweep the surface in both directions, and note that both directions
enumerate and therefore complete rather than sample -- rare enough in that file to
be worth preferring when available -- while neither establishes that the thing
works.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The refinement sylpheed-port earned by sweeping their own instruction surface and
finding all of it loud: a wrong path errors out and announces itself, while an
inert environment variable returns a clean, wrong result. Only the silent kind
manufactures evidence.
Records that the silent surface is ENUMERABLE and therefore sweepable rather than
sampleable -- every env var the docs name, checked against the code -- with the
result of doing it, and the proxy warning that absent-from-code also flags
container paths the brief sets and no code reads.
This entry failed to apply in the previous commit (an exact-match assertion on
surrounding text) while the two document fixes it describes did land. Committed
separately rather than amended.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port generalised the heading rule: an index is an amplifier, since
anything republishing headings multiplies whatever they assert. Checked mine --
INDEX.md's generated table republishes each file's H1 and Status line, a narrower
amplifier than their TOC but the same mechanism -- and then swept headings for the
dead-rule vocabulary.
The strongest hit is not a heading. ui-keyframe-time-unit.md, the Q1 page, told
readers a comparison was "Gated by SYLPHEED_KF_TIME_SHIFT=1, default unchanged"
and referred to "the other reading behind SYLPHEED_KF_TIME_SHIFT=1". That
variable was REMOVED with the record-layout fix and appears nowhere in crates/.
A reader following it sets something inert, gets default behaviour, and concludes
the two readings agree. A stale instruction that no-ops MANUFACTURES A FALSE
CONFIRMATION -- strictly worse than a stale description, and the same shape as
screen-transitions.md telling the port to author a value that is decoded.
Also demoted the section heading "and the shifted reading wins every time": the
shifted reading was itself superseded, the fix having established the same
association by a better route and timed pose 0 as well, which the shifted reading
never did. The evidence stands and is now evidence for the corrected reading.
METHOD gains three things: rank instructions above descriptions when sweeping for
stale text; an index is an amplifier; and the denominator, stated because it is
unflattering -- this corpus has 2 989 headings, 401 of which make a negative or
absolute assertion, and I have audited this session's plus the dead-vocabulary
intersection. That is a sample, not a sweep, and older headings are likelier to be
stale for having had more chances to be overturned.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port diagnosed their four instances of fixed-code-under-unfixed-
description as a habit rather than inattention: corrections are ADDITIVE. They
append a correction block and leave the original standing above it -- right for a
record, wrong for a statement, because a reader takes the first assertion. Their
fix is to keep the quote but demote it grammatically.
Applied their diagnosis here and found a worse instance than theirs.
screen-transitions.md carried the heading "### ❔ The fade-OUT duration is not in
this field", with a section beneath it that is false in every sentence:
"The fourth block has no time -- a group's last block stops 4 bytes short and
that word is already the next group's element index. So the disc gives the
ramp's target (black) and not its length. That duration is measured below, and
the port is authoring it."
All pre-fix. The record-layout fix times a group's final pose, so block 4 carries
t=80 (menu), 74 (EXTRAS) and 269 (title), and the fade-out ramp is DECODED at
70->80 = 10 units, 64->74 = 10, 261->269 = 8. The section told the port to author
a value that is decoded, and its correction sat 78 lines below.
It also carried the dead rule's exact vocabulary -- "stops 4 bytes short" -- which
is the grep I built for code last iteration and never ran against docs.
Rewritten leading with the correction, the original quoted and demoted beneath it.
METHOD: corrections are additive by default and that is wrong for a statement;
the worst form is a HEADING, which asserts with maximum reach and minimum
context, and a reader scanning headings never reaches the retraction. Audit
headings first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port named a pattern narrower than "docs go stale": a correct fix
sitting directly beneath a refuted description in the same file, within twenty
lines. Not drift -- editing at the point of failure without re-reading the frame
around it. Applied their grep (the vocabulary the OLD rule needed) to my crate
and found two.
ui_layout.rs:308, in rest_plateau's fallback: `continue; // the last frame
carries no time`. That is the pre-fix rule, on a branch that is now UNREACHABLE
-- measured at 0 untimed of 24 811 keyframes across 965 builds. Kept as a guard
because `time` is still Option<u32> and a malformed group could yield None, but
relabelled: it is no longer a description of the format.
ui_layout.rs:268, on the `lastall` rest override: "This is what the shifted time
reading predicts ... testing it against the captures is an independent check on
that reading." The shifted reading was refuted by the record-layout fix in the
same file. The override survives as a plain "take the last keyframe" diagnostic
alongside the documented `last` and `maxalpha`, and now says so.
Both corrections quote the original sentence so the change is visible rather than
silently overwritten -- the practice the port adopted from me this iteration.
Verified by artifact rather than by "it compiles": a comment-only edit must leave
output byte-identical, and the build-7 render's md5 is unchanged at
141771d8f1a2b3496cfd679c6cd45d1a.
METHOD records the pattern with the two greps that find it: the vocabulary of the
dead rule in code, and a HEDGE around something the current reader states exactly
in prose -- a "~0" marks where the old reader could not see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port reported hedging a predicate in DECISIONS.md while stating the
unhedged version in their tool's header, and named it as the same delivery gap
they had fixed once elsewhere and not generalised. Checked this side for the same
shape and found it.
`sylpheed-cli screen render --at` told every user that the resting pose "is wrong
twice over" and to "Prefer `--settle`". That recommendation was never measured.
What the corpus actually records: scored against a live capture of the JP title,
settle gives RMSE 40.210 and rest 41.690 -- a margin of 1.48 against that
instrument's own noise floor of 1.2, which is not decisive -- and --settle has its
own failure mode, 25.5 % of elements mid-ramp at their screen's settle instant.
So neither is established as better, and the interface has been telling people
otherwise while the hedge lived only in docs/re/.
Corrected in the help text itself, on both flags, with the numbers rather than a
softer adjective. Verified by artifact: the tool's --help output is quoted in the
commit's own test, not merely recompiled.
METHOD: hedging in the write-up does not protect the claim you ship in the tool.
Docs are where a claim is reasoned; the tool is where it is believed. Read your
own --help as if a stranger wrote it and check every confident sentence against
what the corpus establishes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found the fifth member of our error family on their own side: their
"visible" test counted any element with alpha > 0, which includes palogo_eff0.
Verified from the disc rather than accepted --
entry 10 [0] palogo_eff0.prm 1 kf t=0 fade=0xff000000 scale=100x100 pos=(0,0)
entry 11 same
Alpha 255 over RGB 000000: full-screen opaque black, drawn from t=0 and showing
nothing. So "any element drawn" reports these screens visible from t=0 while the
frame is black -- "visible" read as "drawn".
Worth having on its own: this verifies from the disc the premise behind
`screen render --black`, which its own help states as "what the game composites
over on a screen carrying its own background". On the splash builds that
background is DECLARED, not assumed.
METHOD gains their amendment, which is the sharpest formulation either of us
reached this week: all five instances are a failure of a NOUN, not of a number.
Extent, bounding box, duration, span, visible. The number was always correct FOR
SOMETHING; what went missing was which thing. Every other check in that file
tests whether a number is right, and not one tests whether it is a number of the
thing you think.
Also teaches fade_quads.py to address a PAK ENTRY directly (`e10`) rather than
only a build ordinal. The splashes are entries 10/11 and are not screen builds,
so no ordinal addresses them -- and writing `e10` states which index space is
meant, which is the standing lesson of build-ordinal-vs-entry.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port said the port plays the full group (255 and 210 units) rather than
my 240/195, and they are right for a reason sharper than either of us first had.
The _eff elements ramp alpha 0 -> 255 over t=0..15 while the main logo is still
fully transparent:
palogo_sqex.t32 0:a=0 15:a=0 30:a=255 ... 255:a=0
palogo_sqex_eff.t32 0:a=0 15:a=255 30:a=212 45:a=0
So the SCREEN is visible from within t=0..15 and its visible span is the full
group. My "240 units visible" was ONE ELEMENT's visible span, computed while
another element of the same build was already on screen -- which is exactly the
error class I was writing up when I made it.
Recomputed against the screen: publisher 1.011/1.083/1.028, developer
1.002/1.001/0.962, mean 1.0146 with one measurement BELOW unity, against my
1.085 with none below. That is not a clock at 54 u/s. The systematic is gone and
Q1 stands unqualified.
The consequence was wrong too: "a port playing 240 units at 60 shows the splash
0.42 s less" -- it plays 255, so the gap is 0.174 s, and on the developer splash
the port runs longer than my mean. No direction to correct in.
What survives weakly: against the full group the publisher runs long in all three
boots while the developer sits at unity. Three boots per screen is thin and it is
not a systematic.
METHOD: state the number, and state what it is a number OF. Four instances of
this family now -- pivot anchor as extent, centre track as bounding box, cycle
length as motion duration, one element's visible span as the screen's -- and two
of the four arose because the PUBLISHER of the number never said what it spanned.
The reader reasoned correctly from the only definition available each time.
Publishing a quantity's extent in the same breath is cheaper than every check in
that file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port reported verify-dwell at 4.28 s / 3.58 s and called it agreement
with my three cold boots. Checked the arithmetic instead of the impression, and
it is not agreement with the DISC.
publisher 240 u = 4.000 s at Q1's 60 u/s measured 4.297/4.604/4.370 mean 4.424
developer 195 u = 3.250 s measured 3.508/3.503/3.366 mean 3.459
All six ratios exceed 1 -- 1.074, 1.151, 1.093, 1.079, 1.078, 1.036, mean 1.085 --
implying 54.3 and 56.4 units/s. The port's own two numbers imply 56.1 and 54.5.
Four estimates, none at 60.
The obvious explanation fails: a detector triggering early and late would lengthen
the interval, but the declared span IS 15->255 and outside it the alpha is 0, so
there is nothing on screen to trigger on. An 8.5 % overshoot is 20 units, ten
rendered frames, which no threshold can manufacture from a blank screen.
Recorded as an open qualification on Q1 rather than a correction: three boots per
screen is thin, and Q1 was measured on a different quantity. It is also NOT the
same discrepancy as the sweep leaf's, which runs ~50 % slow rather than 8.5 %.
For the port: the dwells remain decoded and should still not be authored, but a
port playing 240 units at exactly 60 u/s shows the publisher splash for 0.42 s
less than the game does.
METHOD gains the reusable half of the (A) result, which the port named: a probe
whose observation window is shorter than the effect reports a CLEAN NEGATIVE.
(A) takes 4-6 s; a script that presses and looks 0.5 s later concludes the press
was dropped, with nothing in its log to say otherwise. Check the window against
the latency before believing a null, and sample repeatedly when the latency is
unknown.
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
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 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
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 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
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 -- 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
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
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
