Workstation grid may stop repainting after splitter drag

Context

During a headed Workstation film run, the operator observed the visible grid stop updating after moving the layout. The current hypothesis is narrower: the first real splitter drag may leave grid repainting permanently stalled. The observation is real; the causal link is not yet confirmed because no trace was captured.

The existing WorkstationNL.spec.mjs witness drags a real horizontal DockSplitter, then proves pane/Store identity, Store growth, and one Canvas-cell mutation. It does not assert that a visible grid row or cell repaints after that drag, so it neither confirms nor clears this symptom.

The Problem

A worker-side Store can remain live while the rendered grid becomes stale. Current coverage conflates three truths that must be measured separately:

1. the Store accepts a post-drag mutation;
2. the same grid/pane identity survives re-projection;
3. the exact visible row/cell paints the new value.

If only (1) and (2) hold, the film can show a frozen grid while its backend receipts remain green.

The Architectural Reality

• DockSplitter.onDragEnd() re-enables its parent and commits resizeSplit.
• Workspace.onDockZoneDocumentChange() queues a deferred, geometry-only DockProjectionReconciler refresh for that operation.
• Workspace.appendFeedBatch() mutates the provider-owned feed Store through store.add(records).
• FeedPane and ScalePane are framework grid.Container consumers; the defect, if reproduced, may belong to resize/rebinding/reconciliation rather than the Store.

Closed ticket #14985 repaired an earlier stale-DOM geometry family. It is prior art, not evidence that this symptom shares that cause.

The Fix

Start with one bounded headed whitebox witness:

1. mutate a visible grid record and prove the Store value plus exact rendered cell change before dragging;
2. perform a real pointer drag on the projected splitter and await the committed document plus refresh/FLIP settlement;
3. mutate the same visible record (and/or append one uniquely identifiable feed record);
4. require both Store truth and the exact rendered row/cell to change afterward.

If the post-drag control fails, repair the owning lifecycle seam. Do not add screenplay delays or weaken the DOM oracle. If repeated controls stay green, close this hypothesis with the falsifying receipt and retain any generally useful coverage.

Acceptance Criteria

• A headed witness separates pre-drag control, committed splitter drag, post-drag Store mutation, and post-drag DOM repaint.
• The witness records both worker-side Store truth and exact visible row/cell truth.
• Reproduced stalls are fixed at the owning grid/dock lifecycle seam; no timing-only workaround.
• Pane, Store, and rendered-grid identities remain stable across the drag.
• Relevant Workstation and grid suites remain green.

Out of Scope

• Preview-indicator and popup witnesses owned by #16341
• Film pacing or visual-polish changes
• Treating a Store count change alone as rendered-grid proof

Decision Record impact

none — regression investigation and witness.

Related

Related: #16341 · #15252 · closed prior-art #14985

Live latest-open sweep: checked the latest 20 open issues on 2026-08-02 at approximately 13:17Z; no equivalent found. Semantic KB and exact GitHub/local searches found only adjacent prior art. Recent all-state A2A claim sweep found no competing grid/splitter lane.

Retrieval Hint: Workstation visible grid stale after DockSplitter resizeSplit Store remains live