fix(changelog): every release since 0.14.31 writes two sections for one version

[artokun]

Every release since 0.14.31 has written two ## [x.y.z] sections into CHANGELOG.md. Found while checking whether #1172 was releasable; no issue is filed yet — say the word and I'll open one.

The evidence

## [0.14.33] - 2026-08-13   ← cites #1211, #1201        (this repo's PRs)
## [0.14.33] - 2026-08-14   ← cites comfyui-mcp#1478    (the other repo)
## [0.14.32] - 2026-08-13   /  ## [0.14.32] - 2026-08-14
## [0.14.31] - 2026-08-13   /  ## [0.14.31] - 2026-08-14
## [0.14.30] - 2026-08-14   ← single. The duplication STARTS at 0.14.31.

git log -S confirms both sections of a given version arrive in the same release commit (0.14.33's pair in f0532584, PR #1214). This is not two runs racing; one release step emits both.

Two distinct defects, and the dates prove it

f0532584 is authored Thu Aug 13 23:18:14 2026 -0600 — which is 2026-08-14 in UTC. So:

1. Two sections instead of one. scripts/gen-changelog.mjs's own header states the contract: promote the hand-written [Unreleased] highlights verbatim, then append the commits those highlights did not already mention, deduped by PR number — into a single section. What ships instead is the auto-generated body in one section and the promoted highlights in another. The existing guard (if (md.includes("## [" + version + "]")) → "nothing to do") only defends against a second invocation; it cannot see a second section produced within one.
2. Two date sources. One path stamps local time, the other UTC. Even once the sections are merged, this would keep producing off-by-one dates around the evening boundary — and it is why the duplicates are trivially spottable rather than silently identical.

Why it starts at 0.14.31

6aa29670 fix(1191): the changelog generator cannot see this repo's own release commits (#1197) taught the generator to read this repo's own release commits. That is what introduced the second body. The dedupe is by PR number, and the two bodies describe the same work through different identifiers — #1211 (panel PR) versus comfyui-mcp#1478 (upstream issue) — so nothing matches and neither body suppresses the other.

Why this matters beyond tidiness

• PR spec: surface CHANGELOG.md where the panel user actually is (#758) #815 surfaces CHANGELOG.md in the panel, so users read this.
• It is the third pass over this generator: fix(1191): the changelog generator cannot see this repo's own release commits #1197 (base commit), fix(1191): remove the 6 empty section headings the data repair left behind #1202 (six empty section headings left by a data repair), fix(1191): warn on the tagless fallback, and remove the duplicates my repair created #1203 (duplicates that repair itself created). Each fix has produced the next defect, so this one needs the mutation treatment rather than a quick patch.

Work in progress

• make the promotion and the auto-generated body land in ONE section, deduped across both identifier styles (#N and comfyui-mcp#N)
• one date source, stated explicitly (local or UTC, not both)
• a guard that fails the build when any version heading appears twice — the check that would have caught 0.14.31 the day it shipped
• repair the six existing duplicate pairs (0.14.31/32/33 and the older 0.2.0/0.3.0/0.4.0/0.4.1) without creating the empty headings fix(1191): remove the 6 empty section headings the data repair left behind #1202 had to clean up
• verify by mutation, including a run at 23:00 local to pin the timezone boundary

🤖 Generated with Claude Code

---

Correction: the diagnosis above is partly wrong

gen-changelog.mjs cannot emit two sections. buildEntry produces exactly one ## [ver] - today(), and line 375 aborts with "already has a [version] section — nothing to do" when the version is present. My claim that it emits an auto body and a highlights body as separate sections does not survive reading the code.

The two-section mechanism is upstream in the release process, and I have not found it. Recorded as unknown rather than left as a plausible guess — this session has already produced four rejected versions of one changelog sentence for exactly that habit.

What is real in the generator: the highlights dedupe is /\(#(\d+)\)/g, which cannot match (comfyui-mcp#1478). Work described upstream-first is never recognised as covered, so it gets re-listed under its panel PR number. That explains why the two bodies never suppress each other — but not why there are two bodies.

What the guard found that I wasn't looking for

Committed in 5f66e35f — browser_tests/unit/changelog-integrity.test.mjs. It is deliberately red on the three recent pairs and stays red until the cause is found.

The 0.2.0–0.4.1 pairs are not duplicates at all. They are version-number collisions holding different content:

• 0.4.1 - 2026-06-26 → graph_set_node_mode
• 0.4.1 - 2026-06-17 → the Connect button replacing auto-spawn, after the Registry scanner flagged 0.4.0

Two real releases reused one number, early on. Merging them would fabricate a release that shipped both — precisely what #1203 had to undo. They are exempted as documented fact, and the exemption list is asserted exhaustive, so a future repair cannot leave a permanent hole for the next regression to hide in. The lone ordering break (0.1.3 precedes 0.4.1) is where that older history block begins, and gets the same treatment.

0.11.84 was a false positive in my own first draft of the guard: its body is the deliberate _No user-facing changes._. A release that truthfully reports having nothing to report is correct; the assertion demanding a list item was the defect.

Revised remaining work

• find the actual two-section mechanism in the release process — not in gen-changelog.mjs
• widen the highlights dedupe to match comfyui-mcp#N as well as #N
• settle ONE date source (today() is local; the 08-14 headings are UTC)
• merge the three recent pairs (same work, different identifiers — safe, unlike the historical collisions)
• a guard that fails on any new duplicate, empty section, undated heading, or ordering break
• verify by mutation, including a 23:00-local run for the timezone boundary

---

The mechanism, located

git log -S across all refs shows that no commit ever introduced only one variant. Both sections for a version always appear together, in a single release commit (496cf404 pre-squash, f0532584 after). So the release step produced both in one working-tree state — this is not two runs, not a merge, and not the generator looping.

The identifiers say where the second one comes from. The 08-14 bodies cite comfyui-mcp#1448, #1467, #1478 — and the repo contains worktrees named wt-1448b, wt-1467io, wt-1478, one per upstream issue. Each release was cut on a branch dedicated to fixing an upstream comfyui-mcp issue, where the release notes were written as a versioned section (## [0.14.33] - 2026-08-14, UTC-dated, citing the upstream issue) rather than under ## [Unreleased].

gen-changelog.mjs then ran on that branch and added its own ## [0.14.33] - 2026-08-13 from the commit log. Its guard — if (md.includes("## [" + version + "]")) → nothing to do — protects the script from running twice. It cannot protect against a hand-written versioned section added after the script runs. Both end up staged into one release commit.

That also explains the date split cleanly: today() is local (getFullYear/getMonth/getDate, line 274-276) so the generator stamped 08-13, while the hand-written section used the UTC date — the release commit is authored Aug 13 23:18 -0600, which is Aug 14 UTC.

So the fix is process + guard, not generator logic

• Release notes belong under ## [Unreleased], which buildEntry promotes verbatim into the single dated section. Writing them as a pre-numbered section is what defeats the design.
• The generator should refuse rather than proceed when a version heading already exists anywhere after it writes — a post-write assertion, not just the pre-write check.
• Widen the highlights dedupe from /\(#(\d+)\)/g to also match comfyui-mcp#N, so upstream-first descriptions register as covered.
• One date source, stated.

The committed guard (5f66e35f) catches the outcome regardless of which of these regresses, which is why it went in first.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.