port: accept the plateau correction, and census my own rest-transient exposure

The Decoder refuted my refinement: palogo_gamearts_eff/palogo_seta_eff hold a=255
at identical x, y and scale from t=15 to t=30, so that is a genuine plateau,
rest_plateau() handles it, and t=15 is correct for that path. They are not among
their four.

The consequence strengthens the rule rather than retracting it: my rest pose for
them really is the flash's peak, reached by the SOUND path -- so 'a rest render is
not a frame to score against a capture' does not depend on the fallback being
unsound. A plateau can itself be the held peak of a transient, and their census
understates exposure rather than bounding it.

Censused my own tree. The first answer, 28 elements across 12 screens, was wrong:
it counted the screen's exit ramp as the end of visibility, so ptmsg -- the main
menu's own footer -- and ptbtn00, the plate, came back as transients. No control
would have caught that; the arithmetic was right. What caught it was saying what
the number meant physically.

Re-keyed on the screen's span: 31 elements across 8 of 16 screens, all of them
eff/loop sparkles or the two loading screens, with ptmsg and ptbtn00 falling out
on their own. Exposure is twice what the splash finding suggested. None of it
reaches shipped output.

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 12:07:48 +00:00
parent 9233ff1e08
commit f486aac4b9

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 -->
150 sections. Search this before re-deriving anything.
151 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)
@@ -161,6 +161,7 @@ dies, which is what this file is for.
* [The JP title capture adjudicates `title_jp` — and it goes against the port](#the-jp-title-capture-adjudicates-title_jp--and-it-goes-against-the-port)
* [🔴 CORRECTION: the port did not move away from the game — I scored the wrong frame](#correction-the-port-did-not-move-away-from-the-game--i-scored-the-wrong-frame)
* [The `rest()` flash defect reaches four screens I ship — and the port already survives it](#the-rest-flash-defect-reaches-four-screens-i-ship--and-the-port-already-survives-it)
* [Correction: those two are the *sound* path, which makes the rule stronger](#correction-those-two-are-the-sound-path-which-makes-the-rule-stronger)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -8753,3 +8754,53 @@ waiting to be believed. It now names the instant: `transparent at t=6`.
Controlled both ways on one screen: timeline → `transparent at t=6` and the flash
skipped; `--pose=rest` → still `at rest`, and the flash **drawn**.
## Correction: those two are the *sound* path, which makes the rule stronger
The Decoder refuted my refinement, and it is a correction I would rather have than
the credit. I wrote that `palogo_gamearts_eff` / `palogo_seta_eff` show "the same
defect, worse pose — their fallback lands on the flash's peak". **Wrong on the
mechanism.** They hold `a=255` at identical x, y *and scale* from t=15 to t=30 —
a genuine plateau at pair index 1, which `rest_plateau()` handles, and t=15 is
the **correct** answer for that path. They are not among their census's four.
🔴 **And the consequence runs the other way from a retraction.** My rest pose for
them really is the flash's peak, reached by the **sound** path. So *"a rest render
is not a frame to score against a capture"* does **not** depend on the fallback
being unsound: **a plateau can itself be the held peak of a transient.** The
2 305 / 1 697 census *understates* the exposure rather than bounding it.
### Censusing my own tree — and the first answer was wrong
I asked how many elements I ship whose `rest` is visible but whose visibility is
transient. First pass keyed "transient" on the element's own visible span, and
returned **28 across 12 of 16 screens** — a plausible-looking number.
🔴 It was wrong, and what caught it was the check the Decoder and I just agreed
on: **say what the number means physically.** The list included `ptmsg` — the main
menu's own `⊙ Select Ⓐ OK` footer — as "visible 2 of 64 units", and `ptbtn00`,
the `PRESS Ⓐ` plate. Those are on screen the whole time the game sits there. The
story collapses on contact.
The cause: `ptmsg` is `[0:a0 44:a0 56:a255 58:a255 64:a0]`, and that final zero is
the **screen's exit ramp**, which *every* element has. I had counted the exit as
the end of visibility, so every normal element looked like a flash. No control
would have caught this — the arithmetic was right.
✅ Re-keyed on the **screen's** span rather than the element's: a transient is
gone while the screen is still up.
| | |
|---|---|
| elements whose `rest` shows what the settled screen does not | **31** |
| screens affected | **8 of 16** |
Every entry now has a coherent story — `*eff*` and `*loop*` sparkles, plus the two
loading screens — and `ptmsg`/`ptbtn00` fall out on their own, which is the check
passing rather than being applied by hand.
📌 **My exposure is twice what the splash finding suggested.** Not four screens,
eight — both titles, both splashes and their region twins, and both loading
screens. ✅ None of it reaches shipped output: the port poses `pose_at(hold)` and
agrees with every capture it has. The number bounds what would break the day
anything scored a `rest` frame against an oracle.