ticket: remove multi in favor of panel

.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:08:49Z
+updated_at: 2026-06-05T23:13:39Z
 assignee: null
 legacy_ticket: null
 ---

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

@@ -69,4 +69,29 @@ Target route should be `yoi panel`: open the workspace panel for the current wor
 This keeps a single workspace control surface while preserving the existing multi-Pod affordances for non-Ticket workspaces.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:13:39Z -->
+
+## Decision
+
+Decision/update from launch and no-Ticket workspace discussion:
+
+Remove `--multi` as a user-facing launch option rather than keeping it as a compatibility alias.
+
+Target launch model:
+
+- `yoi panel` opens the workspace panel for the current working directory/workspace.
+- The panel resolves Ticket config from the workspace.
+- If `.yoi/ticket.config.toml` / Ticket config is defined and usable, the panel shows Ticket/action-centric workspace UI.
+- If Ticket config is undefined, the panel suppresses Ticket-related UI entirely:
+  - no Ticket/action rows;
+  - no Ticket-specific Pod labels/actions;
+  - no Intake/Orchestrator/Ticket workflow affordances;
+  - no Ticket-related diagnostics unless needed to explain an explicitly requested Ticket action.
+- In that no-Ticket mode, `yoi panel` should provide the same functional surface as the current `--multi` view: Pod discovery/status, selection, attach/open, and direct send where currently supported.
+
+This keeps one panel implementation while avoiding a permanent `--multi` surface or confusing Ticket UI in workspaces that have not opted into Ticket config.
+
+
 ---