[ioquatix]

bake-releases 0.3.10 generates each version's section of releases.md from the squash-merged commit subjects since the previous release tag (base-rs/bake-releases#35), so nobody edits the file by hand any more. This requires that release, which the unchanged cargo:after_version_bump hook now uses through releases:update TAG, and bake-cargo 0.11.0, whose release tasks verify the generated notes. It adds a releases job to this repository's test.yml, inside the test-result aggregate, that runs releases:check with full history. On a pull request it checks against the base branch as GitHub's merge commit has it, HEAD^1, because the event's base SHA is the base from when the pull request was opened. A merge group uses its own base. It also brings the skills in line. base-project-pull-requests says not to edit releases.md: write the title as the user-facing release note, and add a Breaking: paragraph to the description for a breaking change. That is the one exception to the rule against a closing Key: value line, and it points to the Release Notes guide that bake-releases now installs. base-project-releasing previews the notes with releases:notes Unreleased and describes the refusal to start a release with nothing to release, and the stricter detection that comes with base-rs/bake-cargo#71. base-project-setup and base-project-update add the releases job and the adoption steps, including the manifest repository and keeping an existing ## Unreleased. The conventions and the performance skill now say "pull request title" where they said "release notes".

[ioquatix]

Independent review: looks good. I pushed one change and am merging once CI passes.

• HEAD^1 is right for pull_request. The checkout is refs/pull/88/merge, whose first parent is the current tip of main (d1febdb), while the event's base SHA can be stale. merge_group.base_sha is right for a merge queue, but this workflow has no merge_group trigger and the ruleset has no queue, so that clause only matters to repositories that copy the job. On pushes the job checks nothing.
• Bypass: releases:check exempts commits that carry a Release: trailer. A pull request commit with a forged trailer therefore passes the pull-request check, and the hand edit lands through the squash merge. I reproduced this locally. Running the check on pushes against github.event.before (… || github.event.merge_group.base_sha || github.event.before) fails the squashed commit on main; I confirmed that locally too. My token can't push workflow changes (it lacks the workflow scope), so this is left as a follow-up. It detects the edit after the fact rather than preventing it, and reviewers would see the trailer anyway.
• Pushed 49707ba: require bake-cargo 0.11.0 (just released), because releasing.md now describes its refusal to start a release with nothing to release and its stricter detection.
• The skills are consistent with bake-releases' context/release-notes.md: a Breaking: paragraph (not a trailer), and the title as the release note. Each fact is stated in one place, with cross-references. Semver: patch, 0.1.12.