Release

Release

Prepare a new warren release, push it, and verify the pipeline shipped it. The release does not exist when the commit lands — it exists when the Release workflow's five-job chain finishes: gates → tag → draft release → ghcr image + GKE deploy → npm publish → promote draft to final → Discord announce. This command runs everything up to the push, then watches that chain to the end.

1. Pre-flight

• Working tree is clean, on main, up to date with origin (git status, git pull).
• No open PRs about to auto-merge into the release commit: gh pr list --state open. If one is close to merging, either wait for it or release without it deliberately — never race it.
• Find the last release tag: git describe --tags --abbrev=0.

2. Tracker audits (two parallel subagents)

Spawn both subagents in a single message so they run concurrently. Neither pushes — all commits ride out with the single push in step 9.

• Seeds audit — a subagent that invokes the seeds-issue-audit skill and follows it exactly: auto-close only HIGH-confidence issues with citable evidence, run sd sync after closing, report borderline cases, never push. Have it return its two tables (auto-closed / borderline).
• GitHub issue sweep — a subagent that lists open GitHub issues (gh issue list --state open) and verifies each against HEAD. Same discipline as the seeds audit: close an issue only when the fix is verifiably on main (name the commit or merged PR in the closing comment, gh issue close <n> --comment "..."); anything uncertain goes in a borderline table, untouched. Staleness alone never closes anything.

Hold both reports — the borderline tables go in the final summary (step 10), and confirmed-done plans feed the ROADMAP update (step 6).

3. Review changes since the last tag

• git log <tag>..HEAD --oneline and git diff <tag>..HEAD --stat.
• Determine the version bump level. Always use patch unless the user explicitly requests minor or major.

4. Bump the version

Run bun run version:bump <major|minor|patch>. It rewrites all four version sites (package.json, src/index.ts, docs/openapi.yaml via gen:openapi, and the README ## Status line) and drafts an [Unreleased] CHANGELOG block from the commit log.

5. Curate the CHANGELOG — this is a fatal release gate

Rework the drafted block by hand: regroup entries under ### Added / ### Changed / ### Fixed, rename the heading to ## [X.Y.Z] - <today's date>, and delete the <!-- version-bump:draft --> markers.

The Release workflow fails the release if CHANGELOG.md has no non-empty ## [X.Y.Z] section — notes are never auto-generated. Write for the reader of the GitHub release and the Discord announcement, not for the git log.

6. Update ROADMAP.md

Reconcile the roadmap with what this release ships, following its own rules (shipped items shrink to one table row; no design sketches):

• Move finished campaigns/plans out of Now — in flight into the Shipped table — one row, the new version number, a pointer to the design record. Use the seeds audit's confirmed-done plans as the input.
• Update the Seam status table for any seam this release changed.
• Re-order Next if the shipped work unblocked or promoted an item.

7. Doc pass

The gates already hold generated docs in place (gen:docs:check, gen:openapi:check, gen:cli-ref:check, check:agents), so this pass is prose only:

• CLAUDE.md (a symlink to AGENTS.md) if structure or command counts changed.
• README.md if the pitch, stats, or install instructions drifted.

8. Run the gates locally

bun run check:all

The Release workflow runs this same manifest first and a failure kills the release with the version already bumped on main. Catch it here instead.

9. Commit and push

Commit the release changes (version sites, CHANGELOG, ROADMAP, docs). This is the single push point: the tracker-audit commits from step 2 ride out with it. Then git push. The push triggers the Release workflow (it fires on main pushes touching package.json / CHANGELOG.md).

10. Watch the pipeline and verify

• Watch the Release workflow to completion: gh run list --workflow=release.yml --limit 1, then gh run watch <run-id>.
• Verify the release was promoted out of draft: gh release view vX.Y.Z shows it final and --latest. By the pipeline's ordering guarantee, a promoted release proves the ghcr image and the npm package already exist; spot-check npm anyway: npm view @os-eco/warren-cli@X.Y.Z version.
• If any job failed, say so plainly and stop — a draft release with no image is the designed failure state, not a partial success.

Finish with a summary: version, highlights, links (release URL, workflow run), and the two borderline tables from step 2 for human review.