ticket: preflight ticket role launcher
This commit is contained in:
parent
3d4a76cda5
commit
ecd4a37d94
|
|
@ -0,0 +1,138 @@
|
||||||
|
# Delegation intent: Ticket role Pod launcher
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
Implement a reusable Ticket role Pod launcher so TUI and later CLI/orchestrator surfaces can launch fixed Ticket-role Pods without duplicating profile/config/workflow/prompt construction logic.
|
||||||
|
|
||||||
|
The launcher should use `.yoi/ticket.config.toml` fixed role configuration, generate first-run task content, and keep dynamic Ticket/action context in `Method::Run` input rather than hidden context injection.
|
||||||
|
|
||||||
|
## Worktree / branch
|
||||||
|
|
||||||
|
- worktree: `/home/hare/Projects/yoi/.worktree/ticket-role-pod-launcher`
|
||||||
|
- branch: `work/ticket-role-pod-launcher`
|
||||||
|
|
||||||
|
## 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 model-visible workflow input in the first run.
|
||||||
|
- Generate first committed user/task message content from a typed launch context.
|
||||||
|
- Keep selected Profile responsible for durable system/role behavior; do not add `system_instruction` support.
|
||||||
|
- Do not inject dynamic instructions into context outside history; first-run prompt/task content must go through `Method::Run`.
|
||||||
|
- Prefer a client-level API so TUI can use it without depending on `pod` crate internals.
|
||||||
|
- Avoid duplicating current runtime spawn internals if existing `client::spawn_pod`, `PodClient`, and `protocol::Method::Run` can be used cleanly.
|
||||||
|
- Expose a launch planning API even if full execution is constrained, so TUI work has a stable boundary.
|
||||||
|
|
||||||
|
## Suggested module placement
|
||||||
|
|
||||||
|
Preferred:
|
||||||
|
|
||||||
|
- `crates/client/src/ticket_role.rs`
|
||||||
|
- exports from `crates/client/src/lib.rs`
|
||||||
|
|
||||||
|
Rationale:
|
||||||
|
|
||||||
|
- `tui` already depends on `client`.
|
||||||
|
- `client` can depend on `ticket` without introducing `tui -> pod`.
|
||||||
|
- `client` owns host-side spawn/socket mechanics.
|
||||||
|
|
||||||
|
If current crate boundaries make full execution awkward, implement the pure planning API in `client` first and clearly report the execution gap.
|
||||||
|
|
||||||
|
## Suggested API shape
|
||||||
|
|
||||||
|
Exact names can change, but keep the surface typed:
|
||||||
|
|
||||||
|
```rust
|
||||||
|
pub enum TicketRoleLaunchKind {
|
||||||
|
Intake,
|
||||||
|
Orchestrator,
|
||||||
|
Coder,
|
||||||
|
Reviewer,
|
||||||
|
Investigator,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct TicketRoleLaunchContext {
|
||||||
|
pub workspace_root: PathBuf,
|
||||||
|
pub role: TicketRole,
|
||||||
|
pub pod_name: Option<String>,
|
||||||
|
pub ticket: Option<TicketRefLike>,
|
||||||
|
pub user_instruction: Option<String>,
|
||||||
|
pub intent_packet: Option<String>,
|
||||||
|
pub worktree_path: Option<PathBuf>,
|
||||||
|
pub branch: Option<String>,
|
||||||
|
pub validation: Vec<String>,
|
||||||
|
pub report_expectations: Vec<String>,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct TicketRoleLaunchPlan {
|
||||||
|
pub role: TicketRole,
|
||||||
|
pub pod_name: String,
|
||||||
|
pub profile: String,
|
||||||
|
pub workflow: String,
|
||||||
|
pub launch_prompt_ref: Option<String>,
|
||||||
|
pub run_segments: Vec<protocol::Segment>,
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Use existing `ticket::config::TicketRole` if practical rather than duplicating role enum. Avoid exposing pod internals.
|
||||||
|
|
||||||
|
## Prompt generation expectations
|
||||||
|
|
||||||
|
Generated first-run text should include:
|
||||||
|
|
||||||
|
- role name;
|
||||||
|
- Ticket id/slug if present;
|
||||||
|
- user/action instruction;
|
||||||
|
- workflow slug;
|
||||||
|
- launch_prompt ref if configured but unresolved;
|
||||||
|
- intent packet if provided;
|
||||||
|
- worktree path / branch if provided;
|
||||||
|
- validation/report expectations if provided;
|
||||||
|
- reminder that Profile supplies system/role behavior and the Workflow supplies process.
|
||||||
|
|
||||||
|
Prefer typed `Segment::WorkflowInvoke` plus text if current protocol/client path supports it. If not, include workflow slug in text and document the limitation.
|
||||||
|
|
||||||
|
## Non-goals
|
||||||
|
|
||||||
|
- TUI command/action UI.
|
||||||
|
- Stateful workflow engine.
|
||||||
|
- Phase-specific prompts/tool gating.
|
||||||
|
- Role-level `system_instruction` support.
|
||||||
|
- Prompt resource resolution if it requires moving prompt loader APIs across crates.
|
||||||
|
- Changing Profile resolution semantics.
|
||||||
|
- Changing `SpawnPod` tool semantics in the `pod` crate.
|
||||||
|
- Scheduler/lease/queue automation.
|
||||||
|
- Worktree creation automation.
|
||||||
|
|
||||||
|
## Validation
|
||||||
|
|
||||||
|
Run at least:
|
||||||
|
|
||||||
|
- `cargo test -p client ticket` or focused client tests;
|
||||||
|
- `cargo test -p ticket` if touched;
|
||||||
|
- `cargo check --workspace --all-targets`;
|
||||||
|
- `cargo fmt --check`;
|
||||||
|
- `git diff --check`;
|
||||||
|
- `./tickets.sh doctor`.
|
||||||
|
|
||||||
|
Run `nix build .#yoi --no-link` if feasible.
|
||||||
|
|
||||||
|
## Completion report
|
||||||
|
|
||||||
|
Report:
|
||||||
|
|
||||||
|
- worktree path / branch;
|
||||||
|
- commit hash;
|
||||||
|
- final module/API layout;
|
||||||
|
- whether launch execution is implemented or only planning;
|
||||||
|
- generated prompt / workflow segment behavior;
|
||||||
|
- how role profile config is used;
|
||||||
|
- validation results;
|
||||||
|
- unresolved risks/follow-ups;
|
||||||
|
- whether `tui-ticket-role-actions` can proceed.
|
||||||
|
|
@ -7,7 +7,7 @@ kind: task
|
||||||
priority: P1
|
priority: P1
|
||||||
labels: [ticket, pod, role, orchestration]
|
labels: [ticket, pod, role, orchestration]
|
||||||
created_at: 2026-06-05T19:03:30Z
|
created_at: 2026-06-05T19:03:30Z
|
||||||
updated_at: 2026-06-05T19:06:16Z
|
updated_at: 2026-06-05T19:07:09Z
|
||||||
assignee: null
|
assignee: null
|
||||||
legacy_ticket: null
|
legacy_ticket: null
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -27,4 +27,150 @@ Design decisions:
|
||||||
Follow-up after this lands: implement `tui-ticket-role-actions` using the launcher.
|
Follow-up after this lands: implement `tui-ticket-role-actions` using the launcher.
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- event: plan author: hare at: 2026-06-05T19:07:09Z -->
|
||||||
|
|
||||||
|
## Plan
|
||||||
|
|
||||||
|
# Delegation intent: Ticket role Pod launcher
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
Implement a reusable Ticket role Pod launcher so TUI and later CLI/orchestrator surfaces can launch fixed Ticket-role Pods without duplicating profile/config/workflow/prompt construction logic.
|
||||||
|
|
||||||
|
The launcher should use `.yoi/ticket.config.toml` fixed role configuration, generate first-run task content, and keep dynamic Ticket/action context in `Method::Run` input rather than hidden context injection.
|
||||||
|
|
||||||
|
## Worktree / branch
|
||||||
|
|
||||||
|
- worktree: `/home/hare/Projects/yoi/.worktree/ticket-role-pod-launcher`
|
||||||
|
- branch: `work/ticket-role-pod-launcher`
|
||||||
|
|
||||||
|
## 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 model-visible workflow input in the first run.
|
||||||
|
- Generate first committed user/task message content from a typed launch context.
|
||||||
|
- Keep selected Profile responsible for durable system/role behavior; do not add `system_instruction` support.
|
||||||
|
- Do not inject dynamic instructions into context outside history; first-run prompt/task content must go through `Method::Run`.
|
||||||
|
- Prefer a client-level API so TUI can use it without depending on `pod` crate internals.
|
||||||
|
- Avoid duplicating current runtime spawn internals if existing `client::spawn_pod`, `PodClient`, and `protocol::Method::Run` can be used cleanly.
|
||||||
|
- Expose a launch planning API even if full execution is constrained, so TUI work has a stable boundary.
|
||||||
|
|
||||||
|
## Suggested module placement
|
||||||
|
|
||||||
|
Preferred:
|
||||||
|
|
||||||
|
- `crates/client/src/ticket_role.rs`
|
||||||
|
- exports from `crates/client/src/lib.rs`
|
||||||
|
|
||||||
|
Rationale:
|
||||||
|
|
||||||
|
- `tui` already depends on `client`.
|
||||||
|
- `client` can depend on `ticket` without introducing `tui -> pod`.
|
||||||
|
- `client` owns host-side spawn/socket mechanics.
|
||||||
|
|
||||||
|
If current crate boundaries make full execution awkward, implement the pure planning API in `client` first and clearly report the execution gap.
|
||||||
|
|
||||||
|
## Suggested API shape
|
||||||
|
|
||||||
|
Exact names can change, but keep the surface typed:
|
||||||
|
|
||||||
|
```rust
|
||||||
|
pub enum TicketRoleLaunchKind {
|
||||||
|
Intake,
|
||||||
|
Orchestrator,
|
||||||
|
Coder,
|
||||||
|
Reviewer,
|
||||||
|
Investigator,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct TicketRoleLaunchContext {
|
||||||
|
pub workspace_root: PathBuf,
|
||||||
|
pub role: TicketRole,
|
||||||
|
pub pod_name: Option<String>,
|
||||||
|
pub ticket: Option<TicketRefLike>,
|
||||||
|
pub user_instruction: Option<String>,
|
||||||
|
pub intent_packet: Option<String>,
|
||||||
|
pub worktree_path: Option<PathBuf>,
|
||||||
|
pub branch: Option<String>,
|
||||||
|
pub validation: Vec<String>,
|
||||||
|
pub report_expectations: Vec<String>,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct TicketRoleLaunchPlan {
|
||||||
|
pub role: TicketRole,
|
||||||
|
pub pod_name: String,
|
||||||
|
pub profile: String,
|
||||||
|
pub workflow: String,
|
||||||
|
pub launch_prompt_ref: Option<String>,
|
||||||
|
pub run_segments: Vec<protocol::Segment>,
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Use existing `ticket::config::TicketRole` if practical rather than duplicating role enum. Avoid exposing pod internals.
|
||||||
|
|
||||||
|
## Prompt generation expectations
|
||||||
|
|
||||||
|
Generated first-run text should include:
|
||||||
|
|
||||||
|
- role name;
|
||||||
|
- Ticket id/slug if present;
|
||||||
|
- user/action instruction;
|
||||||
|
- workflow slug;
|
||||||
|
- launch_prompt ref if configured but unresolved;
|
||||||
|
- intent packet if provided;
|
||||||
|
- worktree path / branch if provided;
|
||||||
|
- validation/report expectations if provided;
|
||||||
|
- reminder that Profile supplies system/role behavior and the Workflow supplies process.
|
||||||
|
|
||||||
|
Prefer typed `Segment::WorkflowInvoke` plus text if current protocol/client path supports it. If not, include workflow slug in text and document the limitation.
|
||||||
|
|
||||||
|
## Non-goals
|
||||||
|
|
||||||
|
- TUI command/action UI.
|
||||||
|
- Stateful workflow engine.
|
||||||
|
- Phase-specific prompts/tool gating.
|
||||||
|
- Role-level `system_instruction` support.
|
||||||
|
- Prompt resource resolution if it requires moving prompt loader APIs across crates.
|
||||||
|
- Changing Profile resolution semantics.
|
||||||
|
- Changing `SpawnPod` tool semantics in the `pod` crate.
|
||||||
|
- Scheduler/lease/queue automation.
|
||||||
|
- Worktree creation automation.
|
||||||
|
|
||||||
|
## Validation
|
||||||
|
|
||||||
|
Run at least:
|
||||||
|
|
||||||
|
- `cargo test -p client ticket` or focused client tests;
|
||||||
|
- `cargo test -p ticket` if touched;
|
||||||
|
- `cargo check --workspace --all-targets`;
|
||||||
|
- `cargo fmt --check`;
|
||||||
|
- `git diff --check`;
|
||||||
|
- `./tickets.sh doctor`.
|
||||||
|
|
||||||
|
Run `nix build .#yoi --no-link` if feasible.
|
||||||
|
|
||||||
|
## Completion report
|
||||||
|
|
||||||
|
Report:
|
||||||
|
|
||||||
|
- worktree path / branch;
|
||||||
|
- commit hash;
|
||||||
|
- final module/API layout;
|
||||||
|
- whether launch execution is implemented or only planning;
|
||||||
|
- generated prompt / workflow segment behavior;
|
||||||
|
- how role profile config is used;
|
||||||
|
- validation results;
|
||||||
|
- unresolved risks/follow-ups;
|
||||||
|
- whether `tui-ticket-role-actions` can proceed.
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue
Block a user