What should the reviewer check when a builder opens a pull request for framework migrations in a Go microservice?

Tares has the reviewer review every pull request a builder opens and post a verdict. The builder merges once the verdict passes and CI is green. For framework migrations in a Go microservice, you hold the pull request to the milestone’s acceptance checks, then look at what the migration must leave untouched and what the builder decided on its own.

How it works

The reviewer’s bar comes from the spec, so the checks exist before the first pull request does.

• The spec session produces a spec, a plan, an AGENTS.md for the project and milestones, each with acceptance checks. The Tickets fold on the project page lists those checks and each ticket with its builder, pull request and review rounds.
• The builder takes tickets one at a time. For each, it makes a branch, does the work and opens a pull request.
• The reviewer reviews every pull request and posts its verdict. If it asks for changes, the builder makes them and a second round follows. In the worked example, two tickets took a second round and the rest passed on the first.
• When the verdict passes and CI is green, the builder merges. You choose at crew up how far the crew may go, so a project can also wait for your yes before every merge.
• Smaller issues the reviewer finds outside the ticket become a new ticket. The orchestrator places that ticket in the plan, so the pull request under review stays on its own scope.

The Get started page covers the setup that sits behind this loop.

Set it up

Set the bar before the builder starts, then check each pull request against it.

1. Bring up the crew and plan the migration as a project. Name the framework you are moving off and the one you are moving to in the spec prompt.

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

2. In the spec session, write the milestone’s acceptance checks so that each one can be answered yes or no. The example project used checks such as “payout history stays as it was”, which states what must not change. A migration fits that shape: existing behavior stays as it was.
3. Make sure the repo has tests and a CI check on every pull request. In the example, the first milestone added tests and CI to a branch that had none, so later pull requests had something to be judged against.
4. When a pull request appears in the review queue on the Crew page, open its ticket in the Tickets fold and read its acceptance checks next to the pull request.
5. Check the pull request against this list:
   • CI is green, and the tests the acceptance checks call for are in the pull request.
   • Each acceptance check for the milestone is met by the diff, not only by the description.
   • Existing data and production state are left alone. In the example, the builder left existing data as it was, flagged it in the pull request and left any production fix to the person.
   • Any choice the builder made on its own is written down. The builder recorded a different config file name because the one in the working doc failed to load on the repo’s Node version, and it ran the database-test CI job on the same Node version as the unit tests. For a Go service, look for the same kind of note on version and config choices.
   • The description is documented in sections, not left as a stub. In the example, the builder rewrote an existing description instead of appending to it.
6. Check the Assumptions fold. The orchestrator brings the milestone’s assumptions to you in one question at the end of the milestone, and you keep or reject them there.

What you get

• A verdict on every pull request, recorded with its review rounds on the ticket.
• A bar that is fixed by the milestone’s acceptance checks, so each migration pull request is judged against the same written outcome.
• Choices the builder made on its own listed as assumptions, each with its tickets and the builder that made it, so you see them at the end of the milestone instead of finding them later.
• Smaller issues the reviewer finds outside the ticket turned into their own ticket, so the migration pull request stays focused.
• A project page that keeps the whole record: spec, plan, tickets, decisions, assumptions and sessions. The full walkthrough is in A project, end to end.

When something else fits

• If you want to approve every merge yourself, choose that when you run crew up. The project then waits for your yes before each merge, and each approval lands in the Decisions fold as you typed it.
• If a migration needs a call only you can make, such as a production data fix, answer it in the orchestrator’s session instead of expecting the reviewer to settle it.
• If a pull request covers more than one ticket’s checks, steer through the orchestrator so the work is split into separate tickets.

Related