Files
Sylpheed/docs/re/data/rest-fallback-audit.txt
sylph-decoder 155e1b82b3 re: my own 1697 audited -- and the first correction failed its control
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
2026-08-30 12:13:46 +00:00

47 lines
2.2 KiB
Plaintext

# Auditing my OWN 1 697 with the port's rule -- and the first correction failed
# its own control. 2026-08-30.
#
fallback fires 2305
of those, rest alpha > 0 1697
element's LAST keyframe alpha > 0 347 <- ends visible; resting visible is CORRECT
element's LAST keyframe alpha = 0 1350 <- fades out; a visible rest is a transient's peak
rest alpha == the element's MAX 1457
CONTROL on the split itself — is 'ends at a=0' near-universal?
all elements with >= 2 keyframes 13991
of those, last keyframe alpha = 0 12278 (87.8 %)
--- END (if this line is missing, the run did not finish) ---
#
# THE STORY, SAID OUT LOUD:
#
# 1. '1 697 fallback fires return a visible pose' was published as if the
# number were a defect count. It is not. An element that genuinely ends
# visible and stays visible SHOULD rest visible; the fallback being the
# path that got there is not an error.
#
# 2. FIRST CORRECTION, and it looked clean: split by whether the element's
# LAST keyframe is visible. 347 end visible (correct), 1 350 fade out
# (a transient's peak). Plausible, arithmetic fine.
#
# 3. 🔴 IT FAILED ITS CONTROL. The port agent had just found that a SCREEN's
# exit ramp drives every element to a=0 at the end -- which is why its own
# census called ptmsg, the permanent footer, 'a 2-unit flash'. Measured
# here: 12 278 of 13 991 elements (87.8 %) end at alpha 0. So 'ends at
# a=0' is near-universal and says almost nothing about being a transient.
# The 1 350 is not a transient count and is NOT published as one.
#
# 4. ✅ WHAT SURVIVES, and it needs no such split:
#
# 2 305 elements where the dwell fallback decides
# 1 457 of those rest at the element's MAXIMUM alpha
#
# 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 times it returns the BRIGHTEST un-held pose.
# That is the defect shape, stated without needing to know where the
# element's visibility ends.
#
# I ran the control only because the port had just been bitten by the exit
# ramp. Without that message the 1 350 would have shipped.