How it works
The five-stage build cycle
Every build item follows five stages: Define, Build, Review, Test and Finalise. Each stage has its own hand and ends in a commit, and each has its own check.
Once you unblock the first build, your agent takes work items from the queue one at a time. Each follows the five stages in order. Every stage ends in a commit, and every stage has its own hand, named in each commit's Hand: trailer, so the agent that writes the code is never the one that writes its tests or checks it.
The five stages
1. Define. Hand: test-author. The agent picks up the item's spec bundle, everything the chain knows about the work: its checks, its dependencies, its architectural context. The test-author writes the tests for every check in scope first, the acceptance and end-to-end tests and the test cases that point at them, and proves each one fails for the right reason before any code exists. Strict coverage must hold over them. The test-author never writes production code.
2. Build. Hand: builder. Implementation, until the failing tests pass, 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 builder records which source files serve which checks, so the bridge between spec and code is written while the knowledge is fresh. The builder writes production code and its own housekeeping unit tests only, never a test for a check or the check itself.
3. Review. Hand: reviewer. The tree is re-validated, rcf audit separation confirms each commit stayed inside its hand's paths, and the diff is re-read against every check in scope, deviations documented. The reviewer returns MERGE or a list of findings. Separate from this stage, the fresh-context self-review runs between builds every few FBS items and once at the end: 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. Hand: verifier. The independent verification happens here, before the merge. The verifier runs rcf verify run --fbs <fbs-id> --hand verifier against the preview or version host serving the reviewed head, a local server serving it (naming the engine and the served commit), or the packed package, and commits the report it writes under rcf/verify-reports/. The work merges only on a Review MERGE and a Test PASS at the same head. Any claim of "verified" or "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. Hand: stage-keeper. On the pull-request branch, before the merge: CI green on the PR head, then the item marked complete. Completion is refused while any in-scope check has no source file recorded against it. Then the finalise gate, rcf build finalise <fbs-id> --ci-run <ref>, reads the Test-stage report committed on the branch and names the CI run that passed on the head the report names. It runs no verify of its own; it refuses a report that is not committed at HEAD or has changed since, one whose head HEAD does not contain, a loopback report that does not name its engine, port and served commit, one whose verifier is also a builder, or one too old. Only that gate can promote the item to verified, and that write is committed on the branch, so the merge carries it. No production deployment is needed: Close the loop without a deploy shows the local-server, preview-host and packed-package routes. The gate also refuses while any in-scope non-deterministic AC is missing its evaluation or its most recent run is below its threshold; a named opt-out lets you acknowledge the shortfall on the ship manifest so a deliberate degraded ship reads as a written decision rather than a silent skip. For a UI-bearing item, a browser-verification pass also runs: your agent drives the running app through the probe packs an applied blueprint declares against it, and the finalise gate refuses on any block-severity pack failure. Anything a pack does not actually probe stays outside the gate.
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. Moving status backwards without recording the changed intent obscures the history. 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 independent verification is the Test stage: a separate verifier hand, against the preview or version host, a local server or the packed package, with authority to refuse the merge. The finalise gate reads that report on the branch before the merge, and it alone writes verified. Self-review checks the work between builds. Independent verification provides the evidence required for verified status.
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.