@salsita-ai/sdk 0.50.0-develop.f101f4c3c9 → 0.50.0-develop.f354d3576d

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

@@ -40,7 +40,31 @@ pnpm phoenix dev
 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.
 
-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 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
 
@@ -163,7 +187,9 @@ A project has one generated env file. Phoenix keeps it in `.phoenix/`, as `.phoe
 - `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 `.phoenix/` and with it `.phoenix/.env.generated`; the next `phoenix dev` prepares the development deployment again. A root `.env.generated` stays.
+- `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.
 
@@ -240,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.
 
@@ -305,14 +331,16 @@ Starts the full development environment: Vite dev server, development webhook tu
 | `--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.
 
-With the application-spec pipeline, the SDK's own Lingui CLI runs with the configuration 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.
+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.
 
@@ -320,6 +348,7 @@ The dev server watches for changes in:
 
 - `spec/**/*.yaml` — Domain specification files
 - `src/**/*.{ts,tsx,yaml,yml,json,html,css}` — Source files
+- `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.
 
@@ -336,7 +365,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.
 
@@ -403,7 +436,7 @@ Set initial values from a local production build with roughly 5–10% headroom t
 
 ### `phoenix clean`
 
-Removes `.phoenix/` and regenerates all project files from scratch. It 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` also removes `node_modules/` and runs `pnpm install`. 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
@@ -534,7 +567,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.'
@@ -609,8 +642,6 @@ 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`
@@ -725,7 +756,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.
 
@@ -750,11 +781,22 @@ Revokes the token on the server and removes it from the credentials file. `--reg
 
 ### `phoenix deploy`
 
-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). 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.
+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]`
 
@@ -772,14 +814,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
 

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

@@ -80,9 +80,10 @@ a file can share its name with a file in another entity folder.
 
 Two naming limits still apply:
 
-- Transformer file names must be unique across all subfolders of `src/transformers/`, because each transformer
-  registers under its file name. Application-spec projects also treat names that differ only in letter case or dashes
-  as the same name.
+- Transformer file names must be unique across all subfolders of `src/transformers/`, and names that differ only in
+  letter case or dashes count as the same name: each `transformers:` entry of the spec names the file that holds its
+  transformer that way. The transformer the file builds carries the entry's name exactly, as `build('clampWidth')`
+  does for the entry `clampWidth`.
 - Files named `index.ts` inside entity folders are not auto-registered, except in application-spec projects. Give
   entity files descriptive names instead.
 
@@ -155,7 +156,7 @@ In a project on the legacy pipeline (see [Current and legacy project tooling](?p
 
 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:
+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. An install that skipped a build script writes a placeholder entry under `allowBuilds` instead of `true` or `false`; replace it, because the platform build stops on it and `phoenix deploy` refuses it. 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:
@@ -179,9 +180,9 @@ Phoenix generates typed interfaces available globally:
 
 Types are auto-generated in `.phoenix/` from your domain schema:
 
-- `.phoenix/configurator-interface.ts` - Configurator interface types
-- `.phoenix/admin-interface.ts` - Admin interface types
-- `.phoenix/globals.d.ts` - Global type definitions
+- `.phoenix/configurator-globals.ts` - assigns `phx.frontend`
+- `.phoenix/admin-globals.ts` - assigns `phx.frontend.admin`
+- `.phoenix/globals.d.ts` - the type of the `phx` global
 
 Access in code:
 
@@ -199,23 +200,23 @@ type CustomMaterial = Phx['AdminModel']['CustomMaterial']
 
 ### Root Level Files
 
-| 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.
+| 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              | Project-owned instructions; preserved by sync |
+| `.claude/skills/phoenix/`, `.agents/skills/phoenix/` | Yes             | SDK-managed files; see below                  |
+
+With the application-spec pipeline, sync does not write `README.md`, `.env.example`, `.env.ci` or the `README.md` files in `assets/public/` and `assets/private/`. These files are yours to create and edit; sync preserves them. The legacy pipeline writes `README.md`, `.env.example`, `.env.ci` and the asset-folder `README.md` files when they are missing.
 
 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).
 
@@ -229,30 +230,26 @@ 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, 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 `tsconfig.json`, 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
+- **Generated files in `.phoenix/`** — Rewritten on each build. In application-spec projects, `.phoenix/workspace/` is project-owned: sync, build and clean preserve it, and deploy includes it in the private source archive rather than build inputs or public assets. Rebuilds also keep `.phoenix/variants/`, which holds variant option files, and `.phoenix/.env.generated`, the generated env file of `phoenix dev`.
 - `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, runs `phoenix deps`, installs, then runs `phoenix sync`. Other skill folders are never touched.
-
-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`.
+- The SDK-managed `phoenix` and `phoenix-*` folders under `.claude/skills/` and `.agents/skills/` — sync rewrites the current bundle, removes unrecognized files inside it and deletes retired folders with those prefixes. Keep custom files outside those prefixes. Sync also removes the SDK blocks from legacy `CLAUDE.md` and `.cursor/rules/phoenix.mdc`, preserves surrounding project text, deletes files left empty and removes the legacy review-command files.
 
 ### Markers for Partial Auto-Generation
 
-`.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` 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. It ignores generated entries inside `.phoenix/` but leaves `.phoenix/workspace/` available for version control, so working records can travel with a checkout:
 
 ```gitignore
 # ===== BEGIN PHOENIX AUTO-GENERATED =====
-# ... Phoenix-managed ignores ...
+# ... other Phoenix-managed ignores ...
+**/.phoenix/*
+!**/.phoenix/workspace/
 # ===== END PHOENIX AUTO-GENERATED =====
 
 # Your custom ignores (preserved)
@@ -263,6 +260,8 @@ With the application-spec pipeline (see [Current and legacy project tooling](?pa
 
 ### Safe to Edit
 
+- `.phoenix/workspace/` (application-spec project records and specification sources; include durable records in version control)
+- `docs/` (client documents such as rendered specification PDFs; deploy includes them in the private source archive, not in build inputs or public assets)
 - `src/` (except compiled `src/locales/**/*.ts` files)
 - `spec/`
 - `public/`
@@ -274,7 +273,7 @@ With the application-spec pipeline (see [Current and legacy project tooling](?pa
 - `.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`
+- `README.md`
 
 ## File Naming Conventions
 
@@ -355,32 +354,30 @@ project-root/
 │
 ├── blender/                       # 3D model source files (Blender)
 │
-├── .phoenix/                      # AUTO-GENERATED (DO NOT EDIT)
-│   ├── domain/                    # Compiled domain specs
-│   │   ├── model/                 # Configurator model
-│   │   └── admin-model/           # Admin model
-│   ├── webhooks/                  # Generated webhook files
-│   │   ├── index.ts
-│   │   └── builders.ts
-│   ├── .swc/                      # SWC transpiled sources
-│   ├── .lingui/                   # Compiled i18n catalogs
-│   ├── variants/                  # Option files of `phoenix variants`, written by coding agents
+├── .phoenix/                      # Generated output, except the project-owned workspace/
+│   ├── workspace/                 # Specification sources and project records, available for version control
+│   ├── variants/                  # Option files of `phoenix variants`; kept by rebuilds, removed by clean
 │   ├── dist/                      # Build output
-│   │   ├── frontend/              # Frontend bundles
-│   │   └── webhooks/              # Webhook bundles
 │   ├── public -> ../public        # Symlink to public
+│   ├── application-spec.json      # The parsed application spec
+│   ├── domain-spec.ts             # Domain model and reflections; assigns `phx.domain`
+│   ├── spec-code.ts               # Code generated from the spec
+│   ├── spec-messages.ts           # Messages of the spec
 │   ├── domain.ts                  # Domain exports
 │   ├── configurator.ts            # Configurator entry
+│   ├── configurator-config.ts     # Configurator configuration
+│   ├── configurator-globals.ts    # Assigns `phx.frontend`
+│   ├── embedded-configurator.ts   # Embedded configurator entry
 │   ├── admin.ts                   # Admin entry
+│   ├── admin-config.ts            # Admin configuration
+│   ├── admin-globals.ts           # Assigns `phx.frontend.admin`
 │   ├── embedded-admin.ts          # Embedded admin entry
+│   ├── webhook.ts                 # Webhook entry
+│   ├── webhook-builders.ts        # Assigns `phx.webhooks`
 │   ├── editor.tsx                 # Editor component
-│   ├── frontend.config.ts         # Frontend configuration
-│   ├── webhooks.config.ts         # Webhook configuration
-│   ├── phoenix.config.ts          # Phoenix framework config
-│   ├── configurator-interface.ts  # Configurator interface types
-│   ├── admin-interface.ts         # Admin interface types
-│   ├── i18n.ts                    # i18n initialization
-│   ├── globals.d.ts               # Global type definitions
+│   ├── frontend.config.ts         # Frontend runtime configuration
+│   ├── webhooks.config.ts         # Webhook runtime configuration
+│   ├── globals.d.ts               # The type of the `phx` global
 │   ├── tsconfig.json              # TypeScript settings, extended by the root tsconfig.json
 │   ├── .linguirc                  # Lingui configuration
 │   ├── index.html                 # Configurator HTML entry

package/dist/docs/phoenix/quickstart.mdx

@@ -267,7 +267,7 @@ export default phx.domain.implementCustomExpressions({
 })
 ```
 
-Application projects receive `phx` as a global. Storybook examples cannot rely on that project environment, so the complete example below imports it from `../../.phoenix/phx.js`; that import is the only intentional difference.
+Application projects receive `phx` as a global. Storybook examples cannot rely on that project environment, so the example's files import it from `../../.phoenix/phx.js`; a project leaves that import out, the only intentional difference.
 
 After sync, the property panel offers Grey, Black, and White. Selecting one updates the domain field, recomputes `$frameColor`, and smoothly changes the real `metalMaterial` in the model. Explore the individual pieces in [Attribute List Selector](?path=/docs/controls-select-attribute-listselect--docs) and [Material Transition](?path=/docs/3d-scene-materials-transition--docs).
 
@@ -1092,8 +1092,6 @@ components:
 ### ./src/expressions/table.ts
 
 ```ts
-import { phx } from '../../.phoenix/phx.js'
-
 const FRAME_COLORS = {
   Grey: '#6f7378',
   Black: '#202124',

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

@@ -22,7 +22,7 @@ pnpm install
 pnpm phoenix sync
 ```
 
-`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.
+`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 TypeScript, lint and formatting config and the other generated files described in [Project Structure](?path=/docs/phoenix-project-structure--docs#root-level-files). 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, and gains only the entries it lacks (see [Starting a New Project](?path=/docs/phoenix-phoenix-cli--docs#starting-a-new-project)).
 
@@ -36,7 +36,7 @@ The starter `spec/application.yaml` begins with `project: default`, which means
 pnpm phoenix login <workspace>
 ```
 
-`phoenix login` opens Studio, where you name the token and approve the sign-in. Only a super admin of the workspace can open Studio, so only a super admin can approve it. The CLI suggests `phoenix CLI on <computer>`; a name of your own, such as the agent and the machine, tells your tokens apart later. Studio sends a one-time code back to the CLI on `127.0.0.1`, the CLI exchanges it for a personal token and returns the browser to Studio, which confirms the sign-in. The code only works for the CLI that asked for it and expires after five minutes. **Deny** stops the waiting CLI at once and creates no token. Use `--no-open` to print the link instead of opening a browser.
+`phoenix login` opens Studio, where you name the token and approve the sign-in. Only a super admin of the workspace can open Studio, so only a super admin can approve it. The CLI suggests `phoenix CLI on <computer>`; a name of your own, such as its purpose and the machine, tells your tokens apart later. Studio sends a one-time code back to the CLI on `127.0.0.1`, the CLI exchanges it for a personal token and returns the browser to Studio, which confirms the sign-in. The code only works for the CLI that asked for it and expires after five minutes. **Deny** stops the waiting CLI at once and creates no token. Use `--no-open` to print the link instead of opening a browser.
 
 The CLI stores the token in `~/.phoenix/credentials.json`, readable only by you, with one entry per server. `PHOENIX_CREDENTIALS_FILE` moves the file. The token acts for you in your workspace until you revoke it. It stops working when you are removed from the workspace or banned.
 
@@ -63,10 +63,6 @@ Every user who signs the CLI in gets their own development environment, so a tea
 
 `pnpm phoenix dev --persistence local-storage` still runs the project without any server, with state kept in the browser.
 
-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.
-
 ## 4. Deploy
 
 ```bash
@@ -76,7 +72,7 @@ pnpm phoenix deploy
 `phoenix deploy` goes through these steps:
 
 1. It validates the application spec.
-2. It packs the project files: the `.yaml` files in `spec`, everything in `src`, `mocks`, `assets`, `public` and `templates`, and `package.json`, `tsconfig.json`, `pnpm-lock.yaml`, `pnpm-workspace.yaml`, `.gitignore`, `CLAUDE.md` and `.cursor/rules/phoenix.mdc`. Every `node_modules`, `.phoenix` and `__generated` folder, every `.DS_Store` and `._*` file and every `.env` and `.env.*` file are left out, at any depth.
+2. It packs the project files: the `.yaml` files in `spec`, everything in `src`, `mocks`, `assets`, `public` and `templates`, and `package.json`, `tsconfig.json`, `pnpm-lock.yaml`, `pnpm-workspace.yaml`, `.gitignore`, `CLAUDE.md` and `.cursor/rules/phoenix.mdc`. Project-owned `.phoenix/workspace/` records and the client documents in `docs/` also travel in the private source archive; they are excluded from build inputs and public assets. Other `.phoenix` contents, every `node_modules` and `__generated` folder, every `.DS_Store` and `._*` file and every `.env` and `.env.*` file are left out.
 3. It asks the server for a build. The server compares your domain model with the deployed one and refuses, before anything is uploaded, a model that changed under an already deployed model version; see [Migrations](?path=/docs/phoenix-migrations--docs).
 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.
@@ -85,7 +81,9 @@ On the server, the install runs pnpm. It follows your `pnpm-lock.yaml` and `pnpm
 
 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.
 
@@ -97,8 +95,6 @@ Tell us what is broken, confusing or missing, from wherever you are:
 - 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.
 
-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.
-
 ## Known limits
 
 - You can deploy once the workspace's first deployment is live. Until then, `phoenix deploy` tells you the workspace is still being set up.
@@ -107,5 +103,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/state-management.mdx

@@ -315,14 +315,15 @@ const update = phx.frontend.updates.DomainEntityModification({
   updateTag: 'UserResizing',
 })
 
-// Component modification
+// Component modification (distanceDimensionComponent from '@salsita-ai/sdk/domain')
 const componentUpdate = phx.frontend.updates.ComponentModification({
   componentInstance: {
     entityId: 'Cabinet-1',
-    componentType: selectionComponent,
-    instanceName: 'main',
+    componentType: distanceDimensionComponent,
+    instanceName: 'width',
   },
-  writableState: { selected: true },
+  writableState: { value: 1200 },
+  updateTag: 'UserResizing',
 })
 ```
 
@@ -356,7 +357,7 @@ storeSystem.commit()
 
 During commitment:
 
-- OnBeforeCommit hooks can intercept or modify the commit
+- `onBeforeCommit` hooks can hold the commit by returning `false`, for example to ask the user first; a held commit resets the rendered slice, and the hook can commit the same emission later through the `emit` callback it receives. A hook cannot change what is committed
 - Final validation occurs
 - Committed state is emitted to committed slice
 - All attempts (valid or invalid) are emitted to potentiallyInvalid slice
@@ -426,7 +427,7 @@ Validation produces structured results indicating state validity:
 type StateValidationResult =
   | { valid: true, severity: null }  // Perfect state
   | { valid: true, severity: 'warning' | 'notice', entityViolations: [...] }  // Valid with warnings
-  | { valid: false, severity: 'fatal' | 'fixable', entityViolations: [...] }  // Invalid but recoverable
+  | { valid: false, severity: 'fatal' | 'fixable', entityViolations: [...] }  // Invalid, never committed
   | { valid: false, severity: 'uncaught', error: Error }  // Critical error
 ```
 
@@ -434,7 +435,7 @@ type StateValidationResult =
 
 Different violation severities have different behavioral impacts:
 
-**Notice**: Informational only, doesn't affect functionality
+**Notice**: Informational only: the change is committed and saved, and nothing is blocked
 
 ```typescript
 // Example: Suggesting better material combinations
@@ -445,7 +446,7 @@ Different violation severities have different behavioral impacts:
 }
 ```
 
-**Warning**: Alerts user but allows operation
+**Warning**: The change is committed and saved, but the configuration cannot be finalized
 
 ```typescript
 // Example: Performance warnings
@@ -456,18 +457,18 @@ Different violation severities have different behavioral impacts:
 }
 ```
 
-**Fixable**: Prevents some actions but can be auto-corrected
+**Fixable**: Rejected like `fatal`; marks a violation that a project [transformer](?path=/docs/other-features-transformers--docs) repairs before validation. Nothing corrects it automatically: without such a transformer the change is not committed.
 
 ```typescript
 // Example: Dimension constraints
 {
   type: 'dimensionTooLarge',
   severity: 'fixable',
-  message: 'Cabinet width exceeds room width, adjusting automatically'
+  message: 'Cabinet width exceeds room width'
 }
 ```
 
-**Fatal**: Prevents finalization and major operations
+**Fatal**: The change is never committed: it does not reach the rendered state, the undo stack or the saved configuration
 
 ```typescript
 // Example: Critical business rules
@@ -488,8 +489,8 @@ const emission = storeSystem.stage(updates)
 if (emission.validity.valid) {
   // State is valid, can be rendered
   renderState(emission.state)
-} else if (emission.validity.severity === 'fatal') {
-  // Fatal errors prevent rendering updates
+} else if (emission.validity.severity === 'fatal' || emission.validity.severity === 'fixable') {
+  // The change is rejected: the rendered slice keeps the last valid state
   showErrors(emission.validity.entityViolations)
 }
 
@@ -552,9 +553,10 @@ Phoenix uses `useSyncExternalStore` to efficiently synchronize store state with
 // Select specific entities
 const cabinets = phx.frontend.useStoreSelector(state => state.state.entities.filter(e => e.type === 'Cabinet'), [])
 
-// Select computed values with dependencies
-const totalPrice = phx.frontend.useStoreSelector(
-  state => state.state.entities.filter(e => e.type === 'Cabinet').reduce((sum, cabinet) => sum + cabinet.$price, 0),
+// Select computed values: `state.state.entities` holds raw entities without `$` fields,
+// so read expressions and relations from an enhanced entity, here the root `Room`
+const totalPrice = phx.frontend.useRootEntitySelector(
+  room => room.$cabinets.reduce((sum, cabinet) => sum + cabinet.$price, 0),
   []
 )