Skip to Content
Tares

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

Tares records every crew decision on the project page in the console, in the Decisions and Assumptions folds. Decisions holds each question the crew asked you with your answer in your own words. Assumptions holds each choice the crew made on its own, and whether you kept it. The Tickets and Sessions folds complete the audit trail.

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. 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. 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.

You answer the crew’s questions in the orchestrator’s session. Tares finds your answer in that 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, and the tags Claude Code wraps around pasted text do not stop a match.

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, and your answer lands in Decisions.

The walkthrough in A project, end to end shows this on a real project. Its first milestone was tests and CI on the branch: Vitest, unit tests and a CI check on every pull request. The record for that milestone holds assumptions such as these:

  • The working doc named vitest.config.ts, which fails to load on the repo’s Node version, so the builder used vitest.config.mts instead.
  • The CI job for database tests ran on the same Node version as the unit tests, not the one in the working doc.

Set it up

  1. Open the Crew page in the console. Locally it is at http://127.0.0.1:8787/crew. Open projects are listed with their builders, and finished ones are folded below.
  2. Click the project that holds your test coverage work to open its page. The top shows four steps (Spec, Build, Review, Done) and a progress bar with one segment per ticket.
  3. Open the Decisions fold to read each question and your answer as you typed it. Open the Assumptions fold to read each choice the crew made on its own. Mid-build they show as open until the end-of-milestone question.
  4. Open the Tickets fold to see which builder held each test ticket, its pull request and its review rounds. Open Sessions to find the recorded Claude Code session behind a decision.
  5. If a long reply from before a fix shows cut off, paste the missing lines once more. A reply stored before that fix stays cut.
  6. To make an answer stand from now on, say so in the orchestrator’s session, for this project or for every project.

If the crew is not running yet, bring it up first. The crew keeps the projects, tickets and answers when you stop it, so the record is still there when you come back.

tares factory crew up

New to the factory? Get started lists the full setup order.

What you get

  • One page per project that reads as an audit trail: what the crew asked, what you answered, and what it chose alone.
  • Your answers kept in your own words, newest first, so you can check exactly what you approved.
  • Each assumption tied to its tickets and the builder that made it, so a test setup choice leads back to the pull request that carried it.
  • A record that lasts after the project is Done. Tares marks it Done with the words you gave and moves it to the finished list on the Crew page.
  • A way to see unresolved items: questions waiting for you appear at the top of the Crew page and on the project page.
  • Your decisions apply forward. Tell the orchestrator to make an answer stand and the crew follows it.

When something else fits

  • If you want a summary of what moved rather than the full record, use Standup on the Crew page. It reports what is done, started, in review, blocked and waiting on you, and you can copy it or send it to Slack.
  • If you want to steer work in progress, talk to the orchestrator in its session. The project page is for reading back what was decided.

Still stuck? Get help

Last updated on
Quickstart