What does the crew do when the plan does not cover a decision while it works on test coverage?

Tares records the choice as an assumption, and the crew carries on, so a gap in the plan does not stop work on test coverage. At the end of each milestone the orchestrator brings you all the assumptions in one question, and you keep or change them. Every assumption stays on the project page, so you can see what the crew decided and whether you kept it.

How it works

When the crew meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and keeps going. You are not asked at that moment.

• Each assumption is tied to the work. It names the tickets it touches and the builder that made it.
• Assumptions stay open during the milestone. They show as open in the Assumptions fold of the project page until you answer.
• You decide at the end of the milestone. The orchestrator brings you the assumptions together, in one question in its session, asking whether to keep the choices the crew made on its own.
• Your answer is recorded. It appears in the Decisions fold in your own words, and the Assumptions fold shows whether you kept each choice.

A project that added tests to a pull request shows what this looks like in practice:

• The working doc named vitest.config.ts, which fails to load on the repo’s Node version. The builder used vitest.config.mts instead and recorded it as an assumption.
• The CI job for database tests ran on the same Node version as the unit tests, not the one in the working doc. That was recorded too.
• Sitters already inactive in production would keep open-ended slots. The builder left existing data alone, flagged it in the pull request and left any production fix to the person.

The person kept all five assumptions of that project. For the full walkthrough, see A project, end to end.

Questions work differently from assumptions. A step only you can take on your machine, such as trusting the repo folder in Claude Code once or giving Tares a GitHub token, comes to you as a question when it is needed.

Set it up

1. Start in your repo and run the spec session. Answer Claude Code’s questions. The result is a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.

   tares factory spec

2. Start the crew and hand it the project. At crew up you choose how far the crew may go, for example whether it merges on its own once the reviewer passes a pull request and CI is green.

   tares factory crew up

3. Open the Crew page in the console, http://127.0.0.1:8787/crew locally, to see each station, its state and the projects the crew holds.

4. Open the project page and unfold Assumptions at any time to read the choices made so far, with their tickets and builders.

5. When the orchestrator asks at the end of a milestone, answer in its session. Keep the assumptions or change the ones you disagree with.

6. To make an answer stand from now on, say so in your reply, for this project or for every project.

If this is your first project, start with Get started.

What you get

• Work that keeps moving. A gap in the plan becomes a recorded choice, not a stall, so tests, CI and fixes continue while you are away.
• One decision point per milestone. You review the crew’s choices together instead of answering them one by one.
• A full record. The Assumptions fold lists every choice the crew made on its own and whether you kept it. The Decisions fold lists every question and your answer, newest first.
• Control over what stands. You can change any assumption, and you can tell the crew to apply your answer to this project or to every project from then on.
• Visible context. Each assumption names the tickets it touches and the builder that made it, so you can trace it to the pull request.

When something else fits

• If a decision matters too much to wait until the end of a milestone, put it in the spec and plan during the spec session, or talk to the orchestrator to steer the work.
• If you want a say before every merge, choose that at crew up. One project did this, and most of its decisions were merge approvals.

Related