3356343cad
The port recomputed the publisher splash's widest keyframe-free gap as 190 units against my 8 and said one reading must be wrong. Mine was, and the library was never wrong -- only my invocation. From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both match the port exactly. The cause is that screen render --build N takes a BUILD ORDINAL. screen list says [10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not screen builds at all, so my --build 10/11 rendered the LOADING screens. This is the foot-gun HANDOFF already documents, which the port caught months ago in the mirror direction. Three retractions: 1. 'Width does not predict quality' -- withdrawn. It rested entirely on the splashes being width 8 while winning 75x. They are the widest of the five, so width and mid-ramp are perfectly confounded across every screen either of us has measured and the width hypothesis is NOT refuted. 2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket, the worst at 45.1 %. 3. The splash rows of settle-vs-rest-against-captures -- void. They scored loading-screen renders against splash captures. I discarded them for a railed gamma fit; the real reason is that they were the wrong screens, and the railing was that mismatch surfacing where my instrument could report it. Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which iterate pak entries directly and never touch the ordinal path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
55 lines
2.7 KiB
Plaintext
55 lines
2.7 KiB
Plaintext
# RETRACTION: the splash settle windows are 190 and 145, not 8 -- and the
|
|
# width hypothesis is NOT refuted. 2026-08-30.
|
|
#
|
|
# The port agent recomputed the publisher splash's widest keyframe-free gap
|
|
# as 190 units against my reported 8, and said one reading must be wrong.
|
|
# It was mine, and the library was never wrong -- only my invocation.
|
|
#
|
|
# examples/settle_window_check.rs, straight from the file:
|
|
#
|
|
# entry 10 palogo_sqex.t32 [0 15 30 235 239 251 255]
|
|
# palogo_sqex_eff.t32 [0 15 30 45]
|
|
# union [0,15,30,45,235,239,251,255] widest gap 45->235 = 190
|
|
# settle_window() -> Some((45, 235)) <- 190, matches the port
|
|
#
|
|
# entry 11 union [0,15,30,45,190,194,206,210] widest gap 45->190 = 145
|
|
# settle_window() -> Some((45, 190)) <- 145, matches the port
|
|
#
|
|
# 🔴 THE CAUSE: 'screen render --build N' takes a BUILD ORDINAL, not a pak
|
|
# entry. screen list says so directly:
|
|
# [10] entry 12 [11] entry 15
|
|
# The splashes (entries 10 and 11) are not screen builds at all. My
|
|
# '--build 10' and '--build 11' rendered the LOADING screens.
|
|
#
|
|
# This is the foot-gun HANDOFF already documents -- the port caught it months
|
|
# ago, writing that an ordinal-keyed '10'/'11' names the publisher wordmark
|
|
# and developer logos as loading screens 'and everything still validates'.
|
|
# I walked into the mirror image of it.
|
|
#
|
|
# WHAT THIS RETRACTS:
|
|
#
|
|
# 1. 'Width does not predict quality' -- WITHDRAWN. It rested entirely on the
|
|
# splashes being width 8 while winning 75x. They are width 190 and 145,
|
|
# the WIDEST of the five screens. Width and mid-ramp are now perfectly
|
|
# confounded across every screen either of us has measured, exactly as the
|
|
# port said. The port's predictor may still be the mechanism; this evidence
|
|
# does not establish it over width.
|
|
#
|
|
# 2. 'My rest_vs_settle filter excluded the splashes' -- WITHDRAWN. At 190 and
|
|
# 145 they were never near the 10-unit cutoff. The filter's other fault
|
|
# stands: it admitted the 10-19 bucket, the worst at 45.1 % mid-ramp.
|
|
#
|
|
# 3. The splash rows of settle-vs-rest-against-captures.txt -- VOID. They
|
|
# scored LOADING-SCREEN renders against SPLASH captures. I discarded them
|
|
# for a railed gamma fit; the real reason is that they were the wrong
|
|
# screens, and the railing was that mismatch showing up in the only place
|
|
# my instrument could report it.
|
|
#
|
|
# ✅ WHAT SURVIVES: the title row (build ordinal 4 = entry 4, correct), where
|
|
# settle beats rest 4.6x on differing area at an interior gamma. And the
|
|
# disc-wide censuses, which iterate pak entries directly and never touch
|
|
# the ordinal path.
|
|
#
|
|
# ⚠️ To render a splash: entries 10/11 need 'screen render --all', which
|
|
# renumbers --build over every composable bundle.
|