How does the crew’s work on bug fixes reach main?

Tares has each builder fix a bug on its own branch, open a pull request, and merge it to main once the reviewer passes it and CI is green. The reviewer holds every pull request to a fixed bar and posts its verdict on the pull request. You can let the crew merge on its own or have it wait for your yes.

How it works

A bug fix reaches main the same way every ticket in a project does. Four parts of the crew are involved:

• Orchestrator: hands out the ticket to a builder and brings you any question that needs you. It is the only session you talk to.
• Builder: takes the bug-fix ticket, works on its own branch and opens a pull request. Builders are started per milestone and repo of a project.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Builder again: merges the pull request once the reviewer passes it and CI is green.

Builders push and open pull requests with your gh login. Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own access to your repos. That is why the setup includes giving Tares access to GitHub.

Without a releaser, a ticket ends at merged on main. If you ask for a releaser, it tags and deploys after that.

Tares keeps the plan, the tickets and their stages, and every review. The sessions come and go, but the record stays on Tares, so a crew that restarts carries on where it stopped.

You choose how far the crew may go the first time you run tares factory crew up. The crew either merges on its own after review and green CI (the recommended choice) or waits for your yes. A single project can also wait for your yes before every merge while the rest of the crew merges on its own.

Set it up

Setup follows the order in Get started.

1. Check that Claude Code is signed in on a plan that allows background sessions. Sign in to gh with write access to the repos the crew works in, and make sure git, jq and curl are installed.

   gh auth login

2. Install the CLI.

   uv tool install tares     # or: brew install glassflow/tap/tares

3. On a local Tares, start it, then start the MCP endpoint every crew session shares in a second terminal. Stations reach Tares only through this endpoint.

   tares up
   tares mcp --transport streamable-http

4. On Tares Cloud, sign in instead and pick your workspace in the browser. There is no MCP endpoint to start.

   tares login

5. Give Tares access to GitHub so it can read pull request, CI and merge state. On a local Tares, add a GitHub token or App under Settings > GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repos.

6. Bring up the crew. On the first run, choose whether it merges after review and green CI or waits for your yes.

   tares factory crew up

7. Plan a project so the bug-fix tickets exist. Run this in the repo the project builds on.

   tares factory spec "what you want to build"

8. Follow the work. Check the stations and the project with these commands, or open the Crew page of the console.

   tares factory crew status
   tares factory projects

If a merge is not happening, run tares factory doctor to check everything the crew needs.

What you get

• Each bug fix lands as its own pull request from its own branch, so one change can be read, reviewed and merged on its own.
• Every pull request carries the reviewer’s verdict, held to the same fixed bar every time.
• Nothing merges until the reviewer has passed it and CI is green.
• Your merge policy is your choice: the crew merges on its own, or a project waits for your yes before every merge.
• Tickets end at merged on main unless you asked for a releaser.
• You can halt the crew at any time. tares factory crew halt stops merges, pushes and new sessions until you run tares factory crew resume.
• The Crew page in the console lists the pull requests waiting for review, so you see where a fix stands without watching terminals.
• The record of tickets, reviews and your answers stays on Tares, so a restart does not lose the state of a fix.

When something else fits

• If a bug is small and you want to fix it yourself with Tares tools bound to the project, run tares factory session instead of the crew. Take over a project from the crew only when you say yes.
• If you want a human to approve every merge on one project, choose the wait-for-your-yes setting rather than letting the crew merge on its own.

Related