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.
6. Casual, clear tone. Use "you" and "your", not "users". No jargon. No version numbers as headlines.

Format

Create or update docs/changelog-entries/YYYY-MM-DD.mdx with frontmatter + markdown: