@salsita-ai/sdk 0.50.0-develop.ca72986c39 → 0.50.0-develop.cba048b0d7

package/dist/docs/phoenix/project-structure.mdx

@@ -136,18 +136,37 @@ export default [CabinetModule, DrawerModule, ShelfModule]
 
 Phoenix auto-flattens both patterns during build. Use array exports when logically grouping related items in one file.
 
-## Dependencies Merging
+## Dependencies
 
-When running `phx sync` or `phx build`, Phoenix manages `package.json` dependencies:
+In a project on the application-spec pipeline, `package.json` is the project's own: `phoenix sync`, `phoenix dev` and `phoenix build` never write it. The SDK lists the packages its code imports from the project's install as peer dependencies (React, three.js, MUI, Lingui and others), and the project declares them next to `@salsita-ai/sdk`. [`phoenix deps`](?path=/docs/phoenix-phoenix-cli--docs#phoenix-deps) adds the missing ones and moves out-of-range ones into the SDK's range; run it, then install, after every SDK update. With pnpm, and the same through any other package manager (`npm install`, `npx phoenix deps` with npm):
 
-| Behavior              | Description                                                    |
-| --------------------- | -------------------------------------------------------------- |
-| Phoenix deps override | Required Phoenix dependencies override user-specified versions |
-| Versions pinned       | All Phoenix deps use exact versions (no ^ or ~)                |
-| User deps preserved   | Non-conflicting user dependencies are kept                     |
-| Manual deps safe      | Dependencies not in Phoenix's required list remain untouched   |
+```bash
+pnpm add @salsita-ai/sdk@<version>
+pnpm phoenix deps
+pnpm install
+pnpm phoenix sync
+```
+
+`phoenix sync`, `phoenix dev` and `phoenix build`, also on the platform when a deploy builds, check `package.json` before they generate any file. When a peer is missing, or declared at a version whose lowest match falls outside the SDK's range, they stop and list each such peer with the range the SDK needs and what `package.json` declares. A peer counts in `dependencies`, `devDependencies` or `optionalDependencies`, and a specifier that is not a version range, such as `workspace:` or `link:`, counts as declared. Add your own dependencies to `package.json` as usual; Phoenix leaves them, the Node.js and package-manager versions and the rest of the file as you wrote them.
+
+In a project on the legacy pipeline (see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), `phoenix sync` and `phoenix build` merge the SDK's required dependencies into `package.json` instead, at exact versions over the ones you set, and keep every other dependency.
+
+### Package manager
 
-To add custom dependencies, add them normally to `package.json`. Phoenix preserves them unless they conflict with required framework dependencies.
+A project installs with any package manager: pnpm, npm, Yarn or Bun. Phoenix writes no package-manager settings and no `packageManager` field; the lockfile, `pnpm-workspace.yaml`, `.npmrc` and `.yarnrc.yml` are the project's own. Run `phoenix` through the package manager the project uses, such as `pnpm phoenix sync` or `npx phoenix sync`.
+
+A project that installs with pnpm 11 needs a `pnpm-workspace.yaml` in its root before the first install. pnpm 11 stops an install until every dependency build script is allowed or denied, and the SDK's dependencies have three. Its default minimum release age also refuses a package published only recently, so the exclusion lets the project install an SDK build on the day it is released; it is optional:
+
+```yaml
+allowBuilds:
+  '@swc/core': true
+  esbuild: true
+  es5-ext: false
+minimumReleaseAgeExclude:
+  - '@salsita-ai/*'
+```
+
+The file is yours to extend, for example to allow the build script of a dependency you add. In a pnpm monorepo, these settings go into the workspace root's `pnpm-workspace.yaml`. [`phoenix deploy`](?path=/docs/phoenix-phoenix-cli--docs#phoenix-deploy) packs `pnpm-lock.yaml` and `pnpm-workspace.yaml` when the project has them, and the platform build, which installs with pnpm, follows them.
 
 ## Global Interfaces
 
@@ -180,28 +199,27 @@ type CustomMaterial = Phx['AdminModel']['CustomMaterial']
 
 ### Root Level Files
 
-| File                                                   | Auto-Generated? | Notes                                  |
-| ------------------------------------------------------ | --------------- | -------------------------------------- |
-| `package.json`                                         | Partially       | Dependencies merged, scripts untouched |
-| `tsconfig.json`                                        | Once            | Yours; see below                       |
-| `eslint.config.js`                                     | Yes             | Managed by Phoenix                     |
-| `prettier.config.js`                                   | Yes             | Managed by Phoenix                     |
-| `.prettierignore`                                      | No              | Optional and your own; see below       |
-| `.linguirc`                                            | Yes             | Managed by Phoenix                     |
-| `.nvmrc`                                               | Yes             | Managed by Phoenix                     |
-| `.gitignore`                                           | Partially       | Only in a git repository; see Markers  |
-| `.env`                                                 | No              | Git-ignored, local config              |
-| `.env.example`                                         | No              | Template for env vars                  |
-| `.env.generated`                                       | Yes             | Optional, git-ignored; see below       |
-| `README.md`                                            | No              | Project documentation                  |
-| `AGENTS.md`                                            | No              | Your own coding-agent instructions     |
-| `.claude/skills/phoenix*/`, `.agents/skills/phoenix*/` | Yes             | Phoenix agent skills                   |
+| File                                                 | Auto-Generated? | Notes                                 |
+| ---------------------------------------------------- | --------------- | ------------------------------------- |
+| `package.json`                                       | No              | Yours; see Dependencies               |
+| `tsconfig.json`                                      | Once            | Yours; see below                      |
+| `eslint.config.js`                                   | Once            | Yours; see below                      |
+| `prettier.config.js`                                 | Once            | Yours; see below                      |
+| `.prettierignore`                                    | No              | Optional and your own; see below      |
+| `pnpm-workspace.yaml`                                | No              | Only with pnpm; see Package manager   |
+| `.gitignore`                                         | Partially       | Only in a git repository; see Markers |
+| `.env`                                               | No              | Git-ignored, local config             |
+| `.env.example`                                       | No              | Template for env vars                 |
+| `.env.generated`                                     | Yes             | Optional, git-ignored; see below      |
+| `README.md`                                          | No              | Project documentation                 |
+| `AGENTS.md`                                          | No              | Your own coding-agent instructions    |
+| `.claude/skills/phoenix/`, `.agents/skills/phoenix/` | Yes             | Phoenix agent skills                  |
 
 Sync does not write `README.md`, `AGENTS.md`, `.env.example`, `.env.ci` or the `README.md` files in `assets/public/` and `assets/private/`. Earlier SDK versions wrote them once; a project that has them keeps them, and they are yours to edit.
 
 Phoenix keeps the generated env file, with the IDs and values of the prepared deployment, in `.phoenix/` unless the project has a `.env.generated` in its root, which then is the one that counts. `phoenix dev` creates no `.env.generated` in the project root; the deployment and environment commands write it there. See [The generated env file](?path=/docs/phoenix-phoenix-cli--docs#the-generated-env-file).
 
-With the application-spec pipeline (see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), Phoenix does not write a `.prettierignore`, and a fresh clone or CI checkout of a project has none. `phoenix check` and `phoenix fix` do not read one: they skip `.phoenix/`, `dist/`, the compiled catalogs in `src/locales/`, `pnpm-lock.yaml` and `.linguirc` on their own. A project that runs Prettier directly, as `prettier --check .` or from an editor, can add its own `.prettierignore`. To commit it, add a `!.prettierignore` line after the Phoenix block of `.gitignore`, because that block lists the file. The legacy pipeline writes `.prettierignore` on every sync.
+With the application-spec pipeline (see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), Phoenix does not write a `.prettierignore`, and a fresh clone or CI checkout of a project has none. `phoenix check` and `phoenix fix` do not read one: they skip `.phoenix/`, `dist/`, the compiled catalogs in `src/locales/` and `.linguirc` on their own, and the package manager's files in the project root, which belong to whichever package manager the project uses: `pnpm-lock.yaml`, `pnpm-workspace.yaml`, `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock`, `.yarnrc.yml`, `bun.lock` and `bun.lockb`. A project that runs Prettier directly, as `prettier --check .` or from an editor, can add its own `.prettierignore`. To commit it, add a `!.prettierignore` line after the Phoenix block of `.gitignore`, because that block lists the file. The legacy pipeline writes `.prettierignore` on every sync.
 
 With the application-spec pipeline, the project's TypeScript settings are in `.phoenix/tsconfig.json`, which sync rewrites with the rest of `.phoenix/`. The root `tsconfig.json` is the one editors and tools find: sync writes it only when the project has none, as a single line that extends the generated settings, and it is yours to commit and to add to:
 
@@ -211,24 +229,30 @@ With the application-spec pipeline, the project's TypeScript settings are in `.p
 
 The only root `tsconfig.json` sync replaces is the full file earlier SDK versions generated there, recognised by its settings; any other stays as it is. `phoenix dev`, `phoenix build` and the webhook bundle do not resolve `paths` aliases, so an alias added to the root file passes `phoenix check` and fails the build. `phoenix check` type-checks with the root `tsconfig.json`, or with `.phoenix/tsconfig.json` when the project has none. The legacy pipeline writes the full `tsconfig.json` on every sync.
 
+With the application-spec pipeline, sync writes `eslint.config.js` and `prettier.config.js` only when the project has none, each re-exporting the SDK's shared configuration so editors find it. They are yours to commit and to change. The only ones sync replaces are the files earlier SDK versions generated there; any other stays as it is. `phoenix check` and `phoenix fix` lint and format with the project's files, and with the SDK's configurations when a file is missing (see [`phoenix check`](?path=/docs/phoenix-phoenix-cli--docs#phoenix-check)). Sync formats the files it generates in the project root, such as the agent skills, with the same Prettier configuration, so `phoenix check` accepts them; while the project's configuration cannot be loaded, as before the first install, they get the SDK's settings. The legacy pipeline writes both files on every sync.
+
+With the application-spec pipeline, the Lingui configuration is `.phoenix/.linguirc`, which sync rewrites with the rest of `.phoenix/` from `availableLocales` in `spec/application.yaml`. Phoenix passes that file to Lingui every time it extracts or compiles the catalogs and to its Vite builds, so a `.linguirc` in the project root is not read and can be deleted. To run Lingui yourself, name the file: `npx lingui extract --config .phoenix/.linguirc`, from the project root. The legacy pipeline writes `.linguirc` in the project root on every sync.
+
 ### DO NOT EDIT (Fully Auto-Generated)
 
 - **Everything in `.phoenix/`** - Completely regenerated on each build. The exceptions are `.phoenix/variants/`, where a coding agent writes the option files for `phoenix variants`, and `.phoenix/.env.generated`, the generated env file of `phoenix dev`; a rebuild keeps both
-- `eslint.config.js`, `prettier.config.js`
-- `.linguirc`, `.nvmrc`
 - `src/locales/**/*.ts` - Compiled from `.po` catalogs
 - `.env.generated`
 - `phoenix` and `phoenix-*` skill folders under `.claude/skills/` and `.agents/skills/` — rewritten on every sync with anything else inside them removed, and other `phoenix`-prefixed skill folders are removed; to customise a skill, copy it to a folder whose name does not start with `phoenix`
 
 ### Agent Guidance
 
-Coding agents (Claude Code, Codex, Cursor) read the Phoenix agent skills. An `AGENTS.md` is yours to add for your own instructions; sync does not write one. The `phoenix`, `phoenix-cli`, `phoenix-feedback` and `phoenix-review` skills carry the SDK conventions, CLI tooling and review checklist, and the `phoenix-create-configurator` skill walks the agent from your product documents and assets to a reviewed configurator in five stages. The `phoenix-variants` skill has the agent show you several options over the dev preview when a decision is a matter of taste, and build the one you pick. Phoenix keeps them in step with the installed SDK, including the reference files inside a skill folder. During the internal beta, a project created from a canary build of the SDK gets one more section in the `phoenix` skill: once per conversation the agent checks for a newer canary and, after telling you, updates the project's SDK and runs `phoenix sync`. Other skill folders are never touched.
+Coding agents (Claude Code, Codex, Cursor) enter through the single `phoenix` skill under `.claude/skills/phoenix/` or `.agents/skills/phoenix/`. Its `SKILL.md` routes to the existing project, CLI, configurator workflow, code review, variants and feedback guides in `references/`. Agents read the guides for their task rather than the whole tree. The configurator workflow retains its five stages and supporting discovery, UX, asset-conversion and appearance-review references.
+
+Phoenix keeps this guidance in step with the installed SDK. During the internal beta, a project created from a canary build gets the canary-update instructions in the linked project guide: once per conversation the agent checks for a newer canary and, after telling you, updates the SDK, runs `phoenix deps`, installs, then runs `phoenix sync`.
+
+An `AGENTS.md` is yours to add; sync does not write one. Sync removes retired `phoenix-*` skill folders but leaves unrelated skills alone. If your own instructions name an earlier separate skill such as `phoenix-review`, point them at `phoenix` and the same task instead.
 
-Projects created by earlier SDK versions had this guidance in `CLAUDE.md`, `.cursor/rules/phoenix.mdc` and `commands/review.md`. Sync removes the SDK block from the first two, keeps your own text around it, deletes a file that held nothing else, and deletes the review commands; use the `phoenix-review` skill instead of `/review`.
+Projects created by earlier SDK versions had this guidance in `CLAUDE.md`, `.cursor/rules/phoenix.mdc` and `commands/review.md`. Sync removes the SDK block from the first two, keeps your own text around it, deletes a file that held nothing else, and deletes the review commands; ask `phoenix` to review instead of using `/review`.
 
 ### Markers for Partial Auto-Generation
 
-`.gitignore` holds the Phoenix entries between two marker lines. Sync rewrites that block and keeps everything outside it:
+`.gitignore` holds the Phoenix entries between two marker lines. Sync rewrites that block and keeps everything outside it. With the application-spec pipeline the block does not list the files sync writes once, `tsconfig.json`, `eslint.config.js` and `prettier.config.js`, so a project commits them:
 
 ```gitignore
 # ===== BEGIN PHOENIX AUTO-GENERATED =====
@@ -253,6 +277,7 @@ With the application-spec pipeline (see [Current and legacy project tooling](?pa
 - `package.json` (scripts section, custom dependencies)
 - `.env`, `.env.example`, `.env.ci`
 - `tsconfig.json` (application-spec pipeline; keep it extending `.phoenix/tsconfig.json`)
+- `eslint.config.js`, `prettier.config.js` (application-spec pipeline; sync writes them once, and they are the project's afterwards)
 - `README.md`, `AGENTS.md`
 
 ## File Naming Conventions
@@ -361,6 +386,7 @@ project-root/
 │   ├── i18n.ts                    # i18n initialization
 │   ├── globals.d.ts               # Global type definitions
 │   ├── tsconfig.json              # TypeScript settings, extended by the root tsconfig.json
+│   ├── .linguirc                  # Lingui configuration
 │   ├── index.html                 # Configurator HTML entry
 │   └── admin.html                 # Admin HTML entry
 │

package/dist/docs/phoenix/quickstart.mdx

@@ -15,7 +15,7 @@ Build a working office desk configurator from an empty folder. You will describe
 
 ## Before you start
 
-Use Node.js 24 and pnpm 11. The tutorial uses the office desk model served by this documentation site at `/models/office-desk.gltf`; download it first. Real client projects normally start from `phoenix init`. This tutorial creates the four essential files by hand so you can see what Phoenix owns.
+Use Node.js 24 and any package manager; the commands below use pnpm, and with pnpm 11 the project also needs the `pnpm-workspace.yaml` in [Package manager](?path=/docs/phoenix-project-structure--docs#package-manager). The tutorial uses the office desk model served by this documentation site at `/models/office-desk.gltf`; download it first. Real client projects normally start from `phoenix init`. This tutorial creates the four essential files by hand so you can see what Phoenix owns.
 
 ## Step 0 — Create the project
 
@@ -40,17 +40,13 @@ Now add these four files.
   "dependencies": {
     "@salsita-ai/sdk": "0.48.0"
   },
-  "devDependencies": {
-    "@lingui/cli": "5.9.5",
-    "@lingui/swc-plugin": "5.11.0"
-  },
   "phoenix": {
     "applicationFlow": true
   }
 }
 ```
 
-Use the SDK version supplied by your team if it differs from the repository's current `0.48.0` version. `phoenix.applicationFlow` selects the application-spec project structure. The first sync uses Lingui while generating the rest of the dependencies, so its CLI and SWC plugin must also be present in the initial install.
+Use the SDK version supplied by your team if it differs from the repository's current `0.48.0` version. `phoenix.applicationFlow` selects the application-spec project structure. The SDK runs its own Lingui, so the SDK is the only dependency you write by hand; `phoenix deps` adds the packages it needs next to it in the install step below. A project started with `phoenix init` gets a `package.json` that already declares them.
 
 ### `.env`
 
@@ -97,13 +93,17 @@ components:
         layout: universal
 ```
 
-Install the SDK, then ask Phoenix to generate the rest of the project:
+Install the SDK, let it declare the packages it needs, such as React, three.js and MUI, install them, then ask Phoenix to generate the rest of the project:
 
 ```sh
 pnpm install
+pnpm phoenix deps
+pnpm install
 pnpm phoenix sync
 ```
 
+`phoenix sync` stops while `package.json` lacks one of those packages; after every SDK update, run `phoenix deps` and install again (see [`phoenix deps`](?path=/docs/phoenix-phoenix-cli--docs#phoenix-deps)). With npm, the same steps are `npm install`, `npx phoenix deps`, `npm install` and `npx phoenix sync`.
+
 `phoenix sync` keeps `spec/` and `src/` as your authored inputs and generates the application shell, types, and `.phoenix/` implementation. Start development without a server:
 
 ```sh

package/dist/docs/phoenix/sdk-builder-workflow.mdx

@@ -8,9 +8,9 @@ Your workspace's Studio shows the setup, the link to your configurator and the s
 
 ## Before you start
 
-- **Package access:** `@salsita-ai/sdk` is public on npm; `npx` and `pnpm install` download it without a registry token.
+- **Package access:** `@salsita-ai/sdk` is public on npm; any package manager downloads it without a registry token.
 - **Workspace details:** you need your workspace slug and its Phoenix region (`eu` or `us`), which you also received with your workspace.
-- **Tools:** Node.js and pnpm.
+- **Tools:** Node.js and a package manager. The commands below use pnpm; with npm, run `npm install` and `npx phoenix …` instead, with Yarn `yarn phoenix …`, with Bun `bunx phoenix …`.
 - **SDK build:** during the internal beta, use the `canary` build of the SDK, as the commands below do. It is published from every change to the platform, so it is newer than the last release.
 
 ## 1. Create a project
@@ -22,11 +22,11 @@ pnpm install
 pnpm phoenix sync
 ```
 
-`phoenix init [folder]` writes the starter project: `package.json`, `pnpm-workspace.yaml` and the starter spec, `spec/application.yaml` and `spec/configurator.yaml`, which describe one box you can resize and recolour. The starter depends on the same SDK version as the CLI that created it, and its `package.json` has the `dev`, `build`, `deploy`, `check` and `fix` scripts, which are yours to change. `phoenix sync` then adds the rest of the project: the TypeScript, lint and formatting config and the agent skills. It writes no webhook code: a project without `src/webhooks/index.ts` gets a built-in webhook (see [Webhook Entry Point](?path=/docs/phoenix-webhooks--docs#webhook-entry-point)). It writes a `.gitignore` only when the folder is inside a git repository; run `git init` before the first sync, or sync again after it, to get the file.
+`phoenix init [folder]` writes the starter project: `package.json` and the starter spec, `spec/application.yaml` and `spec/configurator.yaml`, which describe one box you can resize and recolour. The starter depends on the same SDK version as the CLI that created it and on the packages the SDK requires next to it (React, three.js, MUI, Lingui and the others, with their type packages), with ESLint and Prettier at the versions the SDK uses itself. Its `package.json` has the `dev`, `build`, `deploy`, `check` and `fix` scripts, which are yours to change. `phoenix sync` then adds the rest of the project: the TypeScript, lint and formatting config and the agent skills. It writes no webhook code: a project without `src/webhooks/index.ts` gets a built-in webhook (see [Webhook Entry Point](?path=/docs/phoenix-webhooks--docs#webhook-entry-point)). It writes a `.gitignore` only when the folder is inside a git repository; run `git init` before the first sync, or sync again after it, to get the file.
 
-`init` only writes these files: it asks nothing and contacts no server. It refuses a folder that already has a `spec/` folder. A `package.json` already in the folder is kept, as long as it depends on the SDK.
+`init` only writes these files: it asks nothing and contacts no server. It refuses a folder that already has a `spec/` folder. A `package.json` already in the folder is kept, as long as it depends on the SDK, and gains only the entries it lacks (see [Starting a New Project](?path=/docs/phoenix-phoenix-cli--docs#starting-a-new-project)).
 
-`pnpm-workspace.yaml` holds the pnpm settings the install needs: it allows the build scripts of the SDK's dependencies and exempts `@salsita-ai/*` packages from pnpm's minimum release age, so a build of the SDK published today installs. The file is yours to edit, for example to allow the build script of a dependency you add. `phoenix sync` adds these entries when they are missing and keeps the values you set. A project inside a pnpm monorepo gets no file of its own; the workspace root holds the settings.
+Phoenix writes no package-manager settings. With pnpm 11, add a `pnpm-workspace.yaml` that allows the build scripts of the SDK's dependencies before the first install; [Package manager](?path=/docs/phoenix-project-structure--docs#package-manager) has the file.
 
 The starter `spec/application.yaml` begins with `project: default`, which means the default project of the workspace you sign in to. Leave it as it is; a workspace has one project.
 
@@ -65,7 +65,7 @@ Every user who signs the CLI in gets their own development environment, so a tea
 
 Coding agents follow the generated `phoenix` skill: before their first change they start `phoenix dev` and open the preview in your browser, and after `phoenix deploy` starts a build they open its page in Studio.
 
-To build the configurator with your coding agent, give it your product documents, prices, pictures, drawings or models and ask it to create the configurator. The generated `phoenix-create-configurator` skill guides it through five stages: a representative first slice you can try early, a plan of the whole configuration experience, options and features added in small increments, finalization, and a complete review. It studies the SDK documentation before building, keeps a `configurator-spec.md` in the project as the record of what is decided and what remains open, and asks you only for decisions it cannot derive from your materials.
+To build the configurator with your coding agent, give it your product documents, prices, pictures, drawings or models and ask it to create the configurator. The generated `phoenix` skill’s Configurator workflow guide takes it through five stages: a representative first slice you can try early, a plan of the whole configuration experience, options and features added in small increments, finalization, and a complete review. It studies the SDK documentation before building, keeps a `configurator-spec.md` in the project as the record of what is decided and what remains open, and asks you only for decisions it cannot derive from your materials.
 
 ## 4. Deploy
 
@@ -81,11 +81,13 @@ pnpm phoenix deploy
 4. It uploads the archive, which may be up to 200 MB.
 5. It starts the build, prints a link to the build's page in Studio and follows the build until your configurator is live, then prints its URL.
 
-On the server, the install follows your `pnpm-lock.yaml` and `pnpm-workspace.yaml`, so it allows the same build scripts and package versions as `pnpm install` on your computer. The build runs without platform secrets. It sees only your own environment variables and the public platform values, the [build environment](?path=/docs/phoenix-phoenix-cli--docs) that `phoenix deployment:build-envs` writes. The trusted deploy step then publishes the frontend, webhooks and assets.
+On the server, the install runs pnpm. It follows your `pnpm-lock.yaml` and `pnpm-workspace.yaml` when the project has them, so a pnpm project gets the same build scripts and package versions as on your computer; without them, pnpm resolves `package.json` with the settings the SDK needs. The build runs without platform secrets. It sees only your own environment variables and the public platform values, the [build environment](?path=/docs/phoenix-phoenix-cli--docs) that `phoenix deployment:build-envs` writes. The trusted deploy step then publishes the frontend, webhooks and assets.
 
 If the build fails, is cancelled or takes too long, `phoenix deploy` prints the end of the build log and exits with an error. `--no-wait` returns as soon as the build starts.
 
-Studio's **Builds & deployments** page lists your builds and shows which one your configurator serves. Each build shows its progress, its error and the full build log while it runs.
+Studio's **Builds & deployments** page lists your builds, 20 to a page, and shows which one your configurator serves. Filter it to the live build or to the builds that failed. Each build shows its progress, its error and the full build log while it runs, and who deployed it with which CLI token.
+
+**Rebuild** on a build's page builds the files uploaded with that build again, with your environment variables as they are now, without a new `phoenix deploy`. Use it after changing a variable, or when a build failed for a reason on our side. If the rebuild succeeds it goes live, so rebuilding an older build rolls production back to it.
 
 `phoenix deploy` refuses symlinks, hard-linked files and other special files among the project files, because builds only accept regular files. Packing uses the system `tar`, which macOS, Linux and Windows 10 or later all include. The build runner checks the uploaded archive again and keeps only project files, so a file outside the list above never reaches the build.
 
@@ -95,9 +97,9 @@ Tell us what is broken, confusing or missing, from wherever you are:
 
 - In Studio, **Send beta feedback** in the sidebar opens a short form.
 - In the terminal, `pnpm phoenix feedback "<message>" --type bug|idea|other` sends it with your sign-in, and `--file <path>` sends a text file instead of the argument. See the [CLI reference](?path=/docs/phoenix-phoenix-cli--docs).
-- On a build's page in Studio, **Download sources** downloads the archive `phoenix deploy` uploaded for that build, so a report only needs to name the build.
+- On a build's page in Studio, **Download** → **Sources** downloads the archive `phoenix deploy` uploaded for that build, so a report only needs to name the build.
 
-Coding agents working in your project use the same command, guided by the generated `phoenix-feedback` skill. They never send on their own: an agent shows you a draft, right away when the problem is crucial and otherwise at the end of the task, and sends it only after you approve it. A report names the build with its Studio page link and the live configurator, says what the agent was doing, what happened and what it expected, quotes the exact error and ends with a condensed conversation log. Agents are told never to include secrets, credentials or personal data; parts of your project and your own words go in only through a draft you approved. When you are done with the configurator, the agent also asks you, once per conversation, to evaluate the run: minutes spent, then scores from 0 to 10 for the agent's guidance, functionality, UX, 3D quality, UI visuals and the overall result, and your comments. It asks one question at a time, never picks a score for you, tells you the answers go to the Phoenix team, shows the message and sends it only after you approve it.
+Coding agents working in your project use the same command, guided by the generated `phoenix` skill’s Feedback guide. They never send on their own: an agent shows you a draft, right away when the problem is crucial and otherwise at the end of the task, and sends it only after you approve it. A report names the build with its Studio page link and the live configurator, says what the agent was doing, what happened and what it expected, quotes the exact error and ends with a condensed conversation log. Agents are told never to include secrets, credentials or personal data; parts of your project and your own words go in only through a draft you approved. When you are done with the configurator, the agent also asks you, once per conversation, to evaluate the run: minutes spent, then scores from 0 to 10 for the agent's guidance, functionality, UX, 3D quality, UI visuals and the overall result, and your comments. It asks one question at a time, never picks a score for you, tells you the answers go to the Phoenix team, shows the message and sends it only after you approve it.
 
 ## Known limits
 
@@ -107,5 +109,5 @@ Coding agents working in your project use the same command, guided by the genera
 - `phoenix deploy` always deploys to the workspace's default project; it doesn't read `project` from the spec yet.
 - Only `phoenix dev` works from the sign-in. `phoenix deployment:prepare-dev` still needs the `.env` block of a Studio development environment.
 - Every deploy uploads the whole project; there are no incremental uploads.
-- Your own environment variables are set in Studio under Environment, by a super admin of the workspace, and apply from the next deploy. `phoenix dev` doesn't receive them: your development environment has its own variables. A build reads them from `process.env`; a webhook reads the ones the spec declares under `env.webhook`, through `phx.webhooksEnv` (see [Webhooks](?path=/docs/phoenix-webhooks--docs)). They can't use platform names such as `LAMBDA_FUNCTION_NAME`, the `AWS_` prefix, the identity provider settings such as `CLERK_API_KEY`, or names the CLI and the deploy tooling read themselves, such as `SERVER_URL` or `NODE_OPTIONS`; Studio refuses those names.
+- Your own environment variables are set in Studio under Environment, by a super admin of the workspace, and apply from the next deploy. After a change, **Redeploy #N now** there rebuilds your live build with the new values, without a new `phoenix deploy`; it appears once your own build is live. `phoenix dev` doesn't receive them: your development environment has its own variables. A build reads them from `process.env`; a webhook reads the ones the spec declares under `env.webhook`, through `phx.webhooksEnv` (see [Webhooks](?path=/docs/phoenix-webhooks--docs)). They can't use platform names such as `LAMBDA_FUNCTION_NAME`, the `AWS_` prefix, the identity provider settings such as `CLERK_API_KEY`, or names the CLI and the deploy tooling read themselves, such as `SERVER_URL` or `NODE_OPTIONS`; Studio refuses those names.
 - Only super admins of a workspace can open its Studio. Admins and users see a page that says so.

package/dist/docs/phoenix/sessions-and-access.mdx

@@ -427,6 +427,8 @@ The `readonly` web component property lets the host force view mode without chan
 
 Because an owner-token session can be forced read-only client-side while the server still accepts writes from that owner token, Phoenix skips persistence and logs a warning instead of updating the configuration. This guards against the configuration being silently overwritten by code paths that mutate state in read-only mode. UI that triggers significant changes (anything that produces a new revision) should still be disabled when `accessInfo.viewMode` is true — the warning is a backstop, not a substitute.
 
+The assistant follows the same read-only rule as the UI: its `apply` tool refuses changes while `accessInfo.viewMode` is true, that is with a read-revision token or while `readonly` is set, and makes them again once it is false. A switch of `readonly` takes effect at once, in both directions, and the configurator loads the configuration again. A change applied after `readonly` is cleared and before the configuration has loaded again is not saved; saving resumes once it has loaded. The `query` tool keeps working, including its dry-run mutations.
+
 ```html
 <salsita-configurator readonly></salsita-configurator>
 ```

package/dist/docs/phoenix/testing.mdx

@@ -33,6 +33,14 @@ invariants, actions, migrations, presets and the components declared in YAML. `c
 handler, element and transformer; it reads the frontend environment when it is imported, so a test that
 uses it stubs `phx.frontendEnv` first.
 
+A test that mounts the configurator's UI builds from `configuratorConfig`: it carries the SDK's default
+elements, the built-in layout, preset screen, not-found, not-authenticated and error pages, app loader content,
+controls, toolbar buttons and sidebar-footer pieces, which `configuratorBuilder` does not, so a test that mounts the UI from `createTestApplicationConfig(configuratorBuilder)`
+shows a "not found" box in place of every built-in element. Code that assembles a config without the
+generated files calls `.withDefaultElements(defaultConfiguratorElements)` on its configurator builder, with
+the list from `@salsita-ai/sdk/configurator`, or `defaultAdminElements` from `@salsita-ai/sdk/admin` for
+the admin.
+
 A test passes the generated export to the helper and does not call the export's methods: they are how the
 SDK assembles an application, not an interface for tests, while the helper's call does not depend on that
 assembly.

package/dist/docs/phoenix/webhooks.mdx

@@ -36,7 +36,11 @@ Phoenix provides domain-aware builders through the global `phx.webhooks` namespa
 
 Your webhook is the default export of `src/webhooks/index.ts`. With the application-spec pipeline (see [Current and legacy project tooling](?path=/docs/phoenix-phoenix-cli--docs#current-and-legacy-project-tooling)), the file is yours to create; sync does not write it. A project without it gets a built-in webhook, so it builds and deploys with no webhook code. The built-in webhook has one handler, an anonymous auth handler, which the platform calls only when `spec/application.yaml` sets `useAuthHook`. The legacy pipeline writes the file with that webhook on the first sync.
 
-Create `src/webhooks/index.ts` when the project needs its own handlers: finalization, backend data, or an auth handler that does more than start an anonymous session. A project that sets `useAuthHook` or `useClerk` needs its own auth handler, because the built-in one answers only anonymous requests. The smallest file is the built-in webhook itself:
+Create `src/webhooks/index.ts` when the project needs its own handlers: finalization, backend data, or an auth handler that does more than start an anonymous session.
+
+If `useAuthHook` or `useClerk` is enabled without this file, sync, build, clean and dev report `AUTH_WITHOUT_PROJECT_WEBHOOK` and generation continues with the anonymous-only built-in webhook. This warning also applies when `useAuthHook: false` is explicit alongside `useClerk: true`. Add a default-exported webhook with the required Clerk or custom auth handlers, or disable the settings if they are unintended.
+
+The smallest file is the built-in webhook itself:
 
 ```ts
 // src/webhooks/index.ts

package/dist/docs/selection-and-highlight/hotspots.mdx

@@ -56,6 +56,8 @@ sceneEntitySelectHotspot:
 
 The `title` supplies the tooltip text. Tooltips appear on hover by default; `tooltipVisibility` can instead keep them visible continuously, while the camera is still, or hide them. The `showWhen` property controls visibility based on selection state. The default `['unselected']` hides hotspots once entities are selected, keeping the view clean. Setting it to `['selected', 'unselected']` keeps hotspots always visible.
 
+The hotspot is the entity element `SelectionHotspot`. A project replaces its look by registering its own with `phx.frontend.createSelectionHotspot`, which receives `onSelect`, the selection with its analytics event; the settings above still apply. See [Configurator Interface → In-Scene Controls](?path=/docs/phoenix-configurator-interface--docs#in-scene-controls).
+
 ## System Component Interfaces
 
 ```typescript

package/dist/domain/application/application-config.d.ts

@@ -9,6 +9,7 @@ import type { AdminIntegrationService } from '#package/react-sdk';
 import type { $DomainEntity, DataCellValue, DataSchema, DomainEntity, DomainFactory, ProductPreset } from '../core/index.js';
 import type { AnalyticsSystem, RegistrableTransformer, TransformerFactory } from '../domain-context/index.js';
 import type { ElementRegistration, ProjectModule } from '../domain-runtime/index.js';
+import type { AdminPagesSection } from '../spec/index.js';
 import type { AssistantResolvedManifest } from './assistant/index.js';
 import type { WebComponentEventDescriptor } from './web-component-event.js';
 import type { WebComponentPropertyDescriptor } from './web-component-property.js';
@@ -55,30 +56,11 @@ export type DataSpec = {
 export type ChunksSpec = Readonly<Record<string, {
     readonly scope: string;
 }>>;
-export type AdminPagesSpec = {
-    readonly presets?: boolean | {
-        readonly categoryNavigationState?: string;
-        readonly presetNavigationState?: string;
-    };
-    readonly recipes?: ReadonlyArray<{
-        readonly name: string;
-        readonly navigationState?: string;
-    }>;
-    readonly pages?: ReadonlyArray<{
-        readonly key: string;
-        readonly title: string;
-        readonly icon?: string;
-        readonly navigationState?: string;
-        readonly entity?: string;
-        readonly component?: string;
-        readonly actionsComponent?: string;
-        readonly connectedDataEntry?: string;
-        readonly sidebar?: {
-            readonly title: string;
-            readonly component: string;
-        };
-    }>;
-};
+/**
+ * The admin pages of an application config: the `$adminPages` section of the application spec as
+ * written, which `createAdminPagesFromSpec` turns into admin pages; see {@link AdminPagesSection}.
+ */
+export type AdminPagesSpec = AdminPagesSection;
 type PersistenceConfig = {
     readonly type: 'server';
     /**

package/dist/domain/application/assistant/assistant-manifest.d.ts

@@ -1,3 +1,4 @@
+import type { AssistantFormElementDescriptor } from './form/index.js';
 /**
  * Where one exposed assistant GraphQL field reads its value on the `$` entity: a stored field name,
  * or an expression name including its `$`. `localized` marks a localizable value that resolves to a
@@ -7,18 +8,28 @@ export interface AssistantFieldSource {
     readonly source: string;
     readonly localized?: true;
 }
+/**
+ * What the integrator promises about a list of choices, so the agent can read it once and reuse it:
+ * `sameForAllInstances` when every entity of the type gets the same list, `constantDuringSession`
+ * when the list does not change during a session. A hint only adds a sentence to the description of
+ * the recipe group or options edge it is declared on; nothing verifies it.
+ */
+export declare const ASSISTANT_HINTS: readonly ['sameForAllInstances', 'constantDuringSession'];
+export type AssistantResolvedHint = (typeof ASSISTANT_HINTS)[number];
 /**
  * One recipe group the assistant manifest exposes on an entity type: a `childEntityRecipes` instance
  * under `childRecipes`, a `replaceEntityRecipes` instance under `replaceRecipes`. `groupId` is the
- * name the agent addresses the group by, `instanceName` the component instance it reads,
- * `description` the manifest's text replacing the component's group description, and `dryRuns`
- * whether the recipes of the group can be dry-run.
+ * name of its field on `<Type>ChildRecipes` or `<Type>ReplaceRecipes` and the id the agent passes to
+ * `addChild` or `replaceEntity`, `instanceName` the component instance it reads, `description` the
+ * manifest's text for that field, `dryRuns` whether the recipes of the group can be dry-run, and
+ * `hints` the sentences of the field's description saying when the agent can reuse what it read.
  */
 export interface AssistantRecipeGroup {
     readonly groupId: string;
     readonly instanceName: string;
     readonly description?: string;
     readonly dryRuns: boolean;
+    readonly hints: readonly AssistantResolvedHint[];
 }
 /**
  * The options edge of one writable field the assistant manifest links to its component. `field` is
@@ -35,6 +46,16 @@ export interface AssistantFieldOptions {
     readonly validate: boolean;
     readonly dryRuns: boolean;
 }
+/**
+ * One view the assistant manifest lets the agent take a screenshot of an entity from: `view` is the
+ * value of the `<Type>ScreenshotView` enum the agent asks for it by, `instanceName` the
+ * `agentScreenshot` component instance that renders it, and `description` what the view shows.
+ */
+export interface AssistantScreenshotView {
+    readonly view: string;
+    readonly instanceName: string;
+    readonly description: string;
+}
 /**
  * Experimental assistant manifest generated from the application spec `assistant` section. `sdl` is
  * the GraphQL schema text rebuilt from the resolved manifest; `fields` maps each GraphQL object type's exposed
@@ -46,7 +67,8 @@ export interface AssistantFieldOptions {
  * the recipe groups `meta { childRecipes }` and `addChild` expose, in manifest order, and absent
  * means none; `replaceRecipes` lists the same for `meta { replaceRecipes }` and `replaceEntity`;
  * `fieldOptions` lists, per entity type, the options edges `meta` exposes for its
- * writable fields, and absent means none; `actions` maps each custom `Mutation` field to the
+ * writable fields, and absent means none; `screenshots` lists, per entity type, the views
+ * `meta { screenshot }` renders, and absent means none; `actions` maps each custom `Mutation` field to the
  * declared action it runs, and absent means none; `lenses` holds the generated lens fragments, and
  * absent means none: `declarations` is the text the prompt shows, each lens once with its relations
  * spreading the lens itself, and `definitions` the valid GraphQL injected into an operation that
@@ -63,9 +85,12 @@ export interface AssistantManifest {
     readonly childRecipes?: Readonly<Record<string, readonly AssistantRecipeGroup[]>>;
     readonly replaceRecipes?: Readonly<Record<string, readonly AssistantRecipeGroup[]>>;
     readonly fieldOptions?: Readonly<Record<string, readonly AssistantFieldOptions[]>>;
+    readonly screenshots?: Readonly<Record<string, readonly AssistantScreenshotView[]>>;
     readonly actions?: Readonly<Record<string, string>>;
     readonly lenses?: {
         readonly declarations: string;
         readonly definitions: string;
     };
+    /** The project's own form elements, in YAML order; absent means none. */
+    readonly formElements?: readonly AssistantFormElementDescriptor[];
 }

package/dist/domain/application/assistant/assistant-manifest.js

@@ -1 +1 @@
-export{};
+export const ASSISTANT_HINTS=["sameForAllInstances","constantDuringSession"];

package/dist/domain/application/assistant/assistant-resolved-manifest.d.ts

@@ -1,4 +1,5 @@
-import type { AssistantFieldOptions, AssistantRecipeGroup } from './assistant-manifest.js';
+import type { AssistantFieldOptions, AssistantRecipeGroup, AssistantResolvedHint, AssistantScreenshotView } from './assistant-manifest.js';
+import type { AssistantFormElementDescriptor } from './form/index.js';
 /** JSON description of a scalar or recursively nested list, including nullability at each level. */
 export type AssistantValueType = {
     readonly kind: 'scalar';
@@ -50,12 +51,18 @@ export interface AssistantResolvedManifest {
     readonly childRecipes: Readonly<Record<string, AssistantResolvedRecipes>>;
     readonly replaceRecipes: Readonly<Record<string, AssistantResolvedRecipes>>;
     readonly optionsEdges: Readonly<Record<string, readonly AssistantResolvedOptionsEdge[]>>;
+    /** The screenshot views of each entity type with at least one, aliases expanded, in manifest order. */
+    readonly screenshots: Readonly<Record<string, readonly AssistantScreenshotView[]>>;
     readonly actionFields: readonly AssistantResolvedAction[];
+    /** The entity types that declare invariants, whose `meta` lists the warnings and notices they hold. */
+    readonly invariantTypes: readonly string[];
     /** The declared lenses by name: when to use each, and how many levels its tagged relations nest. */
     readonly lenses: Readonly<Record<string, {
         readonly description: string;
         readonly maxDepth: number;
     }>>;
+    /** The project's own form elements, in YAML order, which the prompt lists after the built-ins and the panel renders with their registered components. */
+    readonly formElements: readonly AssistantFormElementDescriptor[];
 }
 /** Optional mutation input for one stored field, using its exposed name. */
 export interface AssistantWritableField {
@@ -69,14 +76,8 @@ export interface AssistantWritableType {
     readonly entityType: string;
     readonly fields: readonly AssistantWritableField[];
 }
-/** Description hints resolved from recipe/option entries; no parse context is retained. */
-export declare const ASSISTANT_HINTS: readonly ['sameForAllInstances', 'constantDuringSession'];
-export type AssistantResolvedHint = (typeof ASSISTANT_HINTS)[number];
-/** Recipe groups and their description hints for one entity type. */
-export interface AssistantResolvedRecipes {
-    readonly groups: readonly AssistantRecipeGroup[];
-    readonly hints: readonly AssistantResolvedHint[];
-}
+/** The recipe groups of one kind on one entity type or alias key, in manifest order, each with its own hints. */
+export type AssistantResolvedRecipes = readonly AssistantRecipeGroup[];
 /** One options edge, carrying the write-validation contract and schema description hints. */
 export interface AssistantResolvedOptionsEdge {
     readonly options: AssistantFieldOptions;
@@ -113,6 +114,8 @@ export interface AssistantDeclarations {
     readonly writable: Readonly<Record<string, Readonly<Record<string, AssistantDeclaredWrite>>>>;
     readonly childRecipes: Readonly<Record<string, AssistantResolvedRecipes>>;
     readonly replaceRecipes: Readonly<Record<string, AssistantResolvedRecipes>>;
+    /** The screenshot views under the entity type or alias key that declares them. */
+    readonly screenshots: Readonly<Record<string, readonly AssistantScreenshotView[]>>;
 }
 /** An original field declaration, including metadata needed to reapply inheritance and enum descriptions. */
 export interface AssistantDeclaredField extends AssistantResolvedField {

package/dist/domain/application/assistant/assistant-resolved-manifest.js

@@ -1 +1 @@
-export const ASSISTANT_HINTS=["sameForAllInstances","constantDuringSession"];
+export{};

package/dist/domain/application/assistant/build-assistant-lenses.js

@@ -1,4 +1,4 @@
-import{NoUnusedFragmentsRule as e,parse as t,specifiedRules as i,validate as n}from"graphql";let s="AnyDomainEntity",r=[{name:"RecipeGroup",description:"A recipe group with its recipes, without their dry-runs.",selections:["groupId","name","description","recipes { ...Recipe }"]},{name:"Recipe",description:"A recipe without its dry-run.",selections:["key","name","description","imageUrl"]},{name:"FieldOption",description:"A value a field accepts, without its dry-run.",selections:["value","name","description","imageUrl","color"]},{name:"DryRun",description:"What a dry-run would do, with the ids of the entities it would change instead of the entities.",selections:["ok","deletedEntityIds","sideEffects","errors { type entityId message }","changedEntities { id }"]}],a=(e,t)=>0===t?e:`${e}__${t}`,l=e=>e.split("\n").map(e=>`# ${e}`.trimEnd()).join("\n"),o=(e,t,i)=>[`fragment ${e} on ${t} {`,...i.map(e=>`  ${e}`),"}"].join("\n"),p=(e,t,i)=>{let n=e=>"edge"===e.type.kind?`${e.name} { ${i} }`:e.name;return o(e,s,["id",...t.flatMap(({typeName:e,fields:t})=>e===s?t.map(n):[`... on ${e} {`,...t.map(e=>`  ${n(e)}`),"}"])])};export const buildAssistantLenses=(d,m)=>{let c=Object.entries(d.lenses).flatMap(([e,t])=>{let i=[s,...Object.keys(d.aliases).filter(e=>e!==s),...d.entityTypes].flatMap(t=>{let i=(d.fields[t]??[]).filter(t=>t.lenses?.includes(e));return i.length>0?[{typeName:t,fields:i}]:[]});return i.length>0?[{name:e,...t,conditions:i}]:[]}),$=r.filter(({name:e})=>void 0!==m.getType(e)),h=[...c.map(({name:e,description:t,maxDepth:i,conditions:n})=>{let s=n.some(({fields:e})=>e.some(e=>"edge"===e.type.kind));return`${l(s?`${t} ${`Nested relations carry the same selection up to ${i} ${1===i?"level":"levels"}, below that only \`id\`.`}`:t)}
+import{NoUnusedFragmentsRule as e,parse as t,specifiedRules as i,validate as n}from"graphql";let s="AnyDomainEntity",r=[{name:"RecipeGroup",description:"A recipe group with its recipes, without their dry-runs.",selections:["groupId","name","description","recipes { ...Recipe }"]},{name:"Recipe",description:"A recipe without its dry-run.",selections:["key","name","description","imageUrl"]},{name:"FieldOption",description:"A value a field accepts, without its dry-run.",selections:["value","name","description","imageUrl","color"]},{name:"DryRun",description:"What a dry-run would do, with the ids of the entities it would change instead of the entities.",selections:["ok","deletedEntityIds","sideEffects","warnings","errors { type entityId message }","changedEntities { id }"]}],a=(e,t)=>0===t?e:`${e}__${t}`,l=e=>e.split("\n").map(e=>`# ${e}`.trimEnd()).join("\n"),o=(e,t,i)=>[`fragment ${e} on ${t} {`,...i.map(e=>`  ${e}`),"}"].join("\n"),p=(e,t,i)=>{let n=e=>"edge"===e.type.kind?`${e.name} { ${i} }`:e.name;return o(e,s,["id",...t.flatMap(({typeName:e,fields:t})=>e===s?t.map(n):[`... on ${e} {`,...t.map(e=>`  ${n(e)}`),"}"])])};export const buildAssistantLenses=(d,m)=>{let c=Object.entries(d.lenses).flatMap(([e,t])=>{let i=[s,...Object.keys(d.aliases).filter(e=>e!==s),...d.entityTypes].flatMap(t=>{let i=(d.fields[t]??[]).filter(t=>t.lenses?.includes(e));return i.length>0?[{typeName:t,fields:i}]:[]});return i.length>0?[{name:e,...t,conditions:i}]:[]}),$=r.filter(({name:e})=>void 0!==m.getType(e)),h=[...c.map(({name:e,description:t,maxDepth:i,conditions:n})=>{let s=n.some(({fields:e})=>e.some(e=>"edge"===e.type.kind));return`${l(s?`${t} ${`Nested relations carry the same selection up to ${i} ${1===i?"level":"levels"}, below that only \`id\`.`}`:t)}
 ${p(e,n,`...${e}`)}`}),...$.map(({name:e,description:t,selections:i})=>`${l(t)}
 ${o(e,e,i)}`)].join("\n\n"),u=[...c.flatMap(({name:e,maxDepth:t,conditions:i})=>Array.from({length:t+1},(n,s)=>p(a(e,s),i,s<t?`...${a(e,s+1)}`:"id"))),...$.map(({name:e,selections:t})=>o(e,e,t))].join("\n\n");if(""!==u){let s=c.length>0?`entities { ${c.map(({name:e})=>`...${e}`).join(" ")} }`:"__typename",r=n(m,t(`${u}