# Release Notes Backlog

## Required Work — completed 2026-08-30, before the v1.8.5-alpha cut

- [x] Backfill missing or thin historical release notes before cutting the next release.
  Eight sections backfilled, sourced from the Settings "What's New" blocks,
  the old-lineage release commits, and the diffs of the self-contained
  hotfix releases: **v1.7.44** (was raw commit-hash lines), **v1.7.47,
  v1.7.48, v1.7.64, v1.7.65** (were thin), and **v1.7.50, v1.7.51,
  v1.7.107** (sections were missing entirely — real releases with tags but
  no changelog section; v1.7.107 was restored verbatim from the curated
  version that existed at `35e9c624` and was later lost). The What's New
  modal blocks for the three restored versions were generated by
  `scripts/sync-whats-new.py`, which now passes with all 92 versions.
- [x] Audit every `CHANGELOG.md` section from `v1.7.44-alpha` through the
  current release. Mechanical inventory of all 92 sections in range:
  every section carries ≥3 curated bullets, zero raw commit-hash entries.
- [x] Replace raw commit-hash entries with user/operator-facing bullets
  that explain behavior changes, operational impact, validation, and
  known limitations. The only offender was v1.7.44 (four raw hash lines,
  now curated).
- [x] Ensure `releases/manifest.json` changelog entries come from curated
  `CHANGELOG.md` notes only. Satisfied by construction:
  `create-release-manifest.sh` reads the changelog from `CHANGELOG.md`,
  and `check-release-manifest.sh` rejects manifests with fewer than three
  bullets or raw git-log lines before publishing.

## Release Note Policy

- Every release must have at least three curated bullets.
- Raw `git log --oneline` output is not acceptable release documentation.
- Notes should answer what changed, why it matters, what operators should expect, and any known limitations.
- `scripts/check-release-manifest.sh` is the enforcement gate before publishing artifacts.