Where can I read back what the crew decided during docs updates in a Python backend?

Tares keeps every decision the crew made on a project in the Decisions and Assumptions folds of that project’s page. Open the project that holds your docs updates in the Python backend and read the Decisions fold for your answers, in your own words, and the Assumptions fold for the choices the crew made on its own. Tickets and Sessions complete the audit trail.

How it works

Every project you hand to the crew gets a page of its own, the record of the whole build. Its parts fold open, and four of them make up the audit trail:

• Decisions holds 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 holds every choice the crew made on its own, and whether you kept it. When the crew meets something the plan does not cover, it picks a sensible answer, writes it down as an assumption and carries on. Mid-build the assumptions are still open. The orchestrator brings them to you together at the end of each milestone, and each one names the tickets it touches and the builder that made it.
• Tickets holds milestones with their acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds.
• Sessions holds the recorded Claude Code sessions, from the spec session to each builder.

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 Tares fixed this stays cut, so paste the missing lines once more.

The Docs fold sits beside them. It holds the starting prompt, the spec, the plan and the project’s AGENTS.md, plus the AGENTS.md and memory shared by every project.

Set it up

1. Start Tares locally if it is not running, and make sure the crew has been brought up with tares factory crew up. New to the factory? Get started lists the full setup in order.

tares up

2. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares.
3. Under Projects, click the project that covers the docs updates in your Python backend. Open projects are listed with their builders, and finished ones are folded below.
4. Open the Decisions fold to read each question and your answer in your own words. Newest comes first, so the latest merge approvals or milestone questions are at the top.
5. Open the Assumptions fold to see what the crew chose on its own and whether you kept it. To make an answer stand from now on, say so in the orchestrator’s session, for this project or for every project.
6. Open Tickets to see which builder held each ticket, its pull request and its review rounds. Open Sessions to go back to the recorded Claude Code session behind it.
7. Open Docs, then All docs at its foot, to read the spec, plan and AGENTS.md the sessions work from. You can edit any of them there. Each ticket’s working doc sits with its ticket.

Tares keeps projects, tickets and answers when you stop the crew with tares factory crew down, so the record is still there when you come back.

What you get

• One page per project where you read back the whole build, from the starting prompt to the last merged pull request.
• Your answers kept as you typed them, up to 4,000 characters each, so you see what you said and not a summary.
• A list of the choices the crew made without asking you, each tied to its tickets and the builder that made it, with your keep or reject outcome.
• Tickets that link each change to its builder, pull request and review rounds, and sessions that let you trace the reasoning back to the recorded Claude Code session.
• A project marked Done with your closing words once every ticket is merged, moved to the finished list on the Crew page.

In a worked example, one project raised five decisions. Two were steps only the person could take, and three were the end-of-milestone questions about assumptions. Five assumptions were each recorded, such as a config file swapped because the named one failed to load, and the person kept all five.

When something else fits

• For a summary of what moved rather than the reasons behind it, use Standup on the Crew page. It lists what is done, started, in review, blocked and waiting on you, since yesterday, over 7 days or between dates you pick, with pull request links. See A project, end to end for the full tour.
• For what the crew is doing right now, or a question waiting for you, use the Crew page itself, where waiting questions sit at the top and each station shows its state.
• To change course, talk to the orchestrator. The project page is a record, and steering happens in the orchestrator’s session.

Related