ticket: use base32 project record ids

2026-06-09 22:10:47 +09:00
parent 0803bc3725
commit 4203988d74
798 changed files with 477 additions and 105 deletions
@@ -0,0 +1,88 @@
+---
+title: "TUI Ticket role actions"
+state: "closed"
+created_at: "2026-06-05T19:03:30Z"
+updated_at: "2026-06-05T20:09:50Z"
+---
+
+## Background
+
+After `ticket-role-pod-launcher` lands, TUI should expose simple Ticket-role actions without embedding launch/profile/prompt/workflow construction logic in UI code.
+
+This ticket is for the TUI surface only. The launcher is responsible for reading `.yoi/ticket.config.toml`, selecting the Profile, constructing first-run input, and launching/sending to a role Pod. TUI should call that layer and present conservative, understandable actions.
+
+## Goal
+
+Add TUI actions for fixed Ticket roles using the shared Ticket role launcher.
+
+The initial UI should favor explicit command/action entry over broad dashboard redesign. It should make it possible to start the relevant role Pod for a Ticket-oriented task while preserving human/orchestrator control.
+
+## Requirements
+
+- Depend on the shared `ticket-role-pod-launcher` API; do not duplicate launch construction in TUI.
+- Support fixed Ticket role actions:
+  - Intake / refine Ticket;
+  - Route Ticket with Orchestrator;
+  - Investigate Ticket;
+  - Implement Ticket;
+  - Review Ticket.
+- Use `.yoi/ticket.config.toml` indirectly through the launcher.
+- Show clear diagnostics/notices when:
+  - Ticket config is malformed;
+  - backend root is unusable;
+  - selected Profile is invalid or spawn fails;
+  - required Ticket id/slug/context is missing.
+- Keep actions explicit and user-triggered. Do not introduce automatic scheduling.
+- Do not add a spawned-Pod panel in this ticket.
+- Do not add a generic arbitrary-role launcher UI.
+- Do not bypass Ticket Intake / Orchestrator Routing / Preflight / Multi-agent Workflow gates.
+- Prefer command/actionbar integration first if that is less invasive than adding a new full screen.
+
+## Candidate command surface
+
+Exact names may change during implementation, but the MVP should be close to:
+
+```text
+:ticket intake <ticket-or-new-context>
+:ticket route <ticket-id-or-slug>
+:ticket investigate <ticket-id-or-slug>
+:ticket implement <ticket-id-or-slug>
+:ticket review <ticket-id-or-slug>
+```
+
+If current TUI command parsing makes nested subcommands awkward, use a simpler MVP shape such as:
+
+```text
+:ticket-intake ...
+:ticket-route ...
+:ticket-investigate ...
+:ticket-implement ...
+:ticket-review ...
+```
+
+## Non-goals
+
+- Implementing the role launcher.
+- TUI spawned child Pod panel.
+- Multi-Pod dashboard redesign.
+- Scheduler/lease/queue automation.
+- Stateful workflow engine.
+- TicketUpdate tool.
+- Worktree creation automation beyond what the launcher/Multi-agent Workflow already describes.
+- Generic Role registry/UI.
+- Arbitrary filesystem Ticket edits.
+
+## Acceptance criteria
+
+- TUI has user-triggered Ticket role actions/commands for the fixed roles or a clearly documented MVP subset.
+- Actions call the shared launcher rather than building spawn requests directly.
+- Role action failures surface as actionbar/command diagnostics without crashing TUI.
+- The command/action help text makes clear what each role does.
+- TUI tests cover parsing/execution path for actions and at least one failure diagnostic.
+- `cargo test -p tui` or focused TUI tests pass.
+- `cargo test -p client` passes if the launcher crate is touched by integration.
+- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass.
+
+## Dependencies
+
+- Requires `ticket-role-pod-launcher`.