Why 'Fail-Open' Is the Right Default for a Linter
A security tool that cries wolf gets deleted. Why mirago is deliberately conservative — failing open and warning only when signals agree.
Every developer tool faces the same tension: catch more problems, or raise fewer false alarms. Push too hard on the first and you lose the second — and a tool that cries wolf gets uninstalled. mirago resolves that tension by being deliberately conservative.
Fail-open by design
mirago treats every missing or unknown signal as safe. If PyPI can't be reached, or download statistics are unavailable, it counts that as "fine" rather than manufacturing a warning. A network or stats outage can never become a false alarm.
This is the opposite of "fail-closed" security tooling that blocks on uncertainty. For a linter you run constantly, fail-open is what keeps it from becoming noise you learn to ignore.
Warnings require agreement
mirago only raises a warning when several signals fire together — a package that is both brand-new and barely downloaded. Being merely new, or merely low-download, or merely absent from your lockfile is never enough on its own. (The exact thresholds are conservative and provisional.)
Errors are unambiguous
The one thing mirago is strict about is existence: a package that simply does not exist on PyPI is an error, full stop. There's no false-alarm risk there — the AI invented it.
Why this matters
The value of a checker isn't how many things it flags — it's how much you trust what it flags. A precise tool you act on beats a noisy one you mute. That's why mirago would rather miss occasionally than be wrong loudly.
```bash
mirago check .
```
It's a small philosophy with a big payoff: a check you'll actually keep running. Start with the installation guide.