How should I split bug fixes into milestones for a Python backend?

Tares plans a project as milestones, each with acceptance checks, and you split bug fixes the same way: one milestone per outcome you can check. At the end of each milestone the orchestrator brings you the assumptions the crew made, so you confirm them in one answer. You set the milestones in the spec session that you start with tares factory spec, and the software factory for Claude Code takes them from there.

How it works

A milestone in Tares is a group of tickets with acceptance checks. You write the milestones with Claude Code during the spec session. A second model challenges the plan, and the spec, the plan, the project’s AGENTS.md and the milestones go into Tares.

The builder then 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. Once the verdict passes and CI is green, the builder merges.

When the crew meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and carries on. At the end of each milestone, the orchestrator brings you its assumptions in one question. You keep them or change them. That question is the natural end of a milestone: it is where the choices made during the milestone get confirmed.

The worked example in A project, end to end shows a bug-fix project split into three milestones:

• M1, tests and CI on the branch. A test setup, unit tests for the buggy logic and a CI check on every pull request.
• M2, behavior stays as it was. The bug fixes themselves, stated as outcomes. Past payout weeks stay as they were, and “today” is the household’s date.
• M3, merged and live. The pull request documented, merged into main and running in production.

For a Python backend, use the same shape. Put the tests and CI for the code you are about to touch first, then the fixes, then the merge and deploy.

Set it up

1. Run the spec session in the repo of your Python backend.

tares factory spec

2. Answer Claude Code’s questions. List the bugs you know about, and say which behavior must not change.
3. Ask for a first milestone that puts tests and CI in place for the affected code. Fixes then have something to be checked against.
4. Group the bug fixes into milestones by outcome, not by file. Each milestone gets acceptance checks that describe what is true when it is done, such as “deactivating a record leaves past data as it was”.
5. Make the last milestone the one that gets the work merged and running in production, so the project has a clear finish.
6. Review the spec, the plan and the milestones, then say yes to handing the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
7. Start the crew with tares factory crew up if it is not running yet. Choose how far it may go, for example whether it merges on its own once the reviewer passes and CI is green, and how many builders run at once.
8. Answer the crew’s questions in the orchestrator’s 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.

Keep milestones small enough that you can read their assumptions in one sitting. In the worked example, three milestones produced five assumptions in total, and the person kept all five.

What you get

• A project page with the steps Spec, Build, Review and Done, and a progress bar with one segment per ticket.
• A Tickets fold that shows each milestone with its acceptance checks, and each ticket with its builder, pull request and review rounds.
• A Decisions fold with every question the crew asked you and your answer in your own words.
• An Assumptions fold with every choice the crew made on its own, and whether you kept it.
• A plan that can grow. In the worked example the reviewer found smaller issues outside the ticket it was reviewing, and the orchestrator turned them into a new ticket and placed it in M2 before the integration tests.

Open the Crew page in the console, at http://127.0.0.1:8787/crew locally, to see which station holds which ticket and which questions wait for you.

When the last milestone is done, the orchestrator asks whether the project is finished. Tares marks it Done with your words and moves it to the finished list. Run tares factory crew down to stop every station. Tares keeps the projects, tickets and answers, so the crew carries on from them next time.

When something else fits

• For a single small bug, one milestone with its acceptance checks is enough. You do not need three.
• If you have not used the factory before, read Get started first, then come back to plan your milestones.

Related