Build lifecycle & recovery

From request to reserved job

A new saved project begins as Requested. Its owner can prepare the source plan, changing it to Source review. A successful build reservation creates a queued job and changes the request to Queued.

The dispatcher requires a saved plan, an accepted license, a connected HTTPS runner and at least $10 available credit. It atomically reserves up to $25 and checks for an existing queued job. The same credit cannot be deliberately assigned to a second successful reservation.

Dispatch uses a stable job identifier

The request includes the job and request IDs, GitHub source URL, pinned commit, migration plan, chain target, USD cap and exact completion callback URL. The job ID is also the Idempotency-Key header.

The runner accepts the same job ID and identical payload without scheduling duplicate work. Reusing that ID with a different payload returns a conflict. If dispatch cannot be confirmed within the web request, the reservation stays held and the API returns a reconciliation message.

Runner states are separate from page labels

The runner stores queued, running and done states in its own durable job database. It processes one queued job at a time and gives its E2B sandbox a maximum lifetime of 600 seconds.

An interruption can leave interrupted or reconcile state; uncertain or excessive costs enter cost-review. These states require operator attention. The application’s queued job is not automatically updated for every runner transition, so the event feed provides finer-grained progress than the request label alone.

Events and completion retry independently

Public events are written to a durable outbox with a sequence number per job. Delivery retries send the same job/sequence pair, and the application ignores duplicate inserts. Callback delivery does not rerun paid model work.

A confirmed completion records a review or failed outcome and reported cost within the reservation. An accepted completion releases unused reserved credit and prevents duplicate settlement. The shipped runner sends a review completion for a finished artifact; ambiguous failures remain held for reconciliation.

Completion means an artifact is ready for review

A successful review callback changes the request to Review required. The artifact records supported patch content, source revision, command exit codes, model and limitations. A returned patch can contain incomplete work or no useful changes.

The broader interface includes release-stage labels, but the included request API does not automatically advance a job through Ready to deploy or Live. Those labels need real release and transaction evidence before use.

Recover without duplicating spend

• Preserve the runner’s durable database and find the existing job by its ID.
• Check whether dispatch was accepted, whether provider usage was charged and whether a final artifact exists.
• Retry event or completion delivery separately from code execution.
• Reconcile unknown costs before releasing credit or creating a new paid job.
• Inspect any partially published branch and avoid force-updating a branch that changed unexpectedly.