yoi/.yoi/tickets/closed/20260606-052903-workspace-panel-ticket-action-dispatch/item.md

id	slug	title	status	kind	priority	labels	created_at	updated_at	assignee	legacy_ticket
20260606-052903-workspace-panel-ticket-action-dispatch	workspace-panel-ticket-action-dispatch	Workspace panel Ticket action dispatch	closed	task	P1	tui ticket orchestration panel	2026-06-06T05:29:03Z	2026-06-06T06:04:40Z	null	null

Background

The first workspace panel implementation now has yoi panel, Ticket/action rows, Ticket-gated Orchestrator lifecycle, composer targets, and Intake -> Orchestrator handoff.

Ticket rows currently expose Go/Review/Close/Defer-style actions as display affordances only. To complete the first end-to-end panel before layout/display tuning, the panel needs minimal action dispatch for the user decision points it already displays.

Goal

Implement simple workspace panel Ticket action dispatch so selected Ticket/action rows can record the intended human decision through the Ticket backend and, where appropriate, notify the workspace Orchestrator.

Requirements

• Keep the UI/action model thin; do not build a scheduler/queue or a second Ticket state machine.
• Implement minimal dispatch for visible Ticket actions where safe:
  • Go / approve Intake-ready Ticket for Orchestrator routing/preflight;
  • Defer / move or mark pending where existing Ticket backend semantics support it;
  • Review / open or guide to existing review flow if full inline review is not safe in this first slice;
  • Close / do not close without a resolution; show a bounded diagnostic or require explicit resolution path.
• Re-check Ticket authority immediately before mutation; do not mutate based only on stale WorkspacePanelViewModel data.
• Record actions in .yoi/tickets through Rust Ticket APIs / Ticket tools; do not shell out.
• If an Orchestrator is live/reachable and the action is a routing/Go signal, notify it through existing Pod/peer/client mechanisms where feasible.
• No-Ticket workspaces must remain Pod-centric and expose no Ticket actions.
• Preserve existing selected-Pod send/open behavior.
• Keep layout changes minimal; final visual tuning is a later pass.

Non-goals

• Automatic implementation scheduling.
• Automatic coder/reviewer spawning.
• Full inline review editor.
• Final layout/display tuning.
• Reintroducing --multi.

Acceptance criteria

• Ticket/action rows no longer merely say display-only for every action; at least Go/Defer are actionable or explicitly disabled with a clear reason.
• Action dispatch re-checks current Ticket state before writing.
• Ticket mutations use Rust backend APIs and are visible in .yoi/tickets thread/status state.
• Orchestrator notification is attempted for Go/routing actions when feasible and reported as success/warning.
• No-Ticket panel remains functionally equivalent to Pod-centric dashboard.
• Tests cover action dispatch success, stale/invalid action rejection, no-Ticket behavior, and Pod actions remaining intact.