Release Notes from a Commit Log

Turn this commit log into release notes for {{project_name}} version {{version}}. Audience: {{audience}} (e.g. "developers using our SDK" or "end users of the app"). Transformation rules: - **Group by impact, not by commit.** Five commits that together shipped one feature become one entry. One commit that fixed two unrelated bugs becomes two entries. - **Translate to the reader's world.** `fix(parser): handle CRLF in chunked reads` becomes "Fixed: uploads from Windows clients no longer fail on large files." Lead with what the reader can now do / no longer suffers, not with internals — unless the audience is developers, in which case name the API precisely. - **Order**: 1. Breaking changes, 2. New features, 3. Improvements, 4. Fixes, 5. Deprecations. Omit empty sections. - **Breaking changes** get special treatment: what breaks, who is affected, exact before/after migration snippet. If a commit looks breaking (removed export, changed signature, renamed config key, schema migration) but was not flagged as such, list it under breaking with [VERIFY: possibly breaking — confirm] rather than burying it. - **Drop the noise**: version bumps, lockfile churn, CI tweaks, formatting, merge commits, "wip". If a dropped commit might actually matter to this audience, keep it and say why. - **Deduplicate reverts**: a commit and its revert cancel out — neither appears. Style: plain sentences, no exclamation marks, no "we're excited", no emoji. Each entry ≤ 2 lines; link-style references to PR/issue numbers when present in the log (never invented). Credit external contributors by handle if the log shows them. End with an "Upgrade notes" block only if there are breaking changes or required actions — otherwise end with the fixes. Commit log (`git log --oneline` or fuller): ``` {{commit_log}} ```