Cross-window dock previews lack a four-axis thickness-symmetry contract

Context

Live operator QA on 2026-07-29 reports that top/bottom dock preview bands look roughly twice as thick as the corresponding left/right bands. The asymmetry makes the drop language feel arbitrary even though all four placements represent the same edge operation.

This is a new visual-geometry successor to #15965 / PR #15979 and the earlier DockPreview/indicator leaves. Those predecessors remain closed.

The Problem

The shared DockPreview.affordanceGeometry() implementation is symmetric in source: one band = min(edgeBandSize, targetWidth, targetHeight) drives top/bottom height and left/right width. Unit coverage pins top and right at the same 24 CSS pixels.

The live visual report therefore does not justify changing that pure helper by assumption. It proves a missing integration contract: current headed geometry checks bound each orientation independently and verify edge alignment, but never compare all four thicknesses on the same target, containing block, theme, scale, and cross-window route. An orientation-specific target rect, coordinate conversion, clip, transform, or compositor effect can look 2× while the pure helper remains green.

The Workstation cross-window path is a specific risk boundary: remote preview composition can begin from manager.Window.innerRect while the semantic candidate names an inner dock node. The final renderer must align to the exact target node's measured rectangle, not merely a window-sized surrogate.

The Architectural Reality

Semantic placement owns direction; live target-node geometry owns pixels. A single visual witness must bind them at the same frame. CSS-pixel equality is necessary but not sufficient where window scale/compositing can diverge, so retained output must include both DOM geometry and rendered evidence.

The indicator-menu squares and the preview band are distinct surfaces. This ticket owns the colored target-region preview thickness, not the 32px/26px indicator controls.

The Fix

1. Add a four-orientation Workstation witness on one stable target node for both in-window and cross-window drag routes.
2. Record the exact target component rect, preview affordance rect, containing-block rect, theme, device scale, and placement for top/right/bottom/left.
3. Enforce physical symmetry: top.height, bottom.height, left.width, and right.width resolve to the same policy thickness within a documented rendering tolerance, and every band hugs the corresponding edge of the same target rect.
4. If the pure helper output is already equal, repair the first integration layer where the rendered rectangles diverge—target-node measurement, coordinate translation, containing block, clipping, or CSS—not the symmetric core by guess.
5. Retain same-scale screenshots/crops showing all four orientations.

Contract Ledger

Acceptance Criteria

• A current-dev headed witness reproduces the operator-observed asymmetry or, if not reproducible in the first environment, publishes the exact measured four-axis result without changing source geometry.
• On one target at one settled size, top.height ≈ bottom.height ≈ left.width ≈ right.width within 1 CSS px (or a tighter measured tolerance justified in the PR).
• Every band uses and hugs the exact semantic target node rectangle; a manager.Window.innerRect may be acquisition input but is not accepted as the final node rect.
• The equality + edge-containment matrix passes for in-window and popup→main/cross-window preview routes in both Workstation themes.
• Retained same-scale frames show all four placements. Independent max-thickness assertions or source-code symmetry alone are insufficient visual proof.
• Device-scale/zoom metadata is recorded; if CSS geometry is equal but rendered pixels are not, the compositor/CSS cause is isolated before changing policy values.
• Indicator-menu control sizes and hit targets remain unchanged unless separate evidence identifies them as the actual reported surface.

Out of Scope

Changing dock operation semantics · tab-proxy background · popup conversion/materialization · overflow-menu skin · aesthetic redesign of indicator glyphs.

Avoided Traps

• Do not assume the core computes a 2× value; current source and unit examples say otherwise.
• Do not “fix” one orientation with a magic number.
• Do not compare bands from different target nodes or different zoom/DPR states.
• Do not accept four independent upper bounds as symmetry proof.
• Do not conflate preview-region bands with the square DockDropIndicators controls.

Decision Record impact

aligned-with ADR 0029's semantic preview contract; no amendment expected because this restores visual geometry parity.

Related

Successor to #15965 / PR #15979 · #15207 shared Workstation affordance composition · #14959 DockDropIndicators · QT-parity epic #13158 · sibling #16117.

Freshness evidence: live all-state searches for dock/drop indicator and preview geometry/thickness; current shared geometry helper and unit/e2e assertion census; exact prior ticket bodies; latest 20 open issues and latest 30 all-state A2A messages checked immediately before creation on 2026-07-29. No equivalent open defect or competing claim found.

Retrieval Hint: Workstation dock preview top bottom height left right width thickness symmetry cross window target rect