[miguel-heygen]

Problem

The edit accuracy case seqheldtwice-tlhold-px-r0-nested-z100 fails now and then on unchanged code: pressJump 312.29 and tracking about 120 in some runs, 0.11 in the rest. It is a required check, so an unrelated PR can go red on it.

Cause

It is the bench, not Studio. When a press lands while the previous save is still in flight, Studio queues that drag, shows its "press waiting" marker where the box is meant to be, and replays the drag once the save lands. Until then the element itself sits at its base position. The bench already reads the marker's quad for that state while it drags (sample), but the drag step took its press baseline from the element alone. In the failing runs that read was 312 px from the released position (the move's own vector), and the next drag path was planned from it, which is where the 120 px tracking error comes from.

A user cannot see this. In the failing runs the painted frames, with the marker counted, show the move continuous at 0.07 px; the element's own 312 px jump (measured element-only) is under the marker. The bench is the only reader of the bare element.

Fix

The drag step's baseline is now the shown box: the marker's quad while a press waits, else the element. It is the same read sample uses, now one function (measureShown), with the same guard against a marker that is removed between the two reads. The press still lands with the earlier save in flight, which is what the case is for: the save count at the second resize is 1 in 29 of the 30 runs below, 2 in the other.

Repro counts (case alone, 2-CPU Linux box)

• Before: 6 failures in 37 runs, all with pressJump 312.29 (several runs stopped at the first failure).
• After, on this head: 30 of 30 pass the gate's verdict, pressJump at most 0.11.
• A first version of this change waited for the box to reach the released position before pressing. It passed 20 of 20 too, but it made the press land after the save, which defeats the case, so it is not what is here.

Test

settle.test.mjs covers measureShown: it reads the marker while a press waits (red if the marker is ignored), the element when nothing waits, and reads again when the replay removed the marker between the two reads.

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 124 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

Unstable (1)

• seqplainkeys-none-pct-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE · 0 blocker · 1 important · 0 nits · head 607f0a70

The change is test-only, CI is green on this head (edit accuracy 5/5 shards and the gate pass), and the wait still returns the box as read when it never arrives, so a real miss still fails. One important point is inline: on an element switch the wait compares against the other element's box.

[heygengenesis]

Verdict: APPROVE — 1 resolved, 0 open, 0 new · 607f0a70 → 49f5d7e0

The wait-for-position approach and its per-element intended issue are gone. The press baseline now reuses sample's marker-aware read. The page-wide marker lookup could hand one element's marker to the other in ab, but selectTarget re-reads with plain measure on an element switch, so that can't happen. One of the two CI runs on this head failed Studio: timeline viewport gate (not required); the other run on the same SHA passed it, along with the edit accuracy gate.

[miguel-heygen]

Folded into #6392 (the lane's PRs under 100 lines are bundled). Same commit, same counts; follow it there.