Changelog gate accepts entries added to already-released sections, so they ship in no release

[code-yeongyu]

Summary

Three changelog entries for #1873 were committed into the published ## [2026.9.16-2] section of packages/coding-agent/CHANGELOG.md instead of ## [Unreleased]. The changelog gate passed all three PRs.

Two rules were broken at once: AGENTS.md and .github/agent/commands/cl.md both state that released sections are immutable and that new entries always go under [Unreleased].

Evidence

The three docs commits and the line each one inserted at, against the section headings present in the file at that commit:

commit	inserted at	enclosing section at that commit
79b2238a19 docs(compaction): record the admission verdict	line 337	## [2026.9.16-2] (line 323)
95fc0c69fb docs(compaction): record the held model switch	line 346	## [2026.9.16-2] (line 332)
175d4b168b docs(retry-fallback): record the repaired fallback rung	line 348	## [2026.9.16-2] (line 334)

Every other CHANGELOG-touching commit in v2026.9.19-2..HEAD inserted between lines 6 and 19, which is inside [Unreleased].

This is not a merge-anchor artifact from a stale branch: git merge-base --is-ancestor v2026.9.19-2 79b2238a19 succeeds, so the branch was cut after the last release tag, and the insert point was already inside a published section when the commit was authored.

Impact

scripts/release-changelog.mjs stamps [Unreleased] into the new version section, so entries parked in an older section are published in no release at all. This cycle's release notes would have shipped without the entire deferred-model-switch feature (#1873), while four-day-old published history silently gained three entries it never contained.

Gate gap

scripts/check-pr-changelog.mjs requires that a PR add a CHANGELOG.md entry, and restrictTrackerEntriesToAddedLines restricts tracker credit to lines the diff added. Nothing checks which section a CHANGELOG.md added line lands in, so an entry appended to a released section satisfies the gate exactly as one appended to [Unreleased].

Expected / ideal state

• An added CHANGELOG.md line that lands below the first ## [ version heading fails the gate, naming the file, the line, and the section that swallowed it.
• A PR that modifies or deletes a line inside an already-released section fails the same way, since released sections are immutable.
• The gate keeps passing for entries added under [Unreleased] and for the release tooling's own stamping commit.

Scope

• Immediate: the three misplaced entries are moved to [Unreleased] so this release ships correct notes.
• Remaining: the placement check in check-pr-changelog.mjs plus its regression test. Without it the next agent that writes into a stale offset reproduces this exactly.

Related

• release: git merge origin/main after the 30-min test gate conflicts on CHANGELOG [Unreleased] and loses the whole run #1764 — release-time CHANGELOG [Unreleased] merge conflicts

[code-yeongyu]

Reopening: this closed automatically when #1885 merged, but #1885 only moved the three misplaced entries. The defect this issue is about is still present.

Done (#1885, merged e5e9361f6e): the three #1873 entries are back under [Unreleased], and [2026.9.16-2] is restored to its released contents. That was release-blocking, because release-changelog.mjs stamps only [Unreleased] and this cycle's notes would otherwise have shipped without the deferred-model-switch feature.

Not done: scripts/check-pr-changelog.mjs still accepts a CHANGELOG.md line added below the first ## [ version heading. Nothing stops the next agent from writing into a stale offset and reproducing this exactly, and the next time it happens it may not be caught during release prep.

Remaining scope, unchanged from the description:

• An added CHANGELOG.md line landing below the first version heading fails the gate, naming the file, the line, and the section that swallowed it.
• A PR that modifies or deletes a line inside an already-released section fails the same way, since released sections are immutable per AGENTS.md and .github/agent/commands/cl.md.
• Entries added under [Unreleased], and the release tooling's own stamping commit, keep passing.

Worth noting this cycle produced two separate release blockers of the same shape: a rule the repository states in prose (immutable released sections here, format drift in #1886) with no gate that can fail on it. Both were found by the release job rather than by CI.