therefore release notes and known issues

1. Gather the change list for the release:
   • Prefer a PR list, a git diff range, or a curated list of user-facing items.
   • Pull candidate “known issues” from current tracking (and keep them honest).
2. Convert each item into user-facing language:
   • Lead with impact: “You can now…”, “This release makes…”, “Search feels…”.
   • Avoid implementation terms (for example, “refactor”, “SQLx”, “Zustand”, “IPC”).
3. Classify into:
   • What’s new (new capability)
   • Improvements (better UX, performance, reliability)
   • Fixes (bug fixes)
4. Migration note:
   • If migrations exist, say what users should expect on first launch after updating (one-time upgrade, possible longer first launch).
   • If no migrations, explicitly say “No migration steps needed.”
5. Write a short “Internal QA checklist” that verifies the big changes:
   • 3–6 steps, each with an observable expected result.
6. Produce output using the exact template below.

Style rules

• Sentence case.
• No dev-speak (avoid “refactor”, “under the hood”, “IPC”, “schema”, “migration 042”, “SQLx”).
• Be specific about user impact (“You can now…”, “Search feels faster…”, “Export includes…”).
• Keep it short: prefer bullets over paragraphs.
• If you mention a limitation, include a workaround when possible.

Output format (use exactly)

Release notes

What’s new

• <bullet>
• <bullet>
• <bullet>

Improvements

• <bullet>
• <bullet>

Fixes

• <bullet>
• <bullet>

If you’re updating from an older build

• <migration note or “No migration steps needed.”>

Known issues

• <issue> — Workaround: <what to do>
• <issue> — Workaround: <what to do>

Internal QA checklist (optional)

• <3–6 steps to verify the big changes>

Reference

Read references/therefore-release-notes.md for repo-specific sources (changelog, known issues sections, migration detection) and practical commands.