diff --git a/work-items/open/20260605-190330-ticket-role-pod-launcher/artifacts/.gitkeep b/work-items/open/20260605-190330-ticket-role-pod-launcher/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/work-items/open/20260605-190330-ticket-role-pod-launcher/item.md b/work-items/open/20260605-190330-ticket-role-pod-launcher/item.md new file mode 100644 index 00000000..7fc196bb --- /dev/null +++ b/work-items/open/20260605-190330-ticket-role-pod-launcher/item.md @@ -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. diff --git a/work-items/open/20260605-190330-ticket-role-pod-launcher/thread.md b/work-items/open/20260605-190330-ticket-role-pod-launcher/thread.md new file mode 100644 index 00000000..cab26f81 --- /dev/null +++ b/work-items/open/20260605-190330-ticket-role-pod-launcher/thread.md @@ -0,0 +1,30 @@ + + +## Created + +Created by tickets.sh create. + +--- + + + +## 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. + + +--- diff --git a/work-items/open/20260605-190330-tui-ticket-role-actions/artifacts/.gitkeep b/work-items/open/20260605-190330-tui-ticket-role-actions/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/work-items/open/20260605-190330-tui-ticket-role-actions/item.md b/work-items/open/20260605-190330-tui-ticket-role-actions/item.md new file mode 100644 index 00000000..5b736c13 --- /dev/null +++ b/work-items/open/20260605-190330-tui-ticket-role-actions/item.md @@ -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 route +:ticket investigate +:ticket implement +:ticket review +``` + +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`. diff --git a/work-items/open/20260605-190330-tui-ticket-role-actions/thread.md b/work-items/open/20260605-190330-tui-ticket-role-actions/thread.md new file mode 100644 index 00000000..c8d4c1dc --- /dev/null +++ b/work-items/open/20260605-190330-tui-ticket-role-actions/thread.md @@ -0,0 +1,18 @@ + + +## Created + +Created by tickets.sh create. + +--- + + + +## 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. + + +---