re: the boot shows the publisher first -- the TSV that says otherwise attached late

The port flagged docs/re/data/boot-timeline-2026-08-29.tsv, whose label column
runs splash_dev before splash_pub, as a possible boot-order bug in its tree.

Three cold boots, t=0 at launch, no pad input, and the frames looked at rather
than only correlated: SQUARE ENIX 3.05-7.34 / 1.18-5.78 / 1.19-5.56 s, then a
~0.25 s black hold, then GAME ARTS/SETA/studio anima. Publisher first, 3/3.

The TSV is not wrong about any frame; its t=0 is ~7.7 s into the guest's boot,
so the publisher splash had been and gone before the stream opened. The tell is
in the file: its first twelve rows are byte-identical to four decimals -- one
held frame sampled twelve times -- and those exact numbers reappear in my run 1
at 8.42-10.94 s.

Second trap, new: ADV.wmv opens with its own SQUARE ENIX card, bloomed and below
centre, scoring 0.59-0.75 against live-splash-publisher.png. The classifier
fires splash_pub twice per boot and the second one is a movie frame. The real
splash holds perfectly still and scores 0.93-0.94.

And the dwells are DECODED, not measured: the publisher declares 240 units
(4.000 s) and the developer 195 (3.250 s), against measured 4.30/4.60/4.37 and
3.51/3.50/3.37. Measured over declared is 1.085 on average across six spans --
a 30 Hz timeline at 27.6 fps, which is the presentation rate this corpus has
measured independently three times. The port authors nothing here.

Instrument control run first: 11/11 content, 4/4 plate, the two splash
references rejecting each other at 0.035.

docs/re/boot-order-and-splash-dwell.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY

docs/game/navigation.md

@@ -35,6 +35,15 @@ Confidence: ✅ seen in a capture · 🟡 inferred · ❔ unknown.
 | 4 | **Title screen** — the wordmark appears **first, with no prompt**; `PRESS Ⓐ BUTTON` fades in **2.13 s** later, above the 2006/2007 Square Enix copyright line, and then pulses about every 2.2 s ✅ | press **Ⓐ** | goes to the main menu ✅ |
 | 5 | **Main menu** | — | see §2 |
 
+✅ **The order is publisher then developer, confirmed in three cold boots
+(2026-08-29)** — `SQUARE ENIX` for ~4.3 s, a ~0.25 s black hold, then
+`GAME ARTS` / `SETA` / `studio anima` for ~3.5 s, and both dwells are declared on
+the disc (240 and 195 keyframe units). ⚠️ There is a **third** SQUARE ENIX
+wordmark about ten seconds in — bloomed, below centre — and it is the opening
+card of the intro movie, not a splash.
+[the three frames side by side](../re/captures/boot-order/splash-order-two-runs.png) ·
+[`boot-order-and-splash-dwell.md`](../re/boot-order-and-splash-dwell.md)
+
 Both logo screens are **still pictures the game draws**, not video — neither is a
 `.wmv` on the disc. Captures:
 [publisher](../re/captures/title-builds/live-splash-publisher.png) ·

docs/re/METHOD.md

@@ -114,6 +114,25 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   about how a screen is built or animated has to be armed *before* it exists.
   Re-arming every few seconds and keeping every log tiles the approach: each F10
   opens a new numbered file and closes the previous one complete.
+* **A capture stream that opens N seconds after launch will report the boot in
+  the wrong order, and nothing errors.** `data/boot-timeline-2026-08-29.tsv`
+  opens on the *developer* splash and labels the publisher one 6 s later, which
+  reads as `dev → pub` and is the opposite of the boot. The stream had attached
+  ~7.7 s in and missed the publisher entirely. **The tell was in the file**:
+  its first twelve rows are byte-identical to four decimals — one held frame
+  sampled twelve times, i.e. the probe joined a screen already in progress rather
+  than watching it arrive. If `t = 0` is not the launch, say so in the file; if
+  the first rows do not *change*, you did not see the beginning.
+  ([`boot-order-and-splash-dwell.md`](boot-order-and-splash-dwell.md))
+* **`ADV.wmv` opens with its own SQUARE ENIX card, and it scores 0.75 against the
+  publisher splash.** A correlation classifier keyed on
+  `live-splash-publisher.png` therefore fires **twice** per boot, ~10 s apart,
+  and the second one is a movie frame. Discriminators that work: the real splash
+  is *perfectly still* (identical frame statistics for seconds) and scores
+  0.93–0.94; the movie card drifts continuously and never passes 0.76 — and its
+  wordmark is bloomed and below centre where the splash's is sharp and centred.
+  **A threshold that both a screen and a movie frame clear is not a classifier**;
+  look at the frame.
 * **Measure animation in submitted frames, not in seconds.** `VdSwap` counts are
   the guest's own frames, so an emulator at 80 % of real time does not move them;
   a stopwatch reading does, silently and by an unknown factor.

docs/re/boot-order-and-splash-dwell.md

@@ -0,0 +1,125 @@
+# The boot's first ten seconds: publisher, then developer — and the movie has a logo card too
+
+**Status:** ✅ `CONFIRMED`. The **order** is measured in three independent cold
+boots and confirmed **by eye**, not only by a correlation. The **dwells** are
+**decoded** — they are on the disc, and the running game reproduces them to
+within the emulator's own frame pacing.
+
+Raised by the port agent against `data/boot-timeline-2026-08-29.tsv`, whose
+`label` column runs `splash_dev` *before* `splash_pub` — the opposite of what
+`authored/flow.json` carries. If that ordering were real it would be a boot-order
+bug in the port. **It is not real, and this page says why.**
+
+## The order: publisher first
+
+![the two splashes and the movie's logo card](captures/boot-order/splash-order-two-runs.png)
+
+*Brightened ×6 — these frames have a surface mean of ≈5/255. Top-left and
+top-right are the two splashes; the bottom row is what comes next and is NOT a
+splash.*
+
+| run | `SQUARE ENIX` (publisher) | `GAME ARTS`/`SETA`/`studio anima` (developer) |
+|---|---|---|
+| 1 | 3.046 → 7.343 s | 7.683 → 11.191 s |
+| 2 | 1.180 → 5.784 s | 6.051 → 9.554 s |
+| 3 | 1.192 → 5.562 s | 5.929 → 9.295 s |
+
+Three cold boots, `t = 0` at process launch, a ~0.2–0.3 s black hold between
+them. **Publisher first, every time**, and the top row of the contact sheet is
+what the two segments actually show. `docs/game/navigation.md` §1 and
+[`ui-title-build-map.md`](ui-title-build-map.md) stand.
+
+## Why the committed TSV says otherwise — the probe attached late
+
+`data/boot-timeline-2026-08-29.tsv` opens at `t = 0.692` with twelve
+**byte-identical** rows: mean `5.642`, `splash_dev` `+0.8707`, `splash_pub`
+`+0.0294`, to four decimals. Twelve identical samples over 1.27 s are one
+observation of a held screen, not twelve.
+
+Those exact numbers appear in my run 1 at **8.42 – 10.94 s** — same mean, same
+two correlations, same four decimals. So that capture's `t = 0` is roughly
+**7.7 s into the guest's boot**: the publisher splash had already been and gone
+before the stream opened, and the developer splash was simply the first thing the
+probe ever saw.
+
+**The label column is right about what each frame is. It is wrong about what came
+before the file starts.** Nothing in the TSV is retracted; its *reach* is.
+
+## The trap that makes this worse: `ADV.wmv` opens with a SQUARE ENIX card
+
+After the developer splash there is a black hold and then a screen that scores
+**0.59 – 0.75** against `live-splash-publisher.png` — above the classifier's
+threshold, so it is labelled `splash_pub` a second time. In all three runs:
+
+| run | second "splash_pub" |
+|---|---|
+| 1 | 17.793 → 20.301 s |
+| 2 | 16.930 → 20.664 s |
+| 3 | 14.669 → 17.308 s |
+
+The bottom row of the contact sheet is that screen. It is a **blurred, bloomed
+SQUARE ENIX wordmark, lower in the frame** — the intro movie's own opening title
+card, i.e. `ADV.wmv` ([`movie-binding.md`](movie-binding.md)) already playing.
+The real splash's wordmark is sharp and centred; the movie's is soft and sits
+below centre.
+
+⚠️ **So `splash_pub` is not a safe label once the movie has started.** A boot
+classifier keyed on `live-splash-publisher.png` will fire twice per boot. The
+discriminators that do work: the real splash holds *perfectly still* (identical
+frame statistics to four decimals for seconds at a time) and scores **0.93–0.94**;
+the movie card drifts continuously and never exceeds **0.76**.
+
+## The dwells are on the disc — do not author them
+
+Both splash bundles declare their whole life. Read with the corrected keyframe
+record layout ([`ui-keyframe-record-layout.md`](ui-keyframe-record-layout.md))
+and Q1's `1 unit = 1/60 s`:
+
+| | declared | visible span | measured (run 1 / 2 / 3) |
+|---|---|---|---|
+| publisher, `palogo_sqex.t32` | α `0@15 → 255@30 → 255@235 → 232@239 → 32@251 → 0@255` | `15 → 255` = 240 u = **4.000 s** | 4.297 / 4.604 / 4.370 s |
+| developer, `palogo_gamearts.t32` (`seta`, `anima` identical) | α `0@15 → 255@30 → 255@190 → 232@194 → 32@206 → 0@210` | `15 → 210` = 195 u = **3.250 s** | 3.508 / 3.503 / 3.366 s |
+
+Measured ÷ declared, over all six spans: **1.074, 1.151, 1.093, 1.079, 1.078,
+1.036** — mean **1.085**. A 30 Hz timeline stretched by 8.5 % is the game
+presenting at **27.6 fps**, which is the rate this corpus has measured
+independently three times (27.6 on the boot splash, 28.3 and 28.8 on the idle
+title — [`ui-keyframe-time-unit.md`](ui-keyframe-time-unit.md)).
+
+✅ **Classified decoded.** The port reads **240 units** for the publisher and
+**195 units** for the developer and authors nothing.
+
+⚠️ **Reach of the ±:** a correlation crossing a threshold during a fade is not a
+sharp edge, so an individual span is good to roughly ±0.2 s. The developer's
+first two runs agree to **5 ms**, which is the instrument at its best; run 2's
+publisher span (4.604 s) is the outlier and its onset at 1.180 s is early enough
+to be a stream still filling. The *order* does not depend on any of this.
+
+## Method
+
+`tools/re-capture/boot_timeline_probe.py`, whose `--control` was run first and
+passed **11/11** on the content classifier and **4/4** on the plate detector,
+including `live-splash-publisher.png → splash_pub` and
+`live-splash-developer.png → splash_dev` with each rejecting the other at
+**0.035**. So a 0.87 reading against the developer reference is a real match and
+not an artefact of two dark images: the two references are both dark and they do
+not correlate with each other.
+
+Both splash references are themselves committed captures whose identity is
+independent of any correlation — `live-splash-publisher.png` was matched to
+`GP_TITLE` entry 10, whose elements are literally named `palogo_sqex`, and
+`live-splash-developer.png` to entry 11, `palogo_gamearts` / `palogo_seta` /
+`palogo_anima`.
+
+Boots were cold: `/dev/shm/xenia_*` cleared, no pad input at any point.
+
+## What this does not say
+
+* Nothing here is about the **movie's** length or the attract loop; the runs were
+  cut at 26–45 s. That half is in `data/boot-timeline-2026-08-29.tsv`, whose
+  *intervals* are unaffected by the attach offset even though its absolute `t` is.
+* The 0.2–0.3 s black hold between the two splashes was not separately timed
+  against the declared `palogo_eff0.prm` backdrop; it is consistent with the
+  0.14–0.30 s black hold already measured between screens
+  ([`title-plate-delay-measured.md`](title-plate-delay-measured.md)) but that is
+  a consistency note, not a measurement of this particular gap.