Where can I read back what the crew decided during bug fixes in a Go microservice?

Tares keeps what the crew decided on the project page, in the Decisions and Assumptions folds. Decisions hold every question the crew asked you, with your answer in your own words, newest first. Assumptions hold every choice the crew made on its own and whether you kept it. Tickets and Sessions sit on the same page, so the page is the audit trail for your bug-fix project.

How it works

Every project you hand to the software factory for Claude Code gets a page of its own, the record of the whole build. For your Go microservice bug fixes, the page folds into parts you can open one at a time:

• Decisions: every question the crew asked you and your answer, in your own words, newest first. If the crew asked you to approve a merge, the answer is there as you typed it.
• Assumptions: every choice the crew made on its own when the plan did not cover something, and whether you kept it. While a milestone is running, assumptions are open. Each one 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, GitHub and Crew: the starting prompt, spec, plan and AGENTS.md, the repos the project changes with their pull requests, and the stations that worked on it.

You answer the crew’s questions in the orchestrator’s session. The orchestrator brings the assumptions to you together at the end of each milestone, as one question. Your answer to that question is recorded under Decisions, and the choices it covered are marked in Assumptions. To make an answer stand from now on, say so, either for this project or for every project.

The project page works the same way for any repo, so a Go microservice is read back like any other project. For a worked example of a real project with its five questions and five assumptions, see A project, end to end.

Set it up

1. Bring up the crew and plan the bug-fix project from inside your Go microservice repo. If you have not set up the software factory yet, follow Get started first.

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

   Describe the bug fixes in place of the quoted text. You answer Claude Code’s questions, and the result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks.

2. Say yes when asked to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.

3. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. It lists the open projects, with the finished ones folded below. Open your project to reach its page.

4. Open the Decisions fold to read each question the crew asked you and your answer, newest first.

5. Open the Assumptions fold to see each choice the crew made on its own, whether you kept it, and for open ones the tickets it touches and the builder that made it.

6. Open the Tickets fold to see, for each bug-fix ticket, the builder that held it, its pull request and its review rounds. Open Sessions to find the recorded Claude Code sessions, from the spec session to each builder.

7. Answer the milestone question about assumptions. Keep the choices you agree with, and say so explicitly if you want an answer to stand for this project or for every project.

8. When the project is done, the orchestrator asks whether to stop the crew. Run tares factory crew down to stop every station. Tares keeps the projects, tickets and answers, so the record stays readable and the crew carries on from it when you run crew up again.

What you get

• One page per project that records the whole build, from the starting prompt to the last merged pull request.
• Your answers kept in your own words, so you can see exactly what you approved and when.
• A list of every choice the crew made without asking you, with your verdict on each, so nothing the crew assumed stays hidden.
• Tickets with their builder, pull request and review rounds, so you can follow each bug fix from ticket to merge.
• Recorded sessions you can open when you want the full story behind a ticket.
• A record that stays after the crew stops. Finished projects move to the finished list on the Crew page, and Tares keeps the projects, tickets and answers.

When something else fits

• If you want to steer work while it runs, talk to the orchestrator. The project page is where you read the record back, and the orchestrator is where you give direction.
• If you want the code-level detail of a change, read the pull request listed in the GitHub or Tickets fold, since the project page records decisions and assumptions rather than diffs.

Related