chore(release): prepare 0.13.5

[steipete]

Date the reconciled 0.13.5 changelog after all approved maintenance and fix lanes landed.

Local proof before opening: generated version metadata was already consistent at 0.13.5; the release-preparation diff contains only the changelog date.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 2, 2026, 2:47 PM ET / 18:47 UTC.

ClawSweeper review

What this changes

This PR changes the 0.13.5 changelog heading from Unreleased to 2026-08-01 so that release notes can be published from the dated section.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

Keep this collaborator-owned release-gate PR open for explicit release-owner confirmation. The one-line changelog date is consistent with the documented pre-tag workflow and the repository’s generated 0.13.5 metadata, but current main still marks 0.13.5 as unreleased, no v0.13.5 tag is present locally, and GitHub reports the branch as dirty against main.

Priority: P3
Reviewed head: dc9bda9eeb3a1ecf3862412f507d662ab4367aed
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The patch is appropriately narrow and consistent with the documented release process; only release-date confirmation and branch refresh remain.
Proof confidence	🌊 off-meta tidepool	Not applicable: This collaborator-owned release metadata change does not alter runtime behavior; release-owner confirmation and the normal release validation sequence are the relevant proof.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This collaborator-owned release metadata change does not alter runtime behavior; release-owner confirmation and the normal release validation sequence are the relevant proof.
Evidence reviewed	6 items	Release procedure: The release guide says GitHub Release notes come from the matching changelog section and instructs release preparation to date an existing X.Y.Z - Unreleased heading before tagging. Current release state: Current main has a separate 0.14.0 - Unreleased section and still shows 0.13.5 - Unreleased; the PR changes the latter heading only. Version consistency: Current version.env, generated Swift version source, and Info.plist all identify the build as 0.13.5, matching the release section this PR dates.
Findings	None	None.
Security	None	None.

How this fits together

The changelog is the source for imsg GitHub release notes. Release preparation dates the versioned section before tagging, after which the signed artifacts and GitHub release are published.

flowchart LR
  A[Completed 0.13.5 changes] --> B[Version metadata 0.13.5]
  B --> C[Changelog 0.13.5 section]
  C --> D[Release-owner date confirmation]
  D --> E[Git tag and GitHub release]
  E --> F[Published release notes and artifacts]

Loading

Decision needed

Question	Recommendation
Should the 0.13.5 release notes be dated 2026-08-01 and included in the imminent release after a refresh onto current main?	Confirm and refresh the release date: Rebase or refresh this one-line edit on current main, confirm that August 1 is the release date, then land it as part of the tag-and-publish sequence.

Why: The repository release guide permits this workflow, but the correct publication date and timing are release-owner decisions that source inspection cannot establish while v0.13.5 remains untagged.

Before merge

• Resolve merge risk (P1) - GitHub reports the branch as dirty against current main; merge or rebase refresh is needed before the dated heading is landed.
• Resolve merge risk (P1) - A release date is publication metadata: merging 2026-08-01 without release-owner confirmation could make the changelog disagree with the eventual v0.13.5 tag or release timeline.
• Complete next step (P2) - A release owner must confirm the final date and refresh the dirty branch; there is no narrow autonomous code repair to perform.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch scope	1 file changed; 1 line added, 1 line removed	The branch is intentionally limited to release-note date metadata.
Release provenance	v0.13.4 is the latest local release tag; v0.13.5 is untagged	The proposed date needs release-owner confirmation before it becomes published release metadata.

Merge-risk options

Maintainer options:

1. Refresh and confirm the release gate (recommended)
   Rebase the changelog-only branch onto current main and have the release owner confirm the final 0.13.5 date before merge.
2. Hold until the tag is ready
   Keep the heading as unreleased until the tag, release notes, and publication date are ready to be finalized together.

Technical review

Best possible solution:

Rebase the one-line changelog change onto current main, then have the release owner confirm that 2026-08-01 is the intended v0.13.5 release date immediately before tagging and publishing the release.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR changes release metadata rather than a runtime behavior. The relevant verification is the documented release workflow plus confirmation of the final tag date.

Is this the best way to solve the issue?

Yes, conditionally: dating the existing 0.13.5 section is the documented release path, but it is only the best solution once the release owner confirms the date and refreshes the branch against current main.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against e9580a332432.

Labels

Label justifications:

• P3: This is low-risk release bookkeeping rather than a runtime defect or user-facing outage.
• merge-risk: 🚨 other: The only material merge risk is inconsistent release-publication metadata if the dated changelog lands without a confirmed tag timeline.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This collaborator-owned release metadata change does not alter runtime behavior; release-owner confirmation and the normal release validation sequence are the relevant proof.

Evidence

What I checked:

• Release procedure: The release guide says GitHub Release notes come from the matching changelog section and instructs release preparation to date an existing X.Y.Z - Unreleased heading before tagging. (docs/RELEASING.md:7, e9580a332432)
• Current release state: Current main has a separate 0.14.0 - Unreleased section and still shows 0.13.5 - Unreleased; the PR changes the latter heading only. (CHANGELOG.md:8, e9580a332432)
• Version consistency: Current version.env, generated Swift version source, and Info.plist all identify the build as 0.13.5, matching the release section this PR dates. (version.env:1, e9580a332432)
• Release-history provenance: The current 0.13.5 development section dates to the release-start commit, while the previous dated release is v0.13.4; the current changelog history also includes the pending 0.13.5 fixes and a subsequent 0.14.0 entry. (CHANGELOG.md:3, 8c0e667d4d12)
• Available release provenance: The checked-out tag history contains v0.13.4 as the latest 0.13.x tag and no v0.13.5 tag, so the dated heading cannot yet be treated as shipped release evidence. (CHANGELOG.md:8, 1d8b679cc3a3)
• Current-main adjacency: The current top-level changelog section was added by recent pagination work after the PR base, so the release edit needs a rebase or merge refresh before landing. (CHANGELOG.md:3, e9580a332432)

Likely related people:

• steipete: Peter Steinberger authored the 0.13.5 development-start commit and the v0.13.4 preparation/tag commit, and is the collaborator proposing this release-date update. (role: release-history contributor and current PR author; confidence: high; commits: 8c0e667d4d12, 1d8b679cc3a3, dc9bda9eeb3a; files: CHANGELOG.md, version.env, Sources/imsg/Version.swift)
• vincentkoc: The latest main commit added the 0.14.0 changelog section above the pending 0.13.5 section, making this person relevant to the current release-note ordering and refresh. (role: recent adjacent changelog contributor; confidence: medium; commits: e9580a332432; files: CHANGELOG.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Rebase or refresh the branch against current main.
• Confirm the final v0.13.5 publication date as part of the tag-and-publish sequence.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (5 earlier review cycles)

• reviewed 2026-08-02T06:41:57.798Z sha ec47ef3 :: needs maintainer review before merge. :: none
• reviewed 2026-08-02T06:56:30.956Z sha dc9bda9 :: needs maintainer review before merge. :: none
• reviewed 2026-08-02T09:39:18.045Z sha dc9bda9 :: needs maintainer review before merge. :: none
• reviewed 2026-08-02T12:47:23.593Z sha dc9bda9 :: needs maintainer review before merge. :: none
• reviewed 2026-08-02T17:33:40.046Z sha dc9bda9 :: needs maintainer review before merge. :: none