# Release guide

This project has no automated publishing workflow. A maintainer performs each
release deliberately after reviewing the diff and CI results.

1. Before a public push or visibility change, audit the refs that will be
   published. Use a fresh clone of the intended public branch when prior local
   history was rewritten or contains private development material. A fresh
   clone does not erase an existing repository's Actions logs or prior remote
   history; if either is unsuitable for public disclosure, publish the reviewed
   branch to a new empty repository instead. Push the reviewed branch
   explicitly; never use `git push --mirror` from a general development
   worktree.
2. Ensure the working tree is clean and run:

   ```sh
   pnpm install --frozen-lockfile
   pnpm run check
   pnpm test
   pnpm audit --prod
   npm pack --dry-run
   ```

3. Update `package.json` using the appropriate pre-1.0 semantic version:
   patch for a compatible fix, minor for a compatible feature, and minor or a
   clearly documented breaking change when needed.
4. Review the package contents again with `npm pack --dry-run`; do not publish
   local profiles, Tailscale state, credentials, certificates, or personal
   configuration.
5. Commit the version change, create an annotated `v<version>` tag, and push
   only after the repository owner approves it.
6. Create GitHub release notes that explain user-visible configuration or
   security changes. Publishing to npm is optional and must happen only after
   the package name, access, provenance, and maintainer credentials have been
   reviewed.

Never treat a Git tag, GitHub release, or npm publication as an automatic side
effect of a code change.