Write the GitHub release from the tag that publishes it

[oblomov-dev]

Description

This workflow published five versions to npm and made a GitHub release for none of them. It surfaced when the API was asked for the latest one:

• releases/latest answered 404
• No Latest badge on the repository
• The releases page was 37 rolling render-gate-bundle prereleases, with no version among them

For a repository whose job is to be installed by strangers, that is the first page they see. The five releases (v0.1.0–v0.2.2) were written by hand today. This is so there is no sixth.

Where it goes, and why there

Into the job that already has contents: write and already runs after a successful publish — so:

• publish keeps contents: read, which the comment there asks for explicitly
• no release is written for a publish that did not happen

The job is renamed major-tag → after-publish, because it does two things now and the old name described only one. Not a required status check anywhere (the workflow is tag- and dispatch-triggered), so the rename costs nothing.

Three decisions worth the words

A missing CHANGELOG section warns, it does not fail	The packages are on npm by the time this runs. Missing notes are visible on the page and editable in a minute, and the release is still created — pointing at the file. A red run for something cosmetic is how people learn to ignore red release runs. The stale-alias step next to it is different: silent, serves the wrong code, and rightly fails.
make_latest is computed, not hard-coded	A patch backported to an older line (v0.1.3 after v0.2.0) is a release but not the latest one. Hard-coding true would point every reader at older code.
A re-run leaves an existing release alone	Same doctrine as the publish step: find the work done, move on. Rewriting would destroy notes edited by hand on the page — the likeliest reason to re-run at all.

!cancelled() on the new step, so the order between it and the alias move costs nothing in either direction: a failure here cannot skip the alias move, and a failed alias move cannot skip this.

How to test

The script was run against this repository's real data with a fake github object, since a workflow step cannot be exercised any other way before merge:

Scenario	Result
newest tag v0.2.2	make_latest=true, 74 lines of notes — identical to what the hand-written release got
backport v0.1.3	make_latest=false ✅ does not hijack Latest
CHANGELOG section missing	warning + pointer body, release still created
non-version tag	skipped, nothing written
re-run (HTTP 422)	absorbed, logged, release untouched
server error (HTTP 500)	propagates — not swallowed
## 0.2.1 vs ## 0.2.10	correctly distinguished

Also verified: release.yml parses as YAML with both jobs; the embedded script is syntactically valid in the async-wrapper form github-script executes it in; npm test still green.

The first real proof is the next release tag — and if the step misbehaves, it cannot damage the publish that precedes it.

Checklist

• npm test passes
• Workflow YAML and embedded script validated
• Logic tested against real repository data, failure paths included
• publish still contents: read
• RELEASING.md follows the rename and documents where the notes come from

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.