/release

name: release
description: Prepare, cut, and verify a warren release — tracker audits, version bump, CHANGELOG curation, ROADMAP update, push, then watch the pipeline through to published artifacts.

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.