Fixing a bug is the cheap part. Keeping it fixed is where teams lose time. A merge rule is a check, tied to a bug you already fixed, that GitHub requires to pass before similar code can merge. The fix merges, the person who understood it moves on, and a later refactor brings the same pattern back through a pull request that looks perfectly normal.

Most teams answer this with a regression test, and that is the right first move. But tests cover the inputs someone thought of. A pattern can return with different names, in a different file, with a different call shape. This post is about the second layer: a merge rule that says "if a change looks like this bug again, stop and look".

Step 1: write down the pattern, not the patch

A rule is only as good as its description. Before you automate anything, answer in one sentence: what does the code do wrong, in general terms?

• Weak: "Fixed crash in formatProfileSummary."
• Useful: "A formatting helper reads a field from an optional record without a null guard."

The second one can be recognized in a different file. The first can only be recognized in one.

Step 2: pick where the rule lives

You have three realistic options, and they stack:

For patterns that are semantic ("optional value used without a guard"), a review-time rule is often the only layer that fits.

Step 3: make the check actually block

This is the part people get wrong, whatever tool they use. A failing check does not stop a merge by itself. GitHub only blocks when branch protection requires that check:

1. Repo Settings → Branches → Add branch protection rule (or Settings → Rules → Rulesets) for your default branch.
2. Enable Require status checks to pass before merging.
3. Add your review check to the required list.
4. Decide whether admins can bypass. Anyone with bypass rights can still merge.

Without step 3, a "blocking" rule is a loud warning. That is not useless, a visible warning on the PR changes reviewer behavior, but call it what it is.

Step 4: keep the rule list small

Every rule is a future false positive. A short list of rules for bugs that were expensive beats a long list for every bug that ever happened. Review the list every quarter and delete rules whose pattern no longer exists in the codebase.

Where bugweg's Recurrence Firewall fits

bugweg's Recurrence Firewall is this review-time layer. When bugweg flags an issue in a PR that matches an earlier flagged issue in the same repository, a Never Again button appears on that issue; you name the rule and create it from the dashboard. From then on, a flagged issue that matches a blocking rule above the rule's similarity threshold sets the bugweg GitHub Check Run to action_required. If your branch protection requires that check, GitHub blocks the merge while the check is in that state, subject to the limits below. If it does not, the match shows as a visible warning on the PR. It builds on Bug Genealogy, which spots the repeat in the first place; background in What Is Bug Genealogy?.

Limits, so you can judge it fairly:

• Rules are scoped to one repository. You create them in the dashboard with the Never Again button; deleting a rule and creating a warn-only rule are API-only today.
• Matching is by similarity, so a variant that is different enough can slip through. A match is a prompt to look, not a verdict.
• It only compares against issues bugweg itself flagged in that repository, and only on pull requests that reach the AI review stage.
• If the similarity check cannot run for a PR, no rule is enforced on that review.
• On the Developer plan and during the trial, the cap is 5 rules per team, counted across all repos and including rules Production Lock adds automatically. Team has no cap.
• Anyone with bypass rights on your branch protection can still merge.

The trial is one-time: 3 free PR reviews per developer (each new push to a pull request counts as a review). A card is required to start and is verified with a $0 authorization; nothing is charged unless you choose a paid plan and complete checkout yourself. See pricing. Prices are in Canadian dollars (CAD), plus applicable taxes. bugweg is not currently offered to customers located in Quebec. The longer write-up, including how Production Lock starts from a production incident and opens a pull request with a regression test, is on the bugweg blog.

If you take one thing from this post, take steps 1 and 3: describe the pattern generally, and make sure your branch protection requires the check you are counting on. That works with or without any tool.

Which fixed bug has cost your team the most the second time around? I would like to know what kind of pattern it was.

Disclosure: I work on bugweg. bugweg is an independent product. GitHub is a trademark of GitHub, Inc.; bugweg is not affiliated with, endorsed by or sponsored by GitHub.

Most teams have a recurring bug: one that came back. The first fix looked right, the tests passed, the PR merged. Months later, a refactor reintroduced the same defect, and someone spent an afternoon rediscovering what the team had already learned.

A normal postmortem is built for outages. It is too heavy for a bug that is "just" fixed twice. What you need is smaller: an autopsy, one page that answers one question. Why did the first fix not hold?

Here is the template I would use, followed by a worked example.

What is a bug autopsy?

A bug autopsy is a one-page record written when a bug is fixed for the second time (or when you suspect it will come back). It captures the pattern, not just the patch, so the next reviewer can recognize the same defect even when the code looks different.

The template

Copy this into your repo as docs/bug-autopsies/TEMPLATE.md or into a PR description:

# Bug autopsy: <short name of the pattern>

**First seen:** PR #__  **Fixed in:** PR #__  **Came back in:** PR #__

## 1. The pattern (one sentence, no file names)
What does the code do wrong, in general terms?

## 2. Why the first fix did not hold
- [ ] No test covered the failing case
- [ ] The fix patched one call site, not the pattern
- [ ] The fix was reverted or overwritten by a refactor
- [ ] Reviewer did not know the bug had happened before
- [ ] Other: ____

## 3. How to recognize it next time
Two or three signs a reviewer can spot in a diff.

## 4. The lock
- Regression test added: <path or PR>
- Review rule / lint rule / checklist item added: <where>

## 5. Where it lives
Files and modules where this pattern is likely to reappear.

A worked example (illustrative, not a real incident)

This is a made-up case to show how the template reads.

Pattern: a function reads a field from an object that can be null, and the null path was only guarded at one call site.

Why the first fix did not hold: the fix added a null check at the caller that crashed, and no test covered the null input. Months later a refactor moved the call and dropped the check. Reviewers saw a clean diff.

How to recognize it: a helper that formats or summarizes an optional record; a refactor that moves a call out of a guarded block; a test file with no null case.

The lock: a unit test with a null record, and a checklist line in the PR template: "optional inputs to formatting helpers have a null test".

Notice what is missing: no blame, no timeline of the incident, no file-by-file diff. The value is in sections 1 to 4.

Make it stick: three habits

1. Write the autopsy in the fix PR, while the context is fresh. Ten minutes now can save an afternoon later.
2. Search before you approve. Before approving a refactor of a risky module, search past autopsies and fix PRs for the files it touches.
3. Turn section 4 into something executable. A test or a lint rule outlasts a document nobody reopens.

Where automation can help

The hard part of an autopsy is not writing it. It is remembering to look for it. Reviewers are human, and the PR in front of them looks new.

bugweg is a GitHub App built around that gap. Its Bug Genealogy feature compares each issue it flags with the bugs it flagged earlier in the same repository, using embeddings and a similarity threshold. When there is a match, the annotation says it is a recurring bug, how many times it has been seen in the repo, which PR it was first seen in when that is known, and how similar it is to the earlier occurrence. You can read the longer explanation in What Is Bug Genealogy?.

Limits, so you can judge it fairly:

• It only knows bugs bugweg itself flagged in that repo, not every bug your repo ever had.
• It runs on PRs that reach the AI review stage, not on every PR.
• A match is a prompt to look, not a verdict. It does not catch every bug and does not replace human review.
• An optional block rule (the Recurrence Firewall, see the features page) only blocks a merge if your branch protection requires the bugweg check.

The trial is one-time: 3 free PR reviews per developer (each new push to a pull request counts as a review). A card is required to start; it is verified with a $0 authorization and is not charged during the trial. Nothing is charged unless you choose a paid plan and complete checkout yourself, and a paid plan is needed to keep getting reviews after the trial. See pricing; all prices are in Canadian dollars (CAD), plus applicable taxes.

If you only take one thing from this post, take the template. It works with or without any tool.

What is on your team's "bug that came back" list? I would like to see which pattern shows up most.

Disclosure: I work on bugweg. bugweg is an independent product. GitHub is a trademark of GitHub, Inc.; bugweg is not affiliated with, endorsed by or sponsored by GitHub.