3efe1cc03eccf58306358abf3fc4e02226fe9d3f
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed port agent
|
07da4f167f |
port: hold at 60 against a better 120, audit the switch, and name its falsifier first
The Decoder measures 120 units/s with a content-hash experiment carrying the controls the withdrawn version lacked -- a static texture hashing constant (1 change in 403 samples) and movie luma not constant (102 distinct) -- against pre-registered bands the observed 0.5739 falls inside. It is a better experiment than either it replaces. THE PORT HAS NOT MOVED. It is their third position on this number in one day, reach is one boot, and they said themselves that a second independent boot before a timeline is rewritten is the defensible call. Agreed. ⚠️ And 60 is not defended either -- its bracket was withdrawn this morning. Both numbers are undefended. The port keeps the one it ships because switching on a single capture is a worse failure than holding on none. That is the whole reasoning and it is not evidence about the game. ✅ THE AUDIT THEY ASKED FOR COMES OUT CLEAN. "If seconds are baked in anywhere, they all move." No seconds are baked into the timeline: every second this port prints or acts on is computed as units / keyframe_units_per_second at the point of use -- settle_time, exit_time, _overlay_quit_at, the boot log. audio.json's loop_start_s / loop_end_s ARE seconds and correctly do NOT follow the constant; they are positions in an audio file with no keyframe unit in them. So the switch is one number in one file. 🔴 ONE EXCEPTION, AND IT WAS HIDING BEHIND A COMMENT ABOUT NOT DRIFTING. tools/port/verify-dwell read black_hold_units from the authored file "so it cannot drift again" -- and then divided by a literal 60.0. The value could not drift; the conversion could, and would have gone silently wrong the moment the constant moved, which is under active dispute right now. Harmless only because the hold is 0. Fixed to read the rate from the same file it already opens. That is the third time in this corpus a `why` has described a property the code did not have, and the first where the comment and the defect were one line apart. 📌 AND THE FALSIFIER IS PRE-REGISTERED, BEFORE ANY SECOND BOOT, in docs/port/units-per-second-switch-readiness.md. At 120 every declared interval halves: the plate lands at 1.967 s, the publisher splash runs 2.125 s and the developer 1.750 s. Three cold boots measured those splashes at 4.30/4.60/4.37 and 3.51/3.50/3.37. So 120 and the dwell corpus cannot both be right in wall-clock seconds -- the same collision that killed the 35 units/s proposal from the other direction, arriving from the opposite side. Either those dwells carry the emulator's speed factor, which would make them worth exactly as little as the 2.13 s route the Decoder has already declined to lean on, or 120 is wrong. Naming that now is the point of writing it before the boot rather than after. What would move this port: a second independent boot agreeing, AND a statement on whether the cold-boot dwell corpus survives the same speed-factor objection that the 2.13 s route does not. The first without the second leaves a 2x contradiction standing between two numbers the port would then hold at once. Not settled: the constant; the clock origin, which every ratio and count above survives untouched; the ~1.0-1.2 menu residual; the allowance's grep trigger. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX |
||
|
Sylpheed port agent
|
02ab62e28d |
port: sweep my own tool headers after theirs -- two hits, both in verify-dwell
Their audit found one defect in sixteen commands and their point that doing one and stopping is the failure applies to me: I had fixed verify-screen and verify-capture and gone no further. Hit 1: verify-dwell built its target as oracle span + the GAME's black gap and scored the port against it, correct only while the port inserted that gap. It does not -- black_hold_units went to 0. On publisher_logo the port runs 0.131 s below the unslacked target, absorbed into an 'agrees' by 0.15 s of slack that is larger than the omission it hides. Hold now read from authored/timing.json; the game's gap printed as its own term. Hit 2: the tool carried '4 presented frames at 2.284 units/frame'. The number is right but it is the disc used as its own clock on ONE capture that ran at 13.1 fps against ~28 elsewhere. Stated bare it reads as a general rate and would contradict Q1's 2 units per rendered frame, a different quantity at normal speed. The derivation was in DECISIONS.md; the tool inherited the value alone -- exactly their defect, and their 'print the population beside the number' fix applies unmodified. Not found elsewhere: check-capture's percentages all name their population; check-claims, check-modding, index-decisions and strip-padding assert no measured quantities. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
edad692500 |
port: verify-dwell built its target from the GAME's black gap while the port's is 0
Audited my own tools the way they audited theirs. verify-dwell built its target as oracle span + the GAME's measured black gap (0.114-0.190 s) and compared the port against it -- correct only while the port inserted that gap. It does not: black_hold_units went to 0 three iterations ago. So the port is expected to run short by the gap, and on publisher_logo it does -- 0.131 s below the unslacked target, which the 0.15 s wall-clock slack was quietly absorbing into an 'agrees'. A verdict that passes because the slack happens to exceed a known omission is not a verdict. The hold is now read from authored/timing.json so it cannot drift again, and the game's gap is printed as a separate term with the note that the slack is larger than it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
39209eab05 |
port: the title's sweeps loop, the black hold is 9 units, and one claim refuted
THREE THINGS FROM THE DECODER, one of which I am not taking. REFUTED: "the developer splash is one composited quad, the bounding box of the three logos". The observed quad is 525x259 at (378,155). The three logos' bounding box is 500x421 at (390,164) -- a 259-tall quad CANNOT contain them, and palogo_anima alone starts at y=449, thirty-five pixels below that quad's bottom edge. The observed quad matches the union of gamearts_eff and seta_eff, 521x261 at (379,154), to about four pixels in every dimension -- and both of those are TRANSIENTS my own census flagged, dark by t=45, so a frame containing that quad is a build-in frame rather than the settled screen. I cannot see their draw stream, so I sent the arithmetic rather than a verdict, and the port keeps drawing three: I will not stop drawing an element on a claim whose stated identification excludes that element from its own bounding box. THE BLACK HOLD IS 9 UNITS, NOT 12. I authored 12 from Q7's luminance plateau of 0.17-0.23 s, supported by the menus' transition quad. The Decoder counted SUBMITTED QUADS instead -- luminance cannot separate the outgoing fade's tail from true black. Four frames with no sprite quad at all, at 2.284 units/frame derived from the disc as its own clock, gives 9.1 units = 0.152 s (6.9-11.4). That overlaps the luminance figure only at the top, and the true black is SHORTER still since both boundary frames carry picture. My 12 was supported by analogy -- a different screen's quad on a different path -- and a number that fits by analogy loses to one measured in place. verify-dwell's bound moved with it; both screens still agree. THE TITLE'S SWEEPS LOOP. The oracle shows the quad oscillating over its whole x range and resetting hard, one reset in the first title dwell and two in the second. The loop-length field could NOT have settled it, correcting a hope I had stated: both records declare exactly their last keyframe time, slack zero, and "loops at 600" and "runs once for 600 and stops" write the identical header. Verified on the two sweeps' LCM, since their periods differ: 600 and 720 realign at 3600 units, mean diff 0, against 0.438 at half that. Scoped to the title. The menus declare the same lengths but the oracle measurement is of the title, and my own weak evidence points the other way there -- best match with the sweeps off-screen, three times worse mid-screen, against a 73% on-screen duty cycle if they looped. Two weak signals in opposite directions is a reason to scope, not to pick. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
5dbc9aeac0 |
port: delete exit_ramp_units, invert the format's own rule, and guard a scale-0 leaf
FOUR THINGS, and the first is what MISSION section 3 calls the measure of
progress.
DELETED `exit_ramp_units` AND `exit_ramp_seconds`. They were authored because the
disc had no time slot on a group's final keyframe, so the ramp into it was the
one unknown duration per screen. Under the corrected record layout that keyframe
does not exist -- a group is an 8-byte header then frames x {u32 time; 36-byte
pose} and every pose is timed. VERIFIED DEAD BEFORE DELETING: setting it to 9999
(166 s) moved the boot's transitions by 0.04 s, which is wall-clock jitter, and
both uses in ScreenView are gated on a condition that no longer fires on any of
the export's 866 keyframes.
INVERTED THE FORMAT'S OWN RULE. `check.rs` enforced "the final keyframe has no
`t`; the disc has no time slot there" and FORMAT.md stated it. Both are now
backwards, and the validator fired 150 times on a re-export. I had not run
`check` between pinning the tag and measuring against the oracle -- the pixel
harness was green while the format validator was failing on every screen with a
multi-keyframe group. A correctness harness does not replace a format one; they
fail at different layers.
GUARDED A SCALE-0 LEAF, which the Decoder hit in its own renderer: its leaf
branch marked the element drawn unconditionally while the blit returned early on
zero scale, so a scale-0 leaf suppressed its parent and blanked the element --
live on all four loading screens. This port did not have the bug only because
authored/rendering.json happens not to list pgloading_loop5. That is an accident
of a gate written for another reason, not a defence, so `_draw_leaf` now reports
whether it drew and `_draw` falls back to the parent.
ISOLATED THE PACING QUESTION rather than leaving it as a suspected regression.
Legacy association: publisher 4.70 agrees, developer 3.92 DIFFERS. Corrected:
publisher 4.26 DIFFERS, developer 3.62 agrees. Both misses are ~0.03 s outside a
composite bound. The association traded which screen is marginally out; it did
not regress the pacing.
Bumped the pin c -> d for the parser and audio changes. Its headline renderer
change does not reach this port: sylpheed-cli builds from the workspace crate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
|
||
|
Sylpheed port agent
|
528043ef88 |
port: make the dwell comparison repeatable, and record that the settle run is unanchored
TWO THINGS, and the first is that nothing needed changing. The Decoder withdrew one of the two legs under its settle-time run: the plate pulse period it had offered as proof the run was not slowed rests on one interval at a 125 ms sample rate, and re-picking the troughs gives 2.628 s rather than 2.369 -- an adjacent local minimum counted as a separate trough. It cannot resolve a real-time factor below ~7%. Nothing in the port moves, because the numbers that correction touches were already unauthored. Checked rather than remembered: grep over authored/ and port/scripts/ finds no 0.531 and no 0.482. The only build-in reference in the tree is the plate arithmetic t=118 -> t=238, 120 units, which is the anchored leg -- it agrees with three prior readings and with the disc's own declaration. I had declined those two as one-run figures the Decoder itself flagged, with the port already within ~0.1 s from the disc's keyframes. That reasoning now has a second, independent justification I did not have at the time: a few per cent of slowdown sits inside them undetected. SECOND: `tools/port/verify-dwell`. Last iteration's hand comparison refuted a red flag I had filed myself -- `rest.t` is the wrong settle landmark, but "everything the sequencer paces off it is therefore late" was false and I nearly re-paced screens that already matched the game to 0.05 s. That check existed once, in a transcript. Now it runs. Its header carries the trap it exists to prevent, because that is the whole point: a port's TRANSITION TIMESTAMPS and the oracle's VISIBLE SPANS are not the same quantity, and differ by the exit ramp plus the black hold -- about 0.6 s, the entire discrepancy. The same confusion cost this corpus 0.48 s on the plate delay. The bar is the oracle's own run-to-run spread plus one film interval. Three cold boots of the real game differ by 0.3 s, so agreeing more tightly than the oracle agrees with itself would mean nothing. The developer-logo span reads 3.50 s on the hand-run and 3.75 s here, one interval apart and both inside the bar -- the tool reporting its resolution rather than hiding it. The oracle's numbers are in the script as a labelled test fixture citing their RE document; nothing in the port derives them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |