ElyOffice/tasks/reviews/R5.3-r2.md

FAIL

• [P1] crates/ely-lok/src/view/borders.rs:115 — The table snapshot still receives the latest view revision rather than its supplying batch's revision. apply_batch first calls seen_revision, which keeps the maximum because input completions and event batches can arrive out of order. Reproduce: receive a two-column table at revision 1, insert a column and process its revision-2 input completion, then apply the delayed revision-1 batch and drag its inner border. The kernel probe moved the new table's border from 3324 to 3624 twips without a stale error. Holding geometry through subsequent updates fixes round one's active-drag case, but this ordering still violates R5.3's read-revision requirement. Store the exact supplying batch.revision with the geometry, independently of the latest view revision, and add an out-of-order batch/completion regression. Evidence: .work/R5.3-r2/probes.log.

• [P2] crates/ely-lok/src/view/input.rs:337 — Releasing a border ignores event.position and commits the last position received by on_mouse_move. GPUI only dispatches that move handler while the pointer is over the canvas, so dragging outside freezes the guide and commits the wrong width. Reproduce with a 450-pixel canvas: hold the inner column border at x=426.87, move to x=440, continue outside to x=480, then release. Dispatching through the same GPUI registrations and actual LokView handlers leaves the guide at x=440 and commits 5182 twips instead of the release position's 5782. Track pointer movement throughout the held drag and apply the release coordinates before issuing the single border command; cover release outside the canvas with an event-dispatch regression. Evidence: .work/R5.3-r2/probes.log.