ticket: decide workspace panel launch route

.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [tui, ticket, orchestration, panel]
 created_at: 2026-06-05T21:07:03Z
-updated_at: 2026-06-05T23:05:06Z
+updated_at: 2026-06-05T23:08:49Z
 assignee: null
 legacy_ticket: null
 ---

.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md

@@ -50,4 +50,23 @@ Implications:
 - Avoid designing two separate surfaces with duplicated selection, attach, send, and rendering logic.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:08:49Z -->
+
+## Decision
+
+Decision/update from launch-route discussion:
+
+Current route is still `yoi --multi` -> `LaunchMode::Multi` -> `single_pod::run_multi(...)` -> current multi-Pod dashboard. There is no dedicated `yoi panel` command yet.
+
+Target route should be `yoi panel`: open the workspace panel for the current working directory/workspace. The panel should resolve the workspace from cwd using the same project/config/Ticket root conventions as the rest of Yoi, then:
+
+- show Ticket/action-centric mode when `.yoi/tickets` / Ticket config is available or Ticket use is active;
+- fall back to the Pod-centric route (current `--multi` behavior) when the workspace has no Ticket backend/config or no Ticket records;
+- keep current `--multi` as a temporary compatibility alias/shortcut into `yoi panel`'s Pod-centric route during migration, rather than a separate long-term surface.
+
+This keeps a single workspace control surface while preserving the existing multi-Pod affordances for non-Ticket workspaces.
+
+
 ---