How should I split test coverage into milestones for a monorepo?

Tares plans test coverage as milestones with acceptance checks, so you split a monorepo’s tests into a few outcomes that the crew builds one milestone at a time. Follow the pattern of a real project: first tests and CI running on the branch, then the behaviour that matters, then merged and live. At the end of each milestone the orchestrator brings you the assumptions the crew made, in one question, so you can keep or change them.

How it works

The milestone is the unit of planning in the software factory for Claude Code. When you run tares factory spec, 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 in A project, end to end started with no tests and a few bugs. It was split into three milestones:

• 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.

Once you hand the project to the crew, the orchestrator picks it up 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 the builder merges once the verdict passes and CI is green. A ticket that waits on others shows as blocked and names the tickets it waits for.

A project can also span several repos. The project page lists the repos it changes and where each is checked out, and one project in the docs ran 20 tickets over three milestones and three repos.

Set it up

1. Bring up the crew. Follow Get started first if you have not set up the software factory for Claude Code. Then run:

   tares factory crew up

2. Plan the project from the repo. Describe the coverage you want in terms of outcomes, not files:

   tares factory spec "add test coverage to the monorepo"

3. Answer Claude Code’s questions in the spec session. Shape the milestones with the example above as a guide:

   • Make the first milestone the test tooling and a CI check on every pull request, so every later pull request is checked.
   • Make the next milestones the behaviour you most need protected, each with acceptance checks you can state in one sentence.
   • Make the last milestone the merge and the live result.

4. Review the milestones and their acceptance checks on the project page, in the Tickets fold, then say yes to hand the project to the crew.

5. Watch the build on the Crew page (http://127.0.0.1:8787/crew locally). Each ticket shows its state: to do, in progress, in review, merged or blocked.

6. At the end of each milestone, answer the orchestrator’s question about the assumptions the crew made. If you want an answer to stand from now on, say so, for this project or for every project.

What you get

• A plan you can read before work starts. The spec, the plan and the milestones with their acceptance checks sit in the Docs and Tickets folds of the project page.
• A first milestone that gives the next builder something to work with. In the example, M1 put Vitest and a CI check on every pull request in place.
• Assumptions you can see and decide on. When the crew meets something the plan did not cover, it picks the sensible answer, writes it down and carries on. In the example, the working doc named vitest.config.ts, which fails to load on the repo’s Node version, so the builder used vitest.config.mts and recorded it as an assumption. The orchestrator brought all five assumptions to the person at the end of each milestone, and the person kept them.
• A plan that can grow. 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 record of every answer. The Decisions fold holds each question the crew asked and your answer in your own words, up to 4,000 characters.
• A clear end. After the last milestone the orchestrator asks whether the project is finished, and Tares marks it Done with your words.

When something else fits

• If you only want one small change tested, a single milestone with a few tickets is enough. You do not need three.
• If you want to steer a ticket that is already in progress, talk to the orchestrator in its session instead of re-planning.
• When the crew is finished, run tares factory crew down to stop every station. Tares keeps the projects, tickets and answers, so you can hand it the next project, such as a follow-up spec, later.

Related