ticket: use base32 project record ids
This commit is contained in:
@@ -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.
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Workspace panel action model"
|
||||
state: "closed"
|
||||
created_at: "2026-06-05T21:07:04Z"
|
||||
updated_at: "2026-06-05T23:31:28Z"
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,36 @@
|
||||
Implemented the first workspace panel action/model slice.
|
||||
|
||||
Changes:
|
||||
- Added `crates/tui/src/workspace_panel.rs` with a thin UI/action model:
|
||||
- `WorkspacePanelViewModel`
|
||||
- `WorkspacePanelHeader`
|
||||
- `PanelRow`
|
||||
- `PanelRowKey`
|
||||
- `TicketPanelEntry`
|
||||
- `ActionPriority`
|
||||
- `NextUserAction`
|
||||
- `TicketPanelPhase`
|
||||
- Added local-file-first Ticket row derivation through Rust Ticket config/backend APIs.
|
||||
- Ticket rows are gated on explicit workspace Ticket config. If `.yoi/ticket.config.toml` is absent, the panel suppresses Ticket UI and remains Pod-centric.
|
||||
- Added simple first-slice heuristics for intake/user reply, ready-for-Go, review needed, close ready, blocked, active work, backlog, and spike needed/running.
|
||||
- Ordinary open backlog Tickets remain background/non-action and are not promoted to `Go` by default.
|
||||
- Integrated the model into the current multi-Pod dashboard substrate so Ticket/action rows appear above passive Pod rows while preserving Pod selection, attach/open, and direct-send behavior.
|
||||
- Added `yoi panel` launch parsing and removed `--multi` as a user-facing launch route.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi`
|
||||
- `cargo test -p yoi panel`
|
||||
- `cargo test -p yoi parse_multi_flag_is_not_a_launch_alias`
|
||||
- `cargo check --workspace --all-targets`
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check HEAD~1..HEAD`
|
||||
- `cargo build -p yoi`
|
||||
- `target/debug/yoi ticket doctor`
|
||||
- `nix build .#yoi --no-link --print-out-paths`
|
||||
|
||||
External review approved after fixes.
|
||||
|
||||
Known follow-up:
|
||||
- Surface malformed Ticket config/read failures via panel diagnostics instead of silently falling back to Pod-only display when config exists but loading fails.
|
||||
- Layout/display tuning is intentionally deferred until the end-to-end panel flow exists.
|
||||
@@ -0,0 +1,84 @@
|
||||
<!-- 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`.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: review author: hare at: 2026-06-05T23:31:28Z status: approve -->
|
||||
|
||||
## Review: approve
|
||||
|
||||
External reviewer approved current HEAD after requested changes were addressed.
|
||||
|
||||
Review summary:
|
||||
- Spike classification is present and tested.
|
||||
- Ordinary open backlog Tickets remain background/non-action and are not promoted to `Go` by default.
|
||||
- Integration coverage verifies a Ticket action row above an idle Pod while preserving Pod open/direct-send behavior.
|
||||
- The model remains plain UI/action data; rendering and live socket I/O stay in existing TUI/Pod paths.
|
||||
- Ticket loading uses Rust Ticket config/backend APIs and does not shell out.
|
||||
- `yoi panel` is wired as the launch path; `--multi` is no longer accepted.
|
||||
- Missing Ticket config suppresses Ticket UI and leaves the panel Pod-centric.
|
||||
|
||||
Non-blocking follow-up: malformed Ticket config/read errors are currently silently ignored by the panel model. A later refinement should surface those through the existing diagnostics field when config exists but loading fails.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: close author: hare at: 2026-06-05T23:31:28Z status: closed -->
|
||||
|
||||
## Closed
|
||||
|
||||
Implemented the first workspace panel action/model slice.
|
||||
|
||||
Changes:
|
||||
- Added `crates/tui/src/workspace_panel.rs` with a thin UI/action model:
|
||||
- `WorkspacePanelViewModel`
|
||||
- `WorkspacePanelHeader`
|
||||
- `PanelRow`
|
||||
- `PanelRowKey`
|
||||
- `TicketPanelEntry`
|
||||
- `ActionPriority`
|
||||
- `NextUserAction`
|
||||
- `TicketPanelPhase`
|
||||
- Added local-file-first Ticket row derivation through Rust Ticket config/backend APIs.
|
||||
- Ticket rows are gated on explicit workspace Ticket config. If `.yoi/ticket.config.toml` is absent, the panel suppresses Ticket UI and remains Pod-centric.
|
||||
- Added simple first-slice heuristics for intake/user reply, ready-for-Go, review needed, close ready, blocked, active work, backlog, and spike needed/running.
|
||||
- Ordinary open backlog Tickets remain background/non-action and are not promoted to `Go` by default.
|
||||
- Integrated the model into the current multi-Pod dashboard substrate so Ticket/action rows appear above passive Pod rows while preserving Pod selection, attach/open, and direct-send behavior.
|
||||
- Added `yoi panel` launch parsing and removed `--multi` as a user-facing launch route.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi`
|
||||
- `cargo test -p yoi panel`
|
||||
- `cargo test -p yoi parse_multi_flag_is_not_a_launch_alias`
|
||||
- `cargo check --workspace --all-targets`
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check HEAD~1..HEAD`
|
||||
- `cargo build -p yoi`
|
||||
- `target/debug/yoi ticket doctor`
|
||||
- `nix build .#yoi --no-link --print-out-paths`
|
||||
|
||||
External review approved after fixes.
|
||||
|
||||
Known follow-up:
|
||||
- Surface malformed Ticket config/read failures via panel diagnostics instead of silently falling back to Pod-only display when config exists but loading fails.
|
||||
- Layout/display tuning is intentionally deferred until the end-to-end panel flow exists.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user