Compare
Four checks. Four different questions.
Bracel does not replace what you already run. It answers the one question the others are not built to answer: does the rule still hold, on this change, when the code is executed?
| Question | Code review | Tests you write | Static analysis |  Bracel |
|---|---|---|---|---|
| The question it answers | Does this change look right? | Do the cases someone wrote still pass? | Does the code match a known pattern? | Does the business rule still hold on this change? |
| Runs your application | No | Yes, for the cases written | No | Yes, built and started in isolation |
| Knows your business rule | If the reviewer remembers it | If a test was written for it | Rarely | Yes: the rule your team approved |
| Where the rule lives | In people’s heads | Next to the code it tests | In the tool’s rule set | In a rules file on your default branch |
| Can the change edit its own judge? | — | Yes, tests change in the same pull request | Configuration can change with the code | No. Rules are read from the base commit |
| When it cannot tell | Approves or asks | Usually skipped or green | No finding | UNKNOWN, with the reason and what to change |
| What it leaves behind | Comments | A pass count | Findings | Evidence: expected, observed, why, provenance |
Categories, not products. Many teams use all four; each is good at its own question.
Together
Add a check. Remove nothing.
Bracel runs as one more check on the pull request, next to what you have. It changes no merge settings.
- 01
Keep your reviews
A review catches design, naming and intent. Bracel does not read for style; it executes the rules that must hold.
- 02
Keep your tests
Tests prove the cases you wrote. Bracel proves the rule your team approved, with scenarios a pull request cannot rewrite.
- 03
Keep your scanners
Static analysis finds known patterns. A refund cap or an access rule is specific to your product, so it has to be executed.