Problem scope
Workstation is the flagship DockLayouts adoption example, but its main definition is still a program a consumer must reverse-engineer. At merged dev@01f65aaff67fac724ccfdc61e172eeb83ab4537b, apps/workstation/view/Workspace.mjs has 4,859 total lines and 100 methods. Four scripted gesture executors alone occupy 1,108 method-body lines; tour settlement, live-data production, native vessel policy and preview plumbing share the same instance.
The operator's outcome is explicit: the entrypoint should be a readable 500–1,000 total source lines, with 1,000 as the ceiling, and no replacement module above 2,000 lines. Lower is welcome when the composition remains clear. Ordinary docking must work without constructing or loading the optional scripted demo machinery.
This needs one consumer epic because several independently testable responsibilities must leave the same entrypoint, their callers must move with them, and the final integration must preserve the flagship's visible behavior. It is not another engine decomposition epic: #18304 owns engine responsibilities and working defaults; this epic owns apps/workstation as a usable example.
The closed migration #17546 established inheritance from the engine Workspace, not this compact-entrypoint outcome. The consumer gap recorded on #18304 and its author reconciliation are the starting evidence, not duplicate implementation ownership.
Intended solution shape
Workspace.mjs becomes a declarative dock entrypoint: zones, panes, tabs, widget registration, default layout and configured engine capabilities, with a small set of justified product hooks. The reference shape is examples/dashboard/dock/MainContainer.mjs (609 total lines at the source check), which declares its dockZone.v1 arrangement and lets the engine run it. The goal here is simpler use of the existing DockWorkspace document and feature-config APIs, not a new declarative configuration schema or an automatic owner-construction API. New declarative DockLayouts configuration design belongs to Vega's separately scoped Ideation Sandbox; it is not an implicit prerequisite or additional deliverable of this epic. Owners are reserved for actual app behavior: live-data production, vessel policy and optional scripted gestures/tour settlement; views and stores retain their ordinary Neo roles.
The tour uses the existing TourRunner and InteractionService rather than rebuilding a scheduler or pointer system. Scripted executors and their diagnostics live behind the optional demo boundary. The docking side consumes existing Group, WorkspaceSet, Participation, preview and vessel owners. Any behavior claimed to be app policy must have a current caller/product reason; any missing generic engine behavior is routed to the engine's owning ticket and linked as a prerequisite.
The size goal is achieved by responsibility removal, preserving useful documentation. A code-line ratchet only prevents regrowth; its current green result does not certify an acceptable flagship. No forwarding façade per old method, giant helper, parallel registry, second writer or second lifetime authority may stand in for the reduction.
The final consumer must retain pane/store identity, ordinary docking, native return, history and saved-layout behavior, and its existing tours when explicitly activated. The app README will explain the compact adoption path and where the optional demo lives; this does not author the deferred general DockLayouts guide series.
Ownership and coordination
Emmy stewards this consumer outcome and its dependency graph. Leaf implementation ownership is self-selected at pickup, not pre-assigned as a batch. The native sub-issue graph is the work list; every leaf must be independently reviewable and resolvable by one PR.
Out of scope
- Engine decomposition and new engine APIs: #18304, with individual dependencies linked when needed.
- Group/history/topology redesign: #18303.
- Existing defects and investigations, including #18448, #18376, #18208 and the whole-film gate #16498. Preserve their evidence boundaries; this refactor does not close them by association.
- Demo-B, Fleet or private downstream-app refactors. They can validate generic boundaries without joining this app's edit scope.
- A new repository-wide size policy, lint system, framework, scheduler or compatibility layer.
- Visual redesign, changed tour content, lowered workload, or removal of a feature to meet the line target.
Avoided traps
Moving code is insufficient when ownership stays on the root through dozens of callbacks. A copied app-side implementation is not an engine default. A tour's success is not proof that normal docking works without it. A fresh namespace is not proof that overrides reach executed methods. Any Base-derived owner introduced here must have a documented creator/borrower lifetime.
Decision Record impact
Aligned with ADR 0029's engine host, semantic Group/document ownership and render-target boundaries. No change to operation semantics or commit granularity is authorized. Operator-scoped consumer refactoring under existing contracts, not a new Discussion graduation.
Related: #18304 · #18303 · #17546 · #17540 · #18450
Source grounding: Workstation source, Viewport, WorkspaceController, FeedPane, existing stores, TourRunner and Participation; current Workspace blob 9df0ad4924bc07f8524482ef5753438719baa2ed verified against merged dev. Structural placement uses the existing app domains and ordinary Neo class families. The Engine structure-map command is unavailable (silent exit 1); no Brain mutation or invented map result is claimed. Broad semantic recall returned mostly irrelevant records; current source and the linked public scope records govern.
Origin Session ID: 153d2e0a-ebae-4087-bcd5-3c92d213132c
Retrieval Hint: Workstation compact entrypoint optional demo tour owner vessel policy preview consumer refactoring
Creation sweeps: live latest-20 open tracker and all-state recent A2A checked immediately before creation; no equivalent consumer epic or competing claim. Own open film/guide tickets were read and excluded. The prior scope discussion is on #18304 and is being transferred to this dedicated sibling consumer epic; no former resolved ticket is reopened.
Problem scope
Workstation is the flagship DockLayouts adoption example, but its main definition is still a program a consumer must reverse-engineer. At merged
dev@01f65aaff67fac724ccfdc61e172eeb83ab4537b,apps/workstation/view/Workspace.mjshas 4,859 total lines and 100 methods. Four scripted gesture executors alone occupy 1,108 method-body lines; tour settlement, live-data production, native vessel policy and preview plumbing share the same instance.The operator's outcome is explicit: the entrypoint should be a readable 500–1,000 total source lines, with 1,000 as the ceiling, and no replacement module above 2,000 lines. Lower is welcome when the composition remains clear. Ordinary docking must work without constructing or loading the optional scripted demo machinery.
This needs one consumer epic because several independently testable responsibilities must leave the same entrypoint, their callers must move with them, and the final integration must preserve the flagship's visible behavior. It is not another engine decomposition epic: #18304 owns engine responsibilities and working defaults; this epic owns
apps/workstationas a usable example.The closed migration #17546 established inheritance from the engine Workspace, not this compact-entrypoint outcome. The consumer gap recorded on #18304 and its author reconciliation are the starting evidence, not duplicate implementation ownership.
Intended solution shape
Workspace.mjsbecomes a declarative dock entrypoint: zones, panes, tabs, widget registration, default layout and configured engine capabilities, with a small set of justified product hooks. The reference shape isexamples/dashboard/dock/MainContainer.mjs(609 total lines at the source check), which declares itsdockZone.v1arrangement and lets the engine run it. The goal here is simpler use of the existingDockWorkspacedocument and feature-config APIs, not a new declarative configuration schema or an automatic owner-construction API. New declarative DockLayouts configuration design belongs to Vega's separately scoped Ideation Sandbox; it is not an implicit prerequisite or additional deliverable of this epic. Owners are reserved for actual app behavior: live-data production, vessel policy and optional scripted gestures/tour settlement; views and stores retain their ordinary Neo roles.The tour uses the existing TourRunner and InteractionService rather than rebuilding a scheduler or pointer system. Scripted executors and their diagnostics live behind the optional demo boundary. The docking side consumes existing Group, WorkspaceSet, Participation, preview and vessel owners. Any behavior claimed to be app policy must have a current caller/product reason; any missing generic engine behavior is routed to the engine's owning ticket and linked as a prerequisite.
The size goal is achieved by responsibility removal, preserving useful documentation. A code-line ratchet only prevents regrowth; its current green result does not certify an acceptable flagship. No forwarding façade per old method, giant helper, parallel registry, second writer or second lifetime authority may stand in for the reduction.
The final consumer must retain pane/store identity, ordinary docking, native return, history and saved-layout behavior, and its existing tours when explicitly activated. The app README will explain the compact adoption path and where the optional demo lives; this does not author the deferred general DockLayouts guide series.
Ownership and coordination
Emmy stewards this consumer outcome and its dependency graph. Leaf implementation ownership is self-selected at pickup, not pre-assigned as a batch. The native sub-issue graph is the work list; every leaf must be independently reviewable and resolvable by one PR.
Out of scope
Avoided traps
Moving code is insufficient when ownership stays on the root through dozens of callbacks. A copied app-side implementation is not an engine default. A tour's success is not proof that normal docking works without it. A fresh namespace is not proof that overrides reach executed methods. Any Base-derived owner introduced here must have a documented creator/borrower lifetime.
Decision Record impact
Aligned with ADR 0029's engine host, semantic Group/document ownership and render-target boundaries. No change to operation semantics or commit granularity is authorized. Operator-scoped consumer refactoring under existing contracts, not a new Discussion graduation.
Related: #18304 · #18303 · #17546 · #17540 · #18450
Source grounding: Workstation source, Viewport, WorkspaceController, FeedPane, existing stores, TourRunner and Participation; current Workspace blob
9df0ad4924bc07f8524482ef5753438719baa2edverified against merged dev. Structural placement uses the existing app domains and ordinary Neo class families. The Engine structure-map command is unavailable (silent exit 1); no Brain mutation or invented map result is claimed. Broad semantic recall returned mostly irrelevant records; current source and the linked public scope records govern.Origin Session ID: 153d2e0a-ebae-4087-bcd5-3c92d213132c
Retrieval Hint:
Workstation compact entrypoint optional demo tour owner vessel policy preview consumer refactoringCreation sweeps: live latest-20 open tracker and all-state recent A2A checked immediately before creation; no equivalent consumer epic or competing claim. Own open film/guide tickets were read and excluded. The prior scope discussion is on #18304 and is being transferred to this dedicated sibling consumer epic; no former resolved ticket is reopened.