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

Tares has the crew pick the sensible answer, write it down as an assumption and carry on, so the work does not stop to ask you. At the end of each milestone, the orchestrator brings you all the assumptions in one question, and you keep or change them. This applies to small features the same way it applies to any other work the crew builds.

How it works

When a builder meets something the plan does not cover, it does not wait for you. It makes a choice, records it as an assumption and keeps working on its ticket.

Each assumption names the tickets it touches and the builder that made it. Mid-build, assumptions stay open, and the crew does not interrupt you for each one.

At the end of the milestone, the orchestrator asks you one question that lists the assumptions made during it. You answer in the orchestrator’s session. Your answer goes into the project’s Decisions fold in your own words, up to 4,000 characters.

Here are assumptions from one real project:

• The working doc named vitest.config.ts, which fails to load on the repo’s Node version. The builder used vitest.config.mts instead.
• 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 reviewer’s smaller findings became a new ticket in the plan.
• The CI job for database tests ran on the same Node version as the unit tests, not the one in the working doc.
• A pull request already had a description, so the builder rewrote it into the documented sections instead of appending.

In that project the person kept all five. A project, end to end walks through the whole build.

Set it up

1. Make sure Claude Code and gh are signed in and Tares is running, as described in Get started. Then bring up the crew:

   tares factory crew up

2. Plan the work. Describe your small feature, and answer the questions Claude Code asks. The result is a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.

   tares factory spec "what you want to build"

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

4. Watch the build on the project page. Open the Assumptions fold to see every choice the crew has made on its own so far. Each one lists its tickets and the builder behind it. The Crew page in the console, at http://127.0.0.1:8787/crew locally, shows who is working and who is waiting for you.

5. When a milestone ends, answer the orchestrator’s question in its session. Keep the assumptions, or tell it which ones to change.

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

What you get

• The crew keeps moving when the plan has a gap, so a missing detail does not hold up a ticket.
• Every unplanned choice is written down, with the tickets it touches and the builder that made it.
• You review the choices together once per milestone, in one question, instead of one interruption per decision.
• Your answers are stored in the Decisions fold in your own words, and the Assumptions fold shows which choices you kept.
• You can make an answer stand for a project or for all projects, so the same gap does not come back as a question.
• Choices that need your own action stay with you. For example, a builder flagged a production data question in its pull request and left the fix to the person.

When something else fits

• Some questions only you can answer, such as trusting the repo folder in Claude Code or giving Tares a GitHub token. The crew asks those as questions, not assumptions.
• If you want to approve every merge, set that when you bring up the crew. Your approvals then show up as decisions.
• To steer work between milestones, talk to the orchestrator directly. You do not need to wait for the end-of-milestone question.

Related