What should the reviewer check when a builder opens a pull request for internal refactors in a Python backend?

Tares has the reviewer read every builder pull request and post a verdict, and the builder merges only once the verdict passes and CI is green. For internal refactors in a Python backend, hold the pull request to its ticket’s acceptance checks, CI, the assumptions it records and any data it leaves alone. The factory applies the same review flow to every pull request, so these checks are how you read the verdict.

How it works

Each project you hand to the crew is split into milestones, and each milestone carries acceptance checks. Tickets sit under the milestones. 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.

The flow is the same for any change, including internal refactors in a Python backend. Here is what to check, with how it plays out in the example project in A project, end to end:

• The ticket and its milestone checks. Read the pull request against the acceptance checks of its milestone. In the example, one milestone was “payout history stays as it was”: past weeks had to come out as before when a rate or a sitter changed. A refactor has the same kind of promise, so look for the check that says existing behavior stays put.
• Tests and CI. The example’s first milestone added unit tests and a CI check on every pull request. Check that the pull request runs in CI and that CI is green, since the builder does not merge before that.
• Findings outside the ticket. The reviewer in the example found smaller issues beyond the ticket it was reviewing. The orchestrator turned them into a new ticket placed in the right milestone, and the builder fixed them there. Keep the refactor pull request on its own ticket and let extra findings become their own ticket.
• Choices the plan did not cover. When the crew meets something the plan does not cover, it picks the sensible answer and records it as an assumption. Check that each choice the builder made is written down and tied to its ticket.
• Existing data. In the example, the builder left existing production data alone, flagged it in the pull request and left any production fix to the person. For a backend refactor, look for the same flag wherever the change could touch stored data.
• The description. The example’s builder rewrote an existing pull request description into documented sections. Check that the description says what changed and what did not.

The verdict can ask for changes. In the example, two tickets took a second review round: the reviewer asked for changes, the builder made them and the next round passed.

Set it up

1. Plan the refactor as a project, so each milestone gets acceptance checks the reviewer can hold the pull requests to. Run this in the repo and answer Claude Code’s questions:

tares factory spec "what you want to build"

2. Write the promise of the refactor into a milestone check, for example that existing behavior stays as it was. The spec session produces the spec, the plan, an AGENTS.md for the project and the milestones with their checks. See Get started for the full setup order.
3. Hand the project to the crew once you agree with the plan. Bring the crew up if it is not running:

tares factory crew up

4. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. Pull requests waiting for the reviewer appear in a review queue.
5. Open the project page and the Tickets fold. Each ticket shows the builder that held it, its pull request and its review rounds, so you can read the verdict next to the milestone checks.
6. Open the Assumptions fold to see every choice the crew made on its own. At the end of each milestone the orchestrator brings you its assumptions in one question, and you keep them or not.

What you get

• A review of every builder pull request, with a verdict posted before the merge.
• A merge only after the verdict passes and CI is green.
• Review rounds you can follow per ticket, with changes asked for and made before the next round.
• Side findings turned into their own tickets instead of growing the refactor pull request.
• A written record of each choice the plan did not cover, so you can keep it or not.
• A project page that holds the milestones, acceptance checks, pull requests and your answers in one place.

When something else fits

• If you want to steer a ticket mid-build, talk to the orchestrator. It answers the builders and brings you what needs you.
• If a project should wait for your yes before every merge, say so. The example project in the walkthrough worked that way, and its merge approvals appear in the Decisions fold.
• For a first look at the factory before planning a refactor, start with Get started.

Related