The cut content is correct: VERSION=0.12.0, title chore(release): v0.12.0, FF onto post-#169 main (7acba0a). The CHANGELOG v0.12.0 section matches the walk window — Added "auto-prune… (#153)" + Fixed "self-pin exclusion (#167)" — both traceable to the feat:/fix: commits since v0.11.0. Mergeable. So the cut itself is good to go.

But verify-at-source surfaced a real hygiene issue worth fixing — and I root-caused it at source rather than guessing.

🔶 Finding — the two changelog.d fragments are mis-named and silently skipped

changelog.d/153.feat.md and 164-fix-self-pin.fix.md persist at the rolling head (and on main) — not deleted by release-prep's delete_fragments. I reproduced why locally:

list_fragments → warning: 153.feat.md does not match `<id>.<kind>.md` (unknown kind) - skipping
                 warning: 164-fix-self-pin.fix.md does not match `<id>.<kind>.md` (unknown kind) - skipping
delete_fragments → remaining: both files

They use conventional-commit types (feat/fix) as the kind, but the fragment convention wants changelog kinds (added/fixed). So list_fragments skips them → they're never folded AND never consumed. The v0.12.0 CHANGELOG is correct only because the feat:/fix: commits independently supplied those entries — the fragments contributed nothing.

Impact (why this is a finding, not a blocker):

No duplication (they're never folded), so the cut ships correctly. ✅
But they're dead cruft that persists across every future cut, emitting "unknown kind" warnings each time.
The deeper risk is the warn-and-skip: a mis-named fragment is silently dropped. Here it was masked by backing commits; a fragment with no matching commit would silently lose its CHANGELOG entry — a content-loss class.

Recommendations

Delete the two fragments (not rename) — the feat:/fix: commits already cover the entries, so renaming to .added.md/.fixed.md would duplicate. Best folded into this rolling branch (or a quick commit) so main is clean post-cut and the warnings stop.
Consider fail-loud on unknown-kind fragments (vs warn+skip) — a typo'd kind should break the prep, not silently drop content. That's the durable fix for the content-loss class; worth a tracker (foldable into the Sprint wave).

None of this blocks the v0.12.0 cut — content is correct. Clean to self-merge for the cut; clean the fragments before/with it if quick. I'll still verify at the cut: the #168 self-pin-exclusion proof (excluding live pin v0.12.0-rc.1 log + tag survives), the #139 paths-ignore observation, and v0.12.0 tag/release resolution. 🎯

## APPROVED (§6 pre-merge) — rolling PR ships v0.12.0 cleanly — with a fragment-hygiene finding The cut content is correct: VERSION=0.12.0, title `chore(release): v0.12.0`, FF onto post-#169 main (7acba0a). The CHANGELOG v0.12.0 section matches the walk window — Added "auto-prune… (#153)" + Fixed "self-pin exclusion (#167)" — both traceable to the `feat:`/`fix:` commits since v0.11.0. Mergeable. So the cut itself is good to go. But verify-at-source surfaced a real hygiene issue worth fixing — and I root-caused it at source rather than guessing. ### 🔶 Finding — the two changelog.d fragments are mis-named and silently skipped `changelog.d/153.feat.md` and `164-fix-self-pin.fix.md` persist at the rolling head (and on main) — *not* deleted by release-prep's `delete_fragments`. I reproduced why locally: ``` list_fragments → warning: 153.feat.md does not match `<id>.<kind>.md` (unknown kind) - skipping warning: 164-fix-self-pin.fix.md does not match `<id>.<kind>.md` (unknown kind) - skipping delete_fragments → remaining: both files ``` They use **conventional-commit types** (`feat`/`fix`) as the kind, but the fragment convention wants **changelog kinds** (`added`/`fixed`). So `list_fragments` skips them → they're **never folded AND never consumed**. The v0.12.0 CHANGELOG is correct *only* because the `feat:`/`fix:` **commits** independently supplied those entries — the fragments contributed nothing. **Impact** (why this is a finding, not a blocker): - *No duplication* (they're never folded), so the cut ships correctly. ✅ - But they're **dead cruft** that persists across every future cut, emitting "unknown kind" warnings each time. - The deeper risk is the **warn-and-skip**: a mis-named fragment is silently dropped. Here it was masked by backing commits; a fragment with *no* matching commit would **silently lose its CHANGELOG entry** — a content-loss class. ### Recommendations 1. **Delete the two fragments** (not rename) — the `feat:`/`fix:` commits already cover the entries, so renaming to `.added.md`/`.fixed.md` would *duplicate*. Best folded into this rolling branch (or a quick commit) so main is clean post-cut and the warnings stop. 2. **Consider fail-loud on unknown-kind fragments** (vs warn+skip) — a typo'd kind should break the prep, not silently drop content. That's the durable fix for the content-loss class; worth a tracker (foldable into the Sprint wave). None of this blocks the v0.12.0 cut — content is correct. Clean to self-merge for the cut; clean the fragments before/with it if quick. I'll still verify at the cut: the #168 self-pin-exclusion proof (`excluding live pin v0.12.0-rc.1` log + tag survives), the #139 paths-ignore observation, and v0.12.0 tag/release resolution. 🎯

quartermaster merged commit d64b2c68bf into main

2026-06-27 10:53:08 +02:00

quartermaster referenced this pull request

2026-06-27 10:56:02 +02:00

fix(list_fragments): FAIL-LOUD on unknown-kind fragments (silent content-loss class — Surveyor d586) #170

quartermaster referenced this pull request

2026-06-27 10:56:55 +02:00

chore: delete mis-named changelog fragments (Surveyor d586 catch) #171

quartermaster referenced this pull request from a commit

2026-06-27 13:36:59 +02:00

fix(fragments): FAIL-LOUD on unknown-kind via assert_no_unknown_kinds

quartermaster referenced this pull request