What happens when the reviewer asks for changes to test coverage?

Tares sends the pull request back to the builder when the reviewer asks for changes, and the builder makes them and the pull request goes into a second review round. Smaller findings outside the ticket become a new ticket, so the plan grows by one ticket on its own. The builder fixes those findings there, and you see every round and every added ticket on the project page. Read about the full flow in A project, end to end.

How it works

The software factory for Claude Code runs each ticket as a loop between a builder and the reviewer.

• The builder works through the tickets one at a time. For each, it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• When the reviewer asks for changes, the builder makes them and the pull request gets another round. The builder merges once the verdict passes and CI is green.
• Most tickets pass on the first round. In the example project, T3 and T6 took a second round: the reviewer asked for changes, the builder made them, and the next round passed.
• Smaller issues the reviewer finds outside the ticket under review do not stall that ticket. The orchestrator turns them into a new ticket. In the example project that was T8, placed in M2 before the integration tests, where the builder fixed them.
• The orchestrator records that choice as an assumption (A3 in the example). It brings your assumptions to you in one question at the end of each milestone, and you decide whether to keep them.

A project can put tests first. In the example project, milestone M1 was tests and CI on the branch, with Vitest, unit tests for the babysitting logic and a CI check on every pull request. The review rounds apply to every pull request the same way.

Set it up

You do not configure review rounds one by one. They are part of how the crew handles every ticket. To get them running on your project:

1. Run the spec session in your repo and answer Claude Code’s questions. The result is a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.
2. Start the crew and choose how far it may go, for example whether it merges on its own once the reviewer passes a pull request and CI is green.
3. Hand the project to the crew when the spec session asks. The orchestrator picks it up and starts a builder.
4. Follow the work. Open the Crew page in the console at http://127.0.0.1:8787/crew locally to see pull requests waiting in the review queue. Open the project page and the Tickets fold to see each ticket with its builder, its pull request and its review rounds.
5. Steer by talking to the orchestrator, and answer its questions in its session. At the end of each milestone, answer the assumptions question. To make an answer stand from now on, say so, for this project or for every project.

tares factory spec
tares factory crew up
tares factory crew status

If you want a say before every merge, the crew can wait for your yes each time. Each approval then appears under Decisions with your answer as you typed it.

What you get

• A clear round trip: changes requested, changes made by the builder, a second pass by the reviewer, then merge once the verdict passes and CI is green.
• A record of every round. The Tickets fold shows, per ticket, the builder that held it, its pull request and its review rounds. A blocked ticket names the tickets it waits for.
• No lost findings. Smaller issues outside the ticket become their own ticket in the plan, so the original ticket stays focused and the extra work still gets done and reviewed.
• A visible trail of choices. The new ticket is listed under Assumptions with its tickets and the builder that made it, so you can keep it or not at the end of the milestone.
• A project that stays on track. The progress bar has one segment per ticket, so an added ticket shows up as part of the build.

When something else fits

• If you want to approve each merge yourself, set the crew up to wait for your yes. You still get the review rounds, and you decide when a pull request lands.
• If a finding needs a change to production data or anything outside the repo, the builder flags it in the pull request and leaves it to you.
• If you are new to the crew, start with Get started, then come back to follow one project through its rounds.

Related