fix(changelog): stop two 0.84.0 notes from being shown cut off mid-clause - #591
Merged
Conversation
…ause Each note's first sentence becomes its one-line summary in `kbagent changelog` and in the post-update "What's new" banner, capped at 160 chars. Two 0.84.0 notes opened with a sentence longer than that, so the summary broke off before the point of the change -- the promotion-pipeline note ended at "from a SOURCE project (dev) to a …", losing the destination and the PR gate, and the login-password note spent its whole budget on the flag signature. Both now lead with a short, self-contained sentence and carry the detail in later ones. No information is dropped; only the order changes. A test guards the newest version's notes, and only those: roughly 40% of the historical entries are cut the same way, and rewriting already-published release notes to satisfy a test is not worth it. The entries an author can still fix are the ones worth guarding, and nothing else checks this -- every other test treats a note as an opaque string.
….84.0 The command is not in any released version. It merged after v0.82.0 was cut and ships in 0.84.0, but fifteen places across CLAUDE.md, the agent prompt, the plugin CLAUDE.md and the skill references advertised it as 0.81.0+. That is the failure convention #17 exists to prevent: the agent prompt's VERSION GATE reads those numbers to decide whether a command is available, so a user on 0.81.0 or 0.82.0 would be told to run something their install does not have -- and the gate is meant to be the thing that stops exactly that. Verified against the tag rather than the changelog: `git grep login_password v0.82.0 -- src/` finds nothing, while main has it in six files. The mcp_tool_tasks doctor check, which also claims 0.81.0, is left alone -- it is present at v0.82.0 (three files), so its number is right.
padak
added a commit
that referenced
this pull request
Aug 14, 2026
#591 added a test asserting the newest version's release notes are not shown truncated. #589 was written and CI'd before that test existed and was never re-run against the newer main, so both PRs were green and merging them in order produced a red main. Its Tests note opened with a 161-character sentence, one over CHANGELOG_HEADLINE_MAX_CHARS, so the summary broke off at '... and CI stayed green …'. One dash becomes a period: same words, 161 -> 99 chars. This is the failure mode issue #585 describes -- CI checks the merge commit but only recomputes it when the PR is updated, so a branch that sits while main moves reports green for a merge that no longer exists. Second occurrence today; #560 hit it earlier at 33 commits stale and was caught only because the merge was simulated by hand.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caught by Devin on #590, after that PR had already merged — worth fixing before the 0.84.0 tag, since it is what users will read.
The problem
A note's first sentence becomes its one-line summary in
kbagent changelog(the default, non---fullview) and in the post-update "What's new" banner, truncated atCHANGELOG_HEADLINE_MAX_CHARS= 160. Two 0.84.0 notes opened with a longer sentence, so the cut landed mid-clause:The destination project and the PR gate — the actual point — are gone. The
auth login-passwordnote spent its entire budget on the flag signature before saying what the command does.The fix
Both notes now lead with a short, self-contained sentence and carry the detail in later ones. Nothing is dropped, only reordered:
The test, and its deliberate scope
TestLiveChangelogHeadlineschecks the newest version only. That is not laziness: 241 of 588 historical entries (41%) are cut the same way. Rewriting already-published release notes to satisfy a test is not worth it, and a test that fails on history gets suppressed rather than fixed. The entries an author can still change are the ones worth guarding.It runs against the live
CHANGELOG, unlike its neighbours in that file, which use synthetic entries on purpose so they stay green as notes change — this one is checking the authoring contract, not the renderer, so it has to read the real thing. Verified A/B: it fails on the pre-fix notes naming both, passes after.Note this is the same shape as #585 — an invariant stated in prose (module docstring, CONTRIBUTING "Releasing a new version" step 2) that nothing enforced.