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.

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 |
 |---|---|---|