fix(lab): separate direct device launches from planning profiles

docs/18_APPLICATION_COMPONENT_ARCHITECTURE.md

@@ -113,6 +113,45 @@ Owns shell-level orchestration: selected root/workspace, global panels, runtime
 providers, and passing typed controllers to a workspace. It must not absorb
 domain API calls, per-LAB renderers, or new visual primitives.
 
+## Shared LAB launch profiles — 2026-09-21
+
+Test devices and Spatial scene are shared infrastructure, not children of the
+planner. `DeviceWorkspace` imports only the generic device host and its UI
+contracts; it must render without a `PlanningTestProvider`.
+
+- Direct navigation to either surface selects the `direct` launch profile.
+  A page reload also starts with `direct`, even if the server retains a completed
+  or interrupted planning run. Model selection remains the device host's state.
+- A successful planner start or explicit reopen passes `planning` through
+  `WorkspaceNavigation.openView`. The shell composes `PlanningConnectionWindow`
+  only for that entry. Device connection and spatial-control callbacks preserve
+  the originating profile when opening the scene.
+- `PlanningTestProvider` owns run data and polling, not navigation selection.
+  Reading `/live-tests/active` must never change the launch profile. An unsuccessful
+  explicit run selection must not open a stale run's connection or scene.
+- A nonterminal planning consumer that has not bound a query session still waits
+  for the next capture. The composition-level `PlanningCaptureGuard` requires an
+  explicit return to that study or completion of the study before direct capture;
+  it does not send scanner, network, or recording commands. It waits for a terminal
+  server state, not merely acknowledgment of the stop request. Completed runs and
+  runs already bound to a recording do not claim a later direct launch.
+
+Changing presentation does not delete evidence, end acquisition, or restart an
+experiment. The planner continues to consume an explicitly started recording;
+ordinary acquisition requires neither a reference route nor a planner draft.
+
+Regression coverage: `test/workspaceLaunch.test.mjs`, including independent model
+catalog rendering, explicit handoff, terminal-run isolation, failed selection,
+and both shared-scene entry paths.
+
+Acceptance on the canonical operator service `127.0.0.1:8000`: architecture
+checks, TypeScript, all 882 frontend tests and production build passed. In-app
+browser QA confirmed direct entry with retained completed evidence, catalog →
+XGRIDS connection, the unchanged connection-method selector and Escape,
+normal/expanded layouts, ordinary scene entry, and planner → direct-device
+navigation. No BLE discovery, provisioning, acquisition or new field run was
+performed during this UI acceptance.
+
 ## CSS ownership
 
 CSS follows the same feature boundary: