Two things, and both are about a label being wrong rather than a value.
1. THE rest() PAIR IS MOOT FOR THIS PORT, and that is measured rather than
waited on. R1 re-opened both legs, 8 further claims died with the
⟨render-vs-capture⟩ instrument, and ScreenView.settle_time() uses rest.t -- so
this port has been sitting on a question with no instrument behind either side.
An element reaches the plateau-less fallback exactly when no two consecutive
keyframes are identical. Census over all sixteen screens at every nesting depth:
FIVE elements, three distinct -- palogo_sqex_eff, palogo_anima_eff, ptlogo_eff3,
plus two region twins.
And every one of them is transparent where its rest pose is read:
publisher_logo t=140 not drawn: palogo_sqex_eff (transparent)
developer_logos t=117 not drawn: palogo_anima_eff (transparent)
title_jp --pose=rest not drawn: ptlogo_eff3 (transparent)
So no rest() rule -- plateau-plus-dwell, `last`, `maxalpha` or `lastall` -- can
change any pixel this port draws. That is why the splash rows score 0.01 %
against their captures while resting on a heuristic nobody can currently defend:
it is not load-bearing there.
🔴 And the brief's "the two splashes are the ONLY screens reaching that fallback"
is narrowly refuted -- title_jp reaches it too, via ptlogo_eff3. Stated as a
measurement of the CURRENT export: the record-layout fix re-timed keyframes
corpus-wide and a plateau is exactly what that could create or destroy, so this
does not say the claim was wrong when written.
⚠️ It does NOT rehabilitate rest.t, still wrong for transients like
ptlogo_back2eff1 whose rest.t=54 is a two-frame flash's PEAK. That is a plateau
case, not a fallback case, and nothing here touches it.
2. keyframe_units_per_second RECLASSIFIED measured -> authored. The value does not
move; the label was false. The Decoder withdrew their guest-frame-rate finding
the same day they published it, and this file carried `kind: measured` on its
strength. Three routes now disagree -- withdrawn movie cadence 60, vblank ~120,
title-plate-delay ~56 -- and at most one is right.
60 is kept, and not as a coin toss: the one leg of this file's own reasoning that
never touched a frame count still brackets it. The transition quad is declared
black for 12 units and the capture measured 0.14-0.30 s, i.e. 40-86 units/s. 60
sits inside; 120 does not; ~56 is 7 % away and inside the same bracket.
🔴 audit-kinds caught my first attempt at this, DANGLING: I cited
guest-frame-rate-WITHDRAWN.md, which is on their branch and not in my checkout --
citing a document I cannot read. The check doing exactly its job. The withdrawal
is now named in prose and labelled as coming from their message.
📌 Their method note is worth more than the number and is recorded in the file:
their pre-registration named three ways the ruler could lie and guarded two; the
third occurred, and a PERFECT 1.0000 is precisely what it produces. A clean result
on an instrument whose key assumption is unguarded is not confirmation -- the
cleanness may be the failure mode's own signature. Same family as this port's
non-inverting latch check, which passed for the wrong reason until its control
failed.
Not settled: finding 3 still has no surviving cause; the ~1.0-1.2 menu residual
against the additive-capable reference; pgloading_loop5's own residual; and the
allowance still waits on its grep trigger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
3df042f10f