Fleet remediation

Today does not grow a tab per repo. It widens. When two or more repos actually hold a case, the queue reads the union of every tracked repo's case store and keeps the same three bands: built and waiting, being built, held below the floor. Each row carries a repo badge, a chip row filters the whole queue by repo, and the band headers count what is on screen. With one repo holding cases, nothing changes and the page looks exactly as it did.

The expanded approval card names the repo where it matters: on the tests check, on the PR CI check, on the pull-request link, and on the approve button itself. You are never one glance away from merging into the wrong remote.

One build tick covers the fleet. It walks every root the loop knows, and each queued build job carries the repo it belongs to; the runner resolves that id through your tracked repos to that repo's checkout and runs the build session there. An unknown repo id fails the job with the reason. It never falls back to this dashboard's own tree.

  sense ---> triage ---> scope ---> build ---> verify ---> APPROVE ---> ship ---> learn
  in the                in the      in its     against      one queue,   in its     in its
  finding's             aggregator  own        that repo's  any repo     own repo   own brain
  own repo                          checkout   suite + CI   (you)

• The branch and the PR belong to that repo. The branch pushes to its remote and the PR opens against that repo's own default branch, read from the repo rather than assumed to be main.
• The five checks run that repo's bar. Its build, its tests, its CI on its PR. The verdict records which repo's suite proved the fix, so a pass in the wrong repo is impossible by construction.
• The lesson and the guard arm where the mistake lives. They write to that repo's brain, so the prevention happens where the recurrence would. The catch still counts on your one Today page, attributed to its repo.
• The case, the brief, the gate and the budget stay in the aggregator. Your morning is still one page.

Before anything is dispatched, RepoOps measures five facts per tracked repo: whether it has a local checkout (the read-only mirrors are not a build surface), whether its code graph is filled, whether it has a toolchain with the exact build and test commands a verification run would execute, whether a credential answers for its remote, and what capture tier is measuring it. Each fact carries its evidence or its absence reason. "Could not measure" is recorded as that, never collapsed into a measured no.

The verdict is the runnable prefix of the pipeline, with the first blocked stage named alongside the fact that blocks it. The fleet card on the Today rail and the per-repo table on the AI incidents tab render it: capture, production source, detector coverage, autonomy, open cases. A repo that fails a fact is held at dispatch with the reason on the case, rather than dispatched to fail five checks it could never pass.

The severity floor and the daily dollar cap are one account-wide policy each, and the spend behind the cap is summed across every repo, so ten repos cannot quietly spend ten times the number you set. The scoping budget is counted the same way, across roots rather than per root.

A single repo can be narrowed, never widened past that policy. Raise its floor, or set it to watch only, which scopes findings but never builds them. A narrowed repo's held cases say why, in the same words on the Settings policy card and on the queue.

• Your own build and test commands. A repo entry can name a verify block with build and test command strings, which makes a Rust or Go repo with no package.json verifiable through its own toolchain. The commands used are recorded on the verdict, with their source, so "which commands proved this fix" is never an assumption. A malformed block is refused loudly rather than falling back to npm defaults, because the repo carrying an override is exactly the repo whose defaults are wrong.
• How the sandbox gets dependencies, decided per repo. Link the checkout's installed tree when it is measured healthy, run a real install inside the sandbox when it is thin or absent, and pin either with verify.install. The decision and its reason land on the verify record.
• A credential per remote. A repo entry names the environment variable holding its GitHub token, or opts in explicitly to the machine login. The committed config holds the name; your environment holds the secret, and no token is ever written to a record, a response or a log. A repo with neither refuses at the gate, with both remedies named, before any API call is made.

• Nothing merges on its own, in any repo. Approve is a person, every time. Widening the loop across repos widened its reach, not its authority.
• RepoOps does not mint credentials. It resolves which credential answers for which repo and refuses when none does. Provisioning a token per repo, or per Sentry project, is still yours to do.
• Capture tier is measured per machine, not per repo, and the fleet surfaces label it that way. Two repos on one laptop share a tier because the tools that produce the capture are installed once.
• One defect in two repos opens two cases. Folding repeated sightings into one case deliberately stops at the repo boundary, so a shared-dependency bug is two cases and nothing links them yet.
• A repo tracked without a local checkout can sense and triage, not build. The eligibility read says so per repo rather than leaving the queue quietly still.
• The spend meter is one account-wide number. Every dollar on it is attributed to a repo, but there is no per-repo cap yet; the shared number errs toward less spend, not more.
• The fleet views are for a fleet. Below two tracked repos the fleet card and the per-repo table omit themselves, and the queue stays in its single-repo shape.

• Auto-remediation: the nine stages, the brief that leashes the builder, and the five-check bar this program points at every repo.
• Approval queue: the three bands, the floor and cap, and what approve and reject each do.
• Repos: what tracking a repo gives you before any of this runs.
• Config: the verify and credential fields a repo entry can carry.