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

In Tares, the reviewer posts a verdict on every builder pull request, and for an internal Node/TypeScript refactor you hold it to the acceptance checks plus unchanged behaviour. The reviewer reads the pull request against its ticket and milestone, and the builder merges once the verdict passes and CI is green. The checklist below turns that bar into concrete checks for a refactor.

How it works

Every project in the software factory for Claude Code starts from a spec. The spec holds milestones, and each milestone carries acceptance checks. A builder takes the tickets one at a time: it makes a branch, does the work and opens a pull request. The reviewer reviews every pull request and posts its verdict. If the verdict passes and CI is green, the builder merges. If the reviewer asks for changes, the builder makes them and the next round is reviewed.

The project page shows each ticket with its builder, its pull request and its review rounds, next to the milestone’s acceptance checks. For a refactor in a Node/TypeScript app, the example project in A project, end to end points to these checks:

• The ticket and its acceptance checks. The pull request does what the ticket says and meets every check on its milestone, and nothing else.
• Tests and CI. CI is green on the pull request. The code the refactor touches has tests, and CI runs on every pull request. In the example, the first milestone added Vitest, unit tests for the logic and a CI check.
• Behaviour that must stay the same. A refactor should leave results as they were. In the example, a milestone required that deactivating a sitter or changing a rate left past weeks untouched. Write that kind of check for the behaviour your refactor must keep.
• Existing data. If the change would affect data already in place, the builder leaves it alone and flags it in the pull request, and any production fix is left to you.
• The Node version. Config files must load on the repo’s Node version. In the example, vitest.config.ts failed to load, so the builder used vitest.config.mts. The CI job for database tests ran on the same Node version as the unit tests.
• Scope. Issues the reviewer finds outside the ticket do not widen the pull request. The orchestrator turns them into a new ticket and places it in the plan, as happened with T8 in the example.
• Assumptions. When the builder met something the plan did not cover, it picked the sensible answer and wrote it down as an assumption. Check that each such choice is visible in the pull request.

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. Plan the refactor as a project. In the spec session, give each milestone acceptance checks that name what must stay the same, such as unchanged outputs, tests that pass and CI on every pull request.
3. Bring up the crew, then start the spec session from the repo. The Get started page lists the full setup order, including tares up and tares mcp on a local Tares.

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

4. Open the Crew page in the console (http://127.0.0.1:8787/crew locally) to see the pull requests waiting for the reviewer.
5. Open the project page and unfold Tickets. Read each ticket’s pull request and review rounds against the milestone’s acceptance checks.
6. Answer the assumptions question the orchestrator brings you at the end of each milestone. Keep the choices that are right and say so for choices you want to stand from now on.

What you get

• A verdict on every refactor pull request, with each review round recorded on its ticket.
• A merge only after the reviewer passes the pull request and CI is green.
• Tests and CI that cover the refactored code, so later changes have a safety net.
• Data you did not ask to change left as it was, with any concern flagged in the pull request.
• Findings outside the ticket captured as a new ticket instead of a larger pull request.
• A record in the Decisions and Assumptions folds of every choice the crew made, so you can review the choices in one place.

When something else fits

• If the change is meant to alter behaviour, say so in the acceptance checks, so the reviewer judges it against what you actually want.
• If you want the final say on every merge, set the crew to wait for your yes before each merge. You then act as the last reviewer on top of the reviewer’s verdict.
• If the refactor touches something the plan did not foresee, expect it to come back to you as a question or an assumption rather than a silent change.

Related