Releases

How a release happens

1. Every merge to main runs semantic-release from conventional commits: fix: is a patch, feat: a minor, a breaking change a major. Commits scoped web, docs or ci never release.
2. The job re-runs typecheck, the full test suite and the build before publishing.
3. Publishing uses npm trusted publishing (OIDC) with provenance. There is no long-lived npm token.
4. A first-release guard refuses to compute 1.0.0: the release line is anchored at v0.0.0, so the first release is 0.0.1 or 0.1.0.
5. A manual workflow publishes canaries to the canary dist-tag, leaving latest untouched.

What counts as breaking

Scoring formulas, weights and caps; CLI command or flag removals; schema field removals; raising the Node floor. New or promoted rules and additive schema fields are minor; false-positive reductions and docs are patches. Rule changes that alter findings on unchanged inputs are called out in the release notes.

Gates by stage

• 0.1.0-alpha: alpha-scoped tests, benchmarks on three real Next.js apps, and the M1–M3 demonstration.
• 1.0.0-beta: full deterministic suites, a 30-site / 10-repo benchmark, published agent evals, and an external security review with no open high findings.
• 1.0.0: the beta gates plus four weeks with no open high-severity bugs.

npm · GitHub releases