From 0583b15fba739e91c7b06beba1719c1dbcb3914c Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 17:22:06 +0000 Subject: [PATCH] port: verify the boot as a sequence -- path, timing and endpoint Twice I wrote that the boot's 0.00% agreement is one frame, the last one, and the boot could take a wrong path and still land correctly. Closed, with no new capture and no new feature. --boot --shots= writes nothing: _shots is wired to the --script path only. I was about to build stepwise boot photography; the trace and verify-dwell already answer the question, so I did not. Path: the boot logs its transitions, and they match authored/flow.json's declared sequence exactly -- publisher_logo, developer_logos at 4.26 s, video ADV at 7.78, title at 152.54 with the overlay raised at the same instant, ending 156.48. Timing: verify-dwell against the Decoder's three cold boots gives publisher 4.28 s against 4.297/4.604/4.370 and developer 3.58 against 3.508/3.503/3.366, both agreeing. And authored/flow.json's dwell is EMPTY by design -- the dwell is declared and the port plays it -- so these are disc-derived timings agreeing with three cold boots of the real game with no authored constant between them. So the shipped artefact is verified on three axes: path from the trace, timing against the oracle, final frame at 0.00% differing. Still unverified: the intermediate frames themselves, and the 144.76 s video beyond the fact it plays. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 60 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 6e5c86bb..3ad8fbec 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -189 sections. Search this before re-deriving anything. +190 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -200,6 +200,7 @@ dies, which is what this file is for. * [Their linearity gate, applied to my side of the ratio — and an inversion](#their-linearity-gate-applied-to-my-side-of-the-ratio--and-an-inversion) * [The leaf thread, closed — one export value verified against the game, one self-check abandoned](#the-leaf-thread-closed--one-export-value-verified-against-the-game-one-self-check-abandoned) * [Delivering the phase term where the numbers are, not where I found them](#delivering-the-phase-term-where-the-numbers-are-not-where-i-found-them) +* [The boot verified as a *sequence*, not just at its endpoint](#the-boot-verified-as-a-sequence-not-just-at-its-endpoint) ## P0 — the exporter, 2026-08-28 @@ -10719,3 +10720,60 @@ sourced to their sha, so my tree does not depend on a HANDOFF I cannot see. ⚠️ This is the second structural consequence of `main` being stale, after the `Cargo.toml` pin being load-bearing. Both are recorded rather than worked around. + +## The boot verified as a *sequence*, not just at its endpoint + +I have twice written that the boot's 0.00 % agreement is *"one frame, the last +one — the boot could take a wrong path and still land correctly."* Closing that, +and it needed no new capture and no new feature. + +⚠️ **`--boot --shots=` writes nothing.** `_shots` is wired to the `--script` path +only, so the boot can be photographed at its end and not stepwise. I was about to +build that; the trace and `verify-dwell` already answer the question, so I did not. + +### The path + +The boot logs its own transitions. Trace against `authored/flow.json`'s declared +sequence: + +| declared | observed | +|---|---| +| 1. `publisher_logo` | start, settles t=30 | +| 2. `developer_logos` | → at **4.26 s** | +| 3. video `ADV` | → at **7.78 s** (+ voice ADV) | +| 4. `title` + overlay `press_start` | → at **152.54 s**, overlay raised same instant | +| | boot ends **156.48 s** | + +✅ Four declared steps, four observed, in order, with the overlay raised on the +step that declares it. + +### The timings, and they are not authored + +`verify-dwell` against the Decoder's three cold boots: + +| screen | port | oracle (3 boots) | | +|---|---|---|---| +| publisher wordmark | 4.28 s | 4.297 / 4.604 / 4.370 | **agrees** | +| developer logos | 3.58 s | 3.508 / 3.503 / 3.366 | **agrees** | + +📌 **`authored/flow.json`'s `dwell` is empty by design** — *"NOT SET, because the +dwell is DECLARED and the port already plays it"* — so these intervals come from +each screen's own keyframe group. **Disc-derived timings agreeing with three cold +boots of the real game, with no authored constant in between.** + +### So the shipped artefact is verified on three axes + +**Path** from the trace, **timing** from `verify-dwell` against the oracle, **final +frame** at 0.00 % differing against `live-title-press-a.png`. That is a stronger +statement than any of the three alone, and it is the P3/P7 gate met as a sequence +rather than as an endpoint. + +⚠️ Still not verified: the *intermediate frames*. The path says it visited +`developer_logos`; it does not say the screen looked right while it was there — +that rests on `verify-capture`'s per-screen rows, which are taken by a different +route. And the 144.76 s video is unexamined beyond playing. + +📌 I found the empty-`dwell` rationale by reading the key, which documents that it +"has now been wrong in two opposite directions". **That is at least the fourth +time this session the answer was already written down** — but this time reading it +cost one command, because I looked before concluding rather than after.