Skip to Content
Tares

What acceptance checks should a milestone for test coverage carry?

In Tares, the test milestone of the walkthrough project carried three acceptance checks: a test runner, unit tests for named logic, and a CI check on every pull request. Each milestone in a Tares project carries its own acceptance checks, and the project page shows them. At the end of each milestone, the orchestrator asks you whether to keep the assumptions the crew made during it.

How it works

The spec session produces the milestones. 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.

The walkthrough project in A project, end to end started from a pull request with no tests and a few bugs. Its first milestone was M1, tests and CI on the branch, and it carried three checks:

  • A test runner. The milestone named Vitest.
  • Unit tests for the named logic. The milestone named the babysitting logic.
  • A CI check on every pull request. Tests run each time a pull request opens.

Those are the checks of one real milestone. Use them as a model for your own.

The crew then works the milestone ticket by ticket. The builder 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. In the walkthrough, most tickets passed on the first round. Two needed a second round, in which the reviewer asked for changes and the builder made them.

When the crew meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and carries on. In the walkthrough, 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 that as an assumption.

Set it up

  1. Bring up the crew. On a local Tares, start Tares and its MCP endpoint first, as Get started lists in order.

    tares factory crew up

  2. In the repo, start the spec session and describe what you want, for example the tests and CI the project is missing.

    tares factory spec "what you want to build"

  3. Answer Claude Code’s questions. When the spec session ends, the project holds a spec, a plan, an AGENTS.md and its milestones with their acceptance checks.

  4. Open the project page in the console and unfold Tickets. It lists each milestone with its acceptance checks, and each ticket with its builder, pull request and review rounds. Check that the test milestone names a test runner, the logic the unit tests cover, and a CI check on every pull request.

  5. Say yes to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

  6. Watch progress on the Crew page, at http://127.0.0.1:8787/crew locally. At the end of each milestone, answer the orchestrator’s question about the assumptions the crew made. Answers appear in the Decisions fold, and the choices appear in the Assumptions fold.

What you get

  • A test milestone whose acceptance checks are written down, visible in the Tickets fold of the project page.
  • A reviewer that reviews every pull request and posts a verdict. The builder merges once the verdict passes and CI is green.
  • A CI check on every pull request, so tests keep running after the milestone ends.
  • Assumptions listed in the Assumptions fold, each naming the tickets it touches and the builder that made it. The orchestrator brings them to you together at the end of the milestone, so you decide whether to keep them.
  • A record of every question and your answer in the Decisions fold, in your own words.
  • Extra tickets when the reviewer finds issues outside the ticket it is reviewing. In the walkthrough, the orchestrator turned such findings into ticket T8 and placed it in M2 before the integration tests.

When something else fits

  • If the milestone is about behavior rather than tests, write acceptance checks about that behavior. The walkthrough’s M2 checked that deactivating a sitter or changing a rate leaves past weeks as they were.
  • If the work is a shipping step, use a milestone like M3, merged and live: the pull request documented, merged into main and running in production.
  • If the crew needs a decision from you, answer it in the orchestrator’s session instead of adding a check.

Still stuck? Get help

Last updated on
Quickstart