The original fourth series part was explicitly “Panes Are Ordinary Components.” That outcome never received a ticket. The current Adoption guide shows pane resolution, but the refactor and flagship integrations now expose much richer identity, lifecycle, data, and state-provider questions.
The Problem
Developers can mistake a dock pane for a special docking widget or recreate normal Neo component patterns inside the layout model. There is no focused guide showing how ordinary containers, grids, stores, models, controllers, state providers, async destruction, and stable component identity participate in docking and survive movement.
The Architectural Reality
Dock documents own semantic pane ids, while consumers resolve those ids into ordinary Neo component instances. Workspace.mjs and consumer hooks govern resolution/recreation; stores/providers/controllers retain their own authorities. Moving, pinning, maximizing, or tearing out a pane changes embodiment, not the pane's application-domain identity.
The Fix
Create learn/guides/uibuildingblocks/DockLayoutsPanes.md: an adopter-facing guide that builds realistic panes from ordinary Neo UI/data primitives and follows their identity and lifecycle across DockLayouts operations.
Contract Ledger
Target Surface
Source of Authority
Proposed Behavior
Fallback
Docs
Evidence
Pane guide
Workspace hooks + current consumers + core lifecycle guides
Teach normal component/data/state composition inside panes
Link generic reference instead of copying it
New guide
Live pane journeys
Identity/lifecycle
Current resolution/recreate/tear-out behavior
Explain what identity survives and what may be recreated
State host policy explicitly
Same guide
Instance/document/store receipts
Registration
Existing guide siblings
One discoverable UI-building-blocks guide
No generated-output edits
tree + SEO inputs
lint + rendered portal
Decision Record impact
aligned-with ADR 0029
Decision Record
Not needed; this guide explains consumer composition.
Acceptance Criteria
The guide clears the full guide-authoring bar: source/tool-grounded narrative, reader-owned benefits, lived maintainer voice, and at least one render-verified flowchart TD.
The guide separates explanation from reference: no inlined API/schema/test catalog, and no ticket or PR ids in guide prose.
The new source guide is registered in learn/tree.json and the SEO PRIORITIES input; generated sitemap/LLM outputs remain untouched.
Current-source consistency, guide lint, tree lint, portal rendering, and an independent cross-family whole-guide review are recorded in the PR.
Examples use ordinary Neo components backed by data.Store / data.Model where data UI is involved, with providers at appropriate view roots.
The guide traces pane identity, component lifecycle, controller/store/provider ownership, destruction, and recreation without moving application state into the dock document.
At least one realistic pane is moved through multiple embodiments while its intended state/identity invariants are observed.
Generic component, data, and lifecycle reference is linked rather than re-taught.
Out of Scope
Inventing a pane framework, changing component lifecycle, or embedding app-specific business logic.
Avoided Traps
Do not hand-map data arrays, put providers into every pane, equate pane id with DOM id, or promise instance preservation where host policy permits recreation.
Activation Gate
Do not author the guide while #17836 remains an active refactoring authority. At pickup, re-run Memory Core mining, read the current ADR 0029 and source/test surfaces named below, exercise the relevant live subsystem, and revalidate the proposed guide boundary. If the final API makes this split wrong, reshape this ticket before writing—do not preserve a stale outline.
Related
Related: parent guide Epic #17540; blocked by active DockLayouts refactor Epic #17836; authority ADR 0029.
Retrieval Hint: query_raw_memories("DockLayouts guide series post-refactor final API")
Creation freshness: live created-descending sweep of the latest 20 open Engine issues at 2026-09-01T17:49:38Z found no equivalent guide ticket; the all-state latest-30 A2A sweep found no overlapping guide claim. The Knowledge Base returned stale pre-cut names, so live source, ADR 0029, and the current guide tree remain authority.
Context
The original fourth series part was explicitly “Panes Are Ordinary Components.” That outcome never received a ticket. The current Adoption guide shows pane resolution, but the refactor and flagship integrations now expose much richer identity, lifecycle, data, and state-provider questions.
The Problem
Developers can mistake a dock pane for a special docking widget or recreate normal Neo component patterns inside the layout model. There is no focused guide showing how ordinary containers, grids, stores, models, controllers, state providers, async destruction, and stable component identity participate in docking and survive movement.
The Architectural Reality
Dock documents own semantic pane ids, while consumers resolve those ids into ordinary Neo component instances.
Workspace.mjsand consumer hooks govern resolution/recreation; stores/providers/controllers retain their own authorities. Moving, pinning, maximizing, or tearing out a pane changes embodiment, not the pane's application-domain identity.The Fix
Create
learn/guides/uibuildingblocks/DockLayoutsPanes.md: an adopter-facing guide that builds realistic panes from ordinary Neo UI/data primitives and follows their identity and lifecycle across DockLayouts operations.Contract Ledger
Decision Record impact
aligned-with ADR 0029
Decision Record
Not needed; this guide explains consumer composition.
Acceptance Criteria
flowchart TD.learn/tree.jsonand the SEOPRIORITIESinput; generated sitemap/LLM outputs remain untouched.data.Store/data.Modelwhere data UI is involved, with providers at appropriate view roots.Out of Scope
Inventing a pane framework, changing component lifecycle, or embedding app-specific business logic.
Avoided Traps
Do not hand-map data arrays, put providers into every pane, equate pane id with DOM id, or promise instance preservation where host policy permits recreation.
Activation Gate
Do not author the guide while #17836 remains an active refactoring authority. At pickup, re-run Memory Core mining, read the current ADR 0029 and source/test surfaces named below, exercise the relevant live subsystem, and revalidate the proposed guide boundary. If the final API makes this split wrong, reshape this ticket before writing—do not preserve a stale outline.
Related
Related: parent guide Epic #17540; blocked by active DockLayouts refactor Epic #17836; authority ADR 0029.
Origin Session ID: 309a78d7-2d95-4f23-bdfc-69d2ae393a5d
Retrieval Hint:
query_raw_memories("DockLayouts guide series post-refactor final API")Creation freshness: live created-descending sweep of the latest 20 open Engine issues at 2026-09-01T17:49:38Z found no equivalent guide ticket; the all-state latest-30 A2A sweep found no overlapping guide claim. The Knowledge Base returned stale pre-cut names, so live source, ADR 0029, and the current guide tree remain authority.