Release Process

Release Process

Releases are owned by the human maintainer. Agents should not tag, create GitHub releases, or publish npm packages unless explicitly asked.

Local Gates

go build ./...
go test -count=1 ./...
gofmt -l main.go cmd internal
golangci-lint run --timeout=5m
go vet -tags=integration ./...
go test -race -count=1 ./...
govulncheck ./...
npm pack --dry-run

Real Backend Gate

The release workflow runs the reusable integration suite in required mode against digest-pinned MySQL and PostgreSQL containers. Missing DSNs fail the release instead of becoming green skips.

Release Metadata

Release builds inject metadata through main-package ldflags:

-X main.version=<version> -X main.commit=<sha> -X main.built=<yyyy-mm-dd>

The npm package installs a launcher that downloads the platform binary from GitHub Releases and verifies SHA-256 before use.

Supply Chain

• Publication requires a GitHub-verified signed annotated tag whose target is exactly the freshly fetched origin/main commit and whose version matches package.json and one literal changelog heading.
• The complete CI, vulnerability, MySQL, and PostgreSQL gates rerun on that tagged commit before GitHub Actions builds release artifacts.
• Release aggregation fails closed unless it receives the exact six platform bundles, validates every per-binary SHA-256, emits a six-line global checksums.txt, and produces exactly 27 assets. Binaries and the global manifest are signed with cosign.
• npm publishing uses OIDC trusted publishing with provenance.
• Wiki pages should be updated when user-facing commands, governance, output contracts, or release flow change.