Run Lifecycle

How runs.status and runs.gate_status move through creation, dispatch, finalization, cancellation, and terminal outcomes.

Notes

run create first inserts a non-dispatchable creating run with a durable placement ledger and chunk plan. Once every placement is seeded, one control transaction creates dispatch cursors and changes the run to pending.
Coordinators claim expired creation leases before dispatch work and resume pending placement seeds with the original run_id. Persisted-data conflicts fail creation without opening dispatch cursors.
Coordinator dispatch claims an open run_id + run_shard cursor, marks a new pending run as running, selects a bounded shard-local chunk window, and inserts one run.chunk.ready outbox event record per selected chunk.
Before dispatch and finalization, the coordinator recovers expired worker chunk leases or marks exhausted chunks failed.
Finalization only claims runs whose chunks are all terminal and whose finalization lease is open; pending or leased chunks keep the run out of finalization, including chunks waiting for execution retry windows.
Finalization verifies and merges one bounded scorecard per shard, applies the frozen run gates, and stores the scorecard with the final gate status under the same coordinator lease.
Cancellation applies to pending, running, and finalizing runs. A creating run is owned by the creation recovery workflow until it becomes pending or failed.