From fa40a1b8d502ac19cfca2fcc5bbbdbf331410787 Mon Sep 17 00:00:00 2001 From: Devin Foley Date: Mon, 24 Aug 2026 21:37:17 -0700 Subject: [PATCH] docs(release): canonicalize stable notes for v2026.824.0 (#12139) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable notes are drafted beta-keyed during the soak and published verbatim as the GitHub Release > - After the stable ships, the canonicalize job moves the file to its durable home, releases/vYYYY.MDD.P.md > - v2026.824.0 just shipped from the master-side beta notes, and the job pushed this rename branch > - This pull request lands that rename, keeping the stable-notes record complete at the canonical path > - The benefit is one canonical notes location per stable, with the pinned shipped content ## Linked Issues or Issue Description **What existing behavior does this improve?** The `releases/` record on master after the v2026.824.0 promotion. **Current behavior** The shipped notes live at `releases/beta/v2026.818.0-beta.1.md`; `releases/v2026.824.0.md` does not exist. **Proposed behavior** The file moves to `releases/v2026.824.0.md`, content pinned to the revision the release read (machine-generated by the `canonicalize_stable_notes` job). **Reason and benefit** The durable stable-notes invariant holds: every shipped stable has its notes at `releases/vYYYY.MDD.P.md`. ## What Changed - `git mv`-equivalent rename of the beta-keyed notes to `releases/v2026.824.0.md`, exactly as the release published them. ## Verification - Branch pushed by the release run's `canonicalize_stable_notes` job (run 32806191945) from the preflight-pinned notes revision; the GitHub Release v2026.824.0 body matches this content. ## Risks - None; docs-only rename. ## Model Used Claude Fable 5 (Claude Code) — PR opened for the machine-pushed branch; a GITHUB_TOKEN-created PR would not run required checks. ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- releases/{beta/v2026.818.0-beta.1.md => v2026.824.0.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename releases/{beta/v2026.818.0-beta.1.md => v2026.824.0.md} (100%) diff --git a/releases/beta/v2026.818.0-beta.1.md b/releases/v2026.824.0.md similarity index 100% rename from releases/beta/v2026.818.0-beta.1.md rename to releases/v2026.824.0.md