Recurrence Firewall and Production Lock: bugs that stay fixed

A fixed bug is supposed to stay fixed. In practice it often doesn't: the fix lands, the context behind it fades, and months later a new change quietly reintroduces the same pattern. bugweg's Recurrence Firewall and Production Lock are the two features built to close that gap, one at review time and one starting from production incidents. This post covers what each one actually does today, and where each one deliberately stops.

Recurrence Firewall: a rule per fixed bug

Once a bug is fixed, a team can turn it into a recurrence rule from the bugweg dashboard. Each rule is scoped strictly to the repository it belongs to. From then on, every issue bugweg flags in a pull request is checked against the repo's active rules. If a flagged issue matches a rule above the rule's threshold, bugweg sets a blocking flag, and the GitHub Check Run for the pull request concludes with action_required.

Whether a match actually stops the merge depends on your repository settings, and we'd rather be exact about it. If branch protection requires bugweg's check to pass, the match genuinely blocks the merge. If it doesn't, the match still shows up as a clear, visible warning on the pull request, and the call stays with the reviewer. Either way the rule keeps running on every future pull request, long after the engineer who wrote the original fix has moved on to other work.

Developer plan and trial: up to 5 rules per team (counted across repositories). Team plan: no cap.

Production Lock: starting from a real incident

Recurrence Firewall starts from a bug caught in review. Production Lock starts from one your users already hit. Each repository can connect a Sentry or Rollbar webhook. Incoming errors are correlated by stack trace to fingerprints in the same table pull request reviews write to, and every tracked production bug shows up in a Bug Ledger view in the dashboard. When a pull request's changes stop re-flagging a tracked production bug, bugweg marks it resolved and starts the second half of the process.

Fail, then pass, then a human

The second half runs in an isolated per-job sandbox, which checks out a commit and runs a test command under a hard timeout while bugweg generates a regression test for the bug. The generated test has to fail on the broken commit and pass on the fix. Only a test clearing both conditions becomes a pull request, opened automatically with the regression test inside it. The full chain has fired end to end on a real merged fix: fingerprint resolved, fail-then-pass validation completed in the sandbox, and a real pull request opened with a correct generated test.

The pull request is where automation stops, on purpose. The field increasingly ships agents to auto-fix and auto-merge production incidents. Production Lock proves the fix and opens a pull request, and nothing merges without a human. A generated test can be subtly wrong. Fail-then-pass validation narrows the risk without removing it, so a person reading the diff stays the last gate. The trade costs a few minutes of review per locked bug, and in exchange every test guarding your codebase is one somebody actually read.

If recurring bugs are a known cost on your team, setup is short. Create rules for the fixes you never want to repeat, connect Sentry or Rollbar if you already use one, and make bugweg's check required in branch protection if you want matches to block rather than warn. The fixes you already paid for should stay paid for.

Related reading: what bug genealogy is, why codebases reintroduce the same bugs, and the Bug Genealogy feature.