# Release Checklist
Use this checklist for every public release of `solverforge-ui`.
## Before Tagging
- Confirm `main` is green in CI.
- Run `make assets` and verify no generated file drift remains.
- Run `make pre-release`.
- For changes touching Rust features or embedded asset serving, run
`cargo test --no-default-features` and `cargo check --no-default-features`.
- Review the conventional commits since the last tag and make sure
`commit-and-tag-version` will generate the intended next release notes.
- Confirm README and wireframe docs still match the shipped surface.
- Verify the crate version in `Cargo.toml` matches the intended release.
- Use `make bump-version VERSION=x.y.z` or `make bump-patch|bump-minor|bump-major` to sync repo version surfaces before the release step.
## Tagging
- This repository uses `commit-and-tag-version` for changelog generation plus the release commit/tag step.
- Version bumping is separate and happens through the Makefile bump targets.
- Run `make release-tag` only after the version bump is already in place and validated.
- If using the bump targets locally, ensure Node.js with `npx` is available.
- Push the release commit and tag to every intended release remote. The hosted
GitHub release and crates.io publish workflows run only when the `v*` tag is
present on GitHub.
## After Tagging
- Confirm the GitHub release job succeeds.
- Confirm the crates.io publish job succeeds.
- Inspect the published package contents with the package verification workflow.
- Sanity-check the generated release notes body against the new `CHANGELOG.md`
entry.
## Changelog Rules
- `CHANGELOG.md` is generated by `commit-and-tag-version` during
`make release-tag`.
- Use conventional commits for user-visible changes so the generated changelog
has the right content.
- Do not hand-promote an `Unreleased` section into a dated version heading.
- If release notes need adjustment, review the generated changelog diff before
pushing the release commit and tag.