39 of 40 changelogs announce a breaking change they do not have — the empty-changelog fix broadcasts every repo commit into every package

[sroussey]

What

The empty-changelog class is genuinely closed. Measured across all 40 providers/* + packages/* changelogs at 2d36880:

0.5.0: present in 40, empty 0
0.5.1: present in 40, empty 0
0.6.0: present in 40, empty 0

against 135 of 234 (58%) empty a week ago and 149 of 156 (96%) the week before. Packages with nothing to say now carry an explicit _No changes in this package._, which is an honest answer rather than a blank heading. That is real progress on #854/#903.

The mechanism that produced it attributes every repo-level commit to every package:

$ # changelogs carrying the join() "### Breaking Changes" entry at 0.5.0
39 of 40

$ git show --stat 5f83ae85f -- providers/mlx providers/playwright providers/electron
 providers/electron/package.json   | 2 +-
 providers/mlx/package.json        | 2 +-
 providers/playwright/package.json | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

providers/mlx/CHANGELOG.md at 0.5.0 now reads:

## 0.5.0

### Breaking Changes

- **features(storage)**: add join() to ITabularStorage with SQL pushdown (#893)

### Features
#### storage
- add join() to ITabularStorage with SQL pushdown (#893)

@workglow/mlx is a 166-LOC stub with isAvailable() => false. Its entire involvement in 5f83ae85f was a one-line dependency version bump. A consumer reading its changelog is told 0.5.0 broke their code.

Why it matters

This is the mirror image of the finding this series pushed for five cycles. #854/#903 were about breaking changes shipping invisibly — a patch bump, no !, no footer. This window fixed that half properly: 5f83ae85f is the first !-marked commit and first BREAKING CHANGE footer in fifteen review snapshots, and it went out as a minor (0.4.9 → 0.5.0). Correct.

But an indiscriminate breaking-change marker is the fastest way to teach readers to ignore the marker. 38 of the 39 packages carrying it did not break. Next release, the one package that did break gets the same heading as the 38 that did not, and nobody reads it.

The same mechanism also mis-files real work. providers/playwright's only source change in nine review cycles — a genuine TOCTOU fix in PlaywrightBackend.connect(), where every handle was re-read from its field after an await and a concurrent disconnect() could null it — is recorded in its changelog as:

## 0.5.1
### Chores
- run format-check in CI, and turn on every staged-off lint rule

A reader of @workglow/playwright's changelog cannot tell that a correctness fix shipped.

Proposed fix

1. Attribute a changelog entry to a package only when the commit touched that package's src/. A version-only package.json bump is what _No changes in this package._ already exists to describe. This alone fixes both symptoms.
2. If a dependency's break genuinely propagates, say that instead of restating the dependency's headline — - Updated @workglow/storage to 0.5.0 (breaking: ITabularStorage.join) under a Dependencies heading, not under this package's Breaking Changes.
3. For a sweep commit that touches many packages for different reasons (509724031 is the live example — a lint-rule enablement that also carried the playwright fix), split it, or let the per-package entry be derived from that package's own hunks rather than the commit subject.

Found during the 2026-09-14 review of providers/. Verified against origin/main @ 2d36880. Relates to #903.

[sroussey]

Re-measured at d98940f33 (2026-09-21). Not closed — but read the numbers carefully, because they look like a fix and are not one.

Across the seven releases in this window (0.6.1 → 0.6.7), over all 44 providers/* + packages/* changelogs:

0.6.1: present=42 empty=0 breaking=0
0.6.2: present=43 empty=0 breaking=0
0.6.3: present=43 empty=0 breaking=0
0.6.4: present=43 empty=0 breaking=0
0.6.5: present=43 empty=0 breaking=0
0.6.6: present=43 empty=0 breaking=0
0.6.7: present=44 empty=0 breaking=0

0 of 301 sections empty, 0 spurious breaking markers. And per-package attribution reads correctly at a glance — providers/mlx/CHANGELOG.md carries _No changes in this package._ for all seven, while providers/cactus gets "### Features — add support for Needle v3 model in Cactus" at 0.6.7 and nothing at the other six.

That is not evidence the mechanism changed:

$ git log --format='%h %s' --no-merges 2d36880..origin/main | grep -c '!:'    -> 0
$ git log --format='%B'   --no-merges 2d36880..origin/main | grep -c BREAKING -> 0
$ git diff --stat 2d36880 origin/main -- scripts/                             (no changelog-generation script touched)

There was no breaking change this window for the broadcast to broadcast. The generator is unchanged, so the next feat(...)!: will land in all 44 changelogs exactly as 5f83ae85f did at 0.5.0 — where providers/mlx/CHANGELOG.md still opens with "### Breaking Changes — add join() to ITabularStorage with SQL pushdown (#893)" for a package whose entire involvement was a one-line dependency bump. That historical entry is still in the tree and still tells a consumer of @workglow/mlx that 0.5.0 broke their code.

The ask is unchanged: attribute a Breaking Changes section to a package only when the commit touched that package's src/. The _No changes in this package._ marker proves the generator already knows how to make that determination for the ordinary sections; the breaking one just does not consult it.

---

Generated by Claude Code