Problem
After the v0.8.60 website/readme work landed, the local checkout was still on renovate/website-and-readmes, even though HEAD matched origin/main, origin/codex/v0.8.60, and tag v0.8.60. The remote origin/renovate/website-and-readmes also remained behind the final release tip. That makes it look like the work may not have merged, even when the commits are already present on the release/main refs.
Live repro on 2026-06-14:
HEAD / origin/main / origin/codex/v0.8.60: ae101a123
local branch: renovate/website-and-readmes
origin/renovate/website-and-readmes: 652d3925a
local codex/v0.8.60: 1574dd488, behind origin/codex/v0.8.60 by 17 commits
Desired outcome
Release and scratch branch cleanup should make it obvious where the current release tip lives, and should avoid leaving merged work parked under a stale feature-branch name.
Acceptance criteria
- Add a release hygiene check or runbook step that verifies the current checkout branch, local release branch, remote release branch, and main all point where expected after a release/integration merge.
- Detect local branches whose
HEAD is already contained in origin/main or the release branch and recommend safe cleanup.
- Detect remote scratch/renovate/integration branches that are behind the final release tip and should be deleted or explicitly kept.
- After v0.8.61 work lands,
codex/v0.8.61 should be fast-forwarded locally and the working checkout should not remain on an unrelated scratch/renovate branch.
- Document the exact cleanup commands, including a dry-run mode, so agents do not guess or delete branches blindly.
Notes
This is mostly maintainer UX, but it matters because a stale branch name creates release anxiety and makes it harder for contributors/helpers to tell whether their website/readme work actually landed.
Branch pruning policy
As part of the v0.8.61 cleanup, prune as many old local and remote branches as safely possible. The default should be to delete stale maintainer/scratch/renovate/codex branches once their tips are contained in origin/main, the active release branch, or an explicitly kept integration branch.
Keep branches that contain unique contributor work, especially work from people other than Hunter, until that work has been reviewed, merged, harvested with credit, or explicitly marked as preserved elsewhere. For those branches, the cleanup report should name the branch, the unique commits, the contributor(s), and the reason it was kept.
Additional acceptance criteria:
- Produce a dry-run branch-prune report before deleting anything.
- Separate safe deletes from keep/review decisions.
- Never delete a branch with unique non-Hunter contributor commits unless the work is already merged, credited, or intentionally preserved in another branch/PR/issue.
- After cleanup, report how many branches were deleted, how many were kept for contributor work, and which branches still need a human decision.
Problem
After the v0.8.60 website/readme work landed, the local checkout was still on
renovate/website-and-readmes, even thoughHEADmatchedorigin/main,origin/codex/v0.8.60, and tagv0.8.60. The remoteorigin/renovate/website-and-readmesalso remained behind the final release tip. That makes it look like the work may not have merged, even when the commits are already present on the release/main refs.Live repro on 2026-06-14:
Desired outcome
Release and scratch branch cleanup should make it obvious where the current release tip lives, and should avoid leaving merged work parked under a stale feature-branch name.
Acceptance criteria
HEADis already contained inorigin/mainor the release branch and recommend safe cleanup.codex/v0.8.61should be fast-forwarded locally and the working checkout should not remain on an unrelated scratch/renovate branch.Notes
This is mostly maintainer UX, but it matters because a stale branch name creates release anxiety and makes it harder for contributors/helpers to tell whether their website/readme work actually landed.
Branch pruning policy
As part of the v0.8.61 cleanup, prune as many old local and remote branches as safely possible. The default should be to delete stale maintainer/scratch/renovate/codex branches once their tips are contained in
origin/main, the active release branch, or an explicitly kept integration branch.Keep branches that contain unique contributor work, especially work from people other than Hunter, until that work has been reviewed, merged, harvested with credit, or explicitly marked as preserved elsewhere. For those branches, the cleanup report should name the branch, the unique commits, the contributor(s), and the reason it was kept.
Additional acceptance criteria: