What acceptance checks should a milestone for bug fixes carry?

Tares milestones for bug fixes should carry checks the reviewer can verify on each pull request: tests on the fixed logic, CI on every pull request, and data that must stay unchanged. Each milestone ends with the crew bringing you its assumptions in one question. In the project walked through in A project, end to end, three milestones carried checks of this kind.

How it works

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 Tickets fold on the project page shows every milestone with its checks, and each ticket with its builder, pull request and review rounds.

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 posts a verdict. Once the verdict passes and CI is green, the builder merges.

The example project fixed a Babysitters section that had no tests and a few bugs in how it paid shifts. Its three milestones show what bug-fix checks can look like:

• Tests and CI on the branch. Vitest, unit tests for the babysitting logic, and a CI check on every pull request.
• History stays as it was. Deactivating a sitter or changing a rate leaves past weeks as they were, and “today” is the household’s date.
• Merged and live. The pull request is documented, merged into main and running in production.

Each check is something a reviewer can confirm against a pull request or against the running app. It does not depend on opinion.

Set it up

1. Bring up the crew, then plan the project from the repo that holds the bug. Follow Get started for the full setup, including the Claude Code and GitHub prerequisites.

tares factory crew up
tares factory spec "fix the bugs in how shifts are paid, and test the fix"

2. Answer the questions in the spec session. Name the bug and the behavior that must not change. Say what proves the fix, such as which logic needs tests.
3. Check the milestones before you hand the project over. Open the Tickets fold on the project page and read each milestone’s acceptance checks. For a bug-fix project, look for these:
   • A check that tests cover the logic that was wrong.
   • A check that CI runs on every pull request.
   • A check that names the data or history that must stay unchanged.
   • A check that says what “merged and live” means for you.
4. Say yes to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
5. Answer the crew’s questions in the orchestrator’s session. The Decisions fold records each answer in your own words.
6. At the end of each milestone, answer the question about assumptions. To make an answer stand from now on, say so, for this project or for every project.

What you get

• A reviewer with something to hold each pull request to. The checks sit on the milestone, so every pull request is judged against the same written bar before the builder merges.
• A record of what was checked. The Tickets fold keeps each milestone with its checks, and each ticket with its pull request and review rounds. A ticket that needs changes shows its extra round, as T3 and T6 did in the example.
• Visible side choices. Bug fixes often meet cases the plan did not cover. In the example, the working doc named vitest.config.ts, which fails on the repo’s Node version, so the builder used vitest.config.mts and wrote it down as an assumption. Sitters already inactive in production kept their open-ended slots. The builder left existing data alone, flagged it in the pull request and left any production fix to the person.
• A clean close to each milestone. The orchestrator brings the assumptions in one question, you keep them or not, and the crew carries on. In the example the person kept all five.
• Follow-up work that stays in the plan. The reviewer found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket in the milestone, placed before the integration tests, so the plan grew by one ticket on its own.

When something else fits

• If you want to approve every merge yourself, say so when you choose how far the crew may go. The example project waited for the person’s yes before every merge.
• If a bug needs a production data fix, keep that step with you. The crew can flag the case in the pull request and leave the fix to the person, as it did with the inactive sitters.

Related