Where can I read back what the crew decided during dependency upgrades in a Go microservice?

Tares keeps the crew’s decisions for your dependency upgrades on the project page, in the Decisions fold. Open the project for your Go microservice and read Decisions, Assumptions, Tickets and Sessions as one audit trail. Each answer you gave is stored in your own words.

How it works

Every project you hand to the software factory for Claude Code gets its own page in the console, the record of the build from spec to done. The page is split into folds, and four of them form the trail you want for an upgrade:

• Decisions lists every question the crew asked you, with your answer as you typed it, newest first. A recorded answer holds up to 4,000 characters.
• Assumptions lists every choice the crew made without asking, and whether you kept it.
• Tickets shows the 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. Tares then finds your reply in that session by matching it line by line, so a long pasted answer with several paragraphs is kept in full, up to 20,000 characters of your turn. If a reply was stored before that fix, it stays cut, and you paste the missing lines once more.

When the crew meets something the plan does not cover, it picks a sensible answer, writes it down as an assumption and carries on. At the end of each milestone the orchestrator brings you the assumptions in one question. Keep them and they are recorded as kept. To make an answer stand for later work, say so, for this project or for every project.

Set it up

Follow these steps to get a project page that records an upgrade. They match Get started, so read that page for the full setup.

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 with uv tool install tares (or brew install glassflow/tap/tares).
3. On a local Tares, start it, then start the MCP endpoint that every crew session shares in a second terminal. On Tares Cloud, run tares login instead and skip the MCP step.
4. Give Tares access to GitHub.
5. Bring up the crew, then plan the upgrade from the repo of your service with the spec command.

tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"

6. Answer Claude Code’s questions in the spec session. The result goes into Tares as a spec, a plan, an AGENTS.md for the project and milestones with acceptance checks. Say yes when asked to hand the project to the crew.
7. Open the Crew page in the console, at http://127.0.0.1:8787/crew on a local Tares, and click your project. Questions waiting for you show at the top of that page.
8. While the build runs, open the Decisions fold to read back each answer, and the Assumptions fold to see which choices are still open.

After the last milestone, the orchestrator asks whether the project is finished. Your answer is kept as the closing decision. The finished project stays on the Crew page, folded below the open ones.

What you get

• One place to read what happened during the upgrade, without scrolling through terminal history.
• Your own answers, as you typed them, so the reasoning behind each approval or instruction is yours and not a summary.
• A list of the crew’s own choices, each tied to the tickets it touches and the builder that made it, with a record of whether you kept it.
• A ticket-by-ticket view with the pull request and the review rounds for each change.
• The recorded sessions, so you can go from a decision to the conversation that led to it.
• A standup report on the Crew page that lists 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.

Tares keeps the projects, tickets and answers when you stop the crew with tares factory crew down. They are there when you bring the crew back with crew up. For a worked example of a project from spec to done, see A project, end to end.

When something else fits

• If you only need the pull request history, the GitHub fold lists the repos a project changes, with their open and merged pull requests, and GitHub itself remains the record of the code.
• If a decision belongs in your own tracker, note that sessions update Linear or GitHub Issues with their own tools and Tares only reads those tickets, so keep that tracker for work you want your team to see there.
• If you want the crew’s overall state rather than one project’s history, use the Crew page and the Standup report.

Related