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
|
||||
labels: [ticket, pod, role, orchestration]
|
||||
created_at: 2026-06-05T19:03:30Z
|
||||
updated_at: 2026-06-05T19:06:16Z
|
||||
updated_at: 2026-06-05T19:07:09Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
|
|
|||
|
|
@ -27,4 +27,150 @@ Design decisions:
|
|||
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