docs: add a changelog and the release notes flow

CLAUDE.md

@@ -24,6 +24,54 @@
 - `src/pam`: the PAM module for sudo and admin prompts.
 - `src/ctl`: the client the bash code talks to the daemon with.
 
+## Releases
+
+Releases look like the ones of big projects such as Immich. `.github/release-notes.sh <tag>` builds
+the notes: the entry from `CHANGELOG.md` (welcome and highlights), a support section, every commit
+since the last release sorted by its prefix (`feat`, `fix`, `docs`, ...) with author and link, and
+the full changelog link. So commit subjects end up in public: keep them clear.
+
+1. Read `git log <last tag>..HEAD` and pick the version: only fixes → patch, something new → minor,
+   something that breaks or needs the user to act → major.
+2. Bump the version and add the entry at the top of `CHANGELOG.md`, in one commit (`chore: 1.4.0`).
+3. Push, then push the tag: `git tag v1.4.0 && git push origin main v1.4.0`. The `release` workflow
+   builds the packages and creates the release. It stops before building when the entry is missing.
+4. PKGBUILDS picks up the new release for the AUR on its own.
+
+A minor or major release (has `### Highlights`, gets a heading and the support section):
+
+```markdown
+## v1.4.0
+
+_2026-09-24_
+
+Welcome to plasma-face-unlock `v1.4.0`! One or two sentences on what this release is about.
+
+<p align="center">
+  <img width="480" alt="What the picture shows" src="https://raw.githubusercontent.com/LoonixTools/plasma-face-unlock/v1.4.0/<path>">
+</p>
+
+### 🚨 Breaking changes
+
+- Only if there are any: what changed, and what the user has to do.
+
+### Highlights
+
+- First highlight, a few words
+- Second highlight
+```
+
+A picture or a snippet of the menu under the welcome is optional. The highlights stay a plain list:
+no heading or text per highlight, the list of commits explains the rest.
+
+A patch release is just a sentence or two, for example: "A small patch. The menu no longer closes
+when you press Enter." The list of commits follows on its own.
+
+- Write for users: what they notice, not how the code does it. Friendly and simple.
+- Commands and settings they type go in backticks, buttons and labels in bold.
+- To change an old release: edit its entry, commit, then
+  `gh release edit <tag> --title <tag> --notes "$(.github/release-notes.sh <tag>)"`.
+
 ## Testing
 
 Never test against the real setup: enrolling and the PAM files belong to the user's machine.