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

Tares has the crew pick the sensible answer, write it down as an assumption and carry on, so a framework migration does not stall on a gap in the plan. At the end of each milestone the orchestrator brings all the assumptions to you in one question, and you keep or change them. Nothing the crew chose on its own stays hidden: each assumption is listed on the project page.

How it works

The software factory for Claude Code treats a gap in the plan the same way on every project, a framework migration included.

• The crew decides and records. When a builder meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and keeps working. It does not stop to ask you for each one.
• Each assumption is traceable. While the milestone is still building, assumptions are open. Each one names the tickets it touches and the builder that made it.
• You get one question per milestone. At the end of each milestone, the orchestrator brings you its assumptions together: keep the choices the crew made on its own during this milestone?
• Your answer is recorded. The answer goes into the Decisions fold in your own words, up to 4,000 characters. Tares matches a long pasted reply in full.

An example from a real project, from A project, end to end:

• The working doc named vitest.config.ts, which failed to load on the repo’s Node version. The builder used vitest.config.mts instead and recorded it.
• 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, which the crew added to the plan.

That project raised five assumptions, and the person kept all five.

Some questions are not assumptions. Steps only you can take, such as trusting the repo folder in Claude Code or giving Tares a GitHub token, come as their own questions.

Set it up

1. Follow Get started to install the CLI, start Tares and sign in to GitHub. Claude Code must be signed in first.
2. Bring up the crew. This is where you choose how far it may go.
3. Plan the migration with a spec. Answer Claude Code’s questions in the spec session. The result is a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks. Anything you settle here is in the plan, so the crew has less to assume.
4. Hand the project to the crew when the spec session asks. The orchestrator picks it up and starts a builder for the first milestone.
5. Watch the assumptions pile up, if you like. Open the project page and unfold Assumptions to see every choice the crew made and whether you kept it.
6. Answer the milestone question in the orchestrator’s session. Keep the assumptions or change the ones you disagree with. To make an answer stand from now on, say so, for this project or for every project.

tares factory crew up
tares factory spec "what you want to build"

The Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares, shows any question waiting for you at the top.

What you get

• Work that keeps moving. A decision the plan did not foresee does not block the crew. In the project above, eight pull requests merged in about three hours with only five questions to the person.
• One review point per milestone. You look at the crew’s own choices together, with the tickets they touch, instead of being interrupted one by one.
• A full record. The Assumptions fold lists every choice and whether you kept it. The Decisions fold holds your answers as you typed them.
• Control after the fact. If you change an assumption, you say so in your answer, and you can make that answer apply to this project or to every project.

For the full walk-through of a project, with its spec, review rounds and decisions, read A project, end to end.

When something else fits

• If you want to choose a particular decision yourself, put it in the spec so it is in the plan, or talk to the orchestrator while the work runs. The orchestrator is where you steer.
• If you want a say before every merge, set the crew up that way. One project waited for the person’s yes before each merge, so its decisions were mostly merge approvals.

Related