Their audit found one defect in sixteen commands and their point that doing one
and stopping is the failure applies to me: I had fixed verify-screen and
verify-capture and gone no further.
Hit 1: verify-dwell built its target as oracle span + the GAME's black gap and
scored the port against it, correct only while the port inserted that gap. It does
not -- black_hold_units went to 0. On publisher_logo the port runs 0.131 s below
the unslacked target, absorbed into an 'agrees' by 0.15 s of slack that is larger
than the omission it hides. Hold now read from authored/timing.json; the game's
gap printed as its own term.
Hit 2: the tool carried '4 presented frames at 2.284 units/frame'. The number is
right but it is the disc used as its own clock on ONE capture that ran at 13.1 fps
against ~28 elsewhere. Stated bare it reads as a general rate and would contradict
Q1's 2 units per rendered frame, a different quantity at normal speed. The
derivation was in DECISIONS.md; the tool inherited the value alone -- exactly
their defect, and their 'print the population beside the number' fix applies
unmodified.
Not found elsewhere: check-capture's percentages all name their population;
check-claims, check-modding, index-decisions and strip-padding assert no measured
quantities.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
fe01c3e221