Skip to Content
Tares

What happens when the reviewer asks for changes to dependency upgrades?

Tares sends the pull request back to the builder with the reviewer’s requested changes, the builder makes them, and a second review round runs until the verdict passes. Smaller findings the reviewer spots outside the ticket do not stall the pull request, because the orchestrator turns them into a new ticket in the plan. You see each round and each new ticket on the project page.

How it works

The software factory for Claude Code runs every ticket through the same loop, and a ticket for dependency upgrades follows it like any other.

  • The builder works one ticket at a time. It makes a branch, does the work and opens a pull request.
  • The reviewer reviews every pull request and posts its verdict.
  • When the verdict passes and CI is green, the builder merges.
  • When the reviewer asks for changes, the builder makes them on the same pull request, and the next review round starts. The ticket records each round.

Most tickets pass on the first round. In the project walked through in A project, end to end, two tickets (T3 and T6) took a second round: the reviewer asked for changes, the builder made them, and the next round passed. In another project mid-build, T4 took two rounds in the same way.

Findings outside the ticket

The reviewer also reports smaller issues that sit outside the ticket under review. The orchestrator turns them into a new ticket. In the example project that ticket was T8. The orchestrator placed it in the second milestone, before the integration tests, and the builder fixed the issues there. The plan grew by one ticket on its own, and the original pull request stayed focused on its own ticket.

The orchestrator also writes this choice down as an assumption. At the end of the milestone it brings you all the assumptions in one question, and you decide whether to keep them.

Set it up

You do not configure the review round trip. It is part of the crew. To see it at work on your own project:

  1. Run tares factory spec in your repo and answer Claude Code’s questions. The result is a spec, a plan and milestones with acceptance checks. If you are new to the factory, start with Get started.
  2. Start the crew with tares factory crew up. Here you choose 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, or waits for your yes before every merge.
  3. Check on the crew from the terminal:
tares factory crew status
  1. Open the Crew page in the console, http://127.0.0.1:8787/crew locally. Pull requests waiting for the reviewer appear in the review queue, and questions waiting for you appear at the top.
  2. Open the project page and unfold Tickets. Each ticket shows the builder that held it, its pull request and its review rounds. A ticket that took a second round shows both.
  3. Unfold Assumptions to find the choice that created a new ticket from the reviewer’s smaller findings. At the end of the milestone, answer the orchestrator’s question in its session to keep or change it.

To steer the work while a round is running, talk to the orchestrator. It answers the builders and brings you only what needs you.

What you get

  • A clear round trip. Changes requested lead to a second pass by the same builder on the same pull request, and the pass that succeeds is the one that merges.
  • A record of every round. The ticket lists its review rounds, so you can see which tickets needed more than one.
  • No lost findings. Smaller issues outside the ticket become their own ticket in the plan, with a place in the milestone order, instead of being dropped or piled onto the wrong pull request.
  • Your say over the plan. The new ticket is logged as an assumption, and you keep or change it when the orchestrator asks at the end of the milestone.
  • A full history. The Decisions fold holds your answers, and the Sessions fold holds the recorded Claude Code sessions from the spec session to each builder.

When something else fits

  • If you want to approve every merge yourself, choose that when you run tares factory crew up. The crew then waits for your yes after the reviewer passes a pull request.
  • If a finding needs a fix on your side, such as existing production data, the builder flags it in the pull request and leaves that fix to you.
  • To work on a project that is already finished, hand it to the crew again, for example with a follow-up spec.

Still stuck? Get help

Last updated on
Quickstart