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
8477242656