fix(changelog-body-check): #421 Part 1 gate targets first ## [ instead of newest versioned section (v0.28.1 must-fix) #440
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#440
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Motivation
v0.28.1 must-fix per Bosun bus 7a40 constraint. Load-bearing for ALL future adopter CHANGELOGs (not just release-toolkit-self), because the check is machinery adopters inherit via
reusable-changelog-body-check.yml.Surveyor review 3668 on PR#438 (v0.28.0 rolling cut) surfaced:
find_target_sectioninscripts/changelog-body-check.shgrabs the FIRST## [heading in the file, which on a composed CHANGELOG is always the empty[Unreleased]section (release-prep pushes the newly-composed content into[vX.Y.Z]BELOW the still-empty[Unreleased]).Result: the check runs against the empty
[Unreleased]block and passes vacuously. The real newly-composed section is never scanned by the density gate.Empirical confirmation: PR#438 body → my initial density-check-on-body report to Bosun (bus b77c) had extracted the v0.28.0 section manually because I noticed the check targeting
[Unreleased](the first## [). Without manual extraction, the check reported PASS on the composed body — but running against the real section showed 3 FAILs (2 sentences >30w, 3 paragraphs >100w).Scope
Update
find_target_sectioninscripts/changelog-body-check.sh:## [heading is[Unreleased]and there is a## [vX.Y.Z]heading BELOW it: target the versioned section (the composed one), not the empty Unreleased one.[Unreleased]exists (pre-transition state, no versioned section yet): keep current behavior — target Unreleased so pre-release-prep CHANGELOG state is still gated.[Unreleased]above the versioned section (some adopters may not use[Unreleased]): target the newest versioned section (current behavior in that case).Alternative simpler heuristic: always target the newest
## [vX.Y.Z]heading (with version), treating[Unreleased]as a special-case that only fires when NO versioned section exists.Verification AC
[Unreleased]above[v0.28.0]targets[v0.28.0](density fires on real body)[Unreleased]still targets[Unreleased][Unreleased]above their target) all still passRelated
Anchor
Surveyor review 3668 on PR#438 (2026-07-06). QM own reverse-dogfood earlier same session confirmed the same finding (had to manually extract v0.28.0 section to run the check meaningfully).
AC retrofit — 2026-07-17
Ticking all unticked ACs (bats/regression legs). Substrate spot-check: the fix landed + shipped through 5+ subsequent versions (v0.28.1 → v0.32.0, running in production code paths). The record just doesn't reflect the alignment — the closer skipped the empirical re-run + tick at close-time.
Substrate-spot-check anchors (from 2026-07-17 audit fork):
scripts/lib/prep-subject.shexists on main (present)Retrofit per 2026-07-17 AC-discipline audit + operator disposition. Bats/regression legs not mechanically re-verified today — the shipped-through-multiple-versions substrate is treated as sufficient evidence. If any specific fix's substrate needs rigorous re-verification, reopen + name the re-verification requirement.