How should I split bug fixes into milestones for a Go microservice?
Tares plans a project as milestones, and each milestone carries acceptance checks, so you split your bug fixes by the outcome you can check rather than by file or package. At the end of each milestone, the orchestrator brings you the choices the crew made on its own in one question. For a Go microservice, give each milestone one checkable result, such as tests and CI first, then the bug fixes, then merged and live.
How it works
When you run tares factory spec in your repo, you answer Claude Code’s questions and a second model challenges the plan. The result goes into Tares as a spec, a plan, an AGENTS.md for the project and the milestones, each with acceptance checks.
The orchestrator then picks up the project and starts a builder for the first milestone. The 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. 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 together, in one question in its session.
A real project shows the shape. A pull request with no tests and a few bugs in how it paid shifts became three milestones:
- M1, tests and CI on the branch: a test framework, unit tests for the logic, and a CI check on every pull request.
- M2, payout history stays as it was: the bug fixes, stated as behavior you can check. Changing a rate or deactivating a sitter leaves past weeks as they were.
- M3, merged and live: the pull request documented, merged into main and running in production.
That project went from a spec to eight merged pull requests in about three hours. You can follow it in A project, end to end.
Set it up
- Start the spec session in your service repo. Claude Code asks you questions, and you describe the bugs and what correct behavior looks like.
tares factory spec- Ask for milestones that each have one result you can check. For bug fixes in your Go microservice, the project above suggests this order:
- A first milestone that puts tests and CI in place, so every later fix has a check to pass.
- A milestone per group of related bugs, with acceptance checks written as observable behavior, such as what stays unchanged after the fix.
- A last milestone that merges and deploys.
- Read the acceptance checks in the plan before you say yes. Make each one something a test or a reviewer can confirm. The checks appear later in the Tickets fold of the project page, next to each milestone.
- Say yes to handing the project to the crew. If the crew is not running yet, start it with
tares factory crew up, where you choose how far the crew may go, such as whether it merges on its own once the reviewer passes a pull request and CI is green. - Answer the crew’s questions in the orchestrator’s session. Expect a question about trusting the repo folder in Claude Code and one about giving Tares a GitHub token so it can read pull request, CI and merge state.
- At the end of each milestone, read the assumptions the orchestrator brings you and say whether to keep them. To make an answer stand from now on, say so, for this project or for every project.
If you are new to the factory, Get started covers the first run.
What you get
- A plan where every milestone has acceptance checks, visible in the Tickets fold next to each ticket’s builder, pull request and review rounds.
- One question per milestone that collects every choice the crew made on its own. The Assumptions fold lists each one with the tickets it touches and the builder that made it, so you can see what was assumed, such as which test config file to use, and whether you kept it.
- A record of your own answers in the Decisions fold, in your words.
- A plan that adjusts itself. In the example, the reviewer found smaller issues outside the ticket it was reviewing, and the orchestrator turned them into a new ticket placed in M2 before the integration tests.
- A progress bar with one segment per ticket, and blocked tickets that name the tickets they wait for.
When something else fits
- For a single small bug, a milestone plan is more than you need. A plain Claude Code session in the repo is quicker.
- If your tickets live in Linear or GitHub Issues, you can link them to a Tares project. Tares reads them, and sessions update them with their own tools.