ticket: close workspace panel action model
This commit is contained in:
-100
@@ -1,100 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
id: 20260605-210704-workspace-panel-action-model
|
||||
slug: workspace-panel-action-model
|
||||
title: Workspace panel action model
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [tui, ticket, orchestration, panel]
|
||||
created_at: 2026-06-05T21:07:04Z
|
||||
updated_at: 2026-06-05T22:35:56Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The workspace panel should not be a plain Pod idle/working list. It should prioritize the items where the user needs to decide, respond, approve, or inspect evidence.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define and implement a workspace action model that can rank/display:
|
||||
- Intake needs user reply;
|
||||
- Intake draft ready;
|
||||
- Ticket ready for Go;
|
||||
- requirements sync needed;
|
||||
- preflight needed;
|
||||
- spike needed/running;
|
||||
- implementation running;
|
||||
- review needed;
|
||||
- blocked/action-required;
|
||||
- close-ready;
|
||||
- background informational Pod status.
|
||||
- Prefer Ticket/routing/intake state over raw Pod idle state.
|
||||
- Provide Go/Defer/Edit-style actions where supported by preceding tickets.
|
||||
- Preserve explicit human authorization boundaries.
|
||||
- Do not treat Pod completion notifications as authority; verify Ticket/Pod/output state.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Scheduler/lease/queue automation.
|
||||
- Full implementation of all role actions if earlier handoff/lifecycle tickets are not landed.
|
||||
- Generic issue tracker UI.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Panel displays user-action-required items above passive background Pods.
|
||||
- Ticket-ready Go action is easy to trigger but does not bypass Orchestrator routing/preflight gates.
|
||||
- Action model is testable as plain data independent of terminal rendering.
|
||||
- Existing multi-Pod status data can still be shown as lower-priority background information.
|
||||
@@ -1,20 +0,0 @@
|
||||
<!-- event: create author: yoi ticket at: 2026-06-05T21:07:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user