[tconley1428]

Move pending Python SDK release notes into per-PR Markdown files under category folders. Contributors choose fun, whimsical filenames and write only the note body without a leading list marker. Entries should be concise, ideally one or two sentences, each entirely on one line because each nonempty line becomes a separate list item. Fragments may contain multiple entries. Release preparation prepends a dated section, adds one bullet per nonempty line, and removes exactly the consumed files after version and lockfile updates succeed. CHANGELOG.md contains completed releases only.

Use sdk-rust's shared tooling for fragment checks, changelog writing and consumption, dated-section extraction, and Core revision selection. Python updates its versions and lockfile first, then invokes the tool with the new release version and date. Python retains Git/PR orchestration; no hook or JSON release plan is needed. Breaking headings are standardized on :boom: Breaking Changes, and empty releases are allowed through preparation and note extraction. Switch the checkpoint to the alternative organization-wide fragment workflow and update contributor/agent guidance.

Dependencies:

• Add shared changelog fragment tooling sdk-rust#1625
• Add alternative shared changelog fragment workflow .github#22

Both dependencies are pinned to published PR commit SHAs so this draft can exercise the shared workflow before they merge. Re-pin if upstream commits change or are squash-merged.

Validation: 16 targeted release-script tests passed, along with import/format checks, targeted type checks, and actionlint. Rust tooling has 23 passing tests and targeted Clippy checks. Release preparation was rehearsed with real uv lock, version checks, release commits, and publishing-note extraction. Following the rebase, all 18 pending entries were verified against main and assembled once by the real CLI, with released history unchanged. Duplicate releases were rejected, empty releases were prepared and yielded no SDK-specific notes, and a late fragment was consumed by a subsequent release while preserving history. No release was pushed or published. No SDK release-version bump is required.

Changelog validation failures leave the earlier local version/lockfile updates for inspection while preserving the changelog and fragments. Preparation stops before committing; filesystem failures during writes or deletion may require local recovery.

[THardy98]

lgtm but i don't really have strong opinions on this

[chris-olszewski]

Not to dampen the fun, but this becomes annoying for anyone creating a change w/o an agent. Offering a command that creates this file for you would be nice (this is the approach change sets took in pre-AI world)