Rows 1 and 2 were still labelled '(P3, blocking)' while P3-P7 have all shipped.
Audited all five against HANDOFF and checked whether the port ACTED on each
answer: splash by entry index (publisher_logo 10/13 exported), focus ring
ptbtneff01 drawn, rotation about pos+pivot, gamma floor in verify-capture's
header. Four struck, one (rotation) still a human decision.
HANDOFF ask 2 tells the port to author a ~24-unit fade constant. That is stale:
the corrected record layout leaves no untimed keyframe, and measuring what the
file carries shows the black quad ramping 0->255 over TEN units. Authoring 24 on
top of it would run the fade 2.4x too long. The mechanism ask 2 describes is
confirmed in the file; its number is not.
Offered as a hypothesis, not a finding: in-file ramp 10 + measured hold 10-14 =
20-24 units = 0.33-0.40 s, bracketing the measured 0.4 s at the top -- so the
0.4 s may be ramp + hold, needing no constant at all.
Also surfaces a disagreement in my own tree: black_hold_units 9 (0.15 s) sits
below HANDOFF's measured 0.17-0.23 s plateau. Not changed; recorded as an ask.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
b2b8b76151