re: the last keyframe time is the chunk terminator -- observed, not

assumed

Continuing the pulse's cycle length, which I had called a structural
limit of the format. It is, and now I can show it rather than assert it.

Dumping past what I thought was the final keyframe found an EIGHTH block:
fade 0x00ffffff at the same position, so the glow returns to fully
transparent and the pulse is a closed cycle rather than a one-shot ramp.
That is worth having on its own -- the port knows the animation ends
where it starts.

And the eighth block's time slot contains the four bytes "end ", the
record's ASCII terminator. So the corpus's rule that a group's last block
has no time of its own holds here in a second form: not the next group's
element index, but the chunk terminator. The value does not exist. That
goes into ui-rat-layout.md, because it generalises beyond this record.

The measured 2.3 s would need a final step of about 33 units. I have
written that number down explicitly labelled as fitted to the measurement
rather than read from the file, so nobody later re-derives it as a
decode.

One thing I had half-assumed and can now rule out: the word at +0x004 is
not a keyframe count. It reads 60 here with 8 keyframes and 30 in the
loop records with 3. Unknown, and marked so.

docs/port/HANDOFF.md

@@ -72,11 +72,16 @@ authored version can be deleted.
     screen — a capture's per-tile amplitude map puts **sd 7.65** in the band
     x ≈ 318–954, y ≈ 560–672 against **0.06** on the wordmark. It is
     `ptbtn00f.rat`, the plate's highlight variant (build **2**, not build 4),
-    whose alpha ramps **`0x00 → 0x06 → 0x4a → 0x50` (hold) `→ 0x4a → 0x06`**
+    whose alpha ramps **`0x00 → 0x06 → 0x4a → 0x50` (hold) `→ 0x4a → 0x06 → 0x00`**
-    across `t = 6 … 105` — a glow that fades in and back out.
+    over **eight** keyframes at `t = 6, 29, 35, 50, 58, 97, 105, ?` — a glow that
-  🟡 Its full cycle is **not** readable: the keyframe group's last block carries no
+    fades in and back out, **closing on fully transparent**, so it is a complete
-  time (that slot belongs to the next group), so the declared span is **≥ 105
+    cycle rather than a one-shot ramp.
-  units = 1.75 s** against a measured **≈ 2.3 s**. Consistent, not confirmed.
+  🟡 Its cycle **length** is not readable, and this is now observed rather than
+  assumed: the eighth block's time slot literally contains the ASCII terminator
+  `end `, so the record ends there and the value does not exist. Declared span is
+  therefore **≥ 105 units = 1.75 s** against a measured **≈ 2.3 s** — which would
+  need a final step of ≈ 33 units. That number is **fitted to the measurement, not
+  read**; the port should take ≈ 2.3 s as measured.
   ⚠️ An earlier version of this bullet said "the title screen loops at ≈ 2.2 s"
   and attributed it to `ptloop01/02`. Both halves were wrong: it is the **plate**,
   and it is a different build.

docs/re/structures/ui-rat-layout.md

@@ -695,4 +695,19 @@ rule, and the kind of moderate split that would be easy to over-read.
 rather than untried, and the field is at least correctly *sized*. Assigning
 meanings almost certainly needs the game observed with individual bundles
 loaded, not more static correlation — every property visible in the file has now
-been tried.
+been tried.
+
+## A leaf record's last keyframe time is the chunk terminator (2026-08-28)
+
+The build placement region's "a group's data stops 4 bytes short of its final
+block's time slot — that word is already the next group's element index" has a
+second form in **leaf `.rat` records**, where there is no next group.
+
+`ptbtn00f.rat` (`GP_TITLE` build 2, `RATC` at `0x04115e`) holds 8 keyframe blocks
+of the ordinary 40-byte layout starting at `+0x68`. The eighth block's time slot
+at `+0x1a4` contains **`end `** — the record's ASCII terminator. So the last
+keyframe's time is not merely unread, it is **not present**, and any animation's
+full cycle length has to come from measurement.
+
+❔ The word at `+0x004` is **not** the keyframe count: `0x003c0000` (60) with 8
+keyframes here, `0x001e0000` (30) with 3 in `ptloop01.rat`/`ptloop02.rat`.

docs/re/ui-title-build-map.md

@@ -284,10 +284,23 @@ Decoding `ptbtn00f.rat`, the plate's highlight variant, gives the pulse directly
 
 A glow that fades in to `0x50` and back out — exactly a "press start" pulse.
 
-🟡 **The cycle length is still not readable.** The group's last block has no time
+There is an **eighth** keyframe: fade `0x00ffffff` at the same position — the glow
-(that slot belongs to the next group), so the declared span is **≥ 105 units =
+returns to **fully transparent**, so this is a closed cycle, not a one-shot ramp.
-1.75 s** against the measured **≈ 2.3 s** (138 units). Consistent with a final
+
-block extending the tail; not confirmed.
+🟡 **The cycle length is still not readable — and now that is an observation.**
+The eighth block's time slot contains the four bytes `end `, the record's ASCII
+terminator: the record simply stops there and the value does not exist. So the
+corpus's "a group's last block has no time of its own" rule holds here in a second
+form — not the next group's index, but the chunk terminator.
+
+Declared span is **≥ 105 units = 1.75 s**; measured **≈ 2.3 s** (≈ 138 units),
+which would need a final step of ≈ 33 units. **That 33 is fitted to the
+measurement, not read from the file**, and is recorded only so nobody re-derives
+it as if it were a decode.
+
+❔ **The word at `+0x004` is not a keyframe count.** It reads `0x003c0000` (60)
+here with 8 keyframes, and `0x001e0000` (30) in the loop records with 3. Whatever
+it is, it is not the count, and it is not decoded.
 
 ### ❔ The declared 4.08 s build-in was not tested