ci(release): ship version-matched release notes and rotate the changelog backlog

[Nic-dorman]

Linear issue

V2-1107 — https://linear.app/autonominetwork/issue/V2-1107

Risk tier

• T0 — docs / tooling / CI / pure UX-output. Repo CI only.
• T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
• T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
• T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Compatibility

• Wire: none
• Storage: none
• API: none (no crate code touched — CHANGELOG.md + release workflow only)

Semver impact

• breaking
• feature
• fix

What

Every ant release from 0.2.x through 0.3.4 shipped stale accumulated notes: the release body extracts "the first CHANGELOG.md section", and [Unreleased] was never rotated after [0.1.1] - 2026-03-28. Concretely: 0.3.4's notes are byte-identical to 0.3.3's (its actual content, #173, appears nowhere), ~80% of 0.3.5-rc.1's entries are re-shipped from earlier releases, and the IPv6 dual-stack entry (April, 0.2.0) has re-shipped for four months. Full audit on V2-1107.

Two commits:

1. docs(changelog) — rotation/backfill. Each [Unreleased] entry attributed by git blame on its line → first stable ant-cli-v* tag containing that commit. Entry text preserved verbatim; only placement changed. [0.3.4] is written fresh from the 08-18 train manifest (V2-1000; feat(channel): make the ant client beta-channel aware #173 was its only ant-client PR and never had an entry). The five 0.3.5-line entries (refactor(core): thin the CLI — move parsing/resolution into ant-core, route all daemon calls through the client #157/fix(cli): refuse ambiguous EVM network selection (devnet manifest vs mainnet default) #158/feat(client): resumable external-signer finalize for both paths #172 era) stay under [Unreleased] until 0.3.5 promotes. Releases nothing was ever written for (0.3.0–0.3.2, 0.2.2–0.2.11) get honest stub sections pointing at V2-1107 — happy to drop the stubs or deep-backfill instead if you'd rather.
2. ci(release) — the guard. Extraction now targets ## [<base version>] (rc/beta suffix stripped) and fails the release when that section is missing or empty, with the rotation instruction in the error. This alone would have caught all five stale releases.

Sequencing — please confirm at review

• The 0.3.5 promote on 2026-09-02 is unaffected: it tags on rc-2026.8.4, which carries the pre-guard workflow and its own frozen CHANGELOG. It will ship one final stale body; the live 0.3.2–0.3.4 bodies can be patched post-merge from the rotated sections (gh release edit, listed on V2-1107).
• From the next train's rc.1 onward, the cut must rotate [Unreleased] → ## [X.Y.Z] - <date> (one mechanical edit alongside the version bumps) or the guard blocks the tag — deliberately. The cut/promote tooling needs that step before the next cut.
• Prereleases and the stable of one train intentionally share one section: rotate at rc.1, and beta/rc/stable all ship the same correct notes.

Test evidence

• Extraction simulated locally against the rotated changelog for 0.3.4, 0.3.3, 0.2.0 (each pulls exactly its own section — 1/5/1 entries), and 0.3.5-rc.1 / 0.3.5-beta.2 (fail-closed, no [0.3.5] section yet — the designed behavior pre-rotation).
• Workflow YAML parses (yaml.safe_load).
• Attribution cross-checked two ways: git blame → first-containing-stable-tag per line, and first-appearance diffs across the published 0.3.0→0.3.5-rc.1 release bodies; the train manifests (V2-1000, V2-1068) corroborate the 0.3.4 and 0.3.5-line attributions.

New dependency

none

ADR

n/a

Mitigation / rollback

Revert the workflow commit to restore first-section extraction (the rotated changelog is content-only and safe either way). The guard can only block a release, never mis-publish one.

Noted while auditing, author's call: #174 (NetworkHealth) has no changelog entry; if it warrants one it belongs under [Unreleased] before the 0.3.6 cut.

🤖 Generated with Claude Code