## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - Stable versions date the promotion, and the promotion reads its
notes from master
> - The merged notes for beta 2026.818.0-beta.1 assumed an Aug 21
promotion; the beta soaked longer
> - This pull request re-dates the header to today's resolved version,
v2026.824.0
> - The benefit is a GitHub Release whose title, date, and body agree
## Linked Issues or Issue Description
**What existing behavior does this improve?**
The stable notes header for the promotion happening today.
**Current behavior**
`releases/beta/v2026.818.0-beta.1.md` is titled `# Paperclip
v2026.821.0`, `> Released: 2026-08-21`.
**Proposed behavior**
`# Paperclip v2026.824.0`, `> Released: 2026-08-24` — matching
`./scripts/release.sh stable --date 2026-08-24 --print-version`.
**Reason and benefit**
The file publishes verbatim as the GitHub Release body; the header
should match the version actually minted.
## What Changed
- Three header/intro lines re-dated. Nothing else.
## Verification
- `./scripts/release.sh stable --date 2026-08-24 --print-version` →
`2026.824.0`.
## Risks
- None; docs-only.
## Model Used
Claude Fable 5 (Claude Code)
## 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
ae9711da48