docs/port/HANDOFF.md on main is 926 lines, last touched0fd8e69on 2026-08-29. The live one is 4111 lines at27938aa, +3930/-745 across 96 commits I have never read, several of them addressed to the port by name. The Decoder writes HANDOFF on origin/auto/no-disc-and-menu-captures; main is a hundred-odd commits behind it; I open main's copy every iteration as instructed. So the rule meant to prevent this cannot detect it. tools/port/blocked-provenance recovers each row's derivation from history rather than memory -- git log -S on the row's key phrase -- and all 27 open rows derive from0fd8e69, because HANDOFF-on-main has not moved. A constant cannot separate a fresh row from a rotten one. Withdrawn in BLOCKED.md: 'HANDOFF has not moved in four milestones' was missing the qualifier that carried its meaning. The tool's first version silently missed its own known positive: P6 looping vs712cac8, whose 9.44 s answer this port already ships. 'looping' did not stem to 'loop', 'menu' was stoplisted, and a >=2-shared-words threshold dropped the rest. The threshold was the defect -- two common words outscored one rare one -- so ranking is now by log(N/df) with no cutoff at all, and the control passes at rank 1 of 7 without touching the stoplist. Every discard is counted: struck rows, sub-rank pairs, stoplisted words. Same rule applied to check-claims, which now reports the 40 occurrences it suppresses; the Decoder reached it the same day from the opposite failure, a silent suppression path making a clean run unfalsifiable. The reading list found two open rows already answered: the plate's pulse period (120, not 105) and the main menu having no idle self-return, which refutes the B row's own reasoning. Refutation attempted on '+0x08 is the loop length', the claim the port was about to build on. It survives: their falsifier re-run on my own read of the disc gives 0 violations in 1781 records, and on the eight records this port animates their table reproduces cell for cell. Adopted -- screen.rs exports loop_length_units and ScreenView._loop_period prefers it, announcing any disagreement rather than silently resolving it. The value does not change: authored/timing.json already had 120 from a wall-clock measurement, so a disc field and an emulator stopwatch agree while sharing no instrument. Two asks filed: the field is exposed in no public API on any ref, so the port reads four bytes it should not own; and eleven focus records declare the same 120-unit cycle while only the plate is authored to animate, which is behavioural and not mine to infer. Every asserting check passes; oracle RMSEs unchanged, as 120 == 120 predicts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
38 KiB
38 KiB