---
name: board-credits-a-rider-the-notes-drop
description: Release notes read from the milestone narrative drop wave-gap riders that the request board still credits — two published surfaces then disagree
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 05565488-dcc4-4cbe-b83e-ede118687535
  modified: 2026-08-04T02:04:39.579Z
---

A release's CHANGELOG must be audited against the **commit range**, and the failure mode is specific:
a **wave-gap rider** — a fix that rode the range but was never milestone scope — is INVISIBLE to a notes
pass that reads the milestone narrative, while the alchemy `release` verb still picks it up from the board
and credits it publicly. The two published surfaces then contradict each other.

**Why:** v0.53.0 (LOCKSMITH #132, counter 88). The notes covered #132's four children and omitted `184f2ac`,
the swarm-discovery GC-spin patch for releases#125 — user-facing by its own commit body (a daemon holding
195-210% CPU for two weeks, latent since v0.38.1). I caught it in the runbook's mandated out-of-band audit
BEFORE tagging. Then the release verb promoted **six** requests, #125 among them: the board announced
"v0.53.0 fixed the two-core CPU burn" while the release page said nothing about it. A user following the
roundup link found no mention of the fix they were just told shipped. The rule was already right
([[changelog-scope-vs-commit-range]] — cover every user-facing SURFACE in the range); the execution read the
milestone instead of the range.

**How to apply:**
(a) Enumerate `git log vPREV..<tested-sha> --no-merges` and ask of each commit "does this change something a
user observes?" — do NOT filter by whether it belongs to the milestone. Riders are exactly what that filter
hides. Cross-check against the milestone's `sub_issues` to find range members the milestone never claimed.
(b) A changelog omission does **not** buy a respin. Golden has zero references to `CHANGELOG.md` (only
`release.yml` reads it, at assemble time), so the defect sits outside golden's evidence — Q1-NO on the respin
test. The repair is docs-only and POST-publish: amend `CHANGELOG.md` on main, then
`gh release edit vX --repo BigscreenVR/spt-bs-releases --notes-file <file>`. No retag, no rebuild, no re-sign.
(c) Build the new body by **appending to the published body verbatim**, not by re-extracting the section —
re-extraction silently changes leading/trailing whitespace, and you want `diff published new` to read as a
pure `Na,b` addition so the delta is provable rather than argued. GitHub adds one trailing newline; that
normalization is not a content change.
(d) Never `gh release edit --draft=true/false` to do this. Toggling rewrites `publishedAt` and drops the
release out of `releases/latest` while it is a draft. A plain `--notes-file` edit leaves both intact
(verified: publishedAt stayed `2026-08-04T01:59:24Z`, still Latest, 11 assets).
(e) The tagged tree and main now differ by that one bullet. That divergence is the accepted shape of the
repair, not a second defect to chase — `tested SHA == shipped SHA` governs what golden validated, and the
signed artifacts are untouched.

Related: [[wave-gap-fixes-in-milestone]], [[release-notes-enduser-voice]], [[partial-milestone-golden-is-rejected-alternative]].