release-noteslisted

# Release notes for Switchboard Turns the commits and closed issues since the last tag into the body of a GitHub release. **Who reads this:** people who run four coding CLIs side by side and installed a desktop app to keep them straight. They are developers. So the notes may — and should — be **technical**: name the symptom, name the cause in half a sentence, link the issue. What they must never be is a `git log` in prose. ## The rules that make the difference **Never guess from the subject line.** A subject is fifty characters and often says less than it seems. For every `feat`/`fix` that is not self-evident, read `git show <sha> --stat` — the body and the touched files decide both the wording and the section it belongs in. A commit titled `fix(projects): …` that only touches `src/db/db.js` is not a project fix. **One line per thing the reader will NOTICE — never one line per commit.** Six commits that hardened one feature are one line. A commit that changed nothing a user can see is not a line at all. **Lead with the symptom, not the fix.** "The Stats page came back empty as soon as one template ran on a backend" tells the reader whether it ever bit them. "Fixed backendFilterIds flattening" does not. **Collapse the plumbing.** `chore`, `refactor`, `test`, `docs`, build changes: **one** collected line under *Under the hood*, or nothing. Never a bullet each. **Every entry carries its issue** (`#167`). That is the technical depth this audience wants, and it is free — t