Problem
Made’s status response projects a fixed nine-stage list, but the durable run record still appears to store only completed/skipped stage entries. Stage start is primarily an ephemeral event, current_stage is inferred from the first non-pass result, and required-stage validation can occur after earlier stages have already executed.
This creates inaccurate status, weak restart boundaries, possible duplicate stage rows, and delayed configuration failure.
Required implementation
- Initialize every run with exactly one durable record for each canonical stage:
- intent
- rebase
- review
- test
- document
- lint
- push
- pr
- ci
- Replace result-only semantics with stage states:
- pending
- running
- waiting
- passed
- failed
- skipped
- Before a stage executes, durably transition
pending -> running.
- When a review/document gate waits for a decision, durably transition
running -> waiting.
- On completion, update the existing stage in place:
running -> passed|failed
waiting -> passed|failed
pending -> skipped
- Persist per-stage:
- state
- message
- error
- started timestamp
- ended timestamp
- evidence references
- Define
current_stage as the one stage in running or waiting; it must be null otherwise.
- A skipped stage must never become current.
- A failed stage must not remain current after execution finishes.
- Prevent duplicate rows and reject invalid transitions.
- Resolve and semantically validate the complete effective config before Intent starts.
- Refuse required disabled stages, missing commands, unsupported agents, or invalid delivery policy before any pipeline stage runs.
- Remove late
requireDeliveryStages behavior once preflight owns this invariant.
- Preserve the last durable stage boundary across restart and report interrupted execution truthfully.
- Update the public status schema/version as required.
Acceptance criteria
- Every status response contains every canonical stage exactly once from submission onward.
- A stage is durably
running before its work starts.
- Review/document stages are durably
waiting while parked.
current_stage is correct and null for awaiting-merge or terminal runs.
- Required invalid configuration fails before Intent or any worktree-side stage.
- No duplicate stage rows can be produced.
- Restart preserves the last durable stage state.
Required tests
- initial fixed stage table
- every valid transition
- invalid transition rejection
- current-stage behavior for running/waiting/skipped/failed/terminal states
- duplicate update attempts
- required disabled stage preflight
- missing Test command preflight
- unsupported agent preflight
- restart during each stage state
- status-schema compatibility tests
Problem
Made’s status response projects a fixed nine-stage list, but the durable run record still appears to store only completed/skipped stage entries. Stage start is primarily an ephemeral event,
current_stageis inferred from the first non-pass result, and required-stage validation can occur after earlier stages have already executed.This creates inaccurate status, weak restart boundaries, possible duplicate stage rows, and delayed configuration failure.
Required implementation
pending -> running.running -> waiting.running -> passed|failedwaiting -> passed|failedpending -> skippedcurrent_stageas the one stage inrunningorwaiting; it must be null otherwise.requireDeliveryStagesbehavior once preflight owns this invariant.Acceptance criteria
runningbefore its work starts.waitingwhile parked.current_stageis correct and null for awaiting-merge or terminal runs.Required tests