Make dock edge-band geometry host-relative on both axes

Context

#15165 made the standalone Workstation respond at 1280x900, 900x900, and 900x600 without mutating dockZone.v1. Its inline bands use cqi, but the bottom band remains clamp(140px, 28vh, 200px) and the query container is container-type: inline-size.

That is correct for the standalone viewport tested by #15165, but not for an embedded dock workspace. A child dock host can be 450px tall inside a much taller viewport; vh then sizes against the wrong box. Replacing vh with cqh alone is also insufficient: CSS container units select the nearest eligible query container per axis, and fall back to the small viewport when no eligible axis container exists. An inline-size container is not eligible on the block axis.

A live Workstation CSSOM/getComputedStyle probe made the distinction concrete:

Live latest-open plus all-state GitHub searches for dock container query edge band, nested container cqi cqh, and Workstation host-relative sizing found no equivalent. The only match was closed #15165, whose Out of Scope explicitly excluded generic dashboard edge-band defaults.

The Problem

Dock edge-band policy currently mixes three coordinate systems:

• inline bands are relative to the Workstation root through cqi;
• the bottom band is relative to the browser viewport through vh;
• shared dashboard defaults are physical width / height pixel declarations.

The result is compositional drift: the same dock document behaves differently when the workspace is the viewport versus a child container. It also leaves writing-mode semantics and the shared/app ownership boundary implicit.

The Architectural Reality

• DockLayoutAdapter projects reusable .neo-dashboard-dock-edge-band-<edge> hooks and deliberately keeps their cross-extent non-flexing.
• Neo.dashboard.Container owns shared dock styling; applications own their semantic min/preferred/max policy.
• container-type: inline-size establishes only an inline-axis size-query container.
• container-type: size enables both axes but applies size containment; placing it on an auto-sized ancestor can suppress intrinsic sizing or collapse its block extent.
• Workstation's .workstation-dock-host is a flex child with flex: 1 and a fit layout, making it a stronger candidate than the outer app root for a definite two-axis dock query host.
• rem scales policy floors/caps with root typography. It does not encode available space; the fluid term still belongs to cqi / cqb. Local em values would couple dock geometry to incidental descendant font-size changes.

The Fix

Define a reusable, opt-in dock query-host contract and consume it from Workstation.

1. Establish a named two-axis size query container on the actual definite-size dock host, not on an auto-sized generic ancestor. Prove that the chosen containment point does not collapse intrinsic layout.
2. Change shared edge-band hooks to logical inline-size / block-size properties backed by overridable dock tokens.
3. Keep application policy app-owned: Workstation supplies bounded clamp(<rem floor>, <cqi/cqb fluid term>, <rem cap>) values while shared CSS supplies conservative defaults.
4. Replace the bottom band's viewport dependency with a block-axis container dependency.
5. Add a nested-host whitebox journey that varies host size and outer viewport independently.

Contract Ledger

Acceptance Criteria

• A Workstation dock host embedded below the viewport uses its own content-box inline and block sizes for edge-band geometry.
• With the dock host held fixed, changing only the outer viewport does not change the computed left, right, or bottom edge-band extents.
• Changing the host from 1100x600 to 700x450 moves the right band from its fluid value to its floor and the bottom band from its fluid value to its floor, without page reload or dock-document mutation.
• The selected query host reports two-axis size-query eligibility and has a definite non-zero block size; no size-containment collapse occurs.
• Shared edge-band CSS uses logical sizing properties and app-overridable tokens; Workstation's readable floors/caps are root-font-relative while the fluid terms are container-relative.
• The standalone 1280x900 and 900x600 behavior from #15165 remains within its existing geometry bounds.
• Tab overflow, splitters, rails, perspective changes, Store identities, and the live feed remain intact through host and viewport resizing.
• Focused theme builds and a whitebox getComputedStyle/DOMRect journey cover the nested and standalone cases.

Out of Scope

Mobile topology changes below the existing desktop floor · rewriting dockZone.v1 ratios · JavaScript resize listeners · redesigning pane content · converting unrelated typography or spacing pixels · imposing container-type: size on every generic .neo-dashboard consumer without definite-size proof.

Avoided Traps

• Do not mechanically replace vh with cqh; without block-axis eligibility it still resolves against the small viewport fallback.
• Do not treat rem as the fluid responsive dimension.
• Do not put size containment on an intrinsically auto-sized box and assume its content will preserve the block size.
• Do not move app-specific density ratios into the persisted dock model or a universal hardcoded shared constant.
• Do not prove only viewport resize; nested composition requires independently controlled host and viewport dimensions.

Decision Record Impact

Aligned with ADR 0029 §2.5/§2.6: docking remains in src/dashboard, embedded panes remain layout-blind, and applications supply density policy through the shared projection-CSS contract. No ADR amendment or new persisted/runtime model surface is required.

Related

• Predecessor: #15165
• QT-docking epic: #13158
• Shared projection ownership: #15136 / PR #15170
• Remaining projection consumers: #15171

Origin Session ID: adddb25d-fc36-4b08-b9a3-3a62a108cda1

Retrieval Hint: dock edge band host relative container-type size cqi cqb nested Workstation logical inline-size block-size