Changelog

Add changelog entries as individual files in docs/changelog-entries/, then regenerate docs/changelog.mdx before opening or updating the PR.

Use a single long-lived branch for changelog automation: automation/changelog. The automation should update the existing open changelog PR from that branch when possible instead of opening multiple concurrent changelog PRs.

Principles

1. User-facing only. No infrastructure, CI, security hardening, billing internals, queue fixes, cron changes, self-hosting features, or anything users don't directly see or interact with.
2. Lead with a headline. Each entry has a theme name in the description field (e.g., "Chat Everywhere", not "v2.28"). The theme should immediately tell users what changed.
3. One short paragraph explaining the headline feature — what it does and why it matters. Write for end users, not developers.
4. 3–5 bullets max for other notable improvements in that release. If you can't fill 3 bullets, roll the changes into the next entry that has a strong headline.
5. Skip releases without a standout feature. Not every deploy needs a changelog entry. Only write one when there's something worth headlining.