What should the reviewer check when a builder opens a pull request for bug fixes in a Node/TypeScript app?

In Tares, the reviewer holds every builder pull request to a fixed bar and posts a verdict. When the verdict passes and CI is green, the builder merges. For bug fixes in a Node/TypeScript app, you get the most from that bar when the project docs carry the repo’s own facts, such as its Node version and how existing data must behave. Anything the reviewer finds outside the ticket can become a new ticket.

How it works

The software factory for Claude Code splits the work into a few clear roles. Here is how a bug-fix pull request moves through them, as shown in a real project in A project, end to end.

The spec session produces a spec, a plan, an AGENTS.md for the project and milestones. Each milestone carries acceptance checks.
The sessions that build the project read AGENTS.md and the project’s docs. Each ticket also has a working doc.
The builder takes one ticket at a time. It makes a branch, does the work and opens a pull request.
The reviewer reviews every pull request, holds a fixed bar and posts its verdict.
The merge happens when the verdict passes and CI is green.
Changes requested go back to the builder. It makes them and the next review round decides. In the example project, two tickets needed a second round and the rest passed on the first.
Findings outside the ticket are turned into a new ticket by the orchestrator. In the example, the reviewer’s smaller issues became ticket T8, placed before the integration tests.

What mattered in a Node/TypeScript bug-fix project

The example project fixed and tested a household app’s babysitter payouts. These points came up in it, and they are good candidates for your own docs:

Tests and CI on the branch. The first milestone added Vitest, unit tests for the babysitting logic and a CI check on every pull request.
Past behavior stays as it was. The second milestone said that deactivating a sitter or changing a rate leaves past weeks as they were, and that “today” is the household’s date.
Config that matches the Node version. The working doc named vitest.config.ts, which fails to load on the repo’s Node version. The builder used vitest.config.mts and recorded the choice as an assumption.
CI on the right Node version. The database-test CI job ran on the same Node version as the unit tests, not the one in the working doc.
Existing data left alone. Sitters already inactive in production kept open-ended slots. The builder flagged this in the pull request and left any production fix to the person.

Set it up

Run the spec session in the repo and answer Claude Code’s questions.
```
tares factory spec
```
Put the facts a bug fix depends on into the spec, the plan and the project’s AGENTS.md, so every session that builds the project reads them. For a Node/TypeScript app, that means the Node version, the test runner and its config file name, and which existing data must not change.
Write acceptance checks on each milestone. Phrase them as behavior you can verify, such as “payout history stays as it was”.
Say yes when the spec session asks to hand the project to the crew, and start the crew if it is not running.
```
tares factory crew up
```
Watch the Crew page in the console. Pull requests waiting for the reviewer appear in the review queue, and questions waiting for you appear at the top.
Open the project page and check the Tickets fold. It shows each ticket with its builder, its pull request and its review rounds.
Answer the crew’s questions in the orchestrator’s session. At the end of each milestone, the orchestrator brings you the assumptions the crew made on its own, and you keep or change them.

What you get

A verdict on every pull request. The reviewer reviews each one, so no bug fix merges without it.
A merge rule you can rely on. The builder merges only when the verdict passes and CI is green.
A visible review history. Each ticket shows its pull request and its review rounds on the project page.
Extra findings kept. Smaller issues the reviewer finds outside the ticket become their own ticket instead of being lost.
Judgment calls recorded. Choices like the .mts config or the untouched production data are written down as assumptions, each naming its tickets and its builder. You decide whether to keep them.
Your answers on record. The Decisions fold keeps every question and your answer in your own words.

When something else fits

You want to approve each merge yourself. The crew can be set to wait for your yes before every merge. The mid-build example project did this, and its decisions were mostly merge approvals.
A fix needs something only you can do. Trusting the repo folder in Claude Code, giving Tares a GitHub token, or fixing production data are steps for you, not the crew. The example project left its production data fix to the person.
You want a different bar for one repo. The reviewer’s bar is fixed. Put repo-specific expectations into the acceptance checks, the spec and the project’s AGENTS.md, which the sessions that build the project read.

Still stuck? Get help