yoi/.yoi/tickets/open/20260607-020215-workspace-panel-orchestrator-queue-automation/thread.md

1.6 KiB

Created

Created by LocalTicketBackend create.


Decision

In-progress acceptance contract

workflow_state = inprogress should be the durable Orchestrator acceptance marker, not merely proof that a coder Pod is already running.

Contract:

  • ready: materialized Ticket waiting for the human Queue gate.
  • queued: human has authorized Orchestrator routing; Orchestrator should inspect Ticket/workspace state and start if unblocked.
  • inprogress: Orchestrator has accepted the queued Ticket and owns coordination/progress/block/failure reporting until completion or explicit defer/block.

Ordering invariant:

  • Orchestrator must not create implementation worktrees or spawn implementation/review Pods for a queued Ticket unless the Ticket has already been accepted as inprogress, or the same typed operation atomically accepts it.
  • If queued -> inprogress fails, do not spawn implementation Pods.
  • If side effects fail after inprogress acceptance, record the failure/block under the in-progress Ticket rather than silently returning to queued or starting a duplicate path.

Short-term implementation may enforce this through Orchestrator workflow/prompt text plus the existing typed workflow-state tool. Longer-term, prefer a typed Orchestrator operation such as AcceptQueuedTicket / StartTicketWork that validates queued, records the acceptance transition, establishes any local claim/lease, and only then allows worktree/Pod launch.