port: the phase result does not replicate, and the failure reframes it

The Decoder established ptloop01/02 and their leaves are identical on entries 4, 5
and 7; confirmed against my export on every field. That makes replication
well-posed: same object, different screen, different capture.

main_menu minimises at 0 units (13.2059); title minimises at 240 (13.9417), with 0
at 14.1604. Spread 1.025 on the title, 18x the 0.0565 floor, so both sweeps are
decisive and they decisively disagree.

The meaning: the leaf free-runs in the game too, so each capture froze it wherever
it happened to be. The phase that best matches a capture is a property of when the
shutter fell, not of the game's rest state -- a continuously sweeping element has
no canonical rest phase to find. My 'phase 0 is the measured best of the cycle'
was measuring the capture, not the game. The hedge I attached was the right
caveat for the wrong reason: I framed a well-located property of a photograph as a
weakly-located property of the game.

Phase 0 stays pinned as a harness convention. NOT tuning it per screen -- 0 for
main_menu and 240 for title would minimise both and would be fitting each
capture's shutter moment, making the harness agree with the oracle by
construction.

Every row with a sweeping leaf now carries an irreducible capture-phase term of up
to ~1.0 RMSE, larger than most margins quoted from those rows.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 16:02:49 +00:00
parent a860040f2f
commit 7fe318356c

View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
177 sections. Search this before re-deriving anything.
178 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)
@@ -188,6 +188,7 @@ dies, which is what this file is for.
* [🔴 The third clock was in my own list, and I did not wire it](#the-third-clock-was-in-my-own-list-and-i-did-not-wire-it)
* [The leaf phase was an arbitrary choice; the capture turns out to determine it](#the-leaf-phase-was-an-arbitrary-choice-the-capture-turns-out-to-determine-it)
* [Cross-checking their leaf reading against my export — it reconciles](#cross-checking-their-leaf-reading-against-my-export--it-reconciles)
* [Replicating the phase result on the title — it fails, and the failure is the finding](#replicating-the-phase-result-on-the-title--it-fails-and-the-failure-is-the-finding)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -10118,3 +10119,52 @@ nothing, which is what they withdrew.
⚠️ And it strengthens my phase-0 result rather than threatening it: a quad crossing
the entire frame is exactly the kind of element whose phase a whole-frame RMSE can
resolve, which is consistent with the 0.5 spread I measured against a 0.0565 floor.
## Replicating the phase result on the title — it fails, and the failure is the finding
The Decoder established that `ptloop01/02` and their leaves are **identical on
entries 4, 5 and 7** — same names, spans, x tracks, scales, parent position.
✅ Confirmed against my export, all three screens, every field. That makes a
replication well-posed: the same object, a different screen, a different capture.
| leaf phase | `main_menu` vs its capture | `title` vs its capture |
|---|---|---|
| 0 units | **13.2059** ← min | 14.1604 |
| 60 | — | 14.0910 |
| 120 | 13.7044 | 14.2571 |
| **240** | 13.6486 | **13.9417** ← min |
| 360 | 14.0826 | 14.5409 |
| 480 | 13.9055 | 14.9667 |
| 600 | 13.2065 | 14.1611 |
🔴 **Different minima for the same object.** Spread 1.025 on the title, 18× the
0.0565 floor, so both sweeps are decisive and they decisively disagree.
### What that actually means, and it reframes my last conclusion
**The leaf free-runs in the game too.** Each capture froze it wherever it happened
to be. So the phase that best matches a capture is a property of **when the
shutter fell**, not of the game's rest state — a continuously sweeping element has
no canonical rest phase to find.
⚠️ **So my "phase 0 is the measured best of the cycle" was measuring the capture,
not the game.** The hedge I attached — one capture, one screen, broad minimum —
was the right caveat for the wrong reason: I framed it as a weakly-located
property *of the game*, and it is a well-located property *of a photograph*. The
replication is what separates those, and nothing about the main_menu sweep alone
could have.
### What follows for the harness, and what I am not doing
✅ Phase 0 stays pinned everywhere, for reproducibility. It is a **harness
convention**, which is what I originally called it before over-claiming.
🔴 **I am not tuning the pin per screen.** Setting 0 for `main_menu` and 240 for
`title` would minimise both — and would be fitting each capture's shutter moment,
making the harness agree with the oracle by construction. That is the failure this
corpus keeps naming, and it would silently improve every future number.
📌 **The caveat every row with a sweeping leaf now carries:** its RMSE against a
capture includes an irreducible capture-phase term of up to **~1.0 RMSE**, larger
than most margins I have quoted from those rows. `title` at 14.16 is not 0.22
"worse" than it could be — 13.94 is not more correct, it is differently posed.