Where can I read back what the crew decided during internal refactors in a Node/TypeScript app?

Tares keeps every crew decision on the project page, which each project you hand to the software factory for Claude Code gets. The Decisions fold holds each question the crew asked you and your answer in your own words, newest first. The Assumptions fold holds every choice the crew made on its own and whether you kept it, and the Tickets and Sessions folds complete the trail. This works the same for internal refactors in a Node/TypeScript app as for any other project.

How it works

Each project’s page is the record of the whole build. Across the top it shows four steps, Spec, Build, Review and Done, and a progress bar with one segment per ticket. Below that, each part of the record folds open:

• Decisions: 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: every choice the crew made on its own, and whether you kept it. Mid-build they are open. Each 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.

The Docs, GitHub and Crew folds sit beside them. Docs holds the starting prompt, the spec, the plan and the project’s AGENTS.md. GitHub shows the repos the project changes and their pull requests. Crew lists the stations that worked on the project.

You answer the crew’s questions in the orchestrator’s session, and the answer goes into the Decisions fold as you typed it. When the crew meets something the plan did 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.

The example project shows this on a real build. The working doc named vitest.config.ts, which fails to load on the repo’s Node version, so the builder used vitest.config.mts and recorded that as assumption A1. You read that choice back in the Assumptions fold, with the builder and tickets it touched.

Set it up

1. Follow Get started to check your prerequisites, install the CLI and connect GitHub. On a local Tares, start Tares with tares up and the MCP endpoint with tares mcp --transport streamable-http first.
2. Bring up the crew, then plan the refactor from inside the repo. The spec session asks you questions and produces the spec, plan, AGENTS.md and milestones.

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

3. Say yes when asked to hand the project to the crew. The orchestrator picks it up and starts a builder for the first milestone.
4. Answer the crew’s questions in the orchestrator’s session. Each answer lands in the Decisions fold as you typed it. Questions waiting for you also show at the top of the Crew page and on the project page.
5. At the end of each milestone, answer the orchestrator’s question about its assumptions. To make an assumption stand from now on, say so, for this project or for every project.
6. Read the record on the project page at any time. The Crew page lists open projects and folds finished ones below. Locally it is at http://127.0.0.1:8787/crew.

What you get

• An audit trail that stays after the build. Tares keeps the projects, tickets and answers even when you stop the crew with tares factory crew down, so the crew carries on from them with crew up.
• Your answers in your own words, not a summary, so you can see what you told the crew and when.
• Every self-made choice written down as an assumption, with the tickets it touches and the builder that made it, and a clear record of whether you kept it.
• Tickets that show the builder, the pull request and each review round, so you can trace a decision to the code change that followed.
• Recorded sessions, from the spec session to each builder, for the full conversation behind a decision.
• A Standup report, top right on the Crew page, of what moved in each project: done, started, in review, blocked and waiting on you, with pull request links.

When something else fits

• If you only need to know who is working on what right now, use the Crew page. It shows each station’s state and its last lines, and the project page is for the lasting record.
• To pick up a finished project, hand it to the crew again, for example with a follow-up spec.

Related