0.45.0 - #1555

Approving. This is the first release since the changelog/ restructuring, so I checked the release mechanism rather than just the diff. Baseline origin/main = 4fbf0b71 (the PR is a single commit on top of it, merge-base 4fbf0b71).

The assembly is exactly reproducible. I rebuilt the section independently from main's changelog/unreleased/ — concatenating the 26 files in descending pull-request-number order, no separators, nothing else — and diffed it against changelog/0.45.0.md at this head:

desc order: 1553 1548 1547 1546 1545 1544 1543 1542 1541 1540 1539 1538 1537 1536
            1534 1533 1531 1530 1527 1526 1525 1522 1520 1519 1516 1514
diff expected 0.45.0.md  ->  IDENTICAL (byte for byte)

So every unreleased entry is accounted for: 26 source files → 31 top-level list items, none dropped, none duplicated, none reworded, and the within-file order of the multi-entry files is preserved. changelog/unreleased/ is left with .gitkeep alone, as changelog/README.md specifies, and 0.45.0.md contains no heading — the version stays in the file name.

Resulting order matches the documented rule. changelog/README.md says "concatenates changelog/unreleased/*.md in descending pull-request-number order" and explicitly accepts the deviation from merge order; that is what happened. To quantify the deviation, the pre-#1552 Unreleased list (merge order, CHANGELOG.md at 73e16090^) ran

1547 1546 1548 1545 1544 1543 1542 1541 1538 1539 1530 1540 1536 1537 1533 1534 1531
1527 1526 1520 1525 1522 1519 1516 1514

12 of those 25 PRs sit at a different index under the descending sort (15 of the 30 entries), including the three at the very top. That is the accepted deviation, not a defect — but it does mean this released section is not in the order the entries were historically listed in, which is worth knowing when reading it.

Version bump. package.json and package-lock.json (both the root version and packages[""].version) go 0.44.0 → 0.45.0, and nothing else in the diff. The remaining 0.44.0 strings — fjs/ci/config/module.f.mjs and the generated .github/workflows/ci.yml lines it produces, plus the example tarball name in fjs/ci/packed-consumer-validation.md — are the bootstrap pin to the last published release, which cannot point at 0.45.0 before 0.45.0 exists on npm. That matches the established pattern: 0.44.0 shipped in #1513 and the pin moved separately in #1521. Correctly left alone here.

0.44.0 → 0.45.0 is a minor bump, and the section carries 5 **BREAKING CHANGES:** entries, so it satisfies the pre-1.0 rule in changelog/README.md that 0.Y moves only for a breaking release.

§8.3 released sections. git diff --name-status 4fbf0b71..HEAD is 1 add (changelog/0.45.0.md), 26 deletes under unreleased/, and the two version files. No previously released changelog/<version>.md is touched.

Gates run:

• npm run ci-update on a clean tree, then git add -A && git diff --cached --exit-code — clean, no drift.
• npm run prepack from a clean tree — exit 0.
• node bin/linkcheck.mjs in both trees — 150-line output, broken-link sets identical to main (diff empty), so the new 0.45.0.md strands nothing.

Not run: npm test, since no runtime file changes and prepack already type-checks the tree.

Re-reviewed after the changelog restructuring. Baseline origin/main at 4fbf0b71 (unchanged since the previous review, so no PR has merged into the release window).

What moved since e5edaeb6: the release no longer concatenates entries into a single changelog/0.45.0.md — it renames changelog/unreleased/ to changelog/0.45.0/ and keeps the entry files as they are. Plus changelog/README.md, AGENTS.md §8.3/§8.4 and todo/changelog-website.md updated to describe the new layout. No code files in the delta.

Release fidelity, re-derived from scratch (not carried forward). Compared blob hashes rather than trusting rename detection:

• git ls-tree -r origin/main changelog/unreleased vs git ls-tree -r HEAD changelog/0.45.0: 26 entry files, identical blob object IDs, identical names. The only difference in the listing is .gitkeep, which is deleted. Nothing dropped, added, reworded or renumbered.
• Cross-check against the previously approved form: concatenating this PR's 26 files in descending PR-number order is byte-identical (10,267 bytes) to e5edaeb6:changelog/0.45.0.md, the file I independently reassembled from main last round. So the shipped content is provably the same release, only the storage form changed.
• 31 entries, unchanged. 5 **BREAKING CHANGES:** entries across 5 files — minor bump justified under the §8.4 0.x rule.
• Every entry file links only its own PR (checked each file's pull/NNN against its filename): no foreign PR links, no issue or todo/ links, no non-GitHub links, no headings inside entry files.

Version bump. 0.45.0 in package.json and both package-lock.json slots (root version and the "" package entry); main has 0.44.0 in all three. No 0.44.0 string remains anywhere in the manifests — the previous round's bootstrap-pin observation no longer applies at this head.

The .gitkeep deletion is intentional and documented, not an oversight: changelog/README.md and AGENTS.md §8.3 both now state that Git does not track empty directories, that unreleased/ simply does not exist between a release and the next entry-adding PR, and that such a PR recreates it. No file anywhere in the repo still references unreleased/.gitkeep or changelog/0.45.0.md.

The new §8.4 bullet — re-check changelog/unreleased/ is empty after every update from main, and again right before merging — is the right guard for the one real hazard this layout introduces (a post-rename merge dropping its entry outside the version directory). At this head that check passes: changelog/unreleased/ does not exist in the tree.

Docs are self-consistent: README, AGENTS.md and the website todo all describe the same two-form layout and agree that the renderer derives the PR link from the file name.

Non-blocking observation. The new rule says entries carry no PR link, but the 26 entries shipping in 0.45.0 all still end with an inline [#NNN](url), and AGENTS.md also drops links from the allowed Markdown subset. Both documents grandfather them explicitly ("entries written before this convention … leave them as they are"), and rewriting them would have destroyed exactly the rename fidelity that makes this release verifiable — so this is the right call, just worth knowing that the first directory-form release is itself in the legacy entry style and the website generator must handle links inside <version>/ entries too. The todo already says as much.

No code touched, so the type/test/prepack gates carry over from the previous head unchanged.

LGTM — approving.