From 64ca7d7d4bcb6fbdd6f64a047cf29a26aeff7fca Mon Sep 17 00:00:00 2001 From: Hare Date: Sat, 6 Jun 2026 08:05:06 +0900 Subject: [PATCH] ticket: unify multi under workspace panel --- .../item.md | 2 +- .../thread.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md b/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md index 256c56ba..27c93545 100644 --- a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/item.md +++ b/.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 --- diff --git a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md b/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md index ce252d9d..b6098ff8 100644 --- a/.yoi/tickets/open/20260605-210703-workspace-orchestration-panel/thread.md +++ b/.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. +--- + + + +## 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. + + ---