Bug genealogy is the idea that a bug has a life story, not just a single appearance in a diff, and that a reviewer should know the whole story, not just the current chapter.
Why merges reset memory
Many code reviewers, human and automated alike, judge a PR mainly on its own diff, and once it merges that context is easy to lose. If a bug that was fixed six months ago quietly comes back in a refactor, it looks brand new to the reviewer, because nothing in the process connects it to the earlier occurrence. There is no thread linking the original bug, its fix, and its return.
This is the gap bugweg's Bug Genealogy Engine is built to close. Instead of treating every PR as a fresh, unrelated event, it matches each flagged issue against every bug pattern the repo has had flagged before, so a bug's history — introduced, fixed, reintroduced, and, once a team adds a Recurrence Firewall rule, locked — can be read across several PRs. That history persists across merges, so a reintroduction isn't a mystery, it's a recognized event in a history the system already has.
One history, not isolated reviews
Concretely, this means when bugweg flags something in a new PR, it isn't just evaluating the diff in front of it. It's checking that diff against the bugs the repo has actually had, matching patterns against prior introductions and fixes rather than starting from zero each time. That's a different question than whether this code looks risky in isolation: it's whether the team has been here before.
From memory to a lock
The genealogy record is also what makes the Recurrence Firewall possible. Once a bug has been fixed and its pattern is known, a team can turn that pattern into a Recurrence Firewall rule. A change that matches the rule sets bugweg's check to action_required, which blocks the merge if your branch protection requires that check, and shows up as a clear warning on the PR if it doesn't. Production Lock extends this idea to production incidents: when a bug tracked from a connected error tracker (Sentry or Rollbar) is resolved by a merged fix, bugweg generates a regression test, checks that it fails on the broken commit and passes on the fix, and opens a pull request for a human to review. It only fires for bugs that came in through a connected tracker, and it never merges anything itself, so treat it as an assist for those incidents rather than a blanket guarantee. For a side-by-side with other review tools, see the comparison page.
What to look for in your own repo
The timeline above illustrates what this looks like for a single bug: introduced in one PR, fixed in a second, reintroduced in a third, then locked. If you're evaluating bugweg on a repo you already suspect has recurring bugs, open a PR that touches one of those patterns and read bugweg's comment. When the pattern has been flagged before, the comment says how many times it has appeared and links the earlier fixes. That's the fastest way to see whether the tool actually connects those PRs, or just reviews each one cold.
See it on your own repo. 3 free PR reviews — card required, never charged.
Install on GitHub