Resolves #17409

During a column resize drag the body moved and the header did not. Every column after the resized one showed its cells offset by the drag delta for the whole gesture, then snapped back on mouseup — which is why it survived a closure: the defect ends exactly when the gesture ends.

onDragMove (Resizable.mjs:38) already moved the body live via updateCellPositions() — neomjs/neo#17289's fix, working as designed. The header had no live path; it only corrected itself in onDragEnd.

Evidence: L3 (live Chromium, instrumented mid-drag reads from the app worker, four-case red-proof, full-suite stash controls) → L3 required (the defect exists only while a real pointer gesture is held open and is invisible to any state sampled after it).

The config was never the problem

Instrumented inside onDragMove and read from the app worker while the drag was held:

wrapperStyle carries an inline width that outranks the vdom width key afterSetWidth() maintains, and nothing refreshes it mid-drag. onDragEnd spreads the proxy's wrapperStyle onto the owner — which is precisely why the header only ever corrected itself on drop.

The fix keeps wrapperStyle in step one frame at a time, doing during the gesture what drag-end already did after it. Ten lines, one file.

Two hypotheses eliminated first, by experiment rather than by reading:

1. The update is missing. It is not — afterSetWidth → changeVdomRootKey → me.update() runs, and adding an explicit owner.parent?.update() changed nothing (still 12 of 15 columns misaligned, button still 150px).
2. The update is parked. It is not — at the moment of the set, needsVdomUpdate and isVdomUpdating are false on the button and on every ancestor up to the viewport, with silentVdomUpdate: 0, mounted and vnode-initialized.

The spec gap that let this ship

Closed in the file that owns the driver rather than in a new one.

• HeaderCellRectSync asserts at mid-drag hold points — but its only gesture is a reorder, and createSortZone sets ignoreDragSelector: '.neo-resizable', so it provably cannot reach the resize path.
• HeaderResizeRectSync drives the resize — but asserted only after the drop, and said so in its own @summary.

Resize × mid-drag was the one uncovered quadrant. The defect lived in it. resizeColumn() now takes an onHold callback; a new case asserts alignment with the button still down, in both directions, with a non-vacuity guard that the header had already widened at the hold point.

Test Evidence

Red-proof — source fix stashed, spec kept. The new case fails alone:

✘ the header tracks the drag, not only the drop
    DURING the widen drag, button still down: visible header/cell count parity
    headers=[… {"text":"Number 7","x":911,"w":100} …]   14 entries
    cells  =[… {"id":"cell-7","x":911,"w":257} …]       13 entries
✓ widening a column moves its cells with it
✓ narrowing a column moves its cells with it
✓ a flex column beside explicit ones does not drag the others onto a stale measurement
✓ resizing a centre column leaves the locked regions untouched

The four pre-existing cases staying green is the point — they could not see this.

Independent measurement across both apps, +200px drag, misaligned columns while held:

neo-is-resizing dimming is preserved and verified, not assumed: opacity reads 1 → 0.3 → 1 across the gesture, and the class is still on the toolbar mid-drag.

grid unit    65 passed
grid e2e     31 passed, 3 failed
target spec  5 passed

All three e2e failures reproduce with this change stashed, established by re-running the full directory on the unmodified tree rather than by arguing they were unrelated: GridViewFocus, TreeBigData › Filtering, and a third TreeBigData case that roves between runs (baseline hit Selection persists, the fixed tree hit Bulk Expand). GridViewFocus also fails at 1cc8745ad9, so it predates the neomjs/neo#17401 merge and is not fallout from it.

Deltas from ticket

The ticket's original closure was mine and was wrong; the correction is on the ticket. I closed it as not-a-defect because apps/devindex "behaves identically to examples/grid/bigData" — a true sentence with a false conclusion. They match because both tear. I used one as the healthy control for the other without ever verifying the control was healthy on the axis being measured.

Residuals

The Followers column in apps/devindex reads dx=-16 at rest, before any gesture, and is untouched by this change — a separate pre-existing viewport-edge artifact, not in scope here.

Post-Merge Validation

None. The close-target AC is runtime gesture behaviour and was verified pre-merge in a live browser on two apps, with the red-proof demonstrated in both directions.

Authored by Grace (Claude Opus 5, Claude Code). Session 3e4f33e0-fb23-4a61-a2a0-7f396950f3d6.

Review response — both RAs ADDRESSED @ 6348a09bf1

Both were right. RA-2 in particular caught something I had already recorded as a discipline and then failed to apply symmetrically in the same file.

RA-1 — batch the live width/style transition · ADDRESSED, with one deliberate divergence from the suggested shape

Batched, and your reasoning holds exactly: this runs per pointer step, so the chained setters emitted the stale-width update and then the correcting style update as two cascades per sample.

owner.set({
    width       : newWidth,
    wrapperStyle: {width: `${newWidth}px`}
});

I did not use the {...owner.wrapperStyle, width} spread you suggested, and the reason is load-bearing rather than stylistic.

wrapperStyle_ is a merge: 'shallow' descriptor (component/Base.mjs:306-313), so the partial lands and everything else survives — no read-back needed. And the read-back is a trap: beforeGetWrapperStyle() returns {...this.vdom.style, ...value} (:957), so reading the config merges the entire rendered style back in. On this path that means each of the 40 pointer steps would pin the drag proxy's leaked position / left / top / transform into wrapperStyle as config input — precisely the properties onDragEnd() then has to explicitly null out, and precisely the persistent state loop the style_ docblock warns about at :236-240.

Worth noting my previous version had that same read-back (let ownerStyle = owner.wrapperStyle; …). Your RA made me look at the line properly, and the batching fix removed a second latent problem I had not seen.

Verified rather than assumed — the dimming had to survive the shallow merge:

RA-2 — make narrowing independently non-vacuous and reachable · ADDRESSED, and you were right that it was two defects

Split into its own case, and each arm now carries its own non-vacuity proof.

You identified both failure modes precisely:

1. Unreachable. Sharing one test meant the unfixed widen failure aborted the run before the narrow hold was ever reached. My red proof certified one direction and asserted the other. "Both directions" in the PR body exceeded the evidence, which is the drift you flagged.
2. Vacuous. The narrow hold had no engagement guard. If narrowing stopped engaging, the callback would read an unchanged, trivially aligned header and pass.

Now: the widen hold requires held > before + 20; the narrow hold requires held < before - 20. Narrowing drives Firstname (150px, room to shrink without hitting minWidth: 100) rather than sharing the widened column.

Independent red receipts, against the pre-fix tree — neither aborting the other:

✓ widening a column moves its cells with it
✘ the header tracks the drag, not only the drop
✘ the header tracks a NARROWING drag, not only the drop
✓ narrowing a column moves its cells with it
✓ a flex column beside explicit ones does not drag the others onto a stale measurement
✓ resizing a centre column leaves the locked regions untouched
2 failed, 4 passed

That is the property you asked for: two hold cases, two independent failures, and the four pre-existing cases still green because they still cannot see this.

Suites

grid unit    65 passed
grid e2e     34 passed, 1 failed
target spec  6 passed

The single e2e failure is TreeBigData › Filtering, pre-existing and control-proven on the unmodified tree. GridViewFocus and the roving third TreeBigData case both passed this run — they are the flaky pair I flagged in the original body, and I am not claiming this change fixed them.

On your [RETROSPECTIVE]

"A reference control must be healthy on the measured axis, and a transient gesture bug needs a hold-point assertion whose own motion is proven before parity is checked."

That is the correct generalization and it is sharper than how I had it. I had banked the first half after the wrong closure; RA-2 is the second half, and I had applied it to the widen arm and not the narrow one in the same file, in the same sitting. Banked properly now.

Seat re-requested at 6348a09bf1.