[clabonte]

Summary

Two open PRs that each add a changelog entry no longer conflict when one merges, in any project that opts in, and every entry still reaches the released section. Closes #3563.

• changelog.mode: single|fragments in .specfuse/layout.yml. Default single; those projects keep the same read and write path.
• python3 -m specfuse.loop.changelog_fragments with add, collate and check.
• One reader: close-k, specfuse lint --closing and the terminal auto-close guard all accept an entry in a fragment or in CHANGELOG.md. A malformed fragment does not count.
• scripts/bump_version.py release() folds fragments before stamping, deletes them, and reports the deletions in its returned list.
• New changelog-fragments verification gate; /fix-bug and close-discipline §3 now call the writer.
• This repository opts in.

Review notes

• Judge surfaces changed. The operator reviewed them at the terminal stop and acknowledged them: "guards not weakened, single-file behavior unchanged". changelog.py and changelog_fragments.py also joined the judge module list, so future edits to them trigger the same stop.
• Added at the stop, outside any unit: dfbed42, so release() reports removed fragments. A caller staging its list would otherwise miss the deletions and fold them again next release.
• Retrospective wording: it says the post-merge items were "filed at close as specfuse:post-merge". They were not: post_merge_issue defaults off, followups_recorded shows filed: 0, and the checklist lives in the archived roadmap section by design.

Verification

• Oracle python3 -m unittest tests.test_changelog_fragments -v -b: 28 tests pass, no skips.
• Driver broad run clean; judge agreed met.
• CHANGELOG.md has no entry for this feature; the close passed on fragments alone.

Not verified by the loop:

• GitHub's merge button with two real PRs (the oracle uses real git merge)
• An adopter's own release script calling collate
• A real adopter opting in across specfuse upgrade
• CI running the new gate (this PR is the first run)

Pending learnings (needs promotion)

• [FEAT-LOOP-2026-0249/T01] A unit that gives a function its first production caller must drop that function from the caller-check ratchet's BASELINE in the same unit. T01 made append_entry a real caller target, which shrank the baseline, and test_the_baseline_has_not_silently_shrunk went red. Its narrow tier did not select that repo-wide test, so T01 passed and the failure surfaced at T06's baseline probe, attributed to T06, as a preexisting_gate_failure halt that needed a human. Rule: when a unit wires up previously uncalled code, name the ratchet update in its acceptance and run tests.test_caller_check_ratchet in its verification; a green narrow tier does not cover repo-wide ratchets.

To promote: read each entry in LEARNINGS-pending.md, copy accepted ones into .specfuse/LEARNINGS.md, leave rejected ones with a note; planning never reads the pending file directly.

🤖 Generated with Claude Code