When a tool tells you your code is wrong, you deserve to see why. That's the whole reason api-doctor's rules are open source.
What open source rules actually mean
Every rule in api-doctor is a plain file in the GitHub repository. You can read it, argue with it, and send a pull request if you think it's wrong.
Say the rule for Resend's emails.send() is off, maybe the docs changed, maybe we misread them. You can see that for yourself, fix it, and get a release out the door. No support ticket, no waiting on us to get around to it.
Why this matters more for a verification tool
Think about what you're using api-doctor for: catching mistakes in AI-generated code. If the tool's own rules are wrong, you're either flagging the wrong things or missing the real ones. A black box is genuinely a problem here in a way it isn't for, say, a theme picker.
With open rules, you can audit exactly what's being checked. If a rule fires on your code and you disagree, you can trace it straight back to the specific check and the documentation that justifies it.
Contributing rules
Using a provider we don't cover yet? The path in is refreshingly boring:
- Read the provider's API documentation
- Spot the call patterns that tend to go wrong
- Write a rule and a test fixture
- Open a pull request
The rules are simple tree-pattern matchers. You really don't need deep compiler chops to write one, which is by design.
The alternative
Closed-source linting rules ask you to trust something you can't see. You're running a tool that reshapes your workflow based on logic you're not allowed to inspect. For a security or correctness tool, that's a big thing to hand over on faith.
Open source doesn't magically guarantee correctness. What it does is make correctness verifiable, and that's the bar we hold ourselves to.