Say what changed in a release, instead of the same paragraph every time

[JDS300]

Every release carried one static paragraph describing a "Complete SpinUI Windows release" — which said nothing about what was in the build, and is not even true of this fork, whose headline artifact is a Linux AppImage.

What the notes become

• Install steps that name the actual version — Loremaster-0.4.0-x86_64.AppImage, not a generic instruction — plus which checksum file covers which download, and the "no self-update on Linux" fact people need.
• A candidate warning, only on prereleases.
• --generate-notes, appending every pull request merged since the last release.
• Title becomes Loremaster <version> rather than a fixed marketing line.

The part worth reviewing

Generation is anchored at the last full release, not the previous release:

$previousStable = gh api "repos/$env:GITHUB_REPOSITORY/releases/latest" --jq .tag_name
if ($LASTEXITCODE -eq 0 -and $previousStable) {
  $options += @('--notes-start-tag', $previousStable.Trim())
}

Rendering the output before merging is what caught this. Promoting v0.4.0-rc.1 to v0.4.0 merges nothing in between, so with the default anchor the generated section collapses to a bare "Full Changelog" link — the release people actually install would say nothing, while the whole changelog sat in the candidate's notes.

/releases/latest excludes prereleases, so it names the last full release. Candidates get the same anchor, which is also the more useful list for a tester: everything that differs from what they are currently running, not the delta from the previous candidate.

What this does not do

It generates what changed, from PR titles. It cannot write why — the narrative in v0.4.0-rc.1's notes explaining what the journal is for and why the lockout OCR went was hand-written. The intent here is that the structure and changelog are right by default, so a hand-written summary is an addition rather than a rescue.

Notes are set at creation only. Re-running a dispatch against an existing tag uploads assets and corrects the prerelease flag but leaves the body alone, so hand-edits survive a re-run.

Verification

• Release quality gate ALL PASS under TZ=UTC; workflow parses
• Output rendered by mirroring the PowerShell and calling the same generate-notes API, for both the candidate and the promotion case

As with the rest of the publish path, this only executes on a real dispatch — it will first run for real when v0.4.0 is cut.

🤖 Generated with Claude Code