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:

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.

4.5 KiB Raw Blame History