ticket: preflight workspace panel action model

.yoi/tickets/open/20260605-210704-workspace-panel-action-model/artifacts/delegation-intent.md

@@ -0,0 +1,100 @@
+# Delegation intent: workspace panel action model
+
+## Classification
+
+`implementation-ready` as the first implementation slice after design approval.
+
+The design ticket is closed and approved. The first pass should implement a simple, testable UI/action model that the existing multi-Pod dashboard can consume before we tune layout details.
+
+## Intent
+
+Add a thin workspace panel ViewModel/action model for Ticket-centric display and prioritization. This should be a render/action-dispatch contract, not a new Ticket backend, scheduler, or UI-owned state machine.
+
+The panel should be local-file-first for display:
+
+- read Ticket records from `.yoi/tickets/` through the Rust Ticket backend/config APIs;
+- combine with existing Pod list data for related/background Pod status where practical;
+- keep socket/client operations out of the model layer.
+
+## Worktree / branch
+
+- worktree: `/home/hare/Projects/yoi/.worktree/workspace-panel-action-model`
+- branch: `work/workspace-panel-action-model`
+
+This ticket may edit tracked `.yoi/tickets` records for implementation reports if needed. Do not read or edit `.yoi/memory/`.
+
+## Requirements
+
+- Define plain UI/data model types for the workspace panel, for example:
+  - `WorkspacePanelViewModel`;
+  - `PanelRow` / row key;
+  - `TicketPanelEntry`;
+  - action priority / next user action;
+  - optional timeline/dependency lane structs if useful for the first slice.
+- Keep the model independent from terminal rendering and from live socket I/O.
+- Add an adapter that builds Ticket/action rows from local Ticket backend state.
+- Reuse existing `PodList`/multi-Pod data as lower-priority background rows where practical, without replacing or duplicating Pod registry logic.
+- Prioritize rows roughly as:
+  1. Intake/user reply/approval needed;
+  2. Ticket ready for Go;
+  3. review/close decision required;
+  4. blocked/action-required;
+  5. active implementation/review/background work;
+  6. passive Pod/session information.
+- Use simple heuristics from current Ticket records/thread roles; do not invent a full scheduler or hidden state machine.
+- Preserve human authorization boundaries: a displayed Go/Review/Close action is an affordance, not automatic implementation authorization.
+- Integrate enough with the current `--multi` dashboard to display action-prioritized Ticket rows above passive Pod rows, while keeping current Pod attach/direct-send behavior intact as much as possible.
+- Follow existing TUI visual conventions; do not spend this ticket on fine layout tuning.
+
+## Non-goals
+
+- Final layout polish or detailed display tuning.
+- Orchestrator restore/spawn lifecycle implementation.
+- Composer target switching / New Intake send path.
+- Intake -> Orchestrator handoff contract.
+- Scheduler/lease/queue automation.
+- Replacing the normal single-Pod TUI.
+
+## Current code map
+
+- `crates/tui/src/multi_pod.rs`
+  - Current `--multi` dashboard state, reload, sections, rendering, direct send/open behavior.
+  - Integrate only enough to show Ticket/action rows and preserve existing behavior.
+- `crates/tui/src/pod_list.rs`
+  - Existing plain Pod list model. Reuse rather than duplicating live/stored Pod discovery semantics.
+- `crates/tui/src/lib.rs` / `crates/tui/src/single_pod.rs`
+  - Current `LaunchMode::Multi` path enters `single_pod::run_multi(...)`.
+- `crates/ticket/src/lib.rs`, `crates/ticket/src/config.rs`
+  - Local Ticket backend/config API for reading `.yoi/tickets/`.
+- `crates/yoi/src/ticket_cli.rs`
+  - Examples of backend listing/status formatting; do not shell out.
+- Design artifact:
+  - `.yoi/tickets/closed/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md`
+
+## Validation
+
+Run at least:
+
+- `cargo test -p tui multi` or targeted TUI tests covering the new model/render integration;
+- `cargo test -p ticket` if Ticket backend API usage changes;
+- `cargo test -p yoi ticket` if CLI/config interactions change;
+- `cargo check --workspace --all-targets`;
+- `cargo fmt --check`;
+- `git diff --check`;
+- `cargo build -p yoi`;
+- `target/debug/yoi ticket doctor`.
+
+Run `nix build .#yoi --no-link` if feasible.
+
+## Completion report
+
+Report:
+
+- worktree path / branch;
+- commit hash;
+- model/types added;
+- how Ticket rows are derived and prioritized;
+- how Pod rows are preserved as secondary/background information;
+- tests updated/added;
+- validation results;
+- known follow-up layout/display tuning items.

.yoi/tickets/open/20260605-210704-workspace-panel-action-model/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [tui, ticket, orchestration, panel]
 created_at: 2026-06-05T21:07:04Z
-updated_at: 2026-06-05T21:07:04Z
+updated_at: 2026-06-05T22:35:56Z
 assignee: null
 legacy_ticket: null
 ---

.yoi/tickets/open/20260605-210704-workspace-panel-action-model/thread.md

@@ -4,4 +4,17 @@
 
 Created by LocalTicketBackend create.
 
+---
+
+<!-- event: plan author: hare at: 2026-06-05T22:35:56Z -->
+
+## Plan
+
+Preflight result: `implementation-ready` as the first implementation slice after design approval.
+
+Implementation should add a thin, testable workspace panel ViewModel/action model and integrate it enough into the current `--multi` dashboard to show Ticket/action rows above passive Pod rows. The model should be local-file-first from `.yoi/tickets/`, reuse existing Pod list data for background Pod state, avoid live socket I/O in the model layer, and leave final layout/display tuning to follow-up adjustments after the first end-to-end pass.
+
+Detailed delegation intent is recorded in `artifacts/delegation-intent.md`.
+
+
 ---