ticket: unify multi under workspace 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-05T21:09:19Z
+updated_at: 2026-06-05T23:05:06Z
 assignee: null
 legacy_ticket: null
 ---

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

@@ -31,4 +31,23 @@ Implementation is split into child tickets:
 Existing `:ticket ...` commands remain as low-level fallback, not the main UX.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T23:05:06Z -->
+
+## Decision
+
+Decision/update from UI discussion:
+
+Do not preserve `--multi` as a separate long-term UI surface. The workspace panel should become the unified workspace view.
+
+`--multi`-style Pod list behavior remains useful, but should be treated as the panel's no-Ticket / Pod-centric route rather than a distinct architecture. In workspaces where Ticket config/storage is unavailable or Ticket usage is not desired, opening the panel should still provide the current multi-Pod discovery/attach/send affordances as a fallback view.
+
+Implications:
+- Implementation can reuse current `--multi` code/components as the first panel substrate.
+- The long-term command/launch model should prefer a panel view option; any existing `--multi` entry point can remain as a compatibility alias or shortcut into the Pod-centric panel route during migration.
+- The panel model should tolerate an empty/unavailable Ticket backend and still show useful Pod rows/actions.
+- Avoid designing two separate surfaces with duplicated selection, attach, send, and rendering logic.
+
+
 ---