[siracozmen01]

Problem

release-please publishes the GitHub release notes from the release pull request's body, not from CHANGELOG.md. The standard only asked for the CHANGELOG entry to be rewritten, so a release would publish the generated notes (a self-referencing compare link, internal CI lines).

Change

The release step says the curated entry also replaces the notes in the body, between release-please's --- lines.

Verification

maul-anim #6 and maul-nav #7 are curated this way. scripts/docs_check.py --strict reports the same 5 problems on main and on this branch; they are product-repository layout rules that do not fit .github itself, and none is in the changed file.

[siracozmen01]

Review at 1761d74. Ready, with one limit on the evidence.

The claim matches how release-please builds a release. After the release pull request merges, the manifest releaser reads the merged pull request's body (PullRequestBody.parse in src/manifest.ts, buildReleases) and takes each component's notes from it for the GitHub release. CHANGELOG.md is only one of the files the pull request writes, and the release step never reads it. For a single-component repository, the notes are the section between the header (:robot: I have created a release ... and its ---) and the footer ---, as the new sentence says.

Evidence and its limit:

• maul-unicode #4 (0.0.1) and maul-locale #12 (0.1.0) have bodies whose notes equal the curated CHANGELOG.md entry in their diffs, so they show the curated shape.
• Since body and changelog agree in both, they cannot show which one the published notes came from, and this session cannot read the published notes (gh release view and web fetches are not allowed here). The confirmation rests on release-please's source as I know it, not on an observed release. A release published from a body that differs from its changelog would settle it.

Note, not blocking: release-please rewrites the release pull request, body and CHANGELOG.md alike, whenever another commit lands on main while it is open. A curated entry is lost if anything merges between curating and merging. "Before merging it" covers this, but saying "last, right before merging" would prevent a common slip.