Where can I read back what the crew decided during bug fixes in a documentation website?
Tares keeps the crew’s decisions on the project page, in the Decisions and Assumptions folds. Every project you hand to the crew gets this page, so the record for bug fixes in a documentation website sits in one place. Decisions hold every question the crew asked you and your answer in your own words. Assumptions hold every choice the crew made on its own, and whether you kept it.
How it works
Every project you hand to the software factory for Claude Code gets a project page, the record of the whole build. The page works the same whatever the project builds, so a documentation website with bug fixes gets the same folds as any other project. Across the top are four steps, Spec, Build, Review and Done, and a progress bar with one segment per ticket. Below them, each part of the record folds open:
- Decisions: every question the crew asked you and your answer, newest first. The answer is stored as you typed it, 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. Each assumption 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.
- Docs: the starting prompt, the spec, the plan and the project’s AGENTS.md.
You answer the crew’s questions in the orchestrator’s session. Tares finds your answer in your session by matching it line by line, so a long pasted reply with several lines or paragraphs matches in full. Tares keeps up to 20,000 characters of your turn for this.
Assumptions stay open while a milestone is building. At the end of each milestone, the orchestrator brings them to you in one question, and your answer lands in Decisions.
Set it up
- Bring up the crew and plan the project. Follow Get started for the prerequisites and the full order of steps. Then describe the work, for example the bug fixes you want in your documentation website:
tares factory crew up
tares factory spec "fix the broken links and build errors in the documentation website"- Answer the spec session’s questions, and say yes to handing the project to the crew. The spec, the plan, the AGENTS.md and the milestones with their acceptance checks go into Tares and show in the Docs and Tickets folds.
- Answer the crew’s questions in the orchestrator’s session as they come. Each answer goes into the Decisions fold as you typed it.
- Open the Crew page in the console (
http://127.0.0.1:8787/crewlocally) and open the project from the Projects list. Finished projects are folded below the open ones. - Open the Decisions fold to read your answers, then the Assumptions fold to see each choice the crew made on its own and whether you kept it. Open Tickets for each ticket’s builder, pull request and review rounds, and Sessions for the recorded Claude Code sessions.
- To make an answer stand from now on, say so in the orchestrator’s session, for this project or for every project.
The page A project, end to end walks through one finished project, a pull request with a few bugs in how it paid shifts. It shows the Decisions fold with five questions and the Assumptions fold with five assumptions, each in its own words.
What you get
- Your words, kept as typed. Decisions holds each answer as you wrote it, up to 4,000 characters, newest first. A long pasted reply is matched in full.
- The crew’s own choices, in the open. Assumptions lists every choice the crew made without asking. Each one names the tickets it touches and the builder that made it, and shows whether you kept it.
- The work behind the choices. Tickets show the builder, the pull request and the review rounds for each ticket. Sessions hold the recorded Claude Code sessions, from the spec session to each builder.
- A record that stays. When you stop the crew with
tares factory crew down, Tares keeps the projects, tickets and answers, so the crew carries on from them when you runcrew upagain. - A summary on request. Standup, top right on the Crew page, reports what is done, started, in review, blocked and waiting on you, with pull request links. You can copy it as markdown or send it to Slack.
When something else fits
- If you want a quick view of what moved across projects rather than the full audit record, use Standup on the Crew page.
- If you want to see what the crew is doing right now, use the Crew page, where each station shows its state and its last lines.