How it works
The five-stage build cycle
Every item in the build queue ships through the same five stages, each with a referee that can refuse. This is the loop your agent is running while you supervise.
Once you unblock the first build, your agent takes work items off the queue one at a time and delivers each through the same five stages, in order. Two properties make the loop trustworthy: every stage ends in a commit, and every stage has a referee output it cannot proceed without.
The five stages
1. Define. The agent picks up the item's spec bundle, everything the chain knows about the work: its checks, its dependencies, its architectural context, and confirms a plan against every check in scope. The stage exists to stop the oldest failure in the book, building the wrong thing carefully.
2. Build. Implementation, to the agreed checks and nothing beyond them. Wanting to add something the plan did not ask for is an escalation back to the plan, not an improvisation in the code. As the code lands, the agent records which source files serve which checks, so the bridge between spec and code is written while the knowledge is fresh.
3. Review. The tree is re-validated, and the diff is re-read against every check in scope, deviations documented. This stage also hosts the fresh-context self-review at intervals: a reviewer with no memory of writing the code drives the running app against the item's checks. It reviews the product, not the diff.
4. Test. Tests are written until strict coverage holds over the item's checks: every check has a test case whose pointer resolves to a real test that runs. Any claim of "tested" made here names the runtime it ran against; a green suite is evidence about the runtime it ran on and nothing more.
5. Finalise. CI green, the work merged, the item marked complete after the merge, never before. Completion is refused while any in-scope check has no source file recorded against it. Then, separately, the finalise gate runs an independent verify against the deployed application, and only that gate can promote the item to verified. The gate can also run before any deployment exists: Close the loop without a deploy shows it against a local runtime, under an explicit parity assertion.
Why every stage commits
The commit is the stage boundary. It makes the cycle auditable in history, and it keeps a failed stage cheap to unwind: rolling back a bad review costs the review, not the build. A stage without its commit is not finished, by definition.
Why the cycle only moves forward
An item's lifecycle runs notStarted, inProgress, complete, verified, and the tooling refuses backward transitions outright, with a distinct exit code for the refusal. That is a design decision, not a limitation. If finished work needs reopening, something upstream changed, and the honest route is to change the chain: reopen the plan, adjust the checks, let impact name everything the change touches. A status quietly slid backwards is a history that lies. There is a deliberate manual override for genuine corrections, and reaching for it should be rare enough to be remarkable.
Self-review is not verification
The two checks at the end of the loop are easy to conflate and deliberately distinct. The fresh-context self-review is the cheap, in-loop check between builds: same machine, driving the app against its checks. The finalise gate is the independent verification: post-merge, against the deployed runtime, with authority to refuse, and it alone writes verified. One keeps the loop honest as it runs; the other is the reason the word verified means something at the end.
The full stage-by-stage guidance the agent works from, entry and exit contracts, escalation rules, failure modes, ships in the package and is published verbatim at the build-cycle playbook. The refusal codes are tabulated at exit codes.