The short version
- Fixing the bug on the screen is half the job.
- We name what kind of mistake it was.
- Then we write a test or a rule that blocks that whole kind.
- Every kind gets logged so it doesn't come back later.
The bug versus the kind of bug
Say the booking form on our site broke because a blank phone field got treated as text and blew up. Fixing that one field is the easy part. The real question is what kind of mistake it was. In that case: a blank field that the code assumed would never be blank. That kind of mistake can show up in a hundred other forms. If we only fix the one, we meet the same bug again next month wearing a different shirt.
The guard is the real fix
So for every bug we fix, we also write something that catches the whole kind. Usually that's an automated test that fails if anyone ever writes that mistake again, before the code can reach you. Sometimes it's a rule in the code that makes the bad state impossible. When it needs judgment, it's a checklist. We prefer the automated kind, because a checklist depends on someone remembering and a test doesn't.
What it means for you
When something breaks in Bench and we tell you it's fixed, we mean the bug and its relatives. We keep a log of every kind we've caught, so the list of things that can go wrong gets shorter over time instead of cycling.
Questions
When is a bug done?
When the symptom is fixed, we've named what kind of mistake it was, a guard exists that catches that kind, and it's in the log.
What's a kind of bug?
The pattern under the symptom. A blank field assumed to be filled. Two parts of the code that define the same rule differently. Trusting what a form sent without checking it.
Why not just fix it and move on?
Because the same kind comes back in a different form. The guard is how we stop meeting it.
Keep going
Every Bench word above is on Glossary / FAQs, in plain English.