re: the loop records decode -- and they are not what I measured

Two of my own claims from last iteration die here, and the decode is the
thing that kills them.

Searching for the SHAPE instead of an assumed count found it immediately:
fade words matching 0x??ffffff at alternating strides of 24 and 16, which
is a 40-byte block carrying fade at +0 and tint at +24 -- exactly the
build layout, starting at +0x68. So "a leaf record's keyframes are not in
the build's 40-byte layout" is withdrawn. They are. My scan failed
because I demanded 29 strictly-increasing times, having read the word at
+0x004 as a keyframe count; the records hold THREE.

Decoded, both are horizontal light sweeps. ptloop01 runs pteff03.t32
from x=-639 to x=1521 over t=150..600, which is 450 units or 7.5 s;
ptloop02 runs pteff03a.t32 the other way over 570 units or 9.5 s.

Which refutes the second thing. Last iteration I attributed the measured
2.2 s oscillation to these elements because build 4 declares them --
association, not evidence. A 7.5 s cycle would give about three peaks in
a 22 s capture and I counted eight. So the loops are not what I measured,
the 2.2 s stands as a measurement, and its source is now explicitly
unidentified rather than wrongly assigned.

METHOD gets the general form, because it is what cost the previous
iteration: do not hard-code an expected element count into a structure
scan. Scan for the shape and let the count fall out.

docs/re/METHOD.md

@@ -249,3 +249,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   second is the intro movie's own opening frame. Reading the capture alone gives
   "three logo screens". Cross-check a repeat against what is *supposed* to be
   playing at that moment before counting it as its own screen.
+* **Do not hard-code an expected element count into a structure scan.** Looking
+  for a `.rat` record's keyframes, I required 29 strictly-increasing times because
+  a header word read `30`. The records hold **three** keyframes in exactly the
+  layout I was testing for, and the over-constrained filter reported the layout as
+  refuted. Scan for the *shape* (here: `0x??ffffff` fade words at a constant
+  stride) and let the count fall out.

docs/re/REFUTED.md

@@ -35,10 +35,13 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
-* "a `.rat` leaf record's keyframes use the build's 40-byte placement-block
+* ~~"a `.rat` leaf record's keyframes use the build's 40-byte layout" → they do
-  layout (time at `+36`)" → they do not. A strided monotonic scan over
+  not~~ — **withdrawn.** They do. The scan that "found nothing" required 29
-  `ptloop01.rat`/`ptloop02.rat` finds no increasing time sequence at any aligned
+  increasing times; the records hold **three**. Decoded in
-  start. [`ui-title-build-map.md`](ui-title-build-map.md)
+  [`ui-title-build-map.md`](ui-title-build-map.md).
+* "the title's measured ≈ 2.2 s oscillation is the `ptloop01`/`ptloop02`
+  elements" → **mine, and refuted by decoding them.** Their sweeps run 7.5 s and
+  9.5 s; a 22 s capture showed 8 peaks, not 3. The period's source is unidentified.
 * "the developer splash cannot be rendered by `screen render` at all" → it can,
   with **`--all`**. It is only invisible to the *default* listing, which filters on
   `is_build`. [`ui-title-build-map.md`](ui-title-build-map.md)

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

@@ -220,36 +220,44 @@ composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries
 looping element by construction; what is new is that it runs at ≈ 2.2 s and never
 stops.
 
-### ❔ The loop record was opened, and its cycle is still not readable
+### ✅ The loop records ARE decoded — and they are not what I measured
 
-The `.rat` was located and partly confirmed, but its **keyframe times are not**.
+`ptloop01.rat` is an **`opt `-linked leaf record**: in build 4 the chunk `opt `
+(size `0x0c`) carries the name, immediately followed by a `RATC` blob at
+**`0xbb5966`** (`ptloop02.rat` the same at `0xbb5a82`). Its pivot fields read
+`200`/`90`, matching `screen info`'s `pivot (200,90)` — the right blob.
 
-`ptloop01.rat` is an **`opt `-linked leaf record**, not a nested build: in build 4
+**The keyframes use the ordinary 40-byte block layout**, starting at `+0x68`:
-the chunk `opt ` (size `0x0c`) carries the name `ptloop01.rat`, immediately
-followed by a `RATC` blob at **`0xbb5966`**. `ptloop02.rat` is the same shape at
-`0xbb5a82`.
 
-| offset | value | |
+| | `ptloop01` → `pteff03.t32` | `ptloop02` → `pteff03a.t32` |
 |---|---|---|
-| `+0x004` | `0x001e0000` — **30** in the high half | the ~30 keyframes [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md) predicts |
+| kf0 | `t=150` x=**−639** α=`ff` | `t=150` x=**1721** α=`00` |
-| `+0x014` | `1` | name count |
+| kf1 | `t=540` x=−39 α=`80` | `t=630` x=1111 α=`80` |
-| `+0x018` / `+0x01c` | `1280` / `720` | design space |
+| kf2 | `t=600` x=**1521** α=`ff` | `t=720` x=**−839** α=`ff` |
-| `+0x020` | `pteff03.t32` (`pteff03a.t32` for loop02) | the sprite it places |
+| scale | 100 × 600 | 100 × 800 |
-| `+0x050` / `+0x054` | `200` / `90` | pivot — **matches `screen info`'s `pivot (200,90)` for `ptloop01`**, which confirms this is the right record |
+| span | 150 → 600 = **450 units = 7.5 s** | 150 → 720 = **570 units = 9.5 s** |
 
-**But the times are not where a build's are.** A build's keyframes are 40-byte
+Y is constant at 270 and X runs off one edge to the other, so these are
-blocks with the time at `+36`. Scanning every 4-byte-aligned start across
+**horizontal light sweeps** — `loop01` left → right, `loop02` right → left.
-`+0x60 … +0x120` for 29 strictly-increasing values at a 40-byte stride finds
-**nothing**, in either record. So a leaf record's keyframe layout is *not* the
-build placement layout, and the loop's declared cycle cannot be read by that
-route.
 
-**The ≈ 2.2 s therefore stays measured, not decoded.** What a future attempt
+### 🔴 Two things I wrote last iteration are wrong
-gains from this one is the record's address, the confirmed pivot, and one layout
-ruled out.
 
-**For the port:** drawing build 4's resting pose and stopping will look wrong —
+**1. "A leaf record's keyframes are not in the build's 40-byte layout."**
-the title has a continuous ≈ 2.2 s loop over it.
+Withdrawn — they are, exactly. The scan that "found nothing" demanded **29**
+strictly-increasing times because I read the word at `+0x004` (`0x001e0000`) as a
+keyframe count. These records hold **three** keyframes. A filter that hard-codes
+the expected count rejects the right structure; whatever the `30` is, it is not
+the number of keyframes here.
+
+**2. "The ≈ 2.2 s oscillation is the `ptloop` elements."** Withdrawn — I asserted
+the link because build 4 declares those elements, not because anything showed it.
+The decoded sweeps run **7.5 s and 9.5 s**. A 22 s capture would show ~3 peaks
+from a 7.5 s cycle; it showed **8**. So the loops are *not* what the oscillation
+measured.
+
+❔ **What the ≈ 2.2 s period actually is remains unidentified.** Candidates not
+checked: `pteff01.t32` (`[50 71 118]`), the five `ptlogo_back2eff*` glows, or a
+combination. The measurement stands; only its attribution is withdrawn.
 
 ### ❔ The declared 4.08 s build-in was not tested