Hindsight Release

Cut a core Hindsight release and open the accompanying changelog/blog PR. This is for the core product version (API, clients, CLI, control plane, Helm). Integrations are versioned independently, use scripts/release-integration.sh for those, not this skill.

The release is irreversible and outward-facing: it tags a version and pushes it straight to main, which triggers CI that publishes packages to PyPI / npm / Helm. Confirm the version number and that the intended fixes are already merged to main before you start.

Step 0, Pre-flight

1. Decide the base. A release is cut from the latest origin/main, never from a feature branch. git fetch origin --tags first. Confirm the "couple of fixes" the user means are actually merged to main (git log v<prev>..origin/main --oneline).
2. Find where main is checked out. main is often already checked out in a sibling worktree (git worktree list). You cannot check out main in a second worktree, run the release in the worktree that already holds it. If that worktree is dirty with throwaway cruft (.next-* tsconfig paths, screenshots), git stash push -u, fast-forward to origin/main, run the release, then git stash pop.
3. Pitfall: never pipe the checkout in an && chain like git checkout main 2>&1 | tail && git reset --hard ..., the pipe's exit status is tail's (always 0), so a failed checkout won't stop the chain and the reset fires on the wrong branch. Check out as its own command and verify git branch --show-current before resetting.

Step 1, Cut the release

Run from the worktree on a clean main:

./scripts/release.sh <version>     # e.g. 0.8.1  (no leading v)