Skip to Content

What acceptance checks should a milestone for framework migrations carry?

Tares milestones carry acceptance checks that the reviewer holds each pull request to, and you write them for a framework migration in the spec session. Use the shape of the worked example: tests and CI in place, existing behavior unchanged, and the result merged and live. When a milestone ends, the orchestrator asks whether you keep the choices the crew made on its own, so the next builder starts on confirmed ground.

How it works

The software factory for Claude Code starts with a spec session. You run tares factory spec in the repo and answer Claude Code’s questions. 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.

From there the checks work like this:

  • 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 against the milestone’s checks and posts a verdict. If it asks for changes, the builder makes them and a second round follows.
  • When the verdict passes and CI is green, the builder merges.
  • At the end of the milestone, the orchestrator brings you the assumptions in one question: keep the choices the crew made on its own during it? Your answer is recorded in the project’s Decisions fold.

An assumption is a choice the crew made because the plan did not cover something. It writes the choice down and carries on. In the worked project, the working doc named a config file that failed to load on the repo’s Node version, so the builder used a different file and recorded it. The CI job for database tests also ran on the same Node version as the unit tests, not the one in the working doc. Both became assumptions the person confirmed at the end of the milestone.

The project end to end page walks through this with three milestones and eight merged pull requests.

Set it up

Write the checks as part of the spec session. The worked project used three milestones, and a framework migration fits the same three kinds of check.

  1. Bring up the crew, then plan the project. The first command starts the crew and the second opens the spec session:
tares factory crew up
tares factory spec "what you want to build"
  1. Make the first milestone about safety nets. The worked project’s M1 was tests and CI on the branch: a test runner, unit tests for the existing logic, and a CI check on every pull request. For a migration you can word this as tests that pin today’s behavior and run on every pull request, so the reviewer can hold each later pull request to them.
  2. Make the middle milestones about what must stay the same. The worked project’s M2 was “payout history stays as it was”: past weeks stay as they were after a change. State each check as something the reviewer can observe, such as a named behavior that is unchanged after the framework swap.
  3. End with a milestone for landing it. The worked project’s M3 was “merged and live”: the pull request documented, merged into main and running in production.
  4. Name tools and versions in the checks only where you are sure of them. If the working doc is wrong, the builder picks a working alternative and records it as an assumption for you to confirm.
  5. At each milestone end, answer the assumptions question. To make an answer stand from now on, say so, for this project or for every project.

Before you start, Get started lists the prerequisites and the full setup order.

What you get

  • A reviewer that has a concrete bar for every pull request in the milestone, so verdicts rest on your checks and not on taste.
  • A project page whose Tickets fold shows each milestone with its acceptance checks, and each ticket with its builder, pull request and review rounds.
  • A clean handoff between milestones. The assumptions the crew made are open until you answer, and each names the tickets it touches and the builder that made it. Your answer is kept in the Decisions fold in your own words, up to 4,000 characters.
  • A plan that can grow. In the worked project the reviewer found smaller issues outside its ticket, and the orchestrator added a ticket inside the milestone to fix them before the integration tests.
  • A clear finish. After the last milestone the orchestrator asks whether the project is done, and Tares marks it Done with your words.

When something else fits

  • If the work is a single small change, you may not need milestones. Hand it over with a short spec and let the reviewer hold the one pull request to its description.
  • If you want to approve every merge yourself, say so when you bring up the crew. In the worked project, a project that waits for the person’s yes before each merge shows those approvals as its decisions.
  • If you are new to the factory, read Get started first, then come back to write your checks.

Still stuck? Get help

Last updated on