Nobody writes the post-mortem, so my bug fixes write their own

Description and use

Developers rarely document post‑mortems, leading to recurring bugs. Bug Diary automatically records post‑mortems, compares new changes to past lessons, and warns before committing, reducing bug recurrence.

Problem

Developers rarely document post‑mortems, so recurring bugs are not learned from past fixes.

Outcome

Bug Diary reduced repeated bugs by warning on vulnerable code in 33 out of 92 later bugs and only warned on one of 21 ordinary commits.

Workflow

• 1. Commit a fix with a message starting with "fix".
• 2. Git hook triggers Bug Diary after the commit.
• 3. Bug Diary reads the diff, test, commit message, and issue.
• 4. Gemma 4 writes a post‑mortem card (symptom, root cause, pattern, guard, lesson).
• 5. EmbeddingGemma finds closest lessons in the diary.
• 6. Before a new commit, Bug Diary checks the change against lessons and alerts if a pattern repeats.
• 7. If a warning appears, the developer reviews the alert and writes a test or guard.
• 8. The diary updates with the new lesson for future checks.

Evidence

After a fix, it reads the diff, the new test, the commit message, and the issue if there is one, and Gemma 4 writes the post‑mortem nobody writes: symptom, root cause, pattern, the guard the fix added, and one lesson for next time.

Source

Before a commit, it describes what your change does, finds the closest lessons in the diary, and checks whether your change repeats one of them.

Source

Bug Diary warned on the vulnerable version of 33 bugs and on the fixed version of 14: for 24 bugs it warned on the vulnerable version only, and for 5 the other way round.

Source