release: what a release note has to say is decided in one place

[donislawdev]

Two workflows had an opinion about the same sentences. release.yml wrote them into the note it generates, and verify-release.yml held the published page to a list written out inside itself. Nothing compared the two.

Change the predicate URI in the generator alone and the check goes red on a correct page, and somebody debugs the release page. Change it in the check alone and a page telling people the wrong command sails through.

What changes

The list moves to .github/release-note-must-say.txt, and .github/scripts/note_says.sh reads it for both halves.

release.yml now checks the note it just generated. A generator that quietly stops saying one of those sentences becomes a failed build rather than a published page that goes red hours later, where fixing it is a public edit.

The script reports every missing line rather than the first, for the reason the verdict step already gives: a person reads a release page once.

Measured

By hand, because running bash from a Go test on a machine with three of them starts the wrong one:

input	result
the published v0.2.0 note	fails, naming all three missing
a note carrying all three	passes
an empty list	refused, rather than passing on any note

Guards

TestWhatAReleaseNoteHasToSayIsDecidedInOnePlace holds both workflows to reading the list. Deleting a call removes a check with nothing going red, which is the silent kind.

TestTheGeneratedReleaseNoteSaysEverythingTheListAsksFor holds the generator to saying everything the list asks for. Asked on a pull request rather than on a tag - the one moment nobody wants a surprise. It reads only the block that builds the note, so a substring found elsewhere in the workflow cannot answer for it.

Three mutations, all caught.

Checks

preflight --quick green on all twelve, tools/probes/workflow-shell.py clean on every run: step of both workflows, staleness clean at 733 entries.

🤖 Generated with Claude Code