| chore(app): August 7 changelog entry with Community Credits convention | 30 days ago |
| chore: add .claude/launch.json dev server config Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 1 month ago |
| chore: add Paper Design MCP config for Claude Code and Codex Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> | 4 months ago |
| Add macOS desktop app links and announcement banner to README Link slopus/happy-desktop from the header link row, Step 1, and Project Components, and add a transparent light/dark banner pair announcing the Mac desktop app. | 14 days ago |
| fix(deploy): keep migration in TeamCity recipe | 13 days ago |
| feat: migrate from yarn 1 to pnpm 10 (#1033) * feat: migrate from yarn 1 to pnpm 10 Yarn install was taking ~82s (warm cache, no scripts). pnpm achieves ~7.5s for the same operation — an 11x speedup thanks to its content-addressable store and hard-linking. Key changes: - Add pnpm-workspace.yaml, .npmrc (shamefully-hoist for RN compat) - Replace yarn.lock with pnpm-lock.yaml (imported via pnpm import) - Use workspace:* protocol for @slopus/happy-wire cross-references - Move happy-cli resolutions to root pnpm.overrides - Add pnpm.onlyBuiltDependencies allowlist for native build scripts - Update all 3 Dockerfiles to use corepack + pnpm - Update CI workflows to use pnpm/action-setup@v4 - Update all scripts, tests, and docs referencing yarn Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * chore: bump changelog to version 8 for pnpm migration OTA Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * fix(ci): pnpm pack outputs to repo root, use --pack-destination pnpm pack puts the tarball in the current directory (repo root) unlike yarn which puts it in the package directory. Use --pack-destination to match the expected path in the smoke test workflow. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering> | 4 months ago |
| feat(server): add encrypted project avatars (#1714) | 12 days ago |
| feat: refresh mobile UI and improve session handling | 1 month ago |
| feat: refresh mobile UI and improve session handling | 1 month ago |
| Fix webapp Docker build dependencies | 4 months ago |
| chore: ignore .context/ Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 30 days ago |
| chore: add Paper Design MCP config for Claude Code and Codex Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> | 4 months ago |
| feat: migrate from yarn 1 to pnpm 10 (#1033) * feat: migrate from yarn 1 to pnpm 10 Yarn install was taking ~82s (warm cache, no scripts). pnpm achieves ~7.5s for the same operation — an 11x speedup thanks to its content-addressable store and hard-linking. Key changes: - Add pnpm-workspace.yaml, .npmrc (shamefully-hoist for RN compat) - Replace yarn.lock with pnpm-lock.yaml (imported via pnpm import) - Use workspace:* protocol for @slopus/happy-wire cross-references - Move happy-cli resolutions to root pnpm.overrides - Add pnpm.onlyBuiltDependencies allowlist for native build scripts - Update all 3 Dockerfiles to use corepack + pnpm - Update CI workflows to use pnpm/action-setup@v4 - Update all scripts, tests, and docs referencing yarn Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * chore: bump changelog to version 8 for pnpm migration OTA Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * fix(ci): pnpm pack outputs to repo root, use --pack-destination pnpm pack puts the tarball in the current directory (repo root) unlike yarn which puts it in the package directory. Use --pack-destination to match the expected path in the smoke test workflow. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering> | 4 months ago |
| Set webapp zoom default to 1x | 3 months ago |
| Split self-host publishing out of the production server package d2d2f730 renamed packages/happy-server to happy-server-self-host so the self-host runtime could be published to npm, but that directory is also the production backend, and the rename left /Dockerfile.server and /Dockerfile running `pnpm --filter happy-server ...`. pnpm exits 0 on an unmatched filter, so the production image's build step became a no-op and its CMD became a container that prints one line and exits 0 instead of serving. Production has not been redeployed since. Actually split the two roles: - packages/happy-server goes back to being private "happy-server", the production backend. It is never published, so npm's squatted bare name is irrelevant to it. - packages/happy-server-self-host is a new publishing shell that keeps the published name and version. Its build bun-bundles the sibling's sources/standalone.ts into dist/ and copies prisma/ in, both of which must live inside the package because the runtime resolves migrations from cwd. It asserts its dependency list matches the sibling's, since the bundle externalizes every dependency and drift would otherwise fail at require time. Fixing the Docker filters alone was not enough: `build` now also bundles the npm runtime via bun, which neither image installs, and the full typecheck includes machinesRoutes.spec.ts, which imports happy-app source that the builder stage does not copy. Production therefore gets tsconfig.build.json, which excludes specs, and `build` runs that typecheck only. Every pnpm filter invocation gets --fail-if-no-match so a future rename fails the build instead of silently doing nothing, and Dockerfile.server's CMD no longer depends on the package name at all. Add .github/workflows/server.yml: the server package had no CI coverage, which is why this went unnoticed for 74 days. It typechecks and tests the package and builds both images and boots them, asserting they serve — the only check that catches a no-op CMD. Also revert 450f29e9, a hardcoded voice grant for one account that was written to deploy immediately and never shipped. | 1 month ago |
| Split self-host publishing out of the production server package d2d2f730 renamed packages/happy-server to happy-server-self-host so the self-host runtime could be published to npm, but that directory is also the production backend, and the rename left /Dockerfile.server and /Dockerfile running `pnpm --filter happy-server ...`. pnpm exits 0 on an unmatched filter, so the production image's build step became a no-op and its CMD became a container that prints one line and exits 0 instead of serving. Production has not been redeployed since. Actually split the two roles: - packages/happy-server goes back to being private "happy-server", the production backend. It is never published, so npm's squatted bare name is irrelevant to it. - packages/happy-server-self-host is a new publishing shell that keeps the published name and version. Its build bun-bundles the sibling's sources/standalone.ts into dist/ and copies prisma/ in, both of which must live inside the package because the runtime resolves migrations from cwd. It asserts its dependency list matches the sibling's, since the bundle externalizes every dependency and drift would otherwise fail at require time. Fixing the Docker filters alone was not enough: `build` now also bundles the npm runtime via bun, which neither image installs, and the full typecheck includes machinesRoutes.spec.ts, which imports happy-app source that the builder stage does not copy. Production therefore gets tsconfig.build.json, which excludes specs, and `build` runs that typecheck only. Every pnpm filter invocation gets --fail-if-no-match so a future rename fails the build instead of silently doing nothing, and Dockerfile.server's CMD no longer depends on the package name at all. Add .github/workflows/server.yml: the server package had no CI coverage, which is why this went unnoticed for 74 days. It typechecks and tests the package and builds both images and boots them, asserting they serve — the only check that catches a no-op CMD. Also revert 450f29e9, a hardcoded voice grant for one account that was written to deploy immediately and never shipped. | 1 month ago |
| feat(app): surface build metadata in settings | 3 months ago |
| Fix filename typo from LICENCE to LICENSE fix link in README.md. | 5 months ago |
| feat: refresh mobile UI and improve session handling | 1 month ago |
| Move desktop app banner to an optional Step 4 The banner sat above the numbered steps and competed with the header image. Put it after Step 3 as an optional step instead. | 14 days ago |
| fix: restore logog | 7 months ago |
| Split self-host publishing out of the production server package d2d2f730 renamed packages/happy-server to happy-server-self-host so the self-host runtime could be published to npm, but that directory is also the production backend, and the rename left /Dockerfile.server and /Dockerfile running `pnpm --filter happy-server ...`. pnpm exits 0 on an unmatched filter, so the production image's build step became a no-op and its CMD became a container that prints one line and exits 0 instead of serving. Production has not been redeployed since. Actually split the two roles: - packages/happy-server goes back to being private "happy-server", the production backend. It is never published, so npm's squatted bare name is irrelevant to it. - packages/happy-server-self-host is a new publishing shell that keeps the published name and version. Its build bun-bundles the sibling's sources/standalone.ts into dist/ and copies prisma/ in, both of which must live inside the package because the runtime resolves migrations from cwd. It asserts its dependency list matches the sibling's, since the bundle externalizes every dependency and drift would otherwise fail at require time. Fixing the Docker filters alone was not enough: `build` now also bundles the npm runtime via bun, which neither image installs, and the full typecheck includes machinesRoutes.spec.ts, which imports happy-app source that the builder stage does not copy. Production therefore gets tsconfig.build.json, which excludes specs, and `build` runs that typecheck only. Every pnpm filter invocation gets --fail-if-no-match so a future rename fails the build instead of silently doing nothing, and Dockerfile.server's CMD no longer depends on the package name at all. Add .github/workflows/server.yml: the server package had no CI coverage, which is why this went unnoticed for 74 days. It typechecks and tests the package and builds both images and boots them, asserting they serve — the only check that catches a no-op CMD. Also revert 450f29e9, a hardcoded voice grant for one account that was written to deploy immediately and never shipped. | 1 month ago |
| feat: boot Happy Agent with happy daemon | 14 days ago |
| Split self-host publishing out of the production server package d2d2f730 renamed packages/happy-server to happy-server-self-host so the self-host runtime could be published to npm, but that directory is also the production backend, and the rename left /Dockerfile.server and /Dockerfile running `pnpm --filter happy-server ...`. pnpm exits 0 on an unmatched filter, so the production image's build step became a no-op and its CMD became a container that prints one line and exits 0 instead of serving. Production has not been redeployed since. Actually split the two roles: - packages/happy-server goes back to being private "happy-server", the production backend. It is never published, so npm's squatted bare name is irrelevant to it. - packages/happy-server-self-host is a new publishing shell that keeps the published name and version. Its build bun-bundles the sibling's sources/standalone.ts into dist/ and copies prisma/ in, both of which must live inside the package because the runtime resolves migrations from cwd. It asserts its dependency list matches the sibling's, since the bundle externalizes every dependency and drift would otherwise fail at require time. Fixing the Docker filters alone was not enough: `build` now also bundles the npm runtime via bun, which neither image installs, and the full typecheck includes machinesRoutes.spec.ts, which imports happy-app source that the builder stage does not copy. Production therefore gets tsconfig.build.json, which excludes specs, and `build` runs that typecheck only. Every pnpm filter invocation gets --fail-if-no-match so a future rename fails the build instead of silently doing nothing, and Dockerfile.server's CMD no longer depends on the package name at all. Add .github/workflows/server.yml: the server package had no CI coverage, which is why this went unnoticed for 74 days. It typechecks and tests the package and builds both images and boots them, asserting they serve — the only check that catches a no-op CMD. Also revert 450f29e9, a hardcoded voice grant for one account that was written to deploy immediately and never shipped. | 1 month ago |
