Where can I read back what the crew decided during test coverage in a monorepo?

Tares keeps what the crew decided on the project page, in the Decisions and Assumptions folds. Decisions lists every question the crew asked you and your answer in your own words, newest first. Assumptions lists every choice the crew made on its own, and whether you kept it. Together with the Tickets and Sessions folds, they form an audit trail for the whole build.

How it works

Every project you hand to the crew gets a page of its own, the record of the whole build. Across the top it shows four steps (Spec, Build, Review and Done) and a progress bar with one segment per ticket. Below that, each part of the record folds open:

• Decisions: every question the crew asked you and your answer, in your own words, newest first. A recorded answer holds up to 4,000 characters.
• Assumptions: every choice the crew made on its own when the plan did not cover something, and whether you kept it. While a build is running, assumptions are open. Each names the tickets it touches and the builder that made it.
• Tickets: milestones with their acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds.
• Sessions: the recorded Claude Code sessions, from the spec session to each builder.
• GitHub: the repos the project changes, where each is checked out, and their open and merged pull requests. A project can span several repos, and this fold lists each one.
• Docs and Crew: the starting prompt, spec, plan and AGENTS.md, and the stations that worked on the project.

You answer the crew’s questions in the orchestrator’s session, and the answer goes into the Decisions fold as you typed it. Tares finds your answer in your session by matching it line by line. A long pasted reply with several lines or paragraphs matches in full, because Tares keeps up to 20,000 characters of your turn for this, and the tags Claude Code wraps around pasted text do not stop a match. A reply stored before this was fixed stays cut, so paste the missing lines once more.

At the end of each milestone, the orchestrator brings you its assumptions in one question. Your answer is recorded as a decision, and the assumptions show whether you kept them. In the worked example in A project, end to end, the crew asked five questions and recorded five assumptions, such as using vitest.config.mts instead of vitest.config.ts because the first failed to load on the repo’s Node version.

Set it up

If the crew is not yet running, follow Get started. The decisions you want to read back appear once the crew has a project.

1. Check that Claude Code is signed in, gh is signed in with write access to the repos the crew works in, and git, jq and curl are installed.
2. Install the CLI with uv tool install tares or brew install glassflow/tap/tares.
3. On a local Tares, start Tares, then start the MCP endpoint in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step.
4. Give Tares access to GitHub: Settings > GitHub for a local Tares, or Connect GitHub on Tares Cloud.
5. Bring up the crew, then plan the project, for example the test coverage work you want done.

tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "add test coverage across the repos in the monorepo"

6. Answer the crew’s questions in the orchestrator’s session as they come. Each answer lands in the Decisions fold.
7. Open the Crew page in the console (http://127.0.0.1:8787/crew locally), pick your project, and open the Decisions and Assumptions folds. The page also lists questions that are still waiting for you.

Tares keeps the projects, tickets and answers when you run tares factory crew down, so you can read them back after the crew stops and carry on later with tares factory crew up.

What you get

• Your answers, word for word, in one list, newest first, so you can see what you told the crew and when.
• Every choice the crew made without you, with the tickets it touches, the builder that made it, and whether you kept it.
• The tickets, pull requests and review rounds that sit behind each decision, so you can trace a choice from the question to the merged pull request.
• The recorded sessions, from the spec session to each builder, for the full detail behind a decision.
• A standup report, top right on the Crew page, of what is done, started, in review, blocked and waiting on you across each project, over the period you pick.
• A record that stays after the project is done. Tares marks it Done with your closing words and moves it to the finished list on the Crew page.

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

When something else fits

• For the code itself, use the GitHub fold, which lists each repo the project changes with its open and merged pull requests.
• For the exact steps behind one ticket, open the Tickets fold or the recorded session of the builder that held it.
• To change course on work in progress, talk to the orchestrator rather than editing the record.

Related