Multi-repo rollouts
Fleet · BB IDE plugin
A control tower for applying one change to many repositories: stage read from git, traps caught before work starts, lessons carried from repo to repo.
Problem
A change as small as a new SDK endpoint, multiplied by many repositories, turns into bookkeeping. Which repo has a branch, which has a PR, which merged? And the same environment traps cost time on every repo.
Constraints
- Many near-identical repositories, each with the same environment traps.
- The tool itself must never write to a repository.
How it works
- A round pairs a recipe with a set of repositories.
- Each repository's stage is derived from git: pending, in progress, code ready, PR open, merged, done.
- A read-only preflight checks the known traps before any work starts.
- A brief, including every lesson recorded so far, opens an agent thread in that repository.
- The agent applies the recipe and writes ship notes; the human commits, pushes and opens the PR; the board picks up the new stage.
Decisions
- Only what git cannot see is remembered: five manual marks.
- Recipes have a declarative half that drives status and a prose half that lives in a skill.
- Faking git in tests would only prove the fake works, so tests use real temporary repositories.
- One-line lessons are printed into every later brief of the round.
Trade-offs
- Reading every stage from git is slower than stored state, but it cannot drift from what the repositories actually contain.
- A human still commits and opens every PR, so a round moves at review speed.
Safeguards
- The plugin never mutates a repository, and the preflight is read-only.
- The skill forbids commit, push and PR creation.
- When package auth fails, the agent asks the human and never writes credentials.
Limits
- Recipes cover two kinds of change, code changes and branch merges; anything else needs a new recipe kind.
In numbers
- 6 derived stages
- 4 preflight checks
- 145 tests
- About 3,750 lines