fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the CLI binary was STALE -- screen info's keyframe times were the old parser's

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 11:22:43 +00:00
parent 951b9a4c80
commit 83b7316065
2 changed files with 49 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/agents/CONTAINER-NOTES.md
View File

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

34
docs/re/screen-transitions.md
View File

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