9a3c7535

fix(wan): the authoritative clock was timing the wrong thing

a73x   2026-08-08 17:49

fix(wan): the authoritative clock was timing the wrong thing

predictauth searched the whole capture buffer, so rep 0's one-character
needle matched the shell's echo of the `cat` typed during setup and stopped
the clock at once. That is where the record's 0.3ms minimum came from: not a
fast round trip, a needle that was already on screen.

Two faults, both fixed. The search starts from the keystroke now, like the
other two clocks. And rep 0 contributes no authoritative sample at all,
because a one-character needle is a substring of the prediction's own
ESC[4mX paint — searching from the right place would still have timed the
prediction instead of the echo. Nineteen samples for twenty keystrokes, and
the reason is written where the sample is dropped.

Re-run on the box confirms it: predictauth min goes 0.3 -> 154.0, agreeing
with predictoff, which measures the same physical quantity by an
independent route. That agreement is the check that the new number is right
and the old one never was.

Also: an absent control now FAILS leg 1 rather than being skipped. The gate
existed for a control that comes back too fast; a control that is not there
at all is the same hole and was not covered. Both controls are required to
be present and slow before leg 1 can pass, and the leg prints its own PASS
line rather than implying it.

Record corrected from the new run throughout, including the burst counters
(made=55, one abandoned by the mode-transition flush as `cat` starts), and
the reps this run actually used, so every n in the table follows from
something written down. "One keystroke, two clocks" moves to the pair it
describes — the predicted and authoritative times share a keypress; the
unpredicted control does not and never claimed to.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>