The fix is already written.
You decide if it ships.
A security finding at or above the floor you set becomes a pull request that already builds, passes its tests, and carries a test that fails on the commit which introduced the defect. It proves itself five ways before you ever see it. Then it stops and waits, because merging is the one step RepoOps does not take on your behalf.
Auto-merge is off on every pull request the loop opens · a build floor, a daily cap and a watch-only switch bound what runs without you
What it does
The parts, and the module behind each one.
A brief, a build, five checks, one decision, and a lesson that lands before the merge does.
A brief that works as a leash
Before anything is written, the finding is scoped into a brief that names the files a fix may touch. The builder is then held to it: every changed file must be one the brief named or a new test sitting beside it. A fix that wanders outside its scope does not get shown to you.
lib/remediation/build-verify.mjsFive checks, and no partial credit
It builds. The tests pass. A new regression test passes on the fix and fails on the commit that introduced the defect. The guard holds. The pull request's own CI is green. A fix that misses one goes back to the builder once with the failure attached, and a second miss stops loudly with both attempts recorded.
lib/remediation/verdict.mjsOne decision, re-checked as you press it
Approve or reject. On approve the whole bar is re-run server-side at that moment rather than trusted from when the card was rendered, so a stale green cannot merge anything. Reject requires a reason, and the diff, the guard and the lesson are discarded together.
lib/remediation/verdict-gate.test.mjslib/remediation/builder.mjsThe lesson lands before the merge
Approving writes the lesson first and merges second, because the lesson is reversible and the merge is not. For a security case that carries a catalog rule, the same move arms that detector's own pattern, so the class of defect is caught at the gate next time rather than found again later.
lib/causal/prevention-receipt.mjsA build cannot start on your laptop by surprise
Builds run as an agent session in the cloud, one invocation per tick. The local queue worker skips build jobs outright, so a queued build waits for that routine rather than firing on the machine you happen to be working on.
lib/remediation/build-routine.mjsSeveral findings, one ordered plan
Pick a few things off the queue and get a single plan rather than a pile of pull requests: grouped by what a change touches, foundations first, and the work that needs a human kept separate from the work that does not.
lib/remediation/combine.mjsWhere it lands
What the platform gets, and what you get.
How it helps the platform
Fix is what closes the loop. Without it the other four acts produce a very well-attributed backlog.
- It consumes the chain the earlier acts builtThe brief is only as good as the finding and the trace behind it. A defect resolved to a session and a prompt produces a scoped brief; a defect resolved to a filename produces a guess, which is why the loop sits at the end rather than the start.
- It writes back into the detectorsAn approved security fix arms the detector's own rule, so the watching layer gets sharper every time the gate is used. The knowledge accumulates in the brain rather than in the head of whoever was on call.
- The receipt comes from the ledger, not from the loopA prevention receipt is built only from a row already written to the append-only ledger, and it carries the measured status of the band it came from. That is what makes a catch checkable by someone who does not take our word for it.
How it helps you
You spend your attention on the decision instead of on the diff, and you keep the bounds.
- Nothing merges without youAuto-merge is off on every pull request the loop opens. The merge seam is never touched unless the whole bar passes again, server-side, at the moment you approve. Zero fixes reach main on their own.
- A regression test you can trustThe new test is proved both ways: green on the fix and red on the commit that caused the defect. A test that only passes on the fix proves nothing about whether the fix addressed the bug.
- You set what runs unattendedA build floor decides which severities are worth building against, a daily cap bounds what the loop may spend, and a watch-only switch turns building off entirely while leaving the sensing on.
In practice
Three days this changes.
Each one runs on the modules above. The situation, what RepoOps does with it, and what you are left holding.
- 01
The same injection bug, in the fourth repository
- The situation
- A pattern your team has fixed three times before turns up again in a service nobody has touched this quarter.
- What RepoOps does
- The finding is scoped, the fix is built and proved five ways, and approving it arms the detector's own rule against that pattern rather than only patching the instance.
- What you get
- The fourth occurrence is the last one that reaches a human. The fifth is caught at the gate, and the catch has a receipt.
- 02
A weekend finding nobody wants to own
- The situation
- A high-severity finding lands on Saturday. It is real, it is small, and it will sit unassigned until Monday standup.
- What RepoOps does
- The loop scopes and builds the fix inside the daily cap, runs the five checks, opens the pull request, and stops there with auto-merge off.
- What you get
- Monday starts with a finished, CI-green pull request behind one decision, rather than with a triage conversation about a two-line change.
- 03
A fix you do not want
- The situation
- The loop builds something technically correct that would be wrong for reasons no rule could know, like a deprecation already scheduled for next sprint.
- What RepoOps does
- Reject takes a reason, and the diff, the armed guard and the written lesson are discarded together rather than leaving a guard behind for a fix that never shipped.
- What you get
- A clean no, with the reason recorded, and no half-applied state to discover three weeks later.
The limits
What this does not do.
Stated here rather than found out later. The long version, with the module behind each boundary, is on the proof page.
It does not run unattended
The build floor, the daily cap and the watch-only switch bound what the loop does before the gate, and the gate itself is a person. Nothing on this page describes a system that fixes your repository while you sleep.
Five checks are a bar, not a proof
They establish that the change builds, that the tests pass, that a regression test moves both ways, that the guard holds and that CI is green. They do not establish that the fix is the right design, which is exactly why the decision is yours.
No success rate is claimed here
The available figure comes from a synthetic fixture and needs a paragraph of caveats to be honest, so it does not appear on a marketing page. The loop-health surface in the app measures your own install instead.
It only fixes what the earlier acts found
A finding no detector raised and a defect no chain resolved never reach the loop. Fix inherits the coverage of Watch and the confidence of Trace, and it cannot exceed either.
Read further
Where this is documented in full.
- Auto-remediationthe nine stages, the human gate, and the lesson, as one story
- Auto-remediation referencethe loop, the five checks, and what each stage records
- Approval queuethe three bands, the build policy you edit, and one decision per pull request
- Fleet remediationone queue and one budget across every repository you track
- Lessonswhat an approved fix writes back, and how it reaches the next session
Let it build the fix. Keep the decision.
One developer, no account, nothing leaving the machine. Arm a control when you want one.