Release

Step 2: Gather state

Run these in parallel:

1. npm view happy dist-tags — see current latest + beta
2. cat packages/happy-cli/package.json | grep version — local version
3. git status --short — check for dirty state
4. git branch --show-current — confirm branch
5. git log --oneline -10 — recent commits for release notes context

Present a summary:

Local version:  X.Y.Z
npm latest:     X.Y.Z
npm beta:       X.Y.Z-N
Branch:         main
Working tree:   clean / dirty

Step 3: Pick channel and version

Ask the user:

• Channel: latest or beta
• Bump type: For latest: patch, minor, major. For beta: prerelease (appends -N), or explicit version.

Suggest a sensible default based on the current state. For beta, the next prerelease of the current version. For latest, a patch bump.

Present as options. Wait for confirmation.

Step 4: Version bump

Edit packages/happy-cli/package.json directly — do NOT use npm version (it chokes on pnpm workspace protocol).

IMPORTANT: do this before build/test for the CLI. The build imports package.json and bakes the version into the generated bundle. If you build first and bump later, happy --version can still report the old prerelease version even though npm metadata shows the new one.

Step 5: Build

cd packages/happy-cli
pnpm --filter happy run build

Report success/failure. Stop on failure.

Step 6: Test (unit only)

cd packages/happy-cli
pnpm --filter happy exec vitest run --project unit

Integration tests are slow and flaky — skip them for releases. Unit tests are the gate. Expect the unit suite to take around a minute; src/utils/serverConnectionErrors.test.ts is particularly slow, so don't mistake a long run for a hang.

Report results. If failures, ask the user whether to proceed or abort.

Step 7: Publish

cd packages/happy-cli
pnpm publish --tag {channel} --no-git-checks --ignore-scripts

• --no-git-checks: allows dirty working tree (we already verified state)
• --ignore-scripts: skips prepublishOnly (we already built and tested)

Step 8: Verify

npm view happy dist-tags

Confirm the new version appears under the correct tag. If latest doesn't move immediately, wait 10-15 seconds and check again; npm tag propagation is not always instant.

Step 9: Git tag + commit (latest only)

For latest releases only:

1. Commit the version bump: Release version X.Y.Z
2. Tag: git tag cli-X.Y.Z
3. Push: git push && git push --tags

For beta releases: ask the user if they want to commit the version bump or leave it uncommitted.

If git push is rejected because origin/main advanced while releasing, fetch and rebase the release commit before retrying:

git fetch origin main
git rebase --autostash origin/main
git tag -f cli-X.Y.Z
git push && git push --tags

Use --autostash when the worktree is dirty from unrelated local changes so those edits are preserved. Recreate the tag after rebase because the release commit hash changes.

Step 10: GitHub Release (latest only)

For latest releases, create a GitHub release:

gh release create cli-X.Y.Z --generate-notes --title "cli-X.Y.Z"

Step 11: Install + verify locally

npm i -g happy@{channel}
happy --version
happy daemon status

Report the installed version and daemon status. The smoke check must confirm that happy --version matches the published version, not just npm metadata. If it reports the old version, rebuild after the version bump and cut a corrective patch release.

Mobile Release

Package:     packages/happy-app
Variants:    development, preview, production
Platform:    Expo SDK 54 / React Native 0.81.4

Build types

Ask the user what kind of release. OTA is the most common — suggest it first:

• OTA update (preview) — push JS update to preview channel (most common)

  pnpm --filter happy-app run ota
  

• OTA update (production) — push JS update to production channel

  pnpm --filter happy-app run ota:production
  

Native builds are rare — only needed when native code changes:

• Dev builds — development + preview variants (internal distribution)

  pnpm --filter happy-app run release:build:developer
  

• App Store — production builds with auto-submit

  pnpm --filter happy-app run release:build:appstore
  

EAS Build Profiles

Profile              Distribution   Channel
development          internal       development
development-store    store          development
preview              internal       preview
preview-store        store          preview
production           store          production

Version source is remote (EAS manages build numbers, auto-incremented). Runtime version "20" — bump when native code changes to invalidate OTA.

App Store Connect

Apple ID:    [email protected]
ASC App ID:  126165711
Team ID:     466DQWDR8C

Web Release

Package:     packages/happy-app (same Expo app, web export)
Dockerfile:  Dockerfile.webapp
Image:       docker.korshakov.com/happy-app:{version}
K8s:         packages/happy-app/deploy/happy-app.yaml (3 replicas)

Web releases go through TeamCity (Lab_HappyWeb). The config is in the TeamCity UI, not in the repo.

Flow: expo export --platform web -> nginx:alpine static serve -> Docker build -> push -> K8s deploy.

Build args: POSTHOG_API_KEY, REVENUE_CAT_STRIPE.

Guide the user to trigger the TeamCity build, or help with manual Docker builds if needed.

Server Release

Package:     packages/happy-server
Dockerfile:  Dockerfile.server (production), Dockerfile (standalone w/ PGlite)
Image:       docker.korshakov.com/handy-server:{version}
K8s:         packages/happy-server/deploy/handy.yaml (1 replica, port 3005)

Server releases go through TeamCity (Lab_HappyServer). The config is in the TeamCity UI, not in the repo.

Build: node:20 + python3 + ffmpeg, builds happy-wire + happy-server. Secrets from Vault: handy-db, handy-master, handy-github, handy-files, handy-e2b, handy-revenuecat, handy-elevenlabs. Redis: happy-redis StatefulSet (redis:7-alpine, 1Gi persistent volume).

Guide the user to trigger the TeamCity build.

Docs Release

Site:    happy.engineering (GitHub Pages)
Repo:    github.com/slopus/slopus.github.io

Separate repo, not part of this monorepo. Guide the user to push to that repo.

Rules

• Always present options — never assume which component, channel, or version.
• Always verify before publishing — show the user what will be published and get confirmation.
• Unit tests are the gate, not integration tests — integration tests are slow and have flaky abort/interrupt tests.
• Use pnpm publish, not npm publish — avoids workspace protocol issues.
• Use --ignore-scripts — we build and test explicitly, no need for prepublishOnly to redo it.
• Never force-push tags — if a tag exists, stop and ask.