7e79ec11e01e7ae144116bfdf6e290353dcdec9a
docs/REVIEW-2026-09-07.md's D5. Four places quoted 11750 px/s as the old average estimator's answer -- for `flick-120hz.touch` *and* for the press-plus-one-move-frame set, which are different sample sets, and one number in both rows is the tell. `iris/benches/velocity_reference.py`, which the same section says every number below it comes from, prints 12250 for the recording and 12500 for the two-sample set, and `sense.rs:1406` already had the 12250. Half of where 11750 came from is recoverable and is written down beside the table: it is the recording's 196 px over 16.68 ms, a 60 Hz frame rather than the 16 ms span the file itself records. That explains the flick row; the other row was copied from it. The 1.30x ratio derived from it becomes 1.24x. Also settles the second disagreement about the same experiment (the review's rule finding on the negative control): `sense.rs`'s doc comment claimed reverting `velocity` to total-over-span fails "exactly this one, the flick recording, and phone_screen.rs" while RUST.md said seven. Run again today with the revert in place: seven in `-p iris` (the flick recording, the accelerating flick, the horizon, the stopped finger, the minimum sample count, both `drag_gesture` flick tests) plus `phone_screen.rs`'s flick, everything else green. RUST.md was right and the comment now says the same thing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Languages
Rust
53%
Kotlin
44.4%
Shell
2.6%