ticket: approve workspace panel design

.yoi/tickets/closed/20260605-210704-workspace-orchestration-panel-design/item.md

@@ -2,12 +2,12 @@
 id: 20260605-210704-workspace-orchestration-panel-design
 slug: workspace-orchestration-panel-design
 title: Workspace orchestration panel design
-status: open
+status: closed
 kind: task
 priority: P1
 labels: [tui, design, orchestration, panel]
 created_at: 2026-06-05T21:07:04Z
-updated_at: 2026-06-05T22:29:53Z
+updated_at: 2026-06-05T22:35:18Z
 assignee: null
 legacy_ticket: null
 ---

.yoi/tickets/closed/20260605-210704-workspace-orchestration-panel-design/resolution.md

@@ -0,0 +1,16 @@
+Completed the workspace orchestration panel design.
+
+Final direction:
+- The panel is a `--multi` successor, not a permanent split with the normal single-Pod TUI.
+- The concrete look follows existing TUI conventions/components.
+- The main unit is Ticket/action state; Pods are secondary execution/detail resources opened via attach/drill-down.
+- Display is local-file-first from `.yoi/tickets/` plus lightweight Pod metadata/session state.
+- Client/socket APIs are used at live operation boundaries: Orchestrator restore/spawn, Intake launch, send/notify, attach.
+- The UI intermediate representation is intentionally thin: `WorkspacePanelViewModel`, `PanelRow`, `TicketPanelEntry`, composer state, and timeline lanes as render/action-dispatch data, not a second Ticket backend, scheduler, or state machine.
+- The UI is not display-only; it is a Ticket-centric workspace cockpit for status, human decision points, Intake/Orchestrator actions, and Pod drill-down.
+- First implementation should cover the end-to-end structure before detailed layout/display tuning.
+
+Design artifact:
+- `artifacts/workspace-panel-ui-design.md`
+
+The implementation child tickets can proceed.

.yoi/tickets/closed/20260605-210704-workspace-orchestration-panel-design/thread.md

@@ -51,4 +51,44 @@ Direction recorded:
 - the panel is not display-only: it is a Ticket-centric workspace cockpit for status, decision points, Intake/Orchestrator actions, and Pod drill-down.
 
 
+---
+
+<!-- event: review author: hare at: 2026-06-05T22:35:18Z status: approve -->
+
+## Review: approve
+
+User approved the current workspace panel design direction and asked to implement a first end-to-end version before detailed layout/display tuning.
+
+Approved implementation direction:
+- follow the existing TUI visual language/components;
+- keep the UI intermediate representation thin and simple;
+- make panel display local-file-first from `.yoi/tickets/`;
+- use client/socket APIs only at live operation boundaries such as spawn/restore/send/attach;
+- build the first pass broadly enough to exercise the whole flow, then refine layout and displayed details afterward.
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-05T22:35:18Z status: closed -->
+
+## Closed
+
+Completed the workspace orchestration panel design.
+
+Final direction:
+- The panel is a `--multi` successor, not a permanent split with the normal single-Pod TUI.
+- The concrete look follows existing TUI conventions/components.
+- The main unit is Ticket/action state; Pods are secondary execution/detail resources opened via attach/drill-down.
+- Display is local-file-first from `.yoi/tickets/` plus lightweight Pod metadata/session state.
+- Client/socket APIs are used at live operation boundaries: Orchestrator restore/spawn, Intake launch, send/notify, attach.
+- The UI intermediate representation is intentionally thin: `WorkspacePanelViewModel`, `PanelRow`, `TicketPanelEntry`, composer state, and timeline lanes as render/action-dispatch data, not a second Ticket backend, scheduler, or state machine.
+- The UI is not display-only; it is a Ticket-centric workspace cockpit for status, human decision points, Intake/Orchestrator actions, and Pod drill-down.
+- First implementation should cover the end-to-end structure before detailed layout/display tuning.
+
+Design artifact:
+- `artifacts/workspace-panel-ui-design.md`
+
+The implementation child tickets can proceed.
+
+
 ---