ticket: plan ticket role launcher ui
This commit is contained in:
parent
e1215c79be
commit
3d4a76cda5
111
work-items/open/20260605-190330-ticket-role-pod-launcher/item.md
Normal file
111
work-items/open/20260605-190330-ticket-role-pod-launcher/item.md
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
id: 20260605-190330-ticket-role-pod-launcher
|
||||
slug: ticket-role-pod-launcher
|
||||
title: Ticket role Pod launcher
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, pod, role, orchestration]
|
||||
created_at: 2026-06-05T19:03:30Z
|
||||
updated_at: 2026-06-05T19:06:16Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Ticket orchestration now has:
|
||||
|
||||
- typed Ticket backend and tools;
|
||||
- Ticket Intake and Orchestrator Routing workflows;
|
||||
- fixed Ticket role config in `.yoi/ticket.config.toml`.
|
||||
|
||||
TUI and future CLI/orchestration UI should not construct role-specific Pod launch requests by hand. Before adding TUI Ticket role actions, introduce a reusable launcher layer that turns a fixed Ticket role plus context into a Pod spawn/run request.
|
||||
|
||||
This layer should keep the Profile/SystemInstruction boundary intact: the selected Profile owns durable role/system behavior, while the launcher creates the first committed user/task message for a concrete Ticket/action and includes the workflow reference as explicit model-visible input.
|
||||
|
||||
## Goal
|
||||
|
||||
Add a reusable Ticket role Pod launcher API that can be used by TUI and later CLI/orchestrator surfaces.
|
||||
|
||||
MVP should construct and optionally execute host-side Pod launches for fixed Ticket roles using `.yoi/ticket.config.toml`, selected Profile selector, workflow ref, and generated initial task prompt.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Support fixed Ticket roles only:
|
||||
- `intake`
|
||||
- `orchestrator`
|
||||
- `coder`
|
||||
- `reviewer`
|
||||
- `investigator`
|
||||
- Load `.yoi/ticket.config.toml` through `ticket::config::TicketConfig`.
|
||||
- Use role `profile` selector as the child Pod profile selector.
|
||||
- Use role `workflow` ref as a model-visible workflow invocation / workflow instruction in the first `Method::Run`.
|
||||
- Generate a first committed user/task message from a typed launch context.
|
||||
- Keep Profile-owned system instruction separate from the generated launch prompt.
|
||||
- Do not add a role-level `system_instruction` override.
|
||||
- Do not perform hidden context injection; everything dynamic must be sent as `Method::Run` input.
|
||||
- Provide a launch planning API usable by TUI without depending on `pod` crate internals.
|
||||
- Prefer placing the launcher in `client` if that keeps TUI dependency direction clean:
|
||||
- `tui -> client -> ticket/protocol/manifest`;
|
||||
- avoid `tui -> pod`.
|
||||
- If implementing actual launch execution, use existing `client::spawn_pod` and `client::PodClient` / `protocol::Method::Run` where appropriate.
|
||||
- Generate stable, testable Pod names or accept caller-provided names.
|
||||
- Keep launch prompt text bounded and deterministic enough for tests.
|
||||
- Include enough context for each role without over-scoping:
|
||||
- target Ticket id/slug;
|
||||
- user instruction or routing/action summary;
|
||||
- workflow slug;
|
||||
- optional intent packet;
|
||||
- optional worktree path / branch;
|
||||
- optional validation/report expectations.
|
||||
|
||||
## Launch prompt / workflow semantics
|
||||
|
||||
The first run should separate content like this:
|
||||
|
||||
- Profile supplies the system/role behavior.
|
||||
- Workflow ref supplies the procedural flow to follow.
|
||||
- Generated launch prompt supplies this specific Ticket/action context.
|
||||
|
||||
Prefer `Method::Run` with typed `Segment::WorkflowInvoke { slug }` plus `Segment::Text { content }` when practical. If a workflow segment is not viable in the immediate integration point, include the workflow slug explicitly in the generated text and document the limitation.
|
||||
|
||||
Configured `launch_prompt` refs may remain unresolved in the MVP if prompt-resource resolution is not available below `pod`; they should be exposed in the launch plan for future resolution and not silently treated as system instruction.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- TUI action UI.
|
||||
- Arbitrary role registry.
|
||||
- Scheduler/lease/queue automation.
|
||||
- Stateful workflow engine.
|
||||
- Phase-specific tool gating.
|
||||
- Role-level `system_instruction` support.
|
||||
- Changing Profile resolution semantics.
|
||||
- Changing `SpawnPod` tool semantics inside the `pod` crate.
|
||||
- Implementing coder/reviewer worktree creation policy.
|
||||
- Broad Pod registry/metadata redesign.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- A reusable launch plan/API exists for fixed Ticket roles.
|
||||
- The launcher reads `.yoi/ticket.config.toml` defaults and configured role profile/workflow/launch_prompt refs.
|
||||
- Profile selector selected for the role is available for spawn config.
|
||||
- Dynamic task content is represented as first-run input, not hidden system/context injection.
|
||||
- Workflow slug is included as a typed workflow segment or explicit model-visible instruction.
|
||||
- TUI can consume the API without depending on `pod` internals.
|
||||
- Tests cover:
|
||||
- default config role launch plan;
|
||||
- configured role profile/workflow/launch_prompt refs;
|
||||
- generated prompt content for at least intake/orchestrator/reviewer;
|
||||
- caller-provided Pod name;
|
||||
- missing/malformed Ticket config error surfacing;
|
||||
- no `system_instruction` handling.
|
||||
- `cargo test -p client` or chosen crate tests pass.
|
||||
- `cargo test -p ticket` passes if touched.
|
||||
- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass.
|
||||
|
||||
## Follow-up tickets
|
||||
|
||||
- `tui-ticket-role-actions`: expose fixed Ticket role actions in TUI using this launcher.
|
||||
- Prompt resolution follow-up: resolve `launch_prompt` refs into first-run content once a suitable prompt-resource API exists below/available to the launcher.
|
||||
- Workflow-state follow-up: persist phase/state and commit phase prompts to history before model use.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T19:03:30Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T19:06:16Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Preflight result: `implementation-ready`.
|
||||
|
||||
Implement `ticket-role-pod-launcher` before TUI actions so TUI does not own role/profile/prompt/workflow launch construction.
|
||||
|
||||
Design decisions:
|
||||
|
||||
- Fixed Ticket roles only: intake, orchestrator, coder, reviewer, investigator.
|
||||
- Role profile/workflow/launch_prompt refs come from `.yoi/ticket.config.toml`.
|
||||
- Profile owns durable role/system behavior.
|
||||
- Launcher generates the first committed user/task message for a concrete Ticket/action.
|
||||
- Dynamic content must be sent through `Method::Run`, not hidden context injection.
|
||||
- Prefer a client-level API so TUI can use it without depending on `pod` internals.
|
||||
- Configured `launch_prompt` refs may be exposed but not resolved if no suitable prompt-resource API exists below `pod`; do not treat them as system instruction.
|
||||
|
||||
Follow-up after this lands: implement `tui-ticket-role-actions` using the launcher.
|
||||
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
id: 20260605-190330-tui-ticket-role-actions
|
||||
slug: tui-ticket-role-actions
|
||||
title: TUI Ticket role actions
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [tui, ticket, role, orchestration]
|
||||
created_at: 2026-06-05T19:03:30Z
|
||||
updated_at: 2026-06-05T19:06:17Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## 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`.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T19:03:30Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T19:06:17Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Plan: implement after `ticket-role-pod-launcher` lands.
|
||||
|
||||
TUI should expose explicit user-triggered Ticket role actions/commands and call the shared launcher. It should not duplicate profile/config/prompt/workflow launch construction, introduce automatic scheduling, or add a spawned-Pod panel in this ticket.
|
||||
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user