## 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. ---