What happens when the reviewer asks for changes to bug fixes?

In Tares, when the reviewer asks for changes, the builder makes them and the pull request goes to a second review round. Smaller issues the reviewer finds outside the ticket become a new ticket, and the builder fixes them there.

How it works

The software factory for Claude Code reviews every pull request, and bug fix tickets go through the same loop as any other ticket.

• The builder works through its tickets one at a time. For each ticket it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict.
• If the reviewer asks for changes, the builder makes them and the pull request gets another round of review.
• Once the verdict passes and CI is green, the builder merges.

Most tickets pass on the first round. In the project followed on A project, end to end, two tickets took a second round: the reviewer asked for changes, the builder made them, and the next round passed. In a project that was still building, one ticket also took two rounds and passed on the second.

The reviewer can also find smaller issues outside the ticket it is reviewing. The orchestrator turns them into a new ticket and places it in the plan. In that project the new ticket, T8, went into milestone M2 before the integration tests, and the builder fixed the findings there. The plan grew by one ticket on its own, and the choice was recorded as an assumption (A3).

Set it up

You do not configure the review loop. It runs for every project you hand to the crew. To see it work on your own project:

1. In your repo, run the spec session 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 hand the project over when the spec session asks.
3. Open the Crew page in the console. Pull requests waiting for the reviewer appear in a review queue, and questions waiting for you appear at the top.
4. Open the project page and unfold Tickets. Each ticket shows the builder that held it, its pull request and its review rounds, so you can see which tickets needed a second pass.
5. Unfold Assumptions to see choices the crew made on its own, such as a new ticket made from the reviewer’s smaller findings.
6. At the end of each milestone, answer the orchestrator’s question about its assumptions. To make an answer stand from now on, say so, for this project or for every project.

tares factory spec
tares factory crew up

The first command runs in your repo. The second starts the crew, and what you choose there sets how far the crew may go, for example whether it merges on its own once the reviewer passes a pull request and CI is green.

What you get

• A clear round trip: changes requested, changes made by the builder, a second review, then merge once the verdict passes and CI is green.
• A record of every round on the ticket, next to its builder and pull request.
• Findings outside the ticket do not get lost and do not bloat the pull request under review. They become their own ticket in the plan, fixed in the right milestone.
• A decision trail. The new ticket shows up as an assumption, the orchestrator brings your assumptions to you together at the end of the milestone, and you can keep or drop them. In the project on the example page, the person kept all five.
• No extra work from you during the loop. The orchestrator answers the builders and brings you only what needs you, as a question in its session.

When something else fits

If you want to approve every merge yourself, choose that when you start the crew. One project on the example page waited for the person’s yes before every merge, so most of its decisions were merge approvals, each with your answer as typed.

If the reviewer’s smaller findings are not ones you want in the plan, you can say no when the orchestrator asks about the milestone’s assumptions. If you want to steer a ticket while it builds, talk to the orchestrator, which holds the plan and brings you what needs you.

For the full walkthrough of the crew, the project page, questions and assumptions, read A project, end to end.

Related