Where can I read back what the crew decided during small features in a Go microservice?

Tares keeps that record on the project page, which every project you hand to the software factory for Claude Code gets. Open the Decisions fold for every question the crew asked you and your answer in your own words, and the Assumptions fold for every choice it made on its own. Tickets and Sessions complete the trail for a small feature in your Go microservice.

How it works

Each project handed to the crew has 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 lists every question the crew asked you, newest first, with your answer as you typed it. A recorded answer holds up to 4,000 characters.
• Assumptions lists every choice the crew made without asking, and whether you kept it. Mid-build they show as open. Each names the tickets it touches and the builder that made it.
• Tickets shows milestones with their acceptance checks, and each ticket with the builder that held it, its pull request and its review rounds. A ticket is to do, in progress, in review, merged or blocked, and a blocked one names the tickets it waits for.
• 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 lands in Decisions 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.

When the crew meets something the plan does not cover, it picks the sensible answer, writes it down as an assumption and carries on. At the end of each milestone the orchestrator brings you its assumptions in one question. To make an answer stand from now on, say so, for this project or for every project.

The same page also has Docs, GitHub and Crew folds. Docs holds the starting prompt, the spec, the plan and the project’s AGENTS.md. GitHub lists the repos the project changes, where each is checked out, and their open and merged pull requests. The A project, end to end page walks through one finished project with every fold filled in.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.
2. Install the CLI and start Tares. On a local Tares, run tares up, then start the MCP endpoint in a second terminal, because the crew reaches Tares only through it. On Tares Cloud, run tares login instead and skip the MCP endpoint.
3. Give Tares access to GitHub, in Settings > GitHub for a local Tares or Connect GitHub on Tares Cloud.
4. Bring up the crew, then plan the feature from inside your Go service repo.
5. Open the project page from the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares. Open Decisions, Assumptions, Tickets and Sessions in turn.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

If you want a first-time walkthrough of these steps, start with Get started.

To check the trail while the work runs, open the project page and read Decisions for what you approved, then Assumptions for what is still open. The orchestrator also lists the questions waiting for you on the page, under questions waiting for you.

What you get

• A written answer to “why does the code look like this?” for each small feature: your own words from Decisions, set beside the choices the crew made alone in Assumptions.
• A per-ticket history in Tickets: which builder held it, which pull request carried it and how many review rounds it took.
• Each assumption tied to the tickets it touches and the builder that made it, so you can trace a choice to the change that depended on it.
• The recorded sessions in Sessions, so you can go from a decision back to the conversation that produced it.
• A trail that outlasts the build. When the project is Done it moves to the finished list on the Crew page, and Tares keeps the projects, tickets and answers when you run tares factory crew down. To pick a finished project up again, hand it to the crew again, for example with a follow-up spec.

When something else fits

• If you want a summary of what moved across projects rather than the reasoning behind each choice, use Standup on the Crew page. It reports what is done, started, in review, blocked and waiting on you, and can be copied or sent to Slack.
• If you need to read the code change itself, the pull request on the GitHub fold is the better place. The project page records the decisions around it.

Related