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

Tares has the reviewer check every builder pull request against the acceptance checks of the ticket’s milestone, and the builder merges once the verdict passes and CI is green. For framework migrations in a Python backend, that means checking that the milestone’s checks hold, that CI runs on the repo’s own runtime, and that existing data is left alone and flagged. You see each verdict and review round on the project page.

How it works

Each project you hand to the software factory for Claude Code has milestones, and each milestone carries acceptance checks. The spec session writes them with the spec, the plan and the project’s AGENTS.md. A builder works through the 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 a verdict. When the verdict passes and CI is green, the builder merges.

This applies to a migration the same way as to any other change. Here is what to look at on a migration pull request:

• The milestone’s acceptance checks. The pull request has to satisfy the checks of the milestone its ticket belongs to. In the worked example, one milestone was “payout history stays as it was”, which is the kind of check that fits a migration: behaviour that must not change.
• CI on the right runtime. CI has to be green, and it has to run on the version the repo really uses. In the worked example, a config file named in the working doc failed to load on the repo’s Node version. The builder used a file that loads and wrote that down as an assumption. The CI job for database tests ran on the same Node version as the unit tests. In a Python backend, check the equivalent: the interpreter version and the test setup that CI uses.
• Existing data. In the example, sitters already inactive in production kept open-ended slots. The builder left existing data alone, flagged it in the pull request and left any production fix to the person. For a migration, look for the same flag and make sure the pull request does not quietly change stored data.
• Choices the builder made alone. Anything the plan did not cover is recorded as an assumption. You review these at the end of each milestone.
• Findings outside the ticket. The reviewer can find smaller issues beyond the ticket it is reviewing. The orchestrator turns them into a new ticket and places it in the milestone, so they do not ride along in the migration pull request.

If the reviewer asks for changes, the builder makes them and a second round follows. In the example project, most tickets passed on the first round and two took a second.

Set it up

1. Check the prerequisites and install steps on Get started, then bring up the crew and plan the migration from the repo:

tares factory crew up
tares factory spec "what you want to build"

2. In the spec session, answer Claude Code’s questions. The result is a spec, a plan and milestones with acceptance checks. State what must stay as it was, as the example project’s second milestone does, so the reviewer has a check to hold the migration to.
3. Hand the project to the crew when the spec session asks. The orchestrator starts a builder for the first milestone.
4. Open the project page and the Tickets fold. It shows each milestone with its acceptance checks, and each ticket with its builder, pull request and review rounds. Read the checks before the first pull request arrives, so you know the bar the reviewer applies.
5. Answer questions in the orchestrator’s session. Your answers go into the Decisions fold as you typed them. At the end of each milestone you get the assumptions in one question, so you can keep or reject the choices made on the way.

The full walk through a project is in A project, end to end.

What you get

• A review of every migration pull request against the ticket’s milestone checks, with the verdict recorded on the ticket.
• A visible record of each review round, so you see what the reviewer asked for and what the builder changed.
• Assumptions written down and flagged in the pull request, so choices about versions, config and existing data are not buried.
• Side findings turned into their own ticket instead of widening the migration pull request.
• Merges only after a passing verdict and green CI. You can also set the crew to wait for your yes before every merge, which shows in the Decisions fold as merge approvals.

When something else fits

• If you want to approve each merge yourself, choose that when you run crew up. The Crew page shows how far the crew may go.
• If the migration touches production data, plan to decide that part yourself. The builder flags it in the pull request and leaves the production fix to you.

Related