QT-grade docking strategies for the infinite canvas (dock/split/tab layouts)

Context

Vector-2 market-signal leaf under Epic #13012 (window-manager lane; see the epic's "two market vectors" section). The enterprise desktop-to-web migration market — QT/WPF-class applications wanting web versions — expects QT-grade docking: dock zones, split containers, tabbed dock panels, save/restore layouts, float/pin. Neo's infinite-canvas choreography (#13025 knowledge capture: continuous-drag pane↔popup embodiment migration on the SharedWorker heap) is the differentiated substrate underneath; what's missing is the docking strategy layer on top.

Demand provenance: an enterprise design-partner cohort (QT-heavy ISV) carries an internal ticket for "smarter docking strategies, similar to a QT lib" — recorded here anonymized per the partner guardrail on #13012. The signal is treated as a market hypothesis: QT-migration teams generally need this, not just one partner.

The Problem

Today the dashboard choreography supports vertical slide-resort within a vbox + pane↔popup conversions. QT-class apps need richer layout semantics: dock a pane to any edge, split horizontally/vertically to arbitrary depth, tab multiple panes into one dock slot, drag-to-dock with live zone previews, persist/restore named layouts per user.

The Architectural Reality

• Substrate that exists: the continuous-drag gesture pipeline (apps/colors / agentos prototype), Neo.draggable.dashboard.SortZone, Neo.dashboard.Container, Neo.manager.Window God-View + getWindowAt(x,y), layout system (vbox/hbox/card and friends).
• Reference semantics (study, never port code): QT QDockWidget/QMainWindow docking model; modern web peers (Golden Layout, Dockview) — an industry-friction-radar-style abstraction pass extracts the semantic model only.
• The blueprint angle: a docked layout is a serializable Neo blueprint — save/restore composes with the NL-mutation→commit write-through direction (pillar 2) for free.
• Composes with, does not block: #13025 (popup terminal drop), #13028 (OS-window reintegration). Docking is in-window layout richness; those are cross-window choreography.

The Fix

Scope at claim time via structural-pre-flight (likely a layout.Dock-class primitive + dashboard integration + zone-preview UX with the #13022 visual system). This ticket is the demand-signal capture + scoping anchor; the claimer decomposes into one-PR leaves (zone model → split/tab containers → persistence) under this as a parent if needed.

Acceptance Criteria (scoping-level; refined at claim)

• Dock-zone model: edge docking + nested splits + tabbed dock slots, expressed as Neo layout primitives.
• Drag-to-dock with live zone preview, riding the existing continuous-drag pipeline (no parallel drag system).
• Layouts serializable/restorable (blueprint-compatible).
• Demand validated against ≥2 independent use shapes (the partner's QT migration + one unrelated consumer, e.g. the harness's own settings/dashboard surfaces) before implementation locks.

Out of Scope

• Cross-window choreography (#13025 / #13028).
• Partner-specific layout presets (partner-private overlay if ever needed).

Related

• Parent: Epic #13012. Milestone: M3 (dashboard composition). Board: Project 13.
• Substrate: #13025 (knowledge capture), src/manager/Window.mjs, the #8164→#9498 lineage.
• Closed precursor swept: #7204 (Phase 3 dynamic proxy windowing — different concern, no overlap).

Origin Session ID: c4caff26-d818-486b-8663-19b85ac3cc11 Retrieval Hint: "QT-grade docking strategies dock zones split tabbed layouts infinite canvas enterprise desktop-to-web migration"