happy2 0.0.5 → 0.0.9

package/README.md

@@ -1,82 +1,117 @@
-# Happy (2)
+<div align="center">
 
-Happy (2) is a desktop work and coding app that evolves by adopting itself. This
-pnpm monorepo delivers its shared Solid UI through a web app and an Electron
-desktop app. Happy (2) is desktop-only; its UI must not assume mobile use or adapt
-for mobile viewports.
+<p><img src="./.github/logo.png" alt="Happy (2)" width="640" /></p>
 
-## Packages
+<h3>A self-hosted, Slack-like workspace where people and coding agents build together.</h3>
 
-- `happy2-app` contains the shared Solid component and its tests.
-- `happy2-web` imports `happy2-app` and creates a browser build.
-- `happy2-desktop` imports `happy2-app` in an Electron renderer and builds its
-  Electron main process with Vite.
-- `happy2-server` is the Fastify server and authentication-service package.
-- The root `happy2` package bundles the server and built web app into the complete
-  distributable.
-- `happy2-gym` is the isolated end-to-end testing environment. Its server harness runs
-  black-box HTTP tests against disposable in-memory server instances; see
-  [`packages/happy2-gym/README.md`](packages/happy2-gym/README.md) for usage.
+<p>
+  Following the success of <a href="https://github.com/slopus/happy">Happy</a>,
+  Happy (2) is a ground-up next chapter built on the lessons learned from
+  bringing coding agents into real daily workflows. It brings conversations,
+  files, workspaces, and coding agents into one focused web and desktop app.
+</p>
 
-## Requirements
+<p>
+  Built by the authors of
+  <a href="https://github.com/slopus/happy">Happy</a> and
+  <a href="https://github.com/slopus/rig">Rig</a>.
+</p>
 
-- Node.js 24 or later (required by Portless)
-- pnpm 10.28 or later
+<p>
+  <a href="#quick-start">Quick start</a> ·
+  <a href="#why-happy-2">Why Happy (2)?</a> ·
+  <a href="#how-it-works">How it works</a> ·
+  <a href="#project-components">Project components</a> ·
+  <a href="packages/happy2-server/README.md">Server docs</a>
+</p>
 
-TypeScript is on the v7 release line throughout the workspace.
+</div>
 
-## Commands
+Happy (2) is a self-hosted, Slack-like work and coding app that evolves by
+adopting itself. It gives teams and coding agents a shared home instead of
+scattering work across chat windows, terminals, file browsers, and one-off
+dashboards.
 
-```sh
-pnpm install
-pnpm dev                # Server + web app on stable Portless URLs
-pnpm dev:desktop        # Electron app connected to the server from pnpm dev
-pnpm --dir packages/happy2-gym test # Server end-to-end tests
-pnpm check              # Type-check, test, and build every package
-```
-
-`pnpm build` emits browser files to `packages/happy2-web/dist` and an Electron renderer
-plus main process to `packages/happy2-desktop/dist`. Start the latter after building
-with `pnpm --filter happy2-desktop start`.
-
-`pnpm dev` runs the server and web app through Portless with interleaved logs.
-The main checkout uses `https://happy2.localhost` and
-`https://happy2-api.localhost`; linked worktrees automatically receive unique
-branch-prefixed hostnames. The generated development TOML, database, files,
-keys, and password pepper stay under `.context/dev` in each workspace.
+The same React application runs in the browser and in Electron. A small Fastify
+server provides authentication, durable collaboration state, files, realtime
+updates, and agent execution. The complete server and web app are also bundled
+as one `happy2` package.
 
-With `pnpm dev` running, start `pnpm dev:desktop` in another terminal. It resolves
-the same workspace-specific `happy2-api` URL and passes it to the Electron
-renderer. Portless assigns the renderer an available workspace-specific port;
-set `PORT=xxxx` only when you need to choose it explicitly.
+## Quick start
 
-Start only a local server with `pnpm dev:server`. Without a TOML file it enables
-self-service password registration and login, creates its SQLite database under
-`packages/happy2-server`, and generates durable local JWT keys plus password pepper in
-`packages/happy2-server/.env` on first start. Pass `--config path/to/happy2.toml` (or
-set `HAPPY2_CONFIG`) to override the defaults; copy the example TOML before
-production deployment. See the server package README for deployment and auth
-configuration.
-
-## Publishing
-
-Authenticate with npm once using `pnpm login`, then publish the all-in-one `happy2`
-from a clean, up-to-date `main` branch:
+Happy (2) requires Node.js 24 or later. Start the complete app with one command:
 
 ```sh
-pnpm release 0.1.0
+npx happy2
 ```
 
-The release command also accepts semantic version bumps such as `patch`,
-`minor`, and `major`. It checks the branch, working tree, and npm
-authentication; runs the full workspace check; creates the release commit and
-tag; previews the package; pushes to `main`; and publishes it publicly. If
-publishing is interrupted after the tag is created, rerun the command with the
-exact version to resume safely.
+Open [http://127.0.0.1:3000](http://127.0.0.1:3000) in your browser. Happy (2)
+stores its database, files, generated secrets, agent workspaces, and private Rig
+runtime under `.happy2` in the directory where you start it.
+
+## Why Happy (2)?
+
+- **People and agents share the same workspace.** Conversations, threads,
+  files, approvals, and agent activity live together instead of becoming a pile
+  of disconnected tools.
+- **Self-hosted by design.** Run the complete app with one command and keep its
+  database, files, secrets, agent workspaces, and Rig runtime under your control.
+- **Web and desktop.** Use the same full collaboration experience in a browser
+  or through the Electron app.
+- **Reactive by default.** Realtime events reconcile durable state so focused
+  surfaces stay current without refresh buttons.
+- **Flexible deployment.** The backend can run as an all-in-one server or as a
+  separately deployed authentication service.
+- **Built to adopt itself.** Happy (2)'s own server, state layer, component
+  workbench, browser tests, and coding-agent workflows are part of the product's
+  development loop.
+
+## How it works
+
+Happy (2) keeps the product boundaries explicit:
+
+1. `happy2-server` owns authentication, persistence, files, collaboration, and
+   agent execution.
+2. `happy2-state` turns authenticated HTTP and realtime transports into
+   immutable, independently materialized surface stores.
+3. `happy2-ui` owns the reusable visual system and its cross-browser blueprint
+   coverage.
+4. `happy2-app` composes product state and UI for both the web and Electron
+   entry points.
+
+Local development data stays under `.context/dev` in each workspace, including
+the generated TOML configuration, SQLite database, files, signing keys, and
+password pepper.
+
+## Project components
+
+- **[Happy App](packages/happy2-app)** — Shared React application and product
+  composition.
+- **[Happy UI](packages/happy2-ui)** — Reusable design system, component
+  workbench, and cross-browser visual coverage.
+- **[Happy State](packages/happy2-state)** — Framework-independent client state
+  and realtime reconciliation.
+- **[Happy Web](packages/happy2-web)** — Browser entry point and production web
+  build.
+- **[Happy Desktop](packages/happy2-desktop)** — Electron renderer and desktop
+  main process.
+- **[Happy Server](packages/happy2-server)** — Fastify server, authentication
+  service, persistence, and agent runtime.
+- **[Happy Gym](packages/happy2-gym)** — Isolated black-box server, state, and
+  browser testing environment.
+
+## Development
+
+The repository uses pnpm 10.28 or later. For local development:
 
-## Working convention
+```sh
+pnpm install
+pnpm dev                                 # Server + web app
+pnpm dev:desktop                         # Electron app
+pnpm dev:server                          # Server only
+pnpm --dir packages/happy2-gym test      # End-to-end tests
+pnpm check                               # Format, lint, test, coverage, build
+```
 
-“Sync to main” means to commit the current work, rebase it onto the latest
-`origin/main`, and push the resulting `HEAD` to `main` without force. If `main`
-advances or the push is rejected, fetch and rebase again before retrying. Never
-force-push `main`.
+For production server configuration, authentication modes, and deployment, see
+the [Happy Server documentation](packages/happy2-server/README.md).

package/package.json

@@ -1,7 +1,11 @@
 {
   "name": "happy2",
-  "version": "0.0.5",
+  "version": "0.0.9",
   "description": "Happy (2) desktop web app and server bundle",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/slopus/happy2.git"
+  },
   "bin": {
     "happy2": "packages/happy2-server/bin/happy2.js"
   },
@@ -23,12 +27,40 @@
     }
   },
   "publishConfig": {
-    "access": "public"
+    "access": "public",
+    "registry": "https://registry.npmjs.org"
   },
+  "packageManager": "pnpm@10.28.1",
   "engines": {
     "node": ">=24.0.0",
     "pnpm": ">=10.28.1"
   },
+  "scripts": {
+    "dev": "node scripts/dev.mjs",
+    "dev:web": "pnpm --filter happy2-web dev",
+    "dev:desktop": "node scripts/dev-desktop.mjs",
+    "dev:server": "pnpm --dir packages/happy2-server dev",
+    "start": "node packages/happy2-server/dist/runner.js",
+    "build": "pnpm -r --if-present build && VITE_HAPPY2_SERVER_URL='/' pnpm --filter happy2-web exec vite build --outDir ../happy2-server/dist/web --emptyOutDir false",
+    "test": "pnpm test:coverage-tooling && pnpm -r --if-present test",
+    "test:non-server": "pnpm --parallel --filter happy2-state --filter happy2-ui --filter happy2-app test && pnpm --dir packages/happy2-gym test:playwright",
+    "test:coverage-tooling": "pnpm --dir packages/happy2-server test:coverage-tooling",
+    "coverage:server:unit": "pnpm --dir packages/happy2-server test:coverage",
+    "coverage:server:gym": "pnpm --dir packages/happy2-gym test:server:coverage",
+    "coverage:server": "pnpm test:coverage-tooling && pnpm coverage:server:unit && pnpm coverage:server:gym && tsx packages/happy2-server/tooling/server-coverage/cli.ts check",
+    "coverage:server:baseline": "pnpm test:coverage-tooling && pnpm coverage:server:unit && pnpm coverage:server:gym && tsx packages/happy2-server/tooling/server-coverage/cli.ts baseline",
+    "test:watch": "pnpm -r --parallel --if-present test:watch",
+    "typecheck": "tsc --project tsconfig.json && pnpm -r --if-present typecheck",
+    "format": "oxfmt --write eslint scripts tsconfig.json && pnpm -r --if-present format",
+    "format:check": "oxfmt --check eslint scripts tsconfig.json && pnpm -r --if-present format:check",
+    "lint": "oxlint eslint scripts && pnpm -r --if-present lint",
+    "check:validation": "pnpm format:check && pnpm lint && pnpm --dir packages/happy2-server architecture:check && pnpm typecheck && pnpm test:coverage-tooling && pnpm test:non-server && pnpm coverage:server:unit && pnpm coverage:server:gym",
+    "check": "pnpm check:validation && tsx packages/happy2-server/tooling/server-coverage/cli.ts check && pnpm build",
+    "check:release": "pnpm check:validation && pnpm build",
+    "release": "tsx scripts/release.ts",
+    "prepack": "pnpm run build",
+    "clean": "pnpm -r --if-present clean"
+  },
   "dependencies": {
     "@fastify/cors": "^11.3.0",
     "@fastify/http-proxy": "^11.5.0",
@@ -46,29 +78,15 @@
     "thumbhash": "^0.1.1"
   },
   "devDependencies": {
+    "@eslint/css": "^1.4.0",
+    "@rolldown/plugin-babel": "0.2.3",
     "@types/node": "^26.1.1",
+    "babel-plugin-react-compiler": "1.0.0",
     "concurrently": "^10.0.3",
     "oxfmt": "^0.57.0",
     "oxlint": "^1.73.0",
     "portless": "^0.15.1",
     "tsx": "^4.21.0",
     "typescript": "^7.0.2"
-  },
-  "scripts": {
-    "dev": "node scripts/dev.mjs",
-    "dev:web": "pnpm --filter happy2-web dev",
-    "dev:desktop": "node scripts/dev-desktop.mjs",
-    "dev:server": "pnpm --dir packages/happy2-server dev",
-    "start": "node packages/happy2-server/dist/runner.js",
-    "build": "pnpm -r --if-present build && VITE_HAPPY2_SERVER_URL='/' pnpm --filter happy2-web exec vite build --outDir ../happy2-server/dist/web --emptyOutDir false",
-    "test": "pnpm -r --if-present test",
-    "test:watch": "pnpm -r --parallel --if-present test:watch",
-    "typecheck": "tsc --project tsconfig.json && pnpm -r --if-present typecheck",
-    "format": "oxfmt --write scripts tsconfig.json && pnpm -r --if-present format",
-    "format:check": "oxfmt --check scripts tsconfig.json && pnpm -r --if-present format:check",
-    "lint": "oxlint scripts && pnpm -r --if-present lint",
-    "check": "pnpm format:check && pnpm lint && pnpm typecheck && pnpm test && pnpm build",
-    "release": "tsx scripts/release.ts",
-    "clean": "pnpm -r --if-present clean"
   }
-}
+}

package/packages/happy2-server/README.md

@@ -35,7 +35,7 @@ continues to describe only proxies outside Happy (2); the private loopback hop i
 handled internally.
 
 Without a TOML file, the package starts an `all`-role app on `127.0.0.1:3000`
-with SQLite, self-service password registration, and generated JWT/pepper
+with SQLite, password authentication, and generated JWT/pepper
 material. Database, files, generated secrets, agent workspaces, and Rig runtime
 state live under `.happy2` in the invoking directory. Add `.happy2` to the
 project's ignore rules and preserve it as private application state. The
@@ -47,24 +47,101 @@ package never connects to the user's global Rig daemon. Provide
 `HAPPY2_CONFIG=/path/to/happy2.toml` to override the defaults.
 
 Clients can discover the selected authentication method at `GET /v0/auth/methods`.
-The response includes the server role and one `method` value: `password`,
-`magic_link`, `oidc`, `cloudflare_access`, or `null` in validation-only API mode. Password responses
-also report `signupEnabled`; OIDC responses report `oidcProvider`.
+The response includes the server role, the durable `registration` availability
+(`bootstrap`, `open`, or `closed`), and one `method` value: `password`,
+`magic_link`, `oidc`, `cloudflare_access`, or `null` in validation-only API mode.
+Password responses also report the derived `signupEnabled`; OIDC responses report
+`oidcProvider`.
+
+## Server and user onboarding
+
+Every new database begins with durable server onboarding. `GET /v0/setup/status`
+is the intentionally minimal public routing status. It exposes only the setup
+schema version, phase, and registration availability. An authenticated account
+uses `GET /v0/setup` for the combined server/user step state and exact next route.
+
+Before server onboarding completes, exactly one new authentication account may
+be created across password, magic-link, OIDC, or Cloudflare Access. Magic-link
+requests do not create accounts: the first successfully verified link atomically
+creates the account and claims the bootstrap slot, while other still-pending links
+cannot claim it. The bootstrap account creates the only profile allowed during
+setup and atomically becomes the administrator. All later registration attempts
+are closed while that administrator selects and validates a sandbox provider and
+builds the base agent image.
+
+After the bootstrap profile exists, an administrator calls
+`GET /v0/setup/sandboxProviders`. Each request performs fresh, time-bounded
+Docker and Podman command/engine probes and returns displayable health, version,
+and remediation details. The response always explains that agent code runs
+inside the selected sandbox. It includes `recommendedProviderId` only when
+exactly one provider is healthy; when both are healthy, the administrator must
+choose explicitly.
+
+`POST /v0/setup/selectSandboxProvider` with
+`{ "providerId": "docker" | "podman" }` probes the requested provider again and
+atomically completes both durable provider-selection and validation steps. An
+unhealthy, missing, or timed-out provider is returned as a displayable conflict
+and is not persisted. The provider choice is installation state, not a TOML
+deployment switch. Docker and Podman are discovered from `PATH`; every image
+build, agent sandbox creation, file transfer, terminal attachment, and cleanup
+uses the selected provider boundary after selection and across server restarts.
+
+The next screen reads `GET /v0/setup/baseImages`. It returns the immutable
+Daycare Minimal and Daycare Full definitions plus custom definitions, the
+durable selected/default identifiers, and full progress, current log line,
+retained log, truncation, and failure details for the selected image. Built-ins
+use the display action `Download and build` because they fetch the pinned
+Daycare context; a custom Dockerfile uses `Build`. The administrator starts one
+choice with `POST /v0/setup/selectBaseImage`, passing either
+`{ "builtinKey": "daycare-minimal" | "daycare-full" }` or
+`{ "custom": { "name": "...", "dockerfile": "..." } }`. An existing
+immutable definition is reused. Otherwise the existing leased image worker owns
+the single durable job, so refresh and restart reconstruct the same progress
+screen without process-local state. A failed selected job is retried with
+`POST /v0/setup/retryBaseImageBuild` and an empty object body.
+
+Build completion, ready status, default-image promotion, setup completion,
+audit, and sync evidence commit in one transaction. If promotion fails, that
+transaction rolls back, the previous default remains unchanged, and the same
+selection becomes a visible retryable failure. Registration policy selection
+also revalidates that the setup selection is still the ready default instead of
+trusting completion flags alone. Image progress, failure, and completion use the
+normal `agent-images` plus `setup` SSE/difference areas.
+
+The final server step is
+`POST /v0/setup/chooseRegistrationPolicy` with `{ "enabled": true | false }`.
+It succeeds only for an active server administrator after all preceding durable
+steps are complete. The selection and `server_setup_complete` transition commit
+atomically and become the sole registration policy; there is no TOML signup
+switch. Server-owned provider/image work records its own step transitions rather
+than trusting completion flags from a client.
+
+Per-user onboarding is stored separately. A user records the supported
+`avatar` or `desktop_notifications` outcome with
+`POST /v0/me/updateOnboardingStep`; the outcome is `complete` or `skipped`.
+Avatar completion is rejected until a durable avatar exists. Every transition
+writes normal sync state and emits a realtime reconciliation hint.
 
 ## Profiles and avatar files
 
 Authentication creates an inactive account. `POST /v0/me/createProfile` (with the
 temporary bearer token) creates the product-level User profile—first name,
 optional last name, username, optional email, and optional phone—and activates
-the account. `GET /v0/me` reads the active profile and
+the account. The first setup profile atomically becomes the bootstrap administrator;
+later profiles are members after registration is opened. Successful token-issuance responses include `profileRequired`, so a
+client can enter profile creation without probing a protected product route.
+`GET /v0/me` reads the active profile and
 `POST /v0/me/updateProfile` replaces its editable state. Product routes reject
 accounts that do not yet have an active profile.
 
 `POST /v0/me/uploadAvatarFile` accepts one multipart image after profile
-creation. Its required `visibility` field is `public` or `private`. Images over
-2048px on either side or 10 MB are rejected. The server records the uploader,
-stores an unguessable CUID2-backed file record plus a JPEG file, converts the
-image to a 1024×1024 JPEG, and records a ThumbHash.
+creation. Its required `visibility` field is `public` or `private`; `crop` is a
+JSON object with integer `x`, `y`, `width`, and `height` coordinates in the
+orientation-normalized source image. The crop must be square and remain inside
+the source. Corrupt and animated images, images over 2048px on either side, and
+uploads over 10 MB are rejected. The server auto-orients and extracts the crop,
+then records the uploader, stores an unguessable CUID2-backed file record plus
+an exactly 1024×1024 JPEG, and records a ThumbHash.
 
 `POST /v0/me/updateAvatar` takes a `fileId` and accepts only a public file the
 current user uploaded. Public files are fetched directly with
@@ -94,8 +171,10 @@ Choose exactly one of password, magic-link, OIDC, or Cloudflare Access in `happy
 rejects configurations that enable more than one method. Clients can learn the
 selected method from `GET /v0/auth/methods`.
 
-- Password registration is disabled unless `signup_enabled` is true. Every
-  password has its own random salt; a server-wide password pepper is also used.
+- Password registration follows the durable setup registration policy. The first
+  bootstrap account is allowed once; after setup, the administrator's final
+  open/closed choice applies. Every password has its own random salt; a
+  server-wide password pepper is also used.
 - Magic-link SMTP credentials are exclusively `EMAIL_SMTP_HOST`,
   `EMAIL_SMTP_PORT`, `EMAIL_SMTP_USER`, and `EMAIL_SMTP_PASSWORD` environment
   variables. The configured `redirect_url` should be the desktop app’s link
@@ -171,6 +250,52 @@ Sessions are signed JWTs with a 30-day default lifetime and a stable `sid`.
 expiry. All authenticated requests check the shared SQLite session row, so a
 missing, expired, or revoked row is rejected regardless of JWT validity.
 
+## Server test coverage
+
+Run the complete server coverage gate from the repository root:
+
+```sh
+pnpm coverage:server
+```
+
+The command first tests the coverage tooling, then runs server unit tests and
+the complete non-Playwright Gym suite with Vitest's V8 provider. It validates
+both raw maps against one production-source universe, writes their boolean union,
+prints unit/Gym/combined statement, branch, function, and line percentages side
+by side, lists every uncovered file/line range, and compares exact covered/total
+fractions with `coverage-baseline.json`. Threshold comparisons use integer cross
+multiplication, so displayed percentage rounding cannot hide a regression. The
+same gate runs inside `pnpm check`.
+
+The authoritative universe is every `.ts` file under `sources`, including files
+that no test imports. It excludes `*.test.ts`, `*.spec.ts`, generated `*.d.ts`,
+and files inside `__tests__`, `testing`, `fixtures`, or `__fixtures__` directories.
+Both Vitest configs consume the same TypeScript definition, and the merge command
+fails if either report omits a production file or if the universe is empty.
+
+Reports are generated under:
+
+- `coverage/unit` for `happy2-server` unit tests;
+- `coverage/gym` for Gym integration coverage of the aliased server sources;
+- `coverage/combined` for the union, where a line hit by both suites is counted
+  once.
+
+Each directory contains `coverage.txt`, `index.html`, `lcov.info`,
+`coverage-final.json`, and `coverage-summary.json`. Compare
+`coverage/unit/index.html` with `coverage/gym/index.html` (or their
+`coverage.txt` files) to find behavior that unit tests exercise but Gym does not.
+Statements are executable statement regions, branches are control-flow outcomes,
+functions are callable regions, and lines are source lines containing statements.
+Generated coverage directories are gitignored and removed by `pnpm clean`.
+
+The individual report commands are `pnpm coverage:server:unit` and
+`pnpm coverage:server:gym`. `pnpm coverage:server:baseline` reruns the tooling and
+both suites before replacing the checked-in exact-ratio thresholds with that
+run's measurements. Timing-sensitive Gym paths may require a narrow reviewed
+floor below a sampled measurement. Any deliberate threshold reduction must
+include the measured range and rationale in the same reviewed change;
+improvements do not require a rationale.
+
 ## Collaboration API
 
 The API is HTTP-only. Durable reads and actions use JSON GET/POST endpoints;
@@ -209,6 +334,14 @@ authenticated Unix socket. Configure `[agents]` with the socket, token, Rig
 executable, and server-owned `default_cwd`; clients cannot select filesystem
 paths.
 
+An agent's reasoning effort is durable profile state. Any authenticated user can
+read its current value and the effort levels supported by all of its active Rig
+sessions from `GET /v0/agents/:agentUserId/effort`; only the agent's creator or
+a server administrator can change it with
+`POST /v0/agents/:agentUserId/changeEffort`. A change is applied to every
+existing private Rig session, inherited by sessions created later, reconciled
+again after server restart, and published as a normal `users` sync hint.
+
 The server seeds immutable `Daycare Minimal` and `Daycare Full` definitions from
 the pinned upstream Daycare runtime Dockerfiles. Both use Ubuntu 24.04; Full adds
 the Python, Rust, and Go toolchains. Administrators use
@@ -221,11 +354,20 @@ built-in or custom persisted Dockerfile, and select a ready default. List rows
 include a best-effort 0–100 step percentage and the last non-empty log line;
 detail responses include the Dockerfile, log, and an explicit truncation flag.
 Definitions and content-derived tags never change. Builds are leased in SQLite,
-resume after server restart, use the administrator host's active Docker context,
-and publish durable `agent-images` sync hints over the existing SSE connection.
+resume after server restart without clearing the interrupted attempt's progress
+or log, use the administrator host's selected sandbox provider, and publish
+durable `agent-images` sync hints over the existing SSE connection.
 Docker output is persisted in 500 ms batches so progress remains live without
 turning every process chunk into a SQLite transaction. The latest attempt's log
-is capped at two million characters and retries begin a fresh log.
+is capped at two million characters. An explicit retry begins a fresh log;
+worker restart recovery retains and appends to the interrupted log.
+
+Administrators can assign a ready image to an existing agent with
+`POST /v0/admin/agents/:agentUserId/changeImage`. A real change starts a fresh
+container and Rig session for every connected private workspace, atomically
+switches the durable bindings, and then removes the old containers. Workspace
+directories are preserved. Selecting the current image is a no-op, and changing
+an image is rejected while the agent has pending or running work.
 
 Each agent is rooted at `default_cwd/agents/<agent-user-id>`. Direct/private
 conversations get separate `users/<human-user-id>/home` and
@@ -241,11 +383,12 @@ members of group DMs and channels—including multiple agents in one channel—b
 those conversations remain dormant until mention-based collaboration is
 implemented.
 
-The workspace file API is available to any chat that has exactly one connected
-Rig environment. It resolves the persisted `agent_rig_bindings.cwd` host path,
-which is the directory mounted into that environment at `/workspace`; it never
-creates a separate directory from the chat ID. A current chat member can read
-its file-tree snapshot from `GET /v0/chats/:chatId/workspace`. An unconnected or
+Every public or private channel owns a shared server-side workspace at
+`default_cwd/channels/<chat-id>`, created lazily on its first workspace request.
+A DM with exactly one connected Rig environment instead resolves the
+persisted `agent_rig_bindings.cwd` host path, which is the directory mounted
+into that environment at `/workspace`. A current chat member can read its
+file-tree snapshot from `GET /v0/chats/:chatId/workspace`. An unconnected DM or
 ambiguous chat returns `404`, and public-channel discovery alone never reveals
 workspace contents. Paths are canonical `@pierre/trees` input (directory paths
 end in `/`), absolute server paths are never returned, and directory symlinks

package/packages/happy2-server/dist/cli.js

@@ -1,17 +1,24 @@
 #!/usr/bin/env node
 import { parseArgs } from "node:util";
+import { createClient } from "@libsql/client";
 import { TokenService } from "./modules/auth/tokens.js";
 import { loadRuntimeConfig } from "./modules/config/runtime.js";
-import { Database } from "./modules/database.js";
+import { serverSchemaMigrate } from "./modules/server/serverSchemaMigrate.js";
 import { buildServer } from "./server.js";
 const { values } = parseArgs({
     options: { config: { type: "string" } },
 });
 const configPath = values.config ?? process.env.HAPPY2_CONFIG;
 const { config } = await loadRuntimeConfig(configPath);
-const database = new Database(config.database.url, config.database.authTokenEnv ? process.env[config.database.authTokenEnv] : undefined);
-await database.migrate();
-const app = await buildServer(config, { database, tokens: await TokenService.create(config) });
+const client = createClient({
+    url: config.database.url,
+    authToken: config.database.authTokenEnv ? process.env[config.database.authTokenEnv] : undefined,
+});
+await serverSchemaMigrate(client);
+const app = await buildServer(config, {
+    client,
+    tokens: await TokenService.create(config),
+});
 let cleanupPromise;
 const cleanup = () => {
     cleanupPromise ??= (async () => {
@@ -19,7 +26,7 @@ const cleanup = () => {
             await app.close();
         }
         finally {
-            database.close();
+            client.close();
         }
     })();
     return cleanupPromise;

package/packages/happy2-server/dist/cli.js.map

@@ -1 +1 @@
-{"version":3,"file":"cli.js","sourceRoot":"","sources":["../sources/cli.ts"],"names":[],"mappings":";AAEA,OAAO,EAAE,SAAS,EAAE,MAAM,WAAW,CAAC;AACtC,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAChE,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AACjD,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAE1C,MAAM,EAAE,MAAM,EAAE,GAAG,SAAS,CAAC;IACzB,OAAO,EAAE,EAAE,MAAM,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,EAAE;CAC1C,CAAC,CAAC;AACH,MAAM,UAAU,GAAG,MAAM,CAAC,MAAM,IAAI,OAAO,CAAC,GAAG,CAAC,aAAa,CAAC;AAC9D,MAAM,EAAE,MAAM,EAAE,GAAG,MAAM,iBAAiB,CAAC,UAAU,CAAC,CAAC;AACvD,MAAM,QAAQ,GAAG,IAAI,QAAQ,CACzB,MAAM,CAAC,QAAQ,CAAC,GAAG,EACnB,MAAM,CAAC,QAAQ,CAAC,YAAY,CAAC,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,QAAQ,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,SAAS,CACvF,CAAC;AACF,MAAM,QAAQ,CAAC,OAAO,EAAE,CAAC;AACzB,MAAM,GAAG,GAAG,MAAM,WAAW,CAAC,MAAM,EAAE,EAAE,QAAQ,EAAE,MAAM,EAAE,MAAM,YAAY,CAAC,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;AAC/F,IAAI,cAAyC,CAAC;AAC9C,MAAM,OAAO,GAAG,GAAG,EAAE;IACjB,cAAc,KAAK,CAAC,KAAK,IAAI,EAAE;QAC3B,IAAI,CAAC;YACD,MAAM,GAAG,CAAC,KAAK,EAAE,CAAC;QACtB,CAAC;gBAAS,CAAC;YACP,QAAQ,CAAC,KAAK,EAAE,CAAC;QACrB,CAAC;IACL,CAAC,CAAC,EAAE,CAAC;IACL,OAAO,cAAc,CAAC;AAC1B,CAAC,CAAC;AACF,IAAI,CAAC;IACD,MAAM,GAAG,CAAC,MAAM,CAAC,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC;IACzE,MAAM,IAAI,GAAG,GAAG,EAAE;QACd,KAAK,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;YACpC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;YACrB,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACzB,CAAC,CAAC,CAAC;IACP,CAAC,CAAC;IACF,OAAO,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC;IAC7B,OAAO,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC;IAC7B,OAAO,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,CAAC,CAAC;AAClC,CAAC;AAAC,OAAO,KAAK,EAAE,CAAC;IACb,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IACrB,MAAM,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,YAAqB,EAAE,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC,CAAC;IAC9E,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;AACzB,CAAC"}
+{"version":3,"file":"cli.js","sourceRoot":"","sources":["../sources/cli.ts"],"names":[],"mappings":";AAEA,OAAO,EAAE,SAAS,EAAE,MAAM,WAAW,CAAC;AACtC,OAAO,EAAE,YAAY,EAAE,MAAM,gBAAgB,CAAC;AAC9C,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,iBAAiB,EAAE,MAAM,6BAA6B,CAAC;AAChE,OAAO,EAAE,mBAAmB,EAAE,MAAM,yCAAyC,CAAC;AAC9E,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAE1C,MAAM,EAAE,MAAM,EAAE,GAAG,SAAS,CAAC;IACzB,OAAO,EAAE,EAAE,MAAM,EAAE,EAAE,IAAI,EAAE,QAAQ,EAAE,EAAE;CAC1C,CAAC,CAAC;AACH,MAAM,UAAU,GAAG,MAAM,CAAC,MAAM,IAAI,OAAO,CAAC,GAAG,CAAC,aAAa,CAAC;AAC9D,MAAM,EAAE,MAAM,EAAE,GAAG,MAAM,iBAAiB,CAAC,UAAU,CAAC,CAAC;AACvD,MAAM,MAAM,GAAG,YAAY,CAAC;IACxB,GAAG,EAAE,MAAM,CAAC,QAAQ,CAAC,GAAG;IACxB,SAAS,EAAE,MAAM,CAAC,QAAQ,CAAC,YAAY,CAAC,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,QAAQ,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,SAAS;CAClG,CAAC,CAAC;AACH,MAAM,mBAAmB,CAAC,MAAM,CAAC,CAAC;AAClC,MAAM,GAAG,GAAG,MAAM,WAAW,CAAC,MAAM,EAAE;IAClC,MAAM;IACN,MAAM,EAAE,MAAM,YAAY,CAAC,MAAM,CAAC,MAAM,CAAC;CAC5C,CAAC,CAAC;AACH,IAAI,cAAyC,CAAC;AAC9C,MAAM,OAAO,GAAG,GAAG,EAAE;IACjB,cAAc,KAAK,CAAC,KAAK,IAAI,EAAE;QAC3B,IAAI,CAAC;YACD,MAAM,GAAG,CAAC,KAAK,EAAE,CAAC;QACtB,CAAC;gBAAS,CAAC;YACP,MAAM,CAAC,KAAK,EAAE,CAAC;QACnB,CAAC;IACL,CAAC,CAAC,EAAE,CAAC;IACL,OAAO,cAAc,CAAC;AAC1B,CAAC,CAAC;AACF,IAAI,CAAC;IACD,MAAM,GAAG,CAAC,MAAM,CAAC,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC;IACzE,MAAM,IAAI,GAAG,GAAG,EAAE;QACd,KAAK,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;YACpC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;YACrB,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;QACzB,CAAC,CAAC,CAAC;IACP,CAAC,CAAC;IACF,OAAO,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC;IAC7B,OAAO,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC;IAC7B,OAAO,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,CAAC,CAAC;AAClC,CAAC;AAAC,OAAO,KAAK,EAAE,CAAC;IACb,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IACrB,MAAM,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,YAAqB,EAAE,EAAE,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC,CAAC;IAC9E,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;AACzB,CAAC"}

package/packages/happy2-server/dist/index.d.ts

@@ -5,20 +5,24 @@ export { defaultConfig } from "./modules/config/defaults.js";
 export { loadConfig, parseConfig } from "./modules/config/loader.js";
 export { startStandaloneHappy2, type StandaloneHappy2 } from "./standalone.js";
 export type { ServerConfig } from "./modules/config/type.js";
-export { Database, type RequestMetadata, type User } from "./modules/database.js";
-export { CollaborationRepository } from "./modules/collaboration/repository.js";
-export { AutomationRepository } from "./modules/automation/repository.js";
-export { IntegrationRepository } from "./modules/integrations/repository.js";
+export type { RequestMetadata } from "./modules/auth/types.js";
+export type { User } from "./modules/user/types.js";
+export { createDatabase, type DrizzleExecutor } from "./modules/drizzle.js";
+export { accountCreatePassword } from "./modules/auth/accountCreatePassword.js";
+export { sessionCreate } from "./modules/auth/sessionCreate.js";
+export { serverSchemaMigrate } from "./modules/server/serverSchemaMigrate.js";
+export { userCreateProfile } from "./modules/user/userCreateProfile.js";
+export { syncInitialize } from "./modules/sync/syncInitialize.js";
 export { AesGcmSecretProtector } from "./modules/integrations/secrets.js";
 export { NodeWebhookTransport } from "./modules/integrations/transport.js";
 export * from "./modules/integrations/types.js";
-export { OperationsRepository } from "./modules/operations/repository.js";
 export * from "./modules/operations/types.js";
 export { FileStorage, type FileStorageFileSystem } from "./modules/files/storage.js";
-export * from "./modules/collaboration/types.js";
+export * from "./modules/chat/types.js";
 export * from "./modules/realtime/index.js";
+export * from "./modules/setup/index.js";
+export * from "./modules/sandbox/index.js";
+export { userOnboardingUpdateStep } from "./modules/user/userOnboardingUpdateStep.js";
 export * from "./modules/workspace/index.js";
-export { LocalAgentDockerRuntime } from "./modules/agents/index.js";
-export type { AgentContainerInput, AgentDockerRuntime, AgentImageBuildInput, AgentImageBuildOptions, AgentImageBuildUpdate, } from "./modules/agents/index.js";
 export { buildServer } from "./server.js";
 //# sourceMappingURL=index.d.ts.map

package/packages/happy2-server/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../sources/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,KAAK,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAC3E,OAAO,EAAE,oBAAoB,EAAE,KAAK,oBAAoB,EAAE,MAAM,2BAA2B,CAAC;AAC5F,OAAO,EAAE,4BAA4B,EAAE,MAAM,iCAAiC,CAAC;AAC/E,OAAO,EAAE,aAAa,EAAE,MAAM,8BAA8B,CAAC;AAC7D,OAAO,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACrE,OAAO,EAAE,qBAAqB,EAAE,KAAK,gBAAgB,EAAE,MAAM,iBAAiB,CAAC;AAC/E,YAAY,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAC7D,OAAO,EAAE,QAAQ,EAAE,KAAK,eAAe,EAAE,KAAK,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAClF,OAAO,EAAE,uBAAuB,EAAE,MAAM,uCAAuC,CAAC;AAChF,OAAO,EAAE,oBAAoB,EAAE,MAAM,oCAAoC,CAAC;AAC1E,OAAO,EAAE,qBAAqB,EAAE,MAAM,sCAAsC,CAAC;AAC7E,OAAO,EAAE,qBAAqB,EAAE,MAAM,mCAAmC,CAAC;AAC1E,OAAO,EAAE,oBAAoB,EAAE,MAAM,qCAAqC,CAAC;AAC3E,cAAc,iCAAiC,CAAC;AAChD,OAAO,EAAE,oBAAoB,EAAE,MAAM,oCAAoC,CAAC;AAC1E,cAAc,+BAA+B,CAAC;AAC9C,OAAO,EAAE,WAAW,EAAE,KAAK,qBAAqB,EAAE,MAAM,4BAA4B,CAAC;AACrF,cAAc,kCAAkC,CAAC;AACjD,cAAc,6BAA6B,CAAC;AAC5C,cAAc,8BAA8B,CAAC;AAC7C,OAAO,EAAE,uBAAuB,EAAE,MAAM,2BAA2B,CAAC;AACpE,YAAY,EACR,mBAAmB,EACnB,kBAAkB,EAClB,oBAAoB,EACpB,sBAAsB,EACtB,qBAAqB,GACxB,MAAM,2BAA2B,CAAC;AACnC,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../sources/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,KAAK,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAC3E,OAAO,EAAE,oBAAoB,EAAE,KAAK,oBAAoB,EAAE,MAAM,2BAA2B,CAAC;AAC5F,OAAO,EAAE,4BAA4B,EAAE,MAAM,iCAAiC,CAAC;AAC/E,OAAO,EAAE,aAAa,EAAE,MAAM,8BAA8B,CAAC;AAC7D,OAAO,EAAE,UAAU,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACrE,OAAO,EAAE,qBAAqB,EAAE,KAAK,gBAAgB,EAAE,MAAM,iBAAiB,CAAC;AAC/E,YAAY,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAC7D,YAAY,EAAE,eAAe,EAAE,MAAM,yBAAyB,CAAC;AAC/D,YAAY,EAAE,IAAI,EAAE,MAAM,yBAAyB,CAAC;AACpD,OAAO,EAAE,cAAc,EAAE,KAAK,eAAe,EAAE,MAAM,sBAAsB,CAAC;AAC5E,OAAO,EAAE,qBAAqB,EAAE,MAAM,yCAAyC,CAAC;AAChF,OAAO,EAAE,aAAa,EAAE,MAAM,iCAAiC,CAAC;AAChE,OAAO,EAAE,mBAAmB,EAAE,MAAM,yCAAyC,CAAC;AAC9E,OAAO,EAAE,iBAAiB,EAAE,MAAM,qCAAqC,CAAC;AACxE,OAAO,EAAE,cAAc,EAAE,MAAM,kCAAkC,CAAC;AAClE,OAAO,EAAE,qBAAqB,EAAE,MAAM,mCAAmC,CAAC;AAC1E,OAAO,EAAE,oBAAoB,EAAE,MAAM,qCAAqC,CAAC;AAC3E,cAAc,iCAAiC,CAAC;AAChD,cAAc,+BAA+B,CAAC;AAC9C,OAAO,EAAE,WAAW,EAAE,KAAK,qBAAqB,EAAE,MAAM,4BAA4B,CAAC;AACrF,cAAc,yBAAyB,CAAC;AACxC,cAAc,6BAA6B,CAAC;AAC5C,cAAc,0BAA0B,CAAC;AACzC,cAAc,4BAA4B,CAAC;AAC3C,OAAO,EAAE,wBAAwB,EAAE,MAAM,4CAA4C,CAAC;AACtF,cAAc,8BAA8B,CAAC;AAC7C,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC"}