I built MRO because repositories lie — not maliciously, but through entropy.
A README claims tests pass, but there’s no CI.
A CHANGELOG hasn’t been updated in months.
Dependencies have known CVEs no one noticed.
MRO enforces what repositories claim about themselves.
Try it:
npx maintenance-release-operator check
It verifies things like:
- LICENSE exists
- CHANGELOG exists
- CI workflow exists
- No known security vulnerabilities
- No lockfile conflicts
Exit code 0 = compliant
Exit code 1 = failed
Design constraints (intentional):
- Strict by default (no configuration)
- Deterministic (same repo → same result)
- No AI in the execution path
- No telemetry by default
- Rules are enforcement, not suggestions
Designed for CI: if MRO fails, the PR does not merge.
I built MRO because repositories lie — not maliciously, but through entropy.
A README claims tests pass, but there’s no CI. A CHANGELOG hasn’t been updated in months. Dependencies have known CVEs no one noticed.
MRO enforces what repositories claim about themselves.
Try it:
npx maintenance-release-operator check
It verifies things like: - LICENSE exists - CHANGELOG exists - CI workflow exists - No known security vulnerabilities - No lockfile conflicts
Exit code 0 = compliant Exit code 1 = failed
Design constraints (intentional): - Strict by default (no configuration) - Deterministic (same repo → same result) - No AI in the execution path - No telemetry by default - Rules are enforcement, not suggestions
Designed for CI: if MRO fails, the PR does not merge.
Repo: https://github.com/JonathanRyzowy/maintenance-release-operat...
Examples: https://github.com/JonathanRyzowy/maintenance-release-operat...
Question: Most tools optimize for flexibility. MRO optimizes for governance. Is this too strict — or overdue?