Merge branch 'develop' into work/migrate-ticket-storage-to-yoi-tickets

.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md

@@ -24,6 +24,27 @@ The main list must not be a raw Pod list. It should sort by user decision priori
 5. Active implementation/review work.
 6. Informational Pod status and restorable historical sessions.
 
+## Visual design and render boundary
+
+The concrete look-and-feel should follow the existing TUI design language rather than inventing a second product surface. Reuse the current terminal UI conventions for borders, list selection, status/action bars, composer placement, key-hint style, transient notices, color/status semantics, and attach/return behavior where possible.
+
+The panel should feel like a more capable `--multi` workspace view, not a new unrelated dashboard. Any new visual treatment for Ticket/action rows or timeline lanes should be a small extension of existing list/detail components, so the single-Pod UI, current multi-Pod view, and workspace panel remain visually coherent.
+
+Rendering must go through a UI-oriented intermediate representation. Runtime/domain state should be normalized into plain view data first, and widgets should render that data without directly querying Ticket backends, Pod sockets, session logs, or role-launch internals.
+
+```text
+WorkspacePanelViewModel
+- header: workspace label, companion state, orchestrator state, diagnostics
+- action_rows: ordered user-action-required entries
+- ticket_rows: Ticket-oriented progress entries
+- pod_rows: secondary related Pod/session entries
+- detail: selected item detail blocks
+- timeline: optional dependency/phase lanes
+- composer: current target, placeholder, send eligibility, hints
+```
+
+This view model is a render contract, not an authority layer. Ticket files, Pod metadata/session logs, and destination Pod histories remain authoritative; the view model is rebuilt from those sources and carries only display-ready fields plus stable IDs for follow-up actions.
+
 ## Relationship to `--multi` and normal TUI
 
 Reuse the useful `--multi` behaviors:
@@ -54,10 +75,11 @@ Dynamic user text must be committed to the destination authority:
 
 ## Ticket-centric detail model
 
-Each visible Ticket row should be backed by a plain data entry, not by direct render-time Pod inspection:
+Each visible Ticket row should be backed by a UI-ready data entry, not by direct render-time Pod inspection:
 
 ```text
 TicketPanelEntry
+- stable selection/action key
 - id / slug / title / status
 - current phase: intake | preflight | implementing | reviewing | close_ready | blocked | closed
 - next user action: clarify | go | review | close | wait | none
@@ -65,9 +87,10 @@ TicketPanelEntry
 - related role Pods and their live/restorable state
 - latest plan / implementation report / review summary excerpts
 - diagnostics and blocked reason
+- display affordances: icon/status marker, priority, key hints, disabled reason
 ```
 
-This model should be assembled from the Ticket backend, Ticket thread entries, known role launches, visible Pod metadata, and Orchestrator/Intake handoff records. The UI should consume this plain model so later views can be added without coupling rendering to Pod internals.
+This model should be assembled from the Ticket backend, Ticket thread entries, known role launches, visible Pod metadata, and Orchestrator/Intake handoff records before rendering. Widgets should consume `TicketPanelEntry` / `WorkspacePanelViewModel` only, so later views can be added without coupling rendering to Pod internals.
 
 ## Timeline / Gantt-like view
 
@@ -109,10 +132,12 @@ Intake Pods receive the Orchestrator handoff/notification target at launch so th
 
 Implement in this order:
 
-1. Build the plain `WorkspacePanelModel` / `TicketPanelEntry` / `UserActionEntry` model.
-2. Make the existing multi-Pod panel consume enough of that model to show action-prioritized Ticket rows.
-3. Add composer target selection for Companion vs New Intake.
-4. Add attach/drill-down and return behavior for related Pods.
-5. Add the phase/dependency timeline view.
+1. Define the UI intermediate representation (`WorkspacePanelViewModel`, `TicketPanelEntry`, `UserActionEntry`, composer target/view state, timeline lane rows) separately from runtime/domain state.
+2. Add an adapter that builds the view model from Ticket backend records, role-launch state, visible Pod metadata, and diagnostics.
+3. Render the workspace panel using existing TUI visual conventions/components as much as possible.
+4. Make the existing multi-Pod panel path consume enough of that model to show action-prioritized Ticket rows.
+5. Add composer target selection for Companion vs New Intake.
+6. Add attach/drill-down and return behavior for related Pods.
+7. Add the phase/dependency timeline view.
 
 The existing `:ticket ...` commands remain as low-level fallback and debugging affordances, not the primary UX.