Files
Sylpheed/tools
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
2026-09-01 19:26:36 +00:00
..