What does the crew do when the plan does not cover a decision while it works on dependency upgrades?
Tares records an assumption and carries on, so the crew does not stop and wait for you. The orchestrator brings all the assumptions of a milestone to you together at the end of that milestone, and you keep or change each one. Every assumption stays on the project page with its status.
How it works
When a builder meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and keeps working. The ticket does not stall on a question.
Each assumption is kept with the project:
- It names the tickets it touches and the builder that made it.
- It stays open while the milestone is building.
- At the end of the milestone, the orchestrator brings you the open assumptions in one question in its session.
- You answer, and your answer is recorded in the Decisions fold in your own words. The Assumptions fold shows whether you kept each choice.
The project end to end walkthrough shows this on a real build. The plan named vitest.config.ts, which failed to load on the repo’s Node version. The builder used vitest.config.mts instead and recorded it as an assumption. In the same project, the builder left existing production data alone, flagged it in the pull request and left any production fix to the person. At the end of each milestone, the orchestrator asked whether to keep the choices the crew had made on its own, and the person kept all five.
This is how the software factory for Claude Code handles any gap in a plan. The assumptions are separate from the questions only you can answer, such as trusting a repo folder in Claude Code or giving Tares a GitHub token. Those still reach you as questions when work needs them.
Set it up
You do not configure assumptions. They are part of how the crew works once you hand it a project. If you are new to the factory, start with Get started.
- In the repo, run the spec session and 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- Start the crew. What you choose at this step sets 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- Say yes when the spec session asks whether to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
- Open the Crew page in the console,
http://127.0.0.1:8787/crewlocally, to see the stations, the projects and any question waiting for you. You can also check from the terminal.
tares factory crew status- While the milestone builds, open the project page and unfold Assumptions to see the open ones. You do not need to act yet.
- At the end of the milestone, answer the orchestrator’s question in its session. Keep the assumptions or change any you disagree with.
- To make an answer stand from now on, say so in your reply, for this project or for every project.
When no project is left, the orchestrator asks whether to stop the crew. Run tares factory crew down to stop every station. Tares keeps the projects, tickets and answers.
What you get
- Work that keeps moving. A gap in the plan does not stop a builder on a ticket.
- One review point per milestone. You see the crew’s choices together instead of one interruption per gap.
- A visible record. Each assumption lists its tickets and the builder that made it, and your answers sit in the Decisions fold in your own words.
- Control over what stands. You keep or change each assumption, and you can make an answer stand for one project or for all of them.
- Visibility into the work. Choices that touch existing data or files are flagged in the pull request, so you can see them in review.
When something else fits
- If you want to approve a step before it happens, set the crew up so it waits for your yes. The walkthrough shows a project that waits for the person’s yes before every merge, so most of its decisions are merge approvals.
- If you want to steer the work as it goes, talk to the orchestrator in its session instead of waiting for the end of the milestone.
Related
- A project, end to end
- What does the crew do when the plan does not cover a decision while it works on test coverage?
- How should I split dependency upgrades into milestones for a documentation website?
- How does the reviewer decide a pull request for dependency upgrades is good enough to merge?
Still stuck? Get help