Honcho release process

Cut a new Honcho version. Staging first, then production via Groudon.

Related: Releasing a Honcho version onto Groudon · Honcho debugging

---

1. Changelog PR

On main, write notes for everything since the latest ## [X.Y.Z] heading in CHANGELOG.md — not since the git tag. The tag is often weeks earlier than the notes that bear its version. Backfill anything that landed before that heading and never appeared in any release.

Propose versions and wait. Bump the API always. Bump the SDKs only if they grew unreleased surface. Bump the CLI only if its own changelog is behind. Use a minor when the cut is a new primitive (scopes, workspace chat); otherwise a patch is fine.

uv run python scripts/update_version.py \
  --api-version X.Y.Z \
  --api-changelog /tmp/honcho-api-changelog.md \
  --python-version A.B.C \
  --python-changelog /tmp/honcho-python-sdk-changelog.md \
  --typescript-version A.B.C \
  --typescript-changelog /tmp/honcho-ts-sdk-changelog.md

Then fix what the script misses:

• README.md badge is Server-X.Y.Z-blue, not Version-…
• docs/v3/openapi.json info.version
• docs/changelog/compatibility-guide.mdx Latest cards, and any skipped table row
• CLI tab in docs/changelog/introduction.mdx (script does not touch the CLI)
• Extra blank line the script inserts above ## [version]
• uv lock

PR title: release: add changelog and version updates. Example: #841, #1069.

2. Tag

Merge the changelog PR. Tag the merge commit on main, not the branch tip:

git checkout main && git pull
git tag -a vX.Y.Z -m "vX.Y.Z"
git push origin vX.Y.Z

3. Staging, then Groudon

The tag deploys to staging. Smoke it there before production.

Then release the version onto Groudon — secrets, then instances. That is Releasing a Honcho version onto Groudon.