@salsita-ai/sdk 0.50.0-develop.ae9a830ef0 → 0.50.0-develop.afbc5157e1

package/dist/docs/phoenix/migration-guide.mdx

@@ -251,8 +251,21 @@ rm src/frontend/frontend.tsx
 # Remove empty domain/frontend folders after moving all files
 rmdir src/domain/implementation src/domain/data src/domain
 rmdir src/frontend/systems/transformers src/frontend/systems src/frontend/ui src/frontend/admin-pages src/frontend
+
+# Remove the root TypeScript settings (sync writes the file again)
+rm tsconfig.json
 ```
 
+With the application-spec pipeline (`phoenix.applicationFlow` in `package.json`; see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), the project's TypeScript settings are generated into `.phoenix/tsconfig.json`. Sync writes the root `tsconfig.json` only into a project that has none, as a single line that extends them:
+
+```json
+{ "extends": "./.phoenix/tsconfig.json" }
+```
+
+A root `tsconfig.json` from the old multi-folder template, or one written by hand, stays as it is and does not pick up the generated settings or the global `phx` types in `.phoenix/globals.d.ts`, so `pnpm ts:check` fails. Delete it, or replace its content with the line above, before the first sync.
+
+With the application-spec pipeline (see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), `eslint.config.js` and `prettier.config.js` are the project's. Sync replaces a file earlier SDK versions generated, the one under the "Auto-generated file. Do not modify this file manually." header that re-exports `eslintrc` or `prettierrc`, with a file that re-exports the same configuration from `@salsita-ai/sdk/common/eslint` or `@salsita-ai/sdk/common/prettier`, and writes that file into a project that has none. A file of your own stays as it is, and editors, `phoenix check` and `phoenix fix` use it; make sure it imports only packages the project still depends on, or delete it before the first sync. Without the file, `phoenix check` and `phoenix fix` use the SDK's configuration. The legacy pipeline rewrites both files on every sync.
+
 ### 10. Create Mocks (Optional)
 
 If you have mock files, move them to `mocks/`:
@@ -279,7 +292,7 @@ This will:
 
 Other useful commands:
 
-- `pnpm phoenix sync` - Sync dependencies in package.json
+- `pnpm phoenix sync` - Regenerate the generated code and project files
 - `pnpm phoenix gen` - Regenerate project files
 - `pnpm phoenix dev` - Start development server with hot reload
 - `pnpm phoenix deployment:prepare` - Prepare for deployment
@@ -339,33 +352,32 @@ grep -r "from '\.\/" src/
 
 **Error:** Changes to `.phoenix/` files are overwritten
 
-**Solution:** Never commit `.phoenix/` contents. Add to `.gitignore`:
+**Solution:** Keep generated files out of version control. Application-spec projects can commit their project-owned `.phoenix/workspace/` records; sync writes the appropriate ignore rules. Remove any custom rule that ignores the entire `.phoenix/` directory if you want to version those records. See [Project Structure](?path=/docs/phoenix-project-structure--docs#markers-for-partial-auto-generation) for the managed block and ownership rules.
 
-```
-.phoenix/
-```
-
-If you accidentally modified generated files, delete and regenerate:
+If you accidentally modified generated files, clean and regenerate them with the CLI. In application-spec projects this preserves workspace records:
 
 ```bash
-rm -rf .phoenix/
+pnpm phoenix clean
 pnpm phoenix build
 ```
 
+The legacy pipeline has no workspace-preservation contract; see [Phoenix CLI](?path=/docs/phoenix-phoenix-cli--docs#phoenix-clean).
+
 **Note:** Mock templates are no longer auto-applied on Editor load. Users must manually select and apply templates (changed in v0.36.0).
 
 ### .gitignore Conflicts
 
 **Error:** Custom gitignore entries disappear after Phoenix update
 
-**Solution:** Place custom entries between Phoenix markers:
+**Solution:** Place custom entries outside the Phoenix markers. Sync replaces the generated block and preserves everything outside it:
 
 ```gitignore
-# phoenix-start
+# ===== BEGIN PHOENIX AUTO-GENERATED =====
 # Auto-generated by Phoenix - DO NOT EDIT
-.phoenix/
+**/.phoenix/*
+!**/.phoenix/workspace/
 .env.generated
-# phoenix-end
+# ===== END PHOENIX AUTO-GENERATED =====
 
 # Your custom entries below
 my-custom-folder/
@@ -390,7 +402,7 @@ pnpm install
 
 1. Run type check: `pnpm ts:check`
 2. Update any broken type imports
-3. Ensure `tsconfig.json` paths are correct (auto-generated by Phoenix)
+3. With the application-spec pipeline (`phoenix.applicationFlow`; see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), check that the root `tsconfig.json` is the one-line file that extends `.phoenix/tsconfig.json` (see [step 9](#9-remove-auto-generated-files))
 
 ## Checklist
 
@@ -427,19 +439,19 @@ Use this checklist to verify migration completeness:
 - [ ] Configurator renders correctly
 - [ ] Admin interface works
 - [ ] All imports updated to new paths
-- [ ] Node 24 and pnpm v10 installed
+- [ ] Node 24 and a package manager installed
 
 ## Removed Files
 
 The following files are no longer needed - they are auto-generated by the CLI:
 
-| File                        | Replacement                                  |
-| --------------------------- | -------------------------------------------- |
-| `src/domain/domain.ts`      | Auto-generated in `.phoenix/domain.ts`       |
-| `src/frontend/frontend.tsx` | Auto-generated in `.phoenix/configurator.ts` |
-| `tsconfig.json`             | Auto-generated by CLI                        |
-| `eslint.config.js`          | Auto-generated by CLI                        |
-| `prettier.config.js`        | Auto-generated by CLI                        |
+| File                        | Replacement                                                                                                                                                                                                                                                    |
+| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `src/domain/domain.ts`      | Auto-generated in `.phoenix/domain.ts`                                                                                                                                                                                                                         |
+| `src/frontend/frontend.tsx` | Auto-generated in `.phoenix/configurator.ts`                                                                                                                                                                                                                   |
+| `tsconfig.json`             | Delete before the first sync; with the application-spec pipeline, sync writes a one-line file that extends `.phoenix/tsconfig.json`                                                                                                                            |
+| `eslint.config.js`          | With the application-spec pipeline, sync replaces the file earlier SDK versions generated with one that re-exports the SDK's ESLint configuration, or writes one when there is none; a file of your own stays (see [step 9](#9-remove-auto-generated-files))   |
+| `prettier.config.js`        | With the application-spec pipeline, sync replaces the file earlier SDK versions generated with one that re-exports the SDK's Prettier configuration, or writes one when there is none; a file of your own stays (see [step 9](#9-remove-auto-generated-files)) |
 
 ## Builder Options Moved to YAML
 
@@ -473,7 +485,7 @@ Update imports to use these globals instead of importing from packages directly.
 ## Environment Requirements
 
 - Node 24
-- pnpm v10
+- A package manager; the commands in this guide use pnpm
 - `RESOURCES_URL` is an optional frontend environment variable; in local development it defaults to the Vite dev server at `http://localhost:5173`
 
 ## Next Steps

package/dist/docs/phoenix/phoenix-cli.mdx

@@ -14,7 +14,9 @@ The Phoenix CLI (`phoenix` command) is the unified tool for all configurator dev
 
 ## Starting a New Project
 
-`phoenix init [folder]` starts a configurator project in `[folder]` (default: the working directory):
+The SDK and its CLI run on Node.js 22.13 or newer, the range declared in `engines.node` of `@salsita-ai/sdk`. On an older Node.js, `phoenix` stops before it runs a command, names the running version and the required range, and exits with a non-zero code. The legacy binaries run no such check; package managers warn about the range when the SDK is installed.
+
+`phoenix init [folder]` starts a configurator project in `[folder]` (default: the working directory). The project installs with any package manager. The commands on this page use pnpm; with npm, run `npm install` and `npx phoenix sync`, with Yarn `yarn phoenix sync`, with Bun `bunx phoenix sync`:
 
 ```bash
 npx -p @salsita-ai/sdk@canary phoenix init my-configurator
@@ -28,12 +30,41 @@ pnpm phoenix dev
 `phoenix init`:
 
 1. Refuses to run when a `spec/` folder already exists, so it never touches an existing project.
-2. Writes a `package.json` that depends on the CLI's SDK version when the folder has none. An existing `package.json` is kept, as long as it depends on the SDK.
+2. Writes a `package.json` when the folder has none, and an existing one is kept, as long as it depends on the SDK. Either way, `package.json` gains the entries it lacks, and an entry it already has stays as it is:
+   - the CLI's SDK version, in a new `package.json`;
+   - every package the SDK requires as a peer, at the version [`phoenix deps`](#phoenix-deps) writes: the lowest of the SDK's range, with the `@types/*` packages in `devDependencies`. A peer the project declares in any dependency field counts, whatever its version. `@clerk/clerk-react` is not among them, because the starter spec does not set `useClerk`;
+   - `eslint` and `prettier` in `devDependencies`, at the versions the SDK runs itself, so an editor formats and lints with the same versions as `phoenix check`.
+
+   With these, the install gives the project everything `phoenix dev`, `build` and `check` need. `init` writes no `packageManager` field and no package-manager settings: a project that installs with pnpm 11 adds the settings in [Package manager](?path=/docs/phoenix-project-structure--docs#package-manager) itself.
+
 3. Adds the `dev`, `build`, `deploy`, `check` and `fix` scripts to `package.json` (see [Project Scripts](#project-scripts)). A script the project already has under one of those names keeps its command.
 4. Writes a starter spec (`spec/application.yaml`, `spec/configurator.yaml`) with one resizable, recolorable box, and switches `package.json` to the application-spec pipeline.
-5. Writes `pnpm-workspace.yaml` with the pnpm settings the first install needs: the build scripts of the SDK's dependencies are allowed or denied, and `@salsita-ai/*` packages are exempt from pnpm's minimum release age. A project inside a pnpm monorepo gets no file; the workspace root holds these settings.
 
-It asks nothing, writes no `.env` and contacts no server. `phoenix sync` then generates every other project file, including the agent skills described in [Project Structure](?path=/docs/phoenix-project-structure--docs). The `.gitignore` is among them only when the folder is inside a git repository, so run `git init` before the first sync, or sync again after it.
+The next steps it prints use the package manager you ran it with, or name none when it cannot tell. It asks nothing, writes no `.env` and contacts no Phoenix server. It does send the operational telemetry described below unless telemetry is disabled. `phoenix sync` then generates every other project file, as described in [Project Structure](?path=/docs/phoenix-project-structure--docs). The `.gitignore` is among them only when the folder is inside a git repository, so run `git init` before the first sync, or sync again after it.
+
+### CLI telemetry
+
+Operational CLI telemetry is enabled by default. Recognized top-level `phoenix` commands send lifecycle events directly to Amplitude's US ingestion endpoint. Current commands record both started and completed events. Legacy commands retain their existing exit behavior, so completion may be absent when they exit directly, including when legacy `dev` stops.
+
+For `phoenix dev`, `cli_dev_server_ready` records that startup finished and the server is listening; it does not prove that a browser connected or the application works. Its `duration_ms` measures startup time. With the current application-spec pipeline, the command stays open until its existing shutdown path emits completion, whose duration covers the whole run. A normal stop is not evidence of abandonment, and a missing completion (for example after a forced kill) means the outcome is unknown.
+
+Aliases are recorded as their canonical command names. Delivery failures never change the command result, and the CLI stops waiting for each delivery after one second.
+
+Before a successful `phoenix login`, telemetry uses only random anonymous identifiers. Failed login attempts remain anonymous. The CLI stores an installation UUID, work-session UUID and last activity time in `~/.phoenix/telemetry.json`; a work session continues while commands occur less than 30 minutes apart.
+
+After a successful login, the login completion and later commands from that installation include the stable authenticated builder user ID and the internal workspace UUID. Amplitude uses the unchanged installation ID to associate the earlier anonymous command path with that user. A later successful login replaces the stored user and workspace association. The state file never contains a login token, email address, machine fingerprint, project path or project content. Because the installation ID belongs to the operating-system user profile, people who share that profile also share its command history and latest association.
+
+The events contain only:
+
+- schema version, source (`cli`) and command name;
+- unique event and command-attempt IDs;
+- occurrence time, phase, safe outcome/failure category and duration;
+- SDK version, traffic classification (`unknown` before authentication, `general` after it) and work-session ID;
+- after successful login only, the authenticated builder user ID and workspace UUID.
+
+The CLI never sends raw arguments, local paths, environment values, credentials, source/specification content, URLs, free text or raw error messages. The shipped Amplitude ingestion API key is public and only selects the destination project; it grants no read or administrative access. Events sent by a public client can be forged and are observations, not authoritative proof of deployment or server state.
+
+Set `PHOENIX_TELEMETRY_DISABLED=1` to opt out. The opted-out CLI neither sends telemetry nor creates or updates the state file. `PHOENIX_TELEMETRY_FILE` overrides the state path for tests and other isolated environments.
 
 ### Which project `phoenix dev` develops in
 
@@ -135,24 +166,37 @@ The same streams are available in the editor's **Logs** sidebar panel with per-s
 
 ### `phoenix check`
 
-Runs all code quality checks in sequence:
+Runs all code quality checks in sequence, with the TypeScript compiler, ESLint and Prettier the SDK installs as its own dependencies, so the versions in the project's `package.json` do not decide them:
 
-1. **TypeScript** — Type checking with `tsc`
-2. **ESLint** — Linting rules
-3. **Prettier** — Code formatting
+1. **TypeScript** — Type checking with the SDK's `tsc` (TypeScript 7), with the project's root `tsconfig.json`, or with `.phoenix/tsconfig.json` when the project has none (see [Project Structure](?path=/docs/phoenix-project-structure--docs#root-level-files))
+2. **ESLint** — Linting rules, over `src/`; a project with no files there passes. ESLint uses the project's `eslint.config.js`, or the SDK's configuration when the project has none; its type-aware rules then read the same TypeScript configuration as the type check
+3. **Prettier** — Code formatting, with the project's Prettier configuration, or the SDK's when the project has none
 
 ### `phoenix fix`
 
-Auto-fixes ESLint and Prettier issues. Equivalent to running `eslint --fix` and `prettier --write` together.
+Auto-fixes ESLint and Prettier issues, with the same tools and configurations as `phoenix check`. Equivalent to running the SDK's `eslint --fix` and `prettier --write` together.
 
 ## Environment Variables
 
-When you run `deployment:prepare-local` or `deployment:prepare`, the CLI communicates with the Phoenix server, which generates environment variables and writes them to `.env.generated`.
+When you run `deployment:prepare-local` or `deployment:prepare`, the CLI communicates with the Phoenix server, which generates environment variables and writes them to `.env.generated`. `phoenix dev` does the same for its development deployment when it starts.
+
+### The generated env file
+
+A project has one generated env file. Phoenix keeps it in `.phoenix/`, as `.phoenix/.env.generated`, unless the project has a `.env.generated` in its root, which then is the one that counts.
+
+- `phoenix dev` reads and writes `.phoenix/.env.generated` in a project without a root `.env.generated`, and creates no file in the project root. In a project that has a root `.env.generated`, it reads and writes that file and `.phoenix/.env.generated` is not used.
+- The deployment and environment commands (`deployment:prepare`, `deployment:prepare-dev`, `deployment:prepare-local`, `deployment:build-envs` and the others with an `--outFile` option) write `.env.generated` in the project root unless `--outFile` or `OUT_FILE` names another file. Deploy pipelines read it there. Once one of them has written it, `phoenix dev` and `phoenix build` use it.
+- Everything that reads environment variables follows the same rule: the root `.env.generated` when it exists, otherwise `.phoenix/.env.generated`. The two files are never merged.
+- `phoenix clean` removes the generated contents of `.phoenix/`, including `.phoenix/.env.generated`; the next `phoenix dev` prepares the development deployment again. A root `.env.generated` stays.
+- `phoenix dev` starts on the deployment the file names, and prepares a new one when the file was written for another project, environment or server, when the spec registers something on the server the deployment was not prepared with (the domain model, the published data schema, the auth hook, the roles that may create configurations, or the assistant), and on `--force`. A running `phoenix dev` does not prepare again after such a change: it logs an error that asks for a restart.
+- Asset contents do not trigger preparation. After changing uploaded assets, restart with `phoenix dev --force` to prepare and upload them again.
+
+This holds for a project on the application-spec pipeline. In a project on the legacy pipeline (see [Current and legacy project tooling](#current-and-legacy-project-tooling)), `phoenix dev` always reads and writes `.env.generated` in the project root.
 
 ### Data Flow
 
 ```
-spec/application.yaml → Server prepares environment → CLI writes .env.generated → Frontend/Webhooks read it
+spec/application.yaml → Server prepares environment → CLI writes the generated env file → Frontend/Webhooks read it
 ```
 
 ### Project Scripts
@@ -167,13 +211,13 @@ spec/application.yaml → Server prepares environment → CLI writes .env.genera
 | `check`  | `phoenix check`  | Run all checks (TypeScript, ESLint, Prettier) |
 | `fix`    | `phoenix fix`    | Auto-fix lint and formatting issues           |
 
-The scripts are yours: change, rename or delete them, and add your own. `phoenix sync` and `phoenix clean` leave the `scripts` section of `package.json` as it is, so they add no script, restore none you removed and remove none. Every CLI command also runs without a script, as `pnpm phoenix <command>`.
+The scripts are yours: change, rename or delete them, and add your own. `phoenix sync` and `phoenix clean` leave the `scripts` section of `package.json` as it is, so they add no script, restore none you removed and remove none. Every CLI command also runs without a script, through your package manager: `pnpm phoenix <command>`, `npx phoenix <command>`, `yarn phoenix <command>` or `bunx phoenix <command>`.
 
 A project may have other scripts than these five, such as `sync`, `test` or `verify:fix`; they are its own and stay as they are. All of this holds for a project on the application-spec pipeline, which `phoenix init` selects. In a project on the legacy pipeline (see [Current and legacy project tooling](#current-and-legacy-project-tooling)), `phoenix sync` and `phoenix clean` write their own set of scripts into `package.json` on every run, over scripts of the same name.
 
 ### Server-Generated Variables
 
-These are automatically computed by the server and written to `.env.generated`:
+These are automatically computed by the server and written to the generated env file:
 
 | Variable                         | Purpose                                                 |
 | -------------------------------- | ------------------------------------------------------- |
@@ -222,7 +266,7 @@ A build pipeline that receives the source archive of a [`phoenix deploy`](#phoen
 - it refuses an archive over 200 MB, one that extracts to more than 1 GB, or one with more than 100,000 files;
 - it refuses links, special files, absolute paths, paths that leave the folder, names with control characters, and entries that repeat or collide with an earlier one;
 - it refuses an archive it cannot read to the end, such as a truncated upload;
-- it extracts only project files and reports the entries it left out, including the optional `conversation.log` that deploy keeps in the private archive for review.
+- it extracts only project files and reports the entries it left out, including the optional `conversation.log`, the `.phoenix/workspace/` records and the `docs/` documents that deploy keeps in the private archive for review.
 
 `<folder>` must be new or empty. When the command refuses an archive, it removes the folder, so a partly extracted project is never built.
 
@@ -261,15 +305,15 @@ A development environment keeps the AI assistant's conversation when the assista
 Environment variables are resolved in this order (highest to lowest priority):
 
 1. Process environment variables (shell)
-2. `.env.generated` (created by deployment commands)
+2. [The generated env file](#the-generated-env-file): `.env.generated` in the project root when the project has one, otherwise `.phoenix/.env.generated`
 3. `.env` (manual overrides)
 
 ### Generated Config Files
 
 The Phoenix CLI auto-generates config files that read these variables:
 
-- `src/frontend.config.ts` — Frontend runtime config
-- `src/webhooks.config.ts` — Webhook runtime config
+- `.phoenix/frontend.config.ts` — Frontend runtime config
+- `.phoenix/webhooks.config.ts` — Webhook runtime config
 
 ## Development Workflow
 
@@ -277,28 +321,38 @@ The Phoenix CLI auto-generates config files that read these variables:
 
 Starts the full development environment: Vite dev server, development webhook tunnel, domain-cli watcher, and editor WebSocket server.
 
+When it runs as the signed-in Studio user, `phoenix dev` starts in **agent mode**, for projects an AI agent builds. The editor still runs, so the inspect commands work, but its UI is hidden and the preview shows only the configurator. Every dev error that would show a detailed error page or Vite's error overlay shows an "Agent at work" screen instead, with no error details. The details go to the terminal and `.phoenix/phoenix-dev.log`. A corner badge shows when the latest change didn't build, and the page recovers by itself after the next successful rebuild. With a development key, `--local` or an offline persistence mode, dev keeps the visible editor and the detailed error pages. Agent mode comes from the credentials alone: `--editor` and `--no-editor`, or `ENABLE_EDITOR` in the environment or `.env`, keep their meaning on every route, the editor or the configurator alone with the detailed error pages; the value development preparation writes into the generated env file does not count for dev. `phoenix sync`, `build` and `clean` keep an agent-mode page that dev generated unless the flag or `ENABLE_EDITOR` in the environment or `.env` says otherwise; without one they choose as before, with the generated env file's `ENABLE_EDITOR` ahead of `.env`.
+
 | Flag                    | Env Variable       | Default              | Description                                                                     |
 | ----------------------- | ------------------ | -------------------- | ------------------------------------------------------------------------------- |
 | `--workspace`           | —                  | from `.phoenix.json` | Override workspace mode                                                         |
-| `--editor`              | `ENABLE_EDITOR`    | `true`               | Enable editor file generation                                                   |
+| `--editor`              | `ENABLE_EDITOR`    | see agent mode above | Show the editor (`true`) or the configurator alone (`false`)                    |
 | `--editorWsPort`        | `EDITOR_WS_PORT`   | `3020`               | Editor WebSocket port                                                           |
 | `--debug`               | `DEBUG`            | `false`              | Verbose logging                                                                 |
 | `--projectSlug`         | `PROJECT_SLUG`     | `local`              | Project slug                                                                    |
 | `--environmentSlug`     | `ENVIRONMENT_SLUG` | package.json name    | Environment slug                                                                |
 | `--withLingui`          | `WITH_LINGUI`      | `false`              | Enable i18n extraction/compilation and watch i18n sources during dev            |
 | `--persistence`         | `PERSISTENCE_MODE` | `server`             | Persistence mode                                                                |
-| `--force` / `-f`        | `FORCE_REBUILD`    | `false`              | Force full rebuild, skip cache                                                  |
+| `--force` / `-f`        | `FORCE_REBUILD`    | `false`              | Force full rebuild, skip cache, and prepare the development deployment again    |
 | `--serverUrl`           | `SERVER_URL`       | the region's server  | Phoenix server URL                                                              |
 | `--region`              | `PHOENIX_REGION`   | `eu`                 | Region of the signed-in workspace, used when no server URL is set               |
 | `--skipUpload` / `--su` | `SKIP_UPLOAD`      | `false`              | Skip the S3 asset upload when the development deployment is prepared at startup |
 
+With the application-spec pipeline, `phoenix dev` creates an empty `src/` folder when the project has none, so that it rebuilds when the first source file, such as `src/webhooks/index.ts`, is added.
+
+By default, with the application-spec pipeline, `phoenix dev` bootstraps missing compiled catalogs for every configured locale at startup, so a fresh project can start without a prior sync. It compiles existing `.po` translations as they are and extracts a locale only when its `.po` source is also missing. Existing compiled catalogs and `.po` sources stay unchanged. New or changed messages still need `phoenix sync` or continuous updates enabled by `--withLingui` or `WITH_LINGUI=true`.
+
+The SDK's own Lingui CLI uses the configuration generated in `.phoenix/.linguirc`, both for `--withLingui` and when `phoenix sync` and `phoenix build` extract and compile the catalogs; see [Root Level Files](?path=/docs/phoenix-project-structure--docs#root-level-files). The dev server and `phoenix build` compile the Lingui macros (`msg`, `t`, `Trans` and the others, imported from `@lingui/core/macro`, `@lingui/react/macro` or `@lingui/macro`) with the SDK's own Lingui macro plugin and the same configuration, so the project needs neither `babel-plugin-macros` nor `@lingui/macro` for them. Babel macros of other packages are not compiled.
+
 In `server` persistence mode the project comes from `--projectSlug`, `PROJECT_SLUG` or `project` in the spec, and the credential from `DEVELOPMENT_KEY` or the `phoenix login` sign-in; see [Starting a New Project](#starting-a-new-project). When signed in, the environment is always your own development environment and `--environmentSlug` is ignored.
 
 The dev server watches for changes in:
 
 - `spec/**/*.yaml` — Domain specification files
 - `src/**/*.{ts,tsx,yaml,yml,json,html,css}` — Source files
-- `.env`, `.env.generated` — Environment files (triggers full Vite restart)
+- `package.json` — Root dependency declarations; changes recheck the SDK's peers. A mismatch is reported without stopping dev, and correcting the manifest triggers another rebuild. Install changed dependencies with your package manager; changes to installed packages can still require restarting dev.
+- `.env` — Environment file; a change restarts the Vite dev server
+- `.env.generated`, `.phoenix/.env.generated` — Generated env files; a change rebuilds the project files. Only a file that exists when `phoenix dev` starts is watched: a root `.env.generated` that a deployment command creates while dev runs is not watched; restart `phoenix dev` to use it.
 
 When linked SDK packages are detected (`phoenix link`), changes to SDK dist files are also watched.
 
@@ -313,7 +367,11 @@ Restart the application after fixing either failure; a subscriber or generation
 observed the attempted update.
 
 Domain-model changes are not applied live yet. Phoenix rejects them with a restart-required
-diagnostic so the mounted application cannot observe a new model with old configuration data. Other
+diagnostic so the mounted application cannot observe a new model with old configuration data. With
+server persistence, `phoenix dev` logs an error that asks for its own restart, because the
+development deployment keeps the schema it was prepared with until `phoenix dev` starts again and
+prepares it. After the restart, open the preview address it prints: a tab whose address has `?cid=`
+loads a configuration saved with the earlier model, which the new model rejects. Other
 generated bootstrap, admin, data, environment, and host-integration surfaces should also be treated
 as restart-required unless their feature documentation explicitly states live-update support.
 
@@ -380,7 +438,7 @@ Set initial values from a local production build with roughly 5–10% headroom t
 
 ### `phoenix clean`
 
-Removes all build artifacts (`.phoenix/`, `node_modules/`), reinstalls dependencies, and rebuilds all generated files from scratch. Use this when:
+Removes generated output and regenerates the project files. In application-spec projects it preserves project-owned records under `.phoenix/workspace/`, installs nothing and leaves `node_modules/` as it is; to reinstall too, delete `node_modules/` and install with your package manager. In a project on the legacy pipeline (see [Current and legacy project tooling](#current-and-legacy-project-tooling)), `phoenix clean` removes the whole `.phoenix/` folder and `node_modules/` and runs `pnpm install`. Use this when:
 
 - Generated files are corrupted or out of sync
 - After major SDK version upgrades
@@ -388,14 +446,36 @@ Removes all build artifacts (`.phoenix/`, `node_modules/`), reinstalls dependenc
 
 ### `phoenix sync`
 
-Syncs project dependencies and regenerates all project files without building Vite bundles or webhooks. Faster than `clean` — use this for routine updates after changing spec files or upgrading dependencies. Before installing, it adds the pnpm settings `phoenix init` writes to a standalone project's `pnpm-workspace.yaml` when they are missing; values you set there are kept.
+Regenerates all project files without building Vite bundles or webhooks. Faster than `clean` — use this for routine updates after changing spec files or updating the SDK. It installs nothing: install with your package manager before syncing, after any change to `package.json`. It writes no package-manager settings; `pnpm-workspace.yaml` is the project's own. In a project on the legacy pipeline, `phoenix sync` runs `pnpm install` first.
 
 With the application-spec pipeline (see [Current and legacy project tooling](#current-and-legacy-project-tooling)), `.gitignore` is written only when the project is inside a git repository: the project folder or one of its parent folders holds a `.git` entry. Outside a repository, sync neither creates the file nor changes one that is already there, and the same holds for `dev`, `build` and `clean`. Run `git init` before the first sync, or sync again after it, to get the file. The legacy pipeline writes `.gitignore` in every project.
 
+With the application-spec pipeline, sync never writes `package.json`. Before it generates any file, it checks that `package.json` declares every peer of the installed SDK at a version inside the SDK's range, and stops with a non-zero exit code when it does not. The message lists each peer that fails, with the range the SDK needs and the version found, or `missing`, and names the fix: run [`phoenix deps`](#phoenix-deps), then install with your package manager. `phoenix build`, `phoenix clean` and `phoenix dev` make the same check, and so does the platform build of [`phoenix deploy`](#phoenix-deploy). `phoenix dev` stops when the check fails at start; on a rebuild it reports the failure like a spec error and keeps running. [Dependencies](?path=/docs/phoenix-project-structure--docs#dependencies) has the rules. The legacy pipeline merges the SDK's dependencies into `package.json` on every sync.
+
 | Flag             | Env Variable    | Default | Description                    |
 | ---------------- | --------------- | ------- | ------------------------------ |
 | `--force` / `-f` | `FORCE_REBUILD` | `false` | Force full rebuild, skip cache |
 
+### `phoenix deps`
+
+Brings `package.json` in line with the SDK's peer dependencies: the packages the SDK's code imports and the project installs next to it, so the project and the SDK share one copy. The `peerDependencies` of the installed `@salsita-ai/sdk` decide which packages and which versions. `@clerk/clerk-react` is needed only when the spec sets `useClerk`.
+
+```bash
+pnpm phoenix deps
+pnpm install
+```
+
+Run it after every SDK update: `phoenix sync`, `dev` and `build` stop while `package.json` does not declare the SDK's peers (see [`phoenix sync`](#phoenix-sync)).
+
+- A missing peer is added at the lowest version of the SDK's range, as an exact version, in alphabetical order: type packages (`@types/*`) to `devDependencies`, the others to `dependencies`.
+- A peer declared with a version range whose lowest version falls outside the SDK's range is set to the lowest version of the SDK's range, in the field that declares it. The output says when that is a downgrade.
+- A peer declared with a specifier that is not a version range, such as `workspace:`, `npm:`, `catalog:`, `file:`, `link:` or a git URL, stays as it is.
+- `@salsita-ai/common`, `@salsita-ai/contracts`, `@salsita-ai/platform-project-sdk`, `@salsita-ai/platform-common` and `@salsita-ai/platform-contracts` are removed, because `@salsita-ai/sdk` replaces them. No other entry is removed.
+
+Every other part of `package.json` keeps its order and formatting. `phoenix deps` installs nothing: it lists each change and names the install of the package manager you ran it with as the next step, or says that nothing needed to change. Running it again changes nothing. It reads the spec to learn whether the project uses Clerk, so it stops with the spec's errors when the spec does not parse.
+
+This holds for a project on the application-spec pipeline. In a project on the legacy pipeline (see [Current and legacy project tooling](#current-and-legacy-project-tooling)), `phoenix deps` changes nothing and says that `phoenix sync` manages the dependencies.
+
 ### Current and legacy project tooling
 
 Use the `phoenix` binary for projects that still use domain-spec generation. The CLI selects a
@@ -409,7 +489,7 @@ run `phoenix sync` to refresh generated legacy configuration files.
 
 ## Inspect & Debug Tools
 
-All inspect commands connect to the editor via WebSocket (default port `3020`). The editor must be running (`phoenix dev` with `--editor` enabled) for these commands to work.
+All inspect commands connect to the editor via WebSocket (default port `3020`). `phoenix dev` must be running with the preview open; in agent mode the editor runs with its UI hidden and the commands work the same.
 
 ### `phoenix inspect:assets`
 
@@ -489,7 +569,7 @@ phoenix screenshot -o preview.png -w 1920 --height 1080
 
 ### `phoenix variants`
 
-Show several options over the configurator and wait for your pick. It is built for coding agents: when a decision is a matter of taste, such as the edge of a table top, how glossy a finish is or where a control sits, the agent writes one file per option, you choose in the browser, and the command hands your answer back to the agent.
+Compare options such as a table-top edge, surface gloss or control placement in the configurator. Write one file per option, choose in the browser, and the command returns the selection.
 
 ```bash
 phoenix variants .phoenix/variants/table-edge --title 'Which edge suits the table?' --description 'Only the edge of the top differs.'
@@ -508,7 +588,7 @@ export default ({ read, write, remove }) => {
 }
 ```
 
-`read(path)` always reads the baseline. `write(path, contents)` replaces or creates a file; `remove(path)` deletes it. Scripts run in the browser and collect edits; Phoenix validates and writes the batch locally. Supported files are YAML under `spec/` outside `spec/admin/`, and TypeScript under `src/components`, `transformers`, `handlers`, `elements` and `_`-prefixed shared folders. Expressions, actions and invariants also run on the server, so a script cannot edit them.
+`read(path)` always reads the baseline. `write(path, contents)` replaces or creates a file; `remove(path)` deletes it. Scripts run in the browser and collect edits; Phoenix validates and writes the batch locally. Supported files are YAML under `spec/` outside `spec/admin/`, and TypeScript under `src/components`, `transformers`, `handlers`, `elements` and `_`-prefixed shared folders. Expressions and invariants also run on the server; those folders and action files are outside the supported edit surface.
 
 For standalone UI or branding proposals, write self-contained HTML files. Each page renders in its own iframe when selected; its `<title>` names the option and `<meta name="description" content="...">` describes it. HTML and scripts may share a set if their file names give distinct option ids.
 
@@ -564,16 +644,15 @@ Known limits:
 - Binary assets, CSS files, locale catalog changes, dependency changes and edits requiring a full application restart are unsupported.
 - Storybook `story-dev` has no variant previews. A project on the legacy pipeline has no variant previews; the command says so and exits.
 
-Generated projects carry the `phoenix-variants` agent skill, which tells coding agents when to offer options, how to write each kind and what to do with your answer.
-
 ## SDK Development
 
 ### `phoenix link`
 
-Link a local copy of the Phoenix SDK for development. This creates symlinks so that changes to the SDK source are reflected in your project without publishing.
+An internal tool for working on the SDK itself, and pnpm only: in a project with another package manager's lockfile and no `pnpm-lock.yaml`, it stops and changes nothing. Link a local copy of the Phoenix SDK for development in a project installed with pnpm. It writes a `file:` override for each SDK package into `pnpm-workspace.yaml`, so that after the next install changes to the SDK source are reflected in your project without publishing. It installs nothing; run the install it prints next:
 
 ```bash
 phoenix link --sdk-path ../configurator-phoenix
+pnpm install --config.optimistic-repeat-install=false
 ```
 
 | Flag         | Default                   | Description                |
@@ -584,10 +663,11 @@ When linked, `phoenix dev` automatically watches for changes in the linked SDK's
 
 ### `phoenix unlink`
 
-Remove the local SDK linking and restore normal package resolution.
+Remove the local SDK linking: it deletes the overrides `phoenix link` wrote. Like `phoenix link`, it is an internal tool and pnpm only. It installs nothing; the install it prints restores normal package resolution:
 
 ```bash
 phoenix unlink
+pnpm install --config.optimistic-repeat-install=false
 ```
 
 ## Utilities
@@ -678,7 +758,7 @@ SDK-builder workspaces sign the CLI in with a personal API token instead of proj
 
 Signs the CLI in to the SDK-builder workspace `<customer>`:
 
-1. Opens Studio, where you name the token and approve the sign-in (use `--no-open` to only print the link). Only a super admin of the workspace can open its Studio, so only a super admin can sign the CLI in. The page shows the workspace, your account, the computer the CLI runs on and how long the link still works. The CLI suggests the name `phoenix CLI on <computer>`; change it so you can tell your machines and agents apart later.
+1. Opens Studio, where you name the token and approve the sign-in (use `--no-open` to only print the link). Only a super admin of the workspace can open its Studio, so only a super admin can sign the CLI in. The page shows the workspace, your account, the computer the CLI runs on and how long the link still works. The CLI suggests the name `phoenix CLI on <computer>`; change it so you can tell your sign-ins apart later.
 2. Studio sends a one-time code back to the CLI on `127.0.0.1`.
 3. The CLI exchanges the code for a token with the name you approved, and sends the browser back to Studio, which confirms the sign-in.
 
@@ -703,11 +783,24 @@ Revokes the token on the server and removes it from the credentials file. `--reg
 
 ### `phoenix deploy`
 
-Validates the spec, adds the pnpm settings `phoenix init` writes to `pnpm-workspace.yaml` when they are missing, packs and uploads the project, starts its build on the server and follows it until the configurator is live. Before the upload the server compares the domain model with the deployed one: a model that changed under an already deployed model version is refused with the reason, and needs a new model version and a [migration](?path=/docs/phoenix-migrations--docs). Once the build starts it prints `Follow the build in Studio: <url>`, the build's page in the Studio you signed in through; a sign-in stored by an older CLI has no Studio URL, so sign in again to get the link. After `Your configurator is live at <url>` it prints one line for coding agents, which tells them to offer the run evaluation of the `phoenix-feedback` skill once you have nothing more to build; you can ignore it when you run the command yourself. `--region` or `--serverUrl` selects the server, as for `login`; `--no-wait` returns as soon as the build starts.
+Deploys to `project` in `spec/application.yaml` within the workspace selected by `phoenix login`. Omitted or `default` means that workspace's original default project; an explicit slug must belong to the workspace. Deploy does not use the dev command's `--projectSlug` or `PROJECT_SLUG` overrides. After staff move a project, sign in to its new workspace and set its actual slug in the spec. The selected project needs a ready `production` environment. For a nondefault project, the CLI checks server API 1.61.0 or newer before uploading, so an older server cannot silently deploy it to the default project. Studio build links retain the selected project.
+
+Validates the spec, packs and uploads the project, starts its build on the server and follows it until the configurator is live. Before the upload the server compares the domain model with the deployed one: a model that changed under an already deployed model version is refused with the reason, and needs a new model version and a [migration](?path=/docs/phoenix-migrations--docs). Before packing, it also refuses a `pnpm-workspace.yaml` whose `allowBuilds` leaves a package undecided, an entry that is neither `true` nor `false`, such as the placeholder pnpm 11 writes for a build script it skipped, because the platform build stops on it; the message names the packages. Once the build starts it prints `Follow the build in Studio: <url>`, the build's page in the Studio you signed in through; a sign-in stored by an older CLI has no Studio URL, so sign in again to get the link. It prints `Your configurator is live at <url>` when deployment succeeds. `--region` or `--serverUrl` selects the server, as for `login`; `--no-wait` returns as soon as the build starts.
+
+A follow-up evaluation hint is addressed to coding agents; you can ignore it when running the command manually.
+
+Project-owned records under `.phoenix/workspace/` and client documents under `docs/`, such as the
+rendered specification PDFs, are included in the private source archive and can be downloaded with
+the build's sources; deploy reports how many `docs/` files it includes. Local sync, build and clean
+keep both. The build extractor leaves them out, so
+they are not application build inputs or public assets. They use the archive's existing size limits
+and exclusions for dependencies, generated files, environment files and macOS metadata. The
+`.phoenix`, `.phoenix/workspace` and `docs` paths must be real directories, and linked or special
+files are rejected. Keep their contents suitable for everyone authorized to download the sources.
 
 To keep the conversation that led to a build, place a reviewed UTF-8 transcript in `conversation.log` at the project root before deploying. Deploy automatically includes it in the private source archive. Download the build's sources from Studio to read it; access is the same as for the rest of that build's sources. The build extractor skips the log, so it is not an application build input or a public asset. Missing logs produce a warning and deployment continues. Directories, links and special files at that path are rejected.
 
-The Phoenix agent skill explains how to prepare the transcript: prefer a native session export; otherwise mark a reconstruction as incomplete. Preserve available user/assistant messages and tool calls, cap individual tool results at 16 KiB with explicit truncation markers, and reference images rather than embedding them. Include the agent, export time, source and known omissions. Review and redact credentials or unrelated sensitive content before approving upload. The CLI uploads the file as supplied; it does not collect agent history, redact content, check freshness or verify completeness. Remove the file from the project root to deploy without it. The log counts toward the source archive's existing size limits; there is no separate conversation upload or viewer.
+Review and redact credentials or unrelated sensitive content before uploading the transcript. The CLI uploads the file as supplied; it does not collect conversation history, redact content, check freshness or verify completeness. Remove the file from the project root to deploy without it. The log counts toward the source archive's existing size limits; there is no separate conversation upload or viewer.
 
 ### `phoenix feedback [message]`
 
@@ -725,14 +818,14 @@ Pass the message as the argument for a short note, or `--file` for a longer repo
 | `--file`               | —              | —                             | Text file that holds the message, instead of the argument |
 | `--type`               | —              | `other`                       | What the feedback is about: `bug`, `idea` or `other`      |
 | `--contact`            | —              | —                             | How to reach you, when you want a reply                   |
-| `--agent`              | —              | —                             | Name of the coding agent that writes the feedback         |
+| `--agent`              | —              | —                             | Name of the coding agent submitting the feedback          |
 | `--projectSlug` / `-p` | `PROJECT_SLUG` | `project` of the spec, if any | Workspace project the feedback is about                   |
 | `--region`             | —              | `eu`                          | Phoenix region of the workspace: `eu` or `us`             |
 | `--serverUrl` / `--su` | —              | the region's server           | Phoenix server URL, for a local or custom server          |
 
 A message holds at most 100,000 characters, from the argument or from the file. Besides the message and the flags, the CLI sends only the SDK version, the operating system and the Node.js version; no file of the project is attached, and the Phoenix team reads a build's sources through the build's page in Studio. The project must belong to the signed-in workspace, otherwise the server refuses the feedback; without a project, the feedback is sent on its own.
 
-Generated projects carry the `phoenix-feedback` agent skill. It tells coding agents when to draft feedback, to show you the draft and send it only after you approve it, and how to write a report: the build id with its Studio page link, the live configurator link, what the agent was doing, what happened and what was expected, the exact error or output, the workaround and a condensed conversation log. When you say you are done, or a deploy went live and you confirm the run is finished, the agent asks you to evaluate the run, one question at a time: minutes spent, then a score from 0 to 10 for the agent's guidance, the configurator's functionality, its UX, the quality of the 3D, the UI visuals and the overall result, then your comments. It never picks a score for you and sends nothing when you decline. Secrets, credentials and personal data never go into a message; file paths, spec and code snippets and your own words may, once you approved the draft that contains them. The command needs a server with API 1.40.0 or newer; a message over 5000 characters needs API 1.43.0 or newer.
+Review the message before sending and omit secrets, credentials and personal data. The command needs a server with API 1.40.0 or newer; a message over 5000 characters needs API 1.43.0 or newer.
 
 ## Next Steps