docs(changelog): fold Unreleased into 0.7.0 again, and record the drift guards - #368
Merged
Conversation
…ft guards SECOND TIME TODAY, and that is the finding rather than the fix. [Unreleased] sits ABOVE [0.7.0], so under Keep a Changelog its contents are NEWER than the release below them -- and every pull request correctly appended there. Nothing folds it forward, so the gap reopens after each merge and is only ever caught by somebody reading the file. Stranded this time: all seven security fixes from #366, the VOD editor and the EXPERIMENTAL convention from #365. Nine entries. THE SECURITY FIXES ARE WHY THIS IS NOT COSMETIC. GHSA-7jqx-76vq-hvfc points at these release notes, and the fix for its worst defect -- 0.7.0's own seal-at- rest migration leaving plaintext stream keys legible in the WAL, which is true on every upgraded install and needs no attacker -- was in a section a tag would not have included. An operator following the advisory to the notes would not have found it. #367 had no entry at all. Added under Testing, and written to say what actually justifies those ten guards: not that they pass, but that each was watched to fail against the defect it names, and that two real defects were found in the recovered code before it landed -- a comment-defeat where deleting the feature and leaving its text in a `// was:` comment kept the test green, and an unguarded strings.Index that turned a rename into a slice-bounds panic. Verified the same way as the first fold: the prose is MOVED, not retyped. Zero lines of the previous file are absent from this one, 0.6.0 and older are byte-identical, [Unreleased] is empty, 90 entries in 0.7.0 against 80 before, no malformed links, no conflict markers. WORTH FIXING PROPERLY: this fold belongs in the release procedure, not in review. Twice in one day is a process gap, not two mistakes. Claude-Session: https://claude.ai/code/session_01HeLrWaDmsNeeNSbHQfEofX
|
There was a problem hiding this comment.
Pull request overview
This PR corrects release note drift by moving previously “stranded” [Unreleased] entries into the [0.7.0] section, ensuring the 0.7.0 tag’s notes include all intended changes and the newly added drift-guard work.
Changes:
- Resets the
[Unreleased]section to “Nothing yet.” - Moves the previously-unreleased entries back under
## [0.7.0] — 2026-08-14, including the “Ten UI-drift guards” testing note and other recovered content.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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.



Second time today, and that's the finding rather than the fix.
[Unreleased]sits above[0.7.0], so under Keep a Changelog its contents are newer than the release below them — and every PR correctly appended there. Nothing folds it forward, so the gap reopens after each merge and is only ever caught by somebody reading the file.What was stranded
Nine entries that a tag would have silently omitted:
Plus #367 had no entry at all — zero mentions of the ten recovered drift guards.
Why this isn't cosmetic
GHSA-7jqx points at these release notes. The fix for its worst defect — 0.7.0's own seal-at-rest migration leaving plaintext stream keys legible in the WAL, which is true on every upgraded install and needs no attacker — was in a section the tag would not have included.
An operator following the advisory to the notes would not have found it.
The #367 entry
Written to say what actually justifies those ten guards: not that they pass, but that each was watched to fail against the defect it names. It also records the two real defects found in the recovered code before it landed — the comment-defeat, where deleting the feature and leaving its text in a
// was: …comment kept the test green, and the unguardedstrings.Indexthat turned a rename into a slice-bounds panic instead of a readable message.And it records what was not fixed: the two
internal/oauthguards remain comment-defeatable, because that package has no comment stripper and copying a 40-line helper between packages is the wrong repair.Verification — the prose is moved, not retyped
Worth fixing properly
This fold belongs in the release procedure, not in review. Twice in one day is a process gap, not two mistakes — the natural home is a check that fails a release build when
[Unreleased]is non-empty, which this repo would call a guard and would expect to be able to fail.https://claude.ai/code/session_01HeLrWaDmsNeeNSbHQfEofX