Delegation intent: Ticket Intake -> Orchestrator handoff

Classification

implementation-ready after Orchestrator lifecycle and composer target slices.

yoi panel now opens the workspace panel, ensures a workspace Orchestrator for Ticket-enabled workspaces, and can launch a Ticket Intake Pod from the composer. This ticket connects those pieces with an explicit handoff contract.

Intent

When the panel launches a Ticket Intake Pod, provide the workspace Orchestrator as the Intake's notification/handoff target so the Intake can report clarified Ticket readiness to the Orchestrator. The handoff must be visible in the destination Pod's committed input/history or durable peer metadata, not hidden context.

The handoff should not authorize implementation automatically. It only tells Intake where to report readiness or follow-up state after Intake has clarified and materialized/agreed a Ticket.

Worktree / branch

worktree: /home/hare/Projects/yoi/.worktree/ticket-intake-orchestrator-handoff
branch: work/ticket-intake-orchestrator-handoff

This ticket may read tracked .yoi/tickets records/design artifacts. Do not read or edit .yoi/memory/.

Requirements

Define a simple handoff contract from workspace panel to Intake.
- Include Orchestrator Pod name.
- Include that Intake should notify/report to the Orchestrator when it has enough information for routing/preflight.
- State clearly that implementation must not start automatically; human Go / Orchestrator routing gates still apply.
Carry the handoff through the existing Ticket role launch path where practical.
- Prefer adding explicit fields/options to TicketRoleLaunchContext or equivalent over ad hoc string assembly in TUI.
- Do not duplicate role prompt/profile construction in TUI.
Register Intake and Orchestrator as peers when both are live/reachable if existing RegisterPeer semantics make this feasible.
- Registration failure should be a bounded diagnostic/warning, not a reason to lose the Intake launch if the launch itself succeeded.
- Do not rely only on an LLM-internal instruction if a durable peer metadata path is available.
Include the handoff instruction in the Intake launch input/history so the Intake can explain why it may notify the Orchestrator in later turns.
- Do not inject hidden context only.
- Do not append the Intake request to Companion/current Pod history.
Add panel success/failure diagnostics for handoff setup separately from Intake launch success.
No-Ticket workspace must not expose this path.
Keep Orchestrator as background coordinator; do not make it foreground composer target by default.
Keep the contract small and typed enough to test, but do not build a scheduler/queue.

Suggested contract shape

A small data type is preferred over freeform string construction in the panel:

TicketIntakeHandoff {
    orchestrator_pod: String,
    workspace_label: String,
}

The role launcher can render this into the Intake user_instruction as an explicit section, for example:

Panel handoff:
- Workspace Orchestrator Pod: <name>
- When Intake has clarified the request and created/updated the Ticket, notify/report readiness to this Orchestrator.
- Do not start implementation automatically; wait for Orchestrator routing/preflight and human Go gates.

If peer registration is implemented, Intake should also receive durable peer metadata for the Orchestrator using the existing Pod peer registration path.

Non-goals

Automatic implementation scheduling.
Queue/lease system.
Full Ticket action model refinement.
Final layout/display tuning.
Generic arbitrary handoff routing.
Reintroducing --multi.

Current code map

crates/tui/src/multi_pod.rs
- Panel composer target handling and Intake launch path.
crates/tui/src/workspace_panel.rs
- Orchestrator state/name and composer target view state.
crates/client/src/ticket_role.rs
- Role launch context and prompt/input assembly; preferred place for typed handoff fields.
crates/protocol/src/lib.rs
- Method::RegisterPeer / Event::PeerRegistered semantics.
crates/pod/src/controller.rs
- Peer registration handling for reference.
crates/tui/src/socket.rs / existing client helpers
- Reuse existing socket/method helpers where practical; do not hand-roll protocol loops unnecessarily.

Validation

Run at least:

targeted tests for role launch input rendering with handoff;
targeted tests for panel Intake launch including handoff data;
targeted tests for peer registration success/failure behavior if implemented;
cargo test -p client ticket_role;
cargo test -p tui workspace_panel;
cargo test -p tui multi_pod or updated panel test names;
cargo test -p yoi panel;
cargo check --workspace --all-targets;
cargo fmt --check;
git diff --check;
cargo build -p yoi;
target/debug/yoi ticket doctor.

Run nix build .#yoi --no-link if feasible.

Completion report

Report:

worktree path / branch;
commit hash;
final handoff contract/data type;
how Orchestrator target is included in Intake input/history;
whether/how peer registration is performed;
launch vs handoff diagnostic behavior;
proof no Companion/current Pod history mutation is used for Intake body;
tests updated/added;
validation results;
known follow-up layout/display tuning items.

5.3 KiB Raw Blame History