yoi/.yoi/tickets/open/20260607-035143-orchestrator-queued-ticket-routing/thread.md

Created

Created by LocalTicketBackend create.

---

Plan

Preflight / implementation intent

Classification: implementation-ready first slice of Orchestrator automation.

Intent:

• Implement the queued Ticket routing entrypoint without starting coder/reviewer/worktree routing in this ticket.
• Panel Queue should notify the workspace Orchestrator with active routing semantics: read Ticket/workspace state and start if unblocked.
• Orchestrator workflow/prompt should define queued -> inprogress as the acceptance marker that must happen before implementation side effects.

Requirements:

• Update Panel Queue notice and Orchestrator notification text away from passive/implementation-not-started semantics.
• Notification must include Ticket id/slug/title where practical and instruct:
  • read the Ticket;
  • inspect current workspace state;
  • if unblocked, transition queued -> inprogress before worktree/SpawnPod side effects;
  • if blocked, record a concise reason and leave queued or explicitly defer.
• Update ticket-orchestrator-routing workflow guidance to reflect queued-trigger routing and the acceptance-order invariant.
• Do not implement worktree/coder/reviewer routing here; that belongs to orchestrator-worktree-agent-routing.
• Do not implement merge/close completion here; that belongs to orchestrator-merge-completion.
• Do not implement the orchestration plan tool here; ticket-orchestration-plan-tool owns durable ordering/dependency/conflict notes.

Current code map:

• crates/tui/src/multi_pod.rs
  • Queue action around dispatch_ticket_action currently says No implementation was started.
  • notify_workspace_orchestrator currently says Do not start implementation directly from this notification; follow routing/preflight gates.
  • Tests around Queue outcome and notify-only path are nearby.
• .yoi/workflow/ticket-orchestrator-routing.md
  • Currently says this workflow is not an unattended scheduler and requires human/upper Orchestrator permission before coder/reviewer spawn.
  • It should be updated so queued notifications are treated as human authorization to route; implementation side effects still require queued -> inprogress acceptance first.
• crates/ticket/src/tool.rs
  • TicketWorkflowState tool/backend already enforce allowed transitions; do not duplicate transition enforcement in panel text.

Validation:

• Update focused tests for Queue notice / notification wording.
• Run cargo test -p tui multi_pod --lib.
• Run prompt/resource relevant checks if available, otherwise target/debug/yoi ticket doctor, cargo fmt --check, and git diff --check.

---

Intake summary

Implementation-ready first slice: update Panel Queue notification/notice and Orchestrator routing workflow so queued Tickets actively trigger Orchestrator routing, with queued -> inprogress acceptance required before worktree/SpawnPod side effects. Worktree/coder/reviewer and merge completion remain separate follow-up tickets.

---

State changed

Ticket intake complete; workflow_state intake -> ready.

---

Implementation report

Delegation

Implementation delegated to child Pod orchestrator-routing-coder-20260607 in worktree .worktree/orchestrator-queued-ticket-routing on branch work/orchestrator-queued-ticket-routing.

Scope:

• Update Panel Queue notice and Orchestrator notification wording to actively trigger routing.
• Preserve the contract that implementation side effects occur only after queued -> inprogress acceptance.
• Update focused TUI tests.
• Do not implement worktree/coder/reviewer routing, merge completion, or the orchestration plan tool in this ticket.

Workflow note:

• Child worktree excludes .yoi, so workflow file updates under .yoi/workflow must be reported back for parent-side application rather than edited in the child worktree.

The child should commit implementation work in the child worktree and report diff/tests. Merge, review, Ticket closure, workflow file updates, and cleanup remain with the parent/human workflow.

---