port: a check that measures CHANGE, run against the defect it was written for

Closes the two items the play-test left after the fix landed.

1. tools/port/verify-motion, wired into check-all with its control.

It films a REAL boot -- no --time, no pinning -- and hands it to
tools/motion-census. The window is the DECLARED build-in (publisher t=0..45,
0.75 s at 60 units/s), so it asks about the interval the disc says is animating
and nothing else.

🔴 BOTH SIDES MEASURED, not one measured and one assumed. I reverted the single
operator in pose_at, ran this check against the defect, and restored it:

  broken (ASSIGNS the settle instant)   40 %   and it FAILED
  fixed  (clamps to it)                 86 %   and it passed

The bar of 60 sits mid-gap: 20 points above the defect, 26 below the fix.

🔴 AND MY FIRST VERSION OF THAT BAR WAS JUSTIFIED BY A NUMBER I HAD NOT
MEASURED. It claimed "~40 points of clearance on both sides"; with a 1.0 s
window the real clearance was 5 points, because that window includes 0.25 s of
legitimate hold and dilutes the signal. A bar defended by an unmeasured number
is this whole check's own defect, one level up. Corrected with the measurements
and the sequence stated.

The control runs FIRST and is not optional: motion-census --selftest drives a
fade, a switch and a frozen film through the same loader and floor. If it cannot
separate those three, every number the check reports is decoration. Then the
--control mode builds a frozen film from the port's own pixels -- one real boot
frame repeated -- and requires it to FAIL. It scores 0 %.

One defect in the check itself, caught by running it: `ls | head` under
`set -o pipefail` exits 141 before asserting anything, and a check that dies
before checking looks a lot like a check that passed.

2. BLOCKED.md H2 corrected from ✅ to 🟡, against myself.

The MECHANISM half stands -- no post-process pass, the blur is a baked companion
texture. The BEHAVIOUR half was false and the row asserted it: I wrote "the port
draws all seven quads -- verified by a frozen sweep". True, and it did not mean
what I used it for. A frozen sweep drives the clock BY HAND. It proves the
renderer can draw pose N and says nothing about the poses being drawn in
sequence while running.

All three of my instruments passed the defect -- frozen sweep, a 0.01 % settled
comparison (a frozen screen matches a settled reference PERFECTLY), and an
achieved-fps counter (identical pixels 25x/s score like animating). Every one
measured throughput or a pose; none measured CHANGE. Same shape as
InputEventAction bypassing the input map.

Not settled: the ~1.0-1.2 menu residual; findings 3 and 4's remaining halves.
Both were explicitly deferred by the human until this was fixed, and it now is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-02 16:00:57 +00:00
parent 08ed3dd17e
commit 8477242656
3 changed files with 161 additions and 1 deletions

View File

@@ -105,7 +105,7 @@ method finding that applies to the Decoder's harness as much as this one:
| # | ask | why the port cannot answer it |
|---|---|---|
| **H1** | 🟢 **PARTLY ANSWERED 2026-09-01 and the port has adopted the half that landed.** The game **digitises the left stick to four direction bits at 61 % deflection** and never sees a velocity (`input-button-numbering-is-remapped.md`). `Gamepad.ENTER` moves **0.5 → 0.61**: 0.5 was a *floor* (Godot's `ui_*` action deadzone), 0.61 is the game's own threshold, and between them Godot reports a direction the real game does not. Asserted at the device level in `tools/port/verify-input`. **Still open: does a held direction REPEAT, and at what rate** — one step per deflection remains authored, and the digitise-to-bits mechanism corroborates that a rate cannot come from this layer. | 🔴 **The 0.11 hysteresis gap stays AUTHORED** — nothing measured says the game has hysteresis at all. ⚠️ **A human chose 0.5 and 0.61 changes how the stick feels**; revert that one constant if it reads as needing too much push. ✅ And I never consumed the mislabelled pad bit table — checked by grep over `port/`, `authored/` and `tools/port/`, not remembered. |
| **H2** | ✅ **ANSWERED 2026-09-01, and the port's own premise was wrong.** The Decoder found **no post-process pass** on either splash (`auto/frame-blend-draw-path` `3cc1b51`). The blur is **in the asset**: every logo ships a pre-blurred copy ~21×20 px larger and concentric, drawn alone first and crossfaded out as the sharp logo fades in — which is the human's *"blurred to clear/sharp, in about a second"*, with no shader. | 🔴 **"The port applies no blur at all" was FALSE and this page said it.** The port draws all seven quads of the developer splash, the three companions included, and always has. Verified by a frozen sweep, 3 units a step: companions alone at u=3–15, all seven at u=18–42, sharp only from u=45. Writing down what the renderer was *believed* to do instead of running it is what produced the claim. What remains is the **extent**, and it is the same unit question as H3 — asked there, once. See [`plate-arrival-halves.md`](plate-arrival-halves.md). |
| **H2** | 🟡 **HALF-ANSWERED, AND I MARKED IT ✅ ON EVIDENCE THAT COULD NOT BEAR IT.** The **mechanism** half stands and is the Decoder's: no post-process pass, the blur is a baked companion texture ~21×20 px larger, crossfaded out as the sharp logo fades in. Decoded, correct, unchanged. | 🔴 **The BEHAVIOUR half was false and this row asserted it.** I wrote *"the port draws all seven quads — verified by a frozen sweep, 3 units a step"*. True, and it did not mean what I used it for: **a frozen sweep drives the clock by hand.** It proves the renderer CAN draw pose N; it says nothing about whether the poses are drawn in sequence while running. They were not — `pose_at` **assigned** the settle instant instead of clamping to it, so every element sat at its settled pose from a screen's first frame and no build-in was ever drawn. A human on a 140 fps GPU saw it in one boot: *"the logos just switch."* ⚠️ **All three of my instruments passed it** — frozen sweep, a 0.01 % settled comparison (a frozen screen matches a settled reference *perfectly*), and an achieved-fps counter (identical pixels 25×/s score like animating). Every one measured throughput or a pose; **none measured CHANGE**, which is the same shape as `InputEventAction` bypassing the input map. Fixed and gated by a film: build-in motion 40 % → 86 %, distinct luma states 120 → 152, splash motion 12 % → 24.8 % against the game's 21.2/27.8 %, with the 3.30 s hold unchanged because the Decoder measured the game holding 3.34 s. `tools/port/verify-motion` is now in `check-all` and was run against the reverted defect to confirm it fails on it. |
| **H3** | ✅ **CLOSED 2026-09-01. ALL FOUR NAMED CAUSES ARE DEAD AND THE HUMAN'S OBSERVATION IS NOT — recorded that way deliberately rather than left green.** The rate is **56.8 units per guest second**, measured, control at 1.15 %, two elements agreeing at one clock (`units-per-second-measured.md`). 30 and 120 both excluded. At 56.8 the plate's t=236 lands at **4.15 s** against the port's 3.93 s — the port is fractionally **early**. | Eliminated in order: `rest.t` (the arrival is a declared keyframe), the clock origin (85/85 filmed frames share one clock), the anchor (answered t=160, and `clock: "shared"` survives it), the unit constant (56.8). 🔴 **`units = 2 × frames` is dead as a route** — the same animation takes 21 labels in one capture and 33 in another. ✅ Audited: this port never used it; `boot.gd` integrates `delta * units_per_second`, so the retirement cost a *justification* in `authored/timing.json` and not a behaviour, and that file's second leg (12 declared units against a 0.14–0.30 s black plateau = 40–86 units/s) has no frames in the chain. **60 units/s is KEPT** — 56.8 is 5.6 % away against ~5 % quantisation and the Decoder did not ask for a move. ⚠️ Reach is the **title**; the splashes are a different `GamePart`. What the human saw is now unattributed — see [`plate-arrival-halves.md`](plate-arrival-halves.md) for the two remaining candidates, of which the strongest is that **Ⓐ was unbound on the play-test build so that human could not skip the 137 s intro**, and the run they judged is not the run any of these measurements describes. |
🟡 **A LIVE CANDIDATE FOR FINDING 4, ADDED 2026-09-01, AND IT IS THE PORT'S NOT