Plan, implement, and review across providers

Start with a task whose result you can verify. Assign planning, implementation, and review roles to configured tools, while the coordinator owns dependencies and the human owns unresolved design and acceptance decisions.

The example uses Claude Code for a plan, Codex for a proposed change, and Claude Code plus Gemini CLI for independent reviews. Change those assignments when your evaluations support a better combination.

Run the full fixture

The reference package contains an implementation recipe:

node cli.mjs new ./implementation-run --recipe implementation

Review and decide the scope gate, then run eligible stages. The next decision is the design gate. It shows a plan to correct one retry-configuration value, the contract that supports the change, and the checks that will follow.

Use node cli.mjs status ./implementation-run whenever you need the current packet and digest. A decision does not automatically launch the next stage; node cli.mjs run ./implementation-run advances the approved work.

1. Humanapprove scope
2. Claude Codepropose plan
3. Humandecide design
4. Codexpropose change
5. Checks and reviewsgather evidence
6. Humanaccept or revise

All provider stages use recorded fixtures by default. The result is a local candidate configuration, not a commit in your project.

For configured tool execution, use CLI stages between human decisions. The same recipe can supervise native processes through a reviewed execution profile while retaining its scope, design, and acceptance gates.

Keep one owner of each change

The fixture's writer can return a new value for retry-policy.json only. The coordinator validates the closed schema and constructs a new artifact. The original snapshot remains available.

For a real source-code task, prepare a dedicated branch or worktree for each writer, record its base revision, and choose one integration owner. A worktree separates changes. The execution sandbox and credential policy determine what the tool and the code it runs can access.

The reference runner intentionally accepts only its JSON configuration task. Adapting it to arbitrary code requires a reviewed writer adapter, sandbox, and check executor. Treat that as an implementation change with its own tests.

Preserve independent verification

The fixture checker lives in the coordinator and evaluates the candidate as data. A proposed replacement test file cannot make the check pass.

For a repository change, keep baseline acceptance definitions under the coordinator's control. Run the agreed commands and retain real exit status and logs. If changing a test is part of the feature, include that change in the review packet before relying on the revised test as evidence.

Reviewers read the same original source, candidate, and check results. They cannot edit the writer's workspace through a review result.

Make revision a bounded branch

The recipe allows one human-requested revision and at most two attempts per model stage. At the acceptance gate, choose revise to invalidate the writer and its dependent checks, reviews, and acceptance decision.

The next run produces new artifacts. Earlier artifacts remain in the inventory, so you can see what changed. An approval digest from the previous candidate cannot approve the revised result.

If the allowed revision still fails, stop and reconsider scope or design. Repeated generation is not a substitute for understanding the failed check.

Customize the recipe

Copy recipes/implementation.json and use --recipe-file PATH when creating a new run. Change an agent's adapter to another supported coding tool, or manual for a chat handoff. Update the approved recipient list accordingly.

Dependencies must remain acyclic and in order. Every stage must depend on the scope gate, acceptance must include every stage, and only one writer is allowed. Parallel work is limited to independent stages and the declared concurrency.

A new recipient, wider write scope, or different integration target needs a newly reviewed contract. Model output cannot introduce those changes.

What goes wrong

Parallel writers can overwrite assumptions made against different revisions. A writer can also weaken its own tests if the coordinator accepts replacement checks without review. Keep one writer in this reference and rerun dependent evidence after every revision.

How to check

Run the package tests, including the case where a proposed configuration is valid JSON but fails the retry contract. Acceptance must reject it. Request a revision and verify that checks and both reviews run again.

For a real project trial, compare the recipe against a single-agent baseline on a small branch. Review the exact diff, reproduced behavior, remaining findings, and usage before integrating. This package stops at local acceptance; your normal repository policy governs integration.