How should I split dependency upgrades into milestones for a Go microservice?

Tares plans work as milestones, each with acceptance checks, so split your Go dependency upgrades where the service is in a state you can verify. A good split is a test and CI baseline, then the upgrades in groups, then merged and live. At the end of each milestone the orchestrator asks you to keep or reject the choices the crew made on its own, so the next builder starts from confirmed ground.

How it works

When you run tares factory spec in the repo, Claude Code asks you 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 milestones, each with acceptance checks. The project page shows them in the Tickets fold, with each ticket, the builder that held it, its pull request and its review rounds.

The build then follows a fixed rhythm:

• The orchestrator picks up the project and starts a builder for the first milestone.
• The builder works through the tickets one at a time. Each ticket gets a branch, the work and a pull request.
• The reviewer reviews every pull request. Once the verdict passes and CI is green, the builder merges.
• A blocked ticket names the tickets it waits for, so order inside a milestone is visible.
• When the crew meets something the plan did not cover, it picks a sensible answer, records it 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 not.

That last step is why the milestone boundary matters. Put it where a wrong assumption would be expensive to carry forward. The A project, end to end page shows an example: the working doc named a config file that failed to load on the repo’s Node version, so the builder used another one and recorded it as an assumption. The person confirmed it at the milestone’s end, before the next work began.

Set it up

Here is a split you can give the spec session. It is a suggestion that follows the shape of the example project, which had a tests and CI milestone first and a merged and live milestone last.

1. M1, tests and CI on the branch. Make sure the service has tests and a CI check on every pull request. Acceptance: CI runs the tests on each pull request and is green on the branch. Every later upgrade is proven against this baseline.
2. M2, low-risk upgrades. Group the small updates together, with one ticket per group. Acceptance: CI is green and the service behaves as before.
3. M3, risky upgrades. Give each major version bump, or a change to the Go toolchain version, its own ticket so each one gets its own pull request and review rounds. Acceptance: CI is green after each ticket and the choices made along the way are written down.
4. M4, merged and live. Document the pull requests, merge into main and run in production. Acceptance: it is deployed and you confirm it works.

To run it, work in this order. Check that Claude Code is signed in, that gh is signed in with write access to the repos, and that git, jq and curl are installed. Install the CLI. On a local Tares, start Tares and then the MCP endpoint in a second terminal. On Tares Cloud, run tares login instead and pick your workspace in the browser. Give Tares access to GitHub, then bring up the crew and plan the project.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

In the spec session, describe the milestones and their acceptance checks in your own words and answer the questions Claude Code asks. At the end, say yes to hand the project to the crew. If you are new to the factory, start with Get started.

When a milestone ends, read the assumptions the orchestrator brings you. To make an answer stand from now on, say so, for this project or for every project.

What you get

• Each milestone ends in checks you can read, so you know when it is done.
• Your assumptions are confirmed one milestone at a time, so a wrong guess does not spread into the next upgrade.
• Every ticket has its own pull request and review rounds, so a failing upgrade is easy to find and cannot hide inside a large change.
• A plan that can grow. In the example project the reviewer found smaller issues, and the orchestrator turned them into a new ticket placed before the integration tests.
• A project page that records the docs, tickets, decisions and assumptions, with your answers in your own words.
• A Done state on the Crew page once you confirm the project is finished and deployed.

When something else fits

• For a single patch bump with no risk, a milestone plan adds more structure than you need. A plain pull request is faster.
• If you want to approve every merge yourself, the crew can be set up that way. Expect most of the early decisions to be merge approvals, each recorded with your answer as typed.

Related