Tighten the repo-state automation so canonical bot commits remain predictable while leaving main clean after each sync. Make the public catalog UI more honest by hiding dev-only sync, turning stars into explicit browser-local saves, aligning risk types, and removing hardcoded catalog counts. Add shared public asset URL helpers, risk suggestion plumbing, safer unpack/sync guards, and CI coverage gates so release and maintainer workflows catch drift earlier.
3.6 KiB
Release Process
This is the maintainer playbook for cutting a repository release. Historical release notes belong in CHANGELOG.md; this file documents the repeatable process.
Preconditions
- The tracked working tree is clean.
- You are on
main. CHANGELOG.mdalready contains the release section you intend to publish.- README counts, badges, and acknowledgements are up to date.
Release Checklist
- Run the scripted preflight:
npm run release:preflight
This preflight now runs the deterministic sync:release-state flow, refreshes the tracked web assets in apps/web-app/public, executes the local test suite, runs the web-app build, and performs npm pack --dry-run --json so release tags are validated against the same artifact path used later in CI.
- Mandatory documentation hardening (repo-wide SKILL.md security scan):
npm run security:docs
This is required so every release validates repo-wide risky command patterns and inline token-like examples before publishing.
- Optional hardening pass:
npm run validate:strict
Use this as a diagnostic signal. It is useful for spotting legacy quality debt, but it is not yet the release blocker for the whole repository.
- Update release-facing docs:
- Add the release entry to
CHANGELOG.md. - Confirm
README.mdreflects the current version and generated counts. - Confirm Credits & Sources, contributors, and support links are still correct.
- If PR or CI workflow behavior changed during the cycle, confirm maintainer and contributor docs mention the active checks (for example the
skill-reviewworkflow forSKILL.mdpull requests).
- Prepare the release commit and tag locally:
npm run release:prepare -- X.Y.Z
This command:
- checks
CHANGELOG.mdforX.Y.Z - aligns
package.json/package-lock.json - runs the full release suite
- refreshes release metadata in
README.md - stages canonical release files
- creates
chore: release vX.Y.Z - creates the local tag
vX.Y.Z
- Publish the GitHub release:
npm run release:publish -- X.Y.Z
This command pushes main, pushes vX.Y.Z, and creates the GitHub release object from the matching CHANGELOG.md section.
- Publish to npm if needed:
npm publish
Normally this still happens via the existing GitHub release workflow after the GitHub release is published.
That workflow now reruns sync:release-state, refreshes tracked web assets, fails on canonical drift via git diff --exit-code, executes tests and docs security checks, builds the web app, and dry-runs the npm package before npm publish.
Canonical Sync Bot
main still uses the repository's auto-sync model for canonical generated artifacts, but with a narrow contract:
- PRs stay source-only.
- After merge, the
mainworkflow may commit generated canonical files directly tomainwith[ci skip]. - The bot commit is only allowed to stage files resolved from
tools/scripts/generated_files.js --include-mixed. - If repo-state sync leaves any unmanaged tracked or untracked drift, the workflow fails instead of pushing a partial fix.
- The scheduled hygiene workflow follows the same contract and shares the same concurrency group so only one canonical sync writer runs at a time.
Rollback Notes
- If the release tag is wrong, delete the tag locally and remotely before republishing.
- If generated files drift after tagging, cut a follow-up patch release instead of mutating a published tag.
- If npm publish fails after tagging, fix the issue, bump the version, and publish a new release instead of reusing the same version.