From 53997dfcbd5de453a69b95f1e8be888a8c433264 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 11:22:43 +0000 Subject: [PATCH] re: the CLI binary was STALE -- screen info's keyframe times were the old parser's The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the keyframe-record-layout fix. The old parser shifted every time by one slot and could not time a group's final pose, printing a trailing '-': stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0] fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0] Both outputs are well-formed and neither announces its age. That refutes the premise of screen-transitions.md's 2026-08-29 section, which argued from 'there is exactly one untimed keyframe, and every element has it'. There is no untimed keyframe, so the question it answered -- is 0.4 s the missing duration of that keyframe -- has lost its subject. The ratio test in the same section is untouched. And it decodes the number the port asked about: pteff00.prm's final ramp is 70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to refute the port's 10 against the bytes and could not. So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10 decoded. That the remaining ~14 units are exactly the black hold is arithmetic that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a measurement; the decomposition stays open. CONTAINER-NOTES gains the trap. Renders are byte-identical across the two binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element identity, pivots, keyframe counts and screen render output are unaffected -- it is the times that move. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/agents/CONTAINER-NOTES.md | 20 ++++++++++++++++++++ docs/re/screen-transitions.md | 34 +++++++++++++++++++++++++++++----- 2 files changed, 49 insertions(+), 5 deletions(-) diff --git a/docs/agents/CONTAINER-NOTES.md b/docs/agents/CONTAINER-NOTES.md index 647467f4..8883d9d7 100644 --- a/docs/agents/CONTAINER-NOTES.md +++ b/docs/agents/CONTAINER-NOTES.md @@ -251,3 +251,23 @@ and produced no `xenia_re_ui_draws_NN.log` at all.** The keypress goes to the window and is silently lost — nothing in the session log distinguishes a run that armed from one that did not, so **check the log file exists before spending the run**, and treat a repeat measurement as needing more attempts than samples. + +* 🔴 **`sylpheed-cli` in `$CARGO_TARGET_DIR` can be STALE, and `screen info` lies + quietly when it is.** The copy here was built **2026-08-29 12:38**, before the + keyframe-record-layout fix. The old parser shifted every keyframe time by one slot + and could not time a group's final pose, printing a trailing `-`: + + ``` + stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0] + fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0] + ``` + + Both outputs are well-formed and neither announces its age. A whole page of this + corpus (`screen-transitions.md`) argued from *"there is exactly one untimed + keyframe"*, which was the stale parser's artefact. + + ⚠️ **`cargo build -p sylpheed-cli` before trusting `screen info`** — it takes 8 s + against a warm cache. ✅ Renders are **byte-identical** across the two binaries + (checked on `GP_TUTORIAL` build 0, max per-channel difference **0**), so + `screen render` output and anything derived from element identity, pivots or + keyframe *counts* is unaffected. It is the *times* that move. diff --git a/docs/re/screen-transitions.md b/docs/re/screen-transitions.md index 5a2fe3ff..c81dec98 100644 --- a/docs/re/screen-transitions.md +++ b/docs/re/screen-transitions.md @@ -124,11 +124,35 @@ worth, or **(c)** something the game does independently of the group? **It is (a)** — and it is bigger than the fade quad. Two facts. -**1. There is exactly one untimed keyframe, and every element has it.** Reading -`screen info --build 5 --geometry` for the main menu, all 16 elements end on a -single timeless block; none has two. So there is one unknown duration per screen, -not a chain of them — which rules out (b) outright. And that final block is not -idle: it is where the screen *plays out*. +🔴 **1. "There is exactly one untimed keyframe, and every element has it" — REFUTED +2026-08-30. It was a STALE BINARY.** + +That claim came from `screen info`, and the copy of `sylpheed-cli` in this container +was built **2026-08-29 12:38**, before the keyframe-record-layout fix landed. The old +parser shifted every time by one slot and could not time a group's final pose, so it +printed a trailing `-`. Rebuilt, the same element reads: + +``` +stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0] +fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0] +``` + +**Four timed poses. There is no untimed keyframe and no unknown duration**, so the +question this section was answering — *"is 0.4 s the missing duration of that +untimed keyframe"* — no longer has its subject. The argument below (the ratio test) +is untouched and still shows the content fading rather than a quad arriving; what is +dead is the framing around it. + +✅ **And the number is now decoded.** `pteff00.prm`'s final ramp is **70 → 80 = 10 +units ≈ 0.167 s**, not the ~24 units this page authored. That confirms the port +agent's reading; I tried to refute it against the bytes and could not. + +🔴 **So the measured ~0.4 s is NOT the ramp alone** — 0.4 s is ~24 units against a +decoded 10. Something else occupies the other ~14 units. 🟡 That the remainder is +exactly the black hold is *arithmetic that fits* (14 units = 0.233 s, inside this +corpus's own 0.17–0.23 s plateau), **not a measurement** — and a fit that closes a +question without evidence is what this pair of agents has been catching all week. +The decomposition stays open. | elements | final untimed block | what it does | |---|---|---|