How should I split framework migrations into milestones for a Go microservice?

Tares splits a project into milestones, each with acceptance checks, and you get them from a spec session you run in your repo. Each milestone ends with one question that asks you to keep or change the choices the crew made on its own. You confirm those assumptions there, so the work carries on from settled ground.

How it works

In the software factory for Claude Code, milestones and their acceptance checks are the unit of planning. They come out of the spec session, together with a spec, a plan and an AGENTS.md for the project. A second model challenges the plan before the result goes into Tares.

The project end to end page follows one real project, a pull request that needed tests and bug fixes. It is not a migration or a Go project, but it shows how the factory treats milestones. Its spec produced three milestones, each with acceptance checks:

• M1, tests and CI on the branch: Vitest, unit tests for the babysitting logic, and a CI check on every pull request.
• M2, payout history stays as it was: deactivating a sitter or changing a rate leaves past weeks as they were.
• M3, merged and live: the pull request documented, merged into main and running in production.

A builder works through the tickets of a milestone one at a time. For each ticket it makes a branch, does the work and opens a pull request. The reviewer posts a verdict on every pull request, and the builder merges once the verdict passes and CI is green. A blocked ticket names the tickets it waits for.

A milestone is also where assumptions get settled. 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 all of that milestone’s assumptions in one question. In the example project, the person kept all five.

Set it up

1. Run the spec command in the repo of your Go microservice and answer Claude Code’s questions. Describe the framework migration you want in that session.

tares factory spec

2. Read the milestones that come out of the spec session. Open the project page and unfold Tickets to see each milestone with its acceptance checks, and each ticket under it.
3. Read the plan and the project’s AGENTS.md in the Docs fold. You can edit any doc there, and each ticket’s working doc sits with its ticket.
4. Steer the work by talking to the orchestrator. If a ticket turns out to need a different order or extra work, the orchestrator can add one. In the example project, the reviewer found smaller issues outside the ticket under review. The orchestrator turned them into a new ticket and placed it in M2 before the integration tests.
5. Answer the question at the end of each milestone. Keep the assumptions you agree with. To make an answer stand from now on, say so, for this project or for every project.
6. Check the Assumptions fold for every choice the crew made on its own and whether you kept it. The Decisions fold holds every question the crew asked and your answer in your own words.

What you get

• A plan broken into milestones, each with acceptance checks, recorded on the project page.
• A pull request for every ticket, reviewed before it merges, with its review rounds visible. Two tickets in the example project took a second round, and the next round passed.
• One question at the end of every milestone, so each assumption is confirmed or changed by you.
• A record of the whole build: progress with one segment per ticket, your decisions, the assumptions and the recorded sessions from the spec session to each builder.
• A project that reaches Done only after the last milestone, when the orchestrator asks whether the project is finished and you answer in your own words.

When something else fits

• The factory requires Claude Code. If your team does not use it, the factory is not the right tool.
• The page above shows how one project was split and does not give a fixed milestone template for migrations. If you want to see a full milestone record before you plan your own, read A project, end to end.
• If you track tickets in Linear or GitHub Issues, Tares reads them, and sessions update them with their own tools.

Related