Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

ticket: record orchestrator inprogress contract

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-07 11:35:26 +09:00
parent b660e790c6
commit 4eefc0f87e
No known key found for this signature in database
2 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.yoi/tickets/open/20260607-020215-workspace-panel-orchestrator-queue-automation/item.md
View File

@ -8,7 +8,7 @@ priority: P1
labels: [panel, orchestrator, ticket, automation, workflow]
workflow_state: intake
created_at: 2026-06-07T02:02:15Z
updated_at: 2026-06-07T02:02:15Z
updated_at: 2026-06-07T02:35:20Z
assignee: null
legacy_ticket: null
---

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

@ -5,3 +5,25 @@
Created by LocalTicketBackend create.
---
<!-- event: decision author: hare at: 2026-06-07T02:35:20Z -->
## 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.
---