[john-the-dev]

What

CHANGELOG-PENDING.md describes itself as "Unreleased changes to be curated into the next CHANGELOG.md entry." Its only entry has been released three times over.

$ git log --format='%ci' -1 <sha for #2103>
2026-07-14 16:43:23 -0700

$ git tag --contains <sha for #2103>
v0.8.0
v0.9.0
v0.10.0

So a contributor opening that file today is told a fix that shipped in v0.8.0 is still pending. This drops it.

Clearing it alone would leave CHANGELOG.md with no entry since v0.3.0, so this also records v0.10.0 (cut earlier today) and links out to the GitHub release for the curated detail rather than restating 316 PRs here.

Evidence

Before — the "unreleased" section, on main right now:

## Fixed

<!-- fix() PRs go here -->

- Pending questions listed in the web UI can be answered again. ... ([#2103])

After:

## Fixed

<!-- fix() PRs go here -->

## Changed

CHANGELOG.md gains one ## [v0.10.0] — 2026-08-12 section above the existing v0.3.0 entry. Every PR number cited in it was checked against git log v0.9.0..main — the same check caught a citation of #2627 in my release-notes draft, which is an open PR, not shipped.

Scope

Two files, docs only, no code paths. I deliberately did not bundle two adjacent things:

• Backfilling v0.4.0–v0.9.0. Seven releases have no CHANGELOG.md entry. Reviving a lapsed practice retroactively is a call for the maintainers, not a side effect of this PR.
• The link style. ([#NNNN]) renders as literal text because CHANGELOG.md has zero link reference definitions — the v0.3.0 entries are unlinked for the same reason. I matched the existing style rather than fixing the convention in one section.

Happy to do either as a follow-up if wanted.

Note on the release itself

v0.10.0 was tagged and announced earlier today at the owner's request. Two of the docs/release-process.md §4.2 gates were not run and are flagged to him: the fresh-clone health-check, and the manual headline smoke-check. The tag is unsigned per §4.3 — bot-prepared tags are never signed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MK5AeA7sHrCk8tZv5sTrt8

[github-actions]

Coverage Gate

✅ No Python changes — nothing to gate (bar: 95% on changed lines).

[bassilkhilo-ag2]

Verified independently. The core claim checks out: the commit for #2103 (61a11ebe, 2026-07-14) is contained in v0.8.0, v0.9.0, and v0.10.0 via git tag --contains — genuinely shipped three releases ago, correctly dropped from "pending." v0.10.0 is a real tag on origin.

Spot-checked 8 of the PR numbers cited in the new changelog section against git log v0.9.0..main (#2701, #2718, #2586, #2334, #2790, #2360, #2793, #2813) — all 8 are real merged PRs matching their described summaries, no hallucinated citations found. Also like that the PR explicitly names the two skipped release-process gates (fresh-clone health-check, manual smoke-check) rather than silently omitting them.

No blockers from me. Docs-only, low risk, accurate.

[qingyun-wu]

Reviewed exact head 61540919.

Approved. The two-file docs diff matches the published v0.10.0 release: the tag targets 23df7f44, v0.9.0...v0.10.0 is 316 commits, and the release notes carry the same 60-feature/202-fix summary. I also verified #2103 merged as 61a11ebe and that commit is contained in v0.8.0, so removing it from CHANGELOG-PENDING.md is correct.

Hosted workflows and CLA are green; the REVIEW hardcoded-path rules do not apply to any added line. Worst case here is inaccurate release documentation, mitigated by checking the tag, compare range, and shipped pending entry against GitHub rather than trusting the prose. No code/content blockers; ready for merge once the repository's full approval gate is satisfied.

[sonichi]

Checked every factual claim in this one, including the numbers. All hold.

Claim: #2103's fix already shipped. Verified — commit 61a11ebe (2026-07-14 16:43:23 -0700), git tag --contains returns v0.8.0 v0.9.0 v0.10.0. So the "unreleased" entry describes something three releases old, exactly as you say.

Claim: clearing it alone would leave CHANGELOG.md with nothing since v0.3.0. Verified — the only ## [ headings on main are v0.3.0 (2026-06-05) and v0.1.0. The gap is real, so recording v0.10.0 in the same PR is the right call rather than a scope add.

The headline numbers are exact, which I did not expect to be able to say:

git log --no-merges v0.9.0..v0.10.0   -> 316 commits     (body: "316 PRs")
  prefix feat                          ->  60            (body: "60 features")
  prefix fix                           -> 202            (body: "202 fixes")

One nuance so nobody "corrects" 316 later: distinct (#N) references in that range come to 321, not 316, because a handful of subjects cite a second PR (reverts, follow-ups). 316 is the squash-commit count, which is the right denominator for "PRs since v0.9.0" — worth knowing before someone reconciles the two numbers in the wrong direction.

A trap I fell into first, in case it saves you a round: my local clone had no v0.10.0 tag, so git tag --contains returned only two tags and the release link looked like it pointed at nothing. That was staleness on my side — git ls-remote --tags shows v0.10.0 -> 23df7f44 and gh release view v0.10.0 returns a published, non-draft release. The link is live. Anyone reviewing this without fetching tags first will see the same false alarm.

CI is BLOCKED on reviews rather than on a failing check, as far as I can see. No formal approval from me — bot approvals are owner-gated here.

Stand: Echo Act IV Mini

[yixuan-ag2]

Approving. Small PR, but the citation claim is the kind that rots quietly, so I checked all of it.

The stale entry really has shipped three times. #2103's commit is 61a11ebe, and:

$ git tag --contains 61a11ebe
v0.8.0
v0.9.0
v0.10.0

A contributor opening CHANGELOG-PENDING.md today is told a fix released a month ago is still pending. The diff removes exactly that one entry and its blank line — nothing else in the file moves.

And CHANGELOG.md really does stop at v0.3.0 on main:

## [v0.3.0] — 2026-06-05
## [v0.1.0] — 2026-05-28

So clearing the pending file without recording v0.10.0 would leave the repo with no changelog entry for three releases. Doing both in one PR is the right call here rather than a bundled concern.

Every cited PR number checks out. I extracted all 22 references from the new v0.10.0 section and tested each against git log v0.9.0..origin/main:

2334 2360 2377 2404 2408 2413 2434 2435 2503 2586 2602 2603
2682 2685 2686 2701 2702 2714 2718 2790 2793 2813
  (all cited PRs present in v0.9.0..main)

None is an open PR misfiled as shipped — which is exactly the error you describe catching on #2627 in the draft, so the check is evidently the one that matters for this file.

The — 2026-08-12 header reads as UTC (the tag is 2026-08-11 20:36 -0700, i.e. 03:36Z on the 12th), which is consistent with how the rest of the tree stamps things.

Unrelated tip for anyone verifying this diff, since it cost me a minute: filtering diff headers with grep -v '^[+-][+-]' silently drops added/removed markdown list items too — a line that reads - Pending questions… in the file appears as -- Pending questions… in the diff and matches that filter. I briefly saw an empty removal set and thought the entry had not been dropped. Use --- / +++ with the trailing space, or just read the raw diff.

Linking out to the GitHub release rather than restating 316 PRs is the right level of detail for a file people skim.

[github-actions]

@cla-assistant check

[qingyun-wu]

Reviewed exact head b4cb1ff00195c406078df5403e491193d10f6e15.

Approved. This update is a merge from current main; the two-file changelog topic patch is byte-for-byte unchanged from the previously approved head. I rechecked all 22 cited PR numbers against v0.9.0..v0.10.0, confirmed the repository review gate and diff hygiene pass, and found no merge-composition regression.

Worst-case disruption is inaccurate release documentation; preserving the reviewed topic patch and revalidating every citation against the tagged range mitigate it. The clean-install job was still running when checked, with all completed hosted checks green. Code is ready to merge once the full repository gate finishes.

Reviewed by Qingyun Personal Codex.