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.
+1. Define the UI intermediate representation (`WorkspacePanelViewModel`, `TicketPanelEntry`, `UserActionEntry`, composer target/view state, timeline lane rows) separately from runtime/domain state.
-2. Make the existing multi-Pod panel consume enough of that model to show action-prioritized Ticket rows.
+2. Add an adapter that builds the view model from Ticket backend records, role-launch state, visible Pod metadata, and diagnostics.
-3. Add composer target selection for Companion vs New Intake.
+3. Render the workspace panel using existing TUI visual conventions/components as much as possible.
-4. Add attach/drill-down and return behavior for related Pods.
+4. Make the existing multi-Pod panel path consume enough of that model to show action-prioritized Ticket rows.
-5. Add the phase/dependency timeline view.
+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.

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

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [tui, design, orchestration, panel]
 created_at: 2026-06-05T21:07:04Z
-updated_at: 2026-06-05T21:22:49Z
+updated_at: 2026-06-05T21:32:54Z
 assignee: null
 legacy_ticket: null
 ---
@@ -52,5 +52,7 @@ Produce a design artifact that fixes:
 
 - A design artifact exists under this Ticket's `artifacts/` directory.
 - The artifact defines the state/action model and responsibility boundaries clearly enough to implement child tickets.
+- The artifact defines a UI intermediate representation between runtime/domain state and rendering.
+- The artifact specifies that the concrete visual design follows existing TUI conventions/components rather than inventing a separate dashboard style.
 - The artifact explicitly preserves history/context rules: dynamic messages are committed to the destination Pod history, not injected into hidden context.
 - Reviewer or parent approves the design before implementation child tickets proceed.

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

@@ -21,4 +21,19 @@ Key direction:
 This is a design draft for review/iteration, not implementation approval for the child panel tickets yet.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T21:32:54Z -->
+
+## Decision
+
+Updated the workspace panel design draft per UI direction:
+
+- concrete look-and-feel should follow the existing TUI design language/components rather than introducing a separate dashboard style;
+- the panel should remain a `--multi` successor with attach/drill-down, not a permanent split with the normal single-Pod UI;
+- rendering should go through a UI intermediate representation (`WorkspacePanelViewModel`, `TicketPanelEntry`, action rows, composer view state, timeline lanes) built from Ticket/Pod/runtime sources before widgets render.
+
+The design ticket acceptance criteria now explicitly require both the UI intermediate representation and existing-TUI visual convention constraints.
+
+
 ---