port: carry the loop-cycle negative into the handoff

The previous commit's handoff edit failed its own assertion -- the text
had been rewrapped since I wrote the pattern -- so the finding landed in
docs/re and REFUTED but not on the page the port agent actually reads.
An answer not reachable from HANDOFF.md has not been delivered.
This commit is contained in:
Sylpheed RE agent
2026-08-28 20:49:39 +00:00
parent 7f12f5474b
commit 3d938499a7

View File

@@ -66,8 +66,11 @@ authored version can be deleted.
over a 22 s capture). Build 4 declares `ptloop01.rat`/`ptloop02.rat`, and over a 22 s capture). Build 4 declares `ptloop01.rat`/`ptloop02.rat`, and
`loop*.rat` is a decoded **looping sprite animation**. Drawing the resting `loop*.rat` is a decoded **looping sprite animation**. Drawing the resting
pose and stopping will look wrong. ❔ Whether 2.2 s is the loop's declared pose and stopping will look wrong. ❔ Whether 2.2 s is the loop's declared
cycle is unread — `screen info` does not print the frame count inside a cycle is **still unread**. The record was located — an `opt `-linked `RATC` at
`.rat`. `0xbb5966` in build 4, placing `pteff03.t32`, declaring 30 at `+0x004`, with a
pivot matching `screen info` — but a leaf record's keyframe times are **not** in
the build's 40-byte block layout, and a strided monotonic scan finds nothing.
The period is measured; the port hardcodes it.
* **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
✅ correct for a vertical menu and is **not** a decoded neighbour graph — the ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
disc's real navigation structure is unknown, and `opt ` is *not* a focus link disc's real navigation structure is unknown, and `opt ` is *not* a focus link