@xmachines/docs 4.0.0 → 5.0.1

package/api/@xmachines/shared/vite-aliases/functions/xmResolve.md

@@ -6,7 +6,7 @@
 function xmResolve(importMetaUrl, extra?): ResolveOptions & object;
 ```
 
-Defined in: [vite-aliases.ts:275](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vite-aliases.ts#L275)
+Defined in: [vite-aliases.ts:275](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vite-aliases.ts#L275)
 
 Full Vite `resolve` config for @xmachines/* workspace packages.
 

package/api/@xmachines/shared/vite-aliases/functions/xmSvelteRunes.md

@@ -6,7 +6,7 @@
 function xmSvelteRunes(): object;
 ```
 
-Defined in: [vite-aliases.ts:334](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vite-aliases.ts#L334)
+Defined in: [vite-aliases.ts:334](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vite-aliases.ts#L334)
 
 Svelte plugin options that enforce runes mode for workspace sources only.
 
@@ -35,4 +35,4 @@ one and change the other.
 
 | Name                      | Type                                                    | Defined in                                                                                                                  |
 | ------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
-| `dynamicCompileOptions()` | (`data`) => \| \{ `runes`: `boolean`; \} \| `undefined` | [vite-aliases.ts:335](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vite-aliases.ts#L335) |
+| `dynamicCompileOptions()` | (`data`) => \| \{ `runes`: `boolean`; \} \| `undefined` | [vite-aliases.ts:335](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vite-aliases.ts#L335) |

package/api/@xmachines/shared/vitest/functions/defineXmBrowserConfig.md

@@ -6,7 +6,7 @@
 function defineXmBrowserConfig(importMetaUrl, overrides, options?): UserConfig;
 ```
 
-Defined in: [vitest.ts:209](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L209)
+Defined in: [vitest.ts:209](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L209)
 
 Create a Vitest browser-mode config with XMachines workspace defaults.
 

package/api/@xmachines/shared/vitest/functions/defineXmVitestConfig.md

@@ -6,7 +6,7 @@
 function defineXmVitestConfig(importMetaUrl, overrides): UserConfig;
 ```
 
-Defined in: [vitest.ts:65](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L65)
+Defined in: [vitest.ts:65](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L65)
 
 Create a Vitest config with XMachines workspace defaults.
 

package/api/@xmachines/shared/vitest/interfaces/XmBrowserConfigOptions.md

@@ -2,7 +2,7 @@
 
 # Interface: XmBrowserConfigOptions
 
-Defined in: [vitest.ts:159](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L159)
+Defined in: [vitest.ts:159](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L159)
 
 Options for [defineXmBrowserConfig](../functions/defineXmBrowserConfig.md) that live outside the plain
 Vitest config overrides.
@@ -11,6 +11,6 @@ Vitest config overrides.
 
 | Property                                           | Type                                     | Description                                                                                                                                                                                                                                                                                                                 | Defined in                                                                                                      |
 | -------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| <a id="property-base"></a> `base?`                 | `UserConfig`                             | Base Vite config to layer the browser test config on top of (typically a demo's `vite.config.ts`). When set, the base is expected to provide its own `resolve`/`plugins`, so the `cacheDir` and `resolve` defaults are not applied — mirroring the previous `mergeConfig(viteConfig, ...)` pattern in demo browser configs. | [vitest.ts:167](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L167) |
-| <a id="property-optimizedeps"></a> `optimizeDeps?` | `string`[]                               | Extra package specifiers to pre-bundle via `xmOptimizeDeps` (e.g. `["@xmachines/json-render-vue", "@xmachines/json-render-vue/schema"]`). Ignored when `overrides.optimizeDeps` is set, which then replaces the default `xmOptimizeDeps()` wholesale.                                                                       | [vitest.ts:174](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L174) |
-| <a id="property-resolve"></a> `resolve?`           | `Partial`\<`ResolveOptions` & `object`\> | Extra resolve options forwarded to `xmResolve` (e.g. `conditions` or additional `alias` entries). Not applied when `base` is set — the base config owns `resolve` in that layout.                                                                                                                                           | [vitest.ts:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v4.0.0/packages/shared/config/vitest.ts#L180) |
+| <a id="property-base"></a> `base?`                 | `UserConfig`                             | Base Vite config to layer the browser test config on top of (typically a demo's `vite.config.ts`). When set, the base is expected to provide its own `resolve`/`plugins`, so the `cacheDir` and `resolve` defaults are not applied — mirroring the previous `mergeConfig(viteConfig, ...)` pattern in demo browser configs. | [vitest.ts:167](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L167) |
+| <a id="property-optimizedeps"></a> `optimizeDeps?` | `string`[]                               | Extra package specifiers to pre-bundle via `xmOptimizeDeps` (e.g. `["@xmachines/json-render-vue", "@xmachines/json-render-vue/schema"]`). Ignored when `overrides.optimizeDeps` is set, which then replaces the default `xmOptimizeDeps()` wholesale.                                                                       | [vitest.ts:174](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L174) |
+| <a id="property-resolve"></a> `resolve?`           | `Partial`\<`ResolveOptions` & `object`\> | Extra resolve options forwarded to `xmResolve` (e.g. `conditions` or additional `alias` entries). Not applied when `base` is set — the base config owns `resolve` in that layout.                                                                                                                                           | [vitest.ts:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v5.0.1/packages/shared/config/vitest.ts#L180) |

package/api/README.md

@@ -4,12 +4,13 @@
 
 - [@xmachines/play](@xmachines/play/README.md)
 - [@xmachines/play-actor](@xmachines/play-actor/README.md)
+- [@xmachines/play-atom](@xmachines/play-atom/README.md)
 - [@xmachines/play-dom](@xmachines/play-dom/README.md)
 - [@xmachines/play-dom-router](@xmachines/play-dom-router/README.md)
+- [@xmachines/play-pattern](@xmachines/play-pattern/README.md)
 - [@xmachines/play-react](@xmachines/play-react/README.md)
 - [@xmachines/play-react-router](@xmachines/play-react-router/README.md)
 - [@xmachines/play-router](@xmachines/play-router/README.md)
-- [@xmachines/play-signals](@xmachines/play-signals/README.md)
 - [@xmachines/play-solid](@xmachines/play-solid/README.md)
 - [@xmachines/play-solid-router](@xmachines/play-solid-router/README.md)
 - [@xmachines/play-svelte](@xmachines/play-svelte/README.md)

package/api/llms.txt

@@ -17,7 +17,7 @@
 
 ## Package Roles
 
-- `Core runtime`: [@xmachines/play](@xmachines/play/README.md), [@xmachines/play-actor](@xmachines/play-actor/README.md), [@xmachines/play-signals](@xmachines/play-signals/README.md), [@xmachines/play-router](@xmachines/play-router/README.md), and [@xmachines/play-xstate](@xmachines/play-xstate/README.md). Catalog and component registry are provided by `@xmachines/json-render-core` and the framework rendering packages.
+- `Core runtime`: [@xmachines/play](@xmachines/play/README.md), [@xmachines/play-actor](@xmachines/play-actor/README.md), [@xmachines/play-atom](@xmachines/play-atom/README.md), [@xmachines/play-router](@xmachines/play-router/README.md), and [@xmachines/play-xstate](@xmachines/play-xstate/README.md). Catalog and component registry are provided by `@xmachines/json-render-core` and the framework rendering packages.
 - `Rendering`: [@xmachines/play-react](@xmachines/play-react/README.md), [@xmachines/play-solid](@xmachines/play-solid/README.md), [@xmachines/play-svelte](@xmachines/play-svelte/README.md), and [@xmachines/play-vue](@xmachines/play-vue/README.md).
 - `Router adapters`: [@xmachines/play-react-router](@xmachines/play-react-router/README.md), [@xmachines/play-tanstack-react-router](@xmachines/play-tanstack-react-router/README.md), [@xmachines/play-solid-router](@xmachines/play-solid-router/README.md), [@xmachines/play-tanstack-solid-router](@xmachines/play-tanstack-solid-router/README.md), [@xmachines/play-vue-router](@xmachines/play-vue-router/README.md), [@xmachines/play-sveltekit-router](@xmachines/play-sveltekit-router/README.md), and [@xmachines/play-svelte-spa-router](@xmachines/play-svelte-spa-router/README.md), all built on top of [Routable](@xmachines/play-router/index/interfaces/Routable.md) actors and shared route metadata.
 - `Shared tooling`: [@xmachines/shared](@xmachines/shared/README.md) for shared config and workspace-level support files.
@@ -25,11 +25,12 @@
 ## API
 - [@xmachines/play](@xmachines/play/README.md): Core Play types and runtime contracts
 - [@xmachines/play-actor](@xmachines/play-actor/README.md): The actor contract: state and send. It names no state machine library, and each capability interface lives with its own package
-- [@xmachines/play-url](@xmachines/play-url/README.md): The URL language: the URLPattern grammar, a base path, and the params of a framework router
+- [@xmachines/play-pattern](@xmachines/play-pattern/README.md): The route pattern language: one parse of the URLPattern pathname grammar, and the path that it builds back. It carries no URLPattern API and no polyfill
+- [@xmachines/play-url](@xmachines/play-url/README.md): The URL layer: the URLPattern API, a base path, a location splitter, and the params of a framework router
 - [@xmachines/play-view](@xmachines/play-view/README.md): The shared view half of every renderer: Viewable, PlaySpec, and the view store lifecycle
 - [@xmachines/play-dom](@xmachines/play-dom/README.md): Vanilla DOM renderer for Viewable actors
 - [@xmachines/play-dom-router](@xmachines/play-dom-router/README.md): Vanilla DOM browser history, router, and actor↔URL synchronization
-- [@xmachines/play-signals](@xmachines/play-signals/README.md): Signal primitives used by Play actors and adapters
+- [@xmachines/play-atom](@xmachines/play-atom/README.md): Atom primitives used by Play actors and adapters
 - [@xmachines/play-router](@xmachines/play-router/README.md): Route extraction, route maps, and shared routing infrastructure
 - [@xmachines/play-tanstack-router](@xmachines/play-tanstack-router/README.md): Shared framework-agnostic TanStack Router bridge base
 - [@xmachines/play-xstate](@xmachines/play-xstate/README.md): XState-backed player and actor integration

package/contributing/architecture.md

@@ -1,20 +1,20 @@
 # Architecture
 
-XMachines Play implements the **Universal Player Architecture** — a layered, actor-authority design where XState machines are the single source of truth for routing, navigation, and view selection. Infrastructure (routers, renderers) is strictly passive: it observes actor signals and reflects them, never enforcing guards or making decisions.
+XMachines Play implements the **Universal Player Architecture** — a layered, actor-authority design where XState machines are the single source of truth for routing, navigation, and view selection. Infrastructure (routers, renderers) is strictly passive: it observes actor atoms and reflects them, never enforcing guards or making decisions.
 
 ## System Overview
 
-XMachines JS is the JavaScript/TypeScript reference implementation of the **Universal Player Architecture** ([Play RFC](../rfc/play.md)). It is a monorepo of modular packages that strictly separates **business logic (the Actor)** from **infrastructure (router adapters and view renderers)**. An XState v5 state machine is the single source of truth; it owns all state, guards, and route validity. Infrastructure is passive: it observes TC39 Signals emitted by the Actor and proposes state changes via typed events. The Actor's guards make every navigation and transition decision. Communication across the boundary is exclusively through TC39 Signals — never subscriptions, callbacks, or direct state mutation. Five architectural invariants (documented in the [Play RFC](../rfc/play.md)) enforce this contract across the entire package graph.
+XMachines JS is the JavaScript/TypeScript reference implementation of the **Universal Player Architecture** ([Play RFC](../rfc/play.md)). It is a monorepo of modular packages that strictly separates **business logic (the Actor)** from **infrastructure (router adapters and view renderers)**. An XState v5 state machine is the single source of truth; it owns all state, guards, and route validity. Infrastructure is passive: it observes atoms emitted by the Actor and proposes state changes via typed events. The Actor's guards make every navigation and transition decision. Communication across the boundary is exclusively through atoms — never subscriptions, callbacks, or direct state mutation. Five architectural invariants (documented in the [Play RFC](../rfc/play.md)) enforce this contract across the entire package graph.
 
 ## Architectural Invariants
 
-| ID     | Name                       | Rule                                                                                                                                     |
-| ------ | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| INV-01 | **Actor Authority**        | Infrastructure proposes intents via `play.route` events; Actor decides via XState guards                                                 |
-| INV-02 | **Strict Separation**      | No direct dependencies between Actor and Infrastructure layers. `play-xstate` never imports UI frameworks or routing libraries           |
-| INV-03 | **Passive Infrastructure** | Infrastructure observes Actor signals, never controls state                                                                              |
-| INV-04 | **Signal-Only Reactivity** | All Actor→Infrastructure state changes flow through TC39 Signals (`Signal.State`, `Signal.Computed`). No subscriptions or event emitters |
-| INV-05 | **State-Driven Reset**     | Invalid external navigation is overwritten by Actor-derived state                                                                        |
+| ID     | Name                       | Rule                                                                                                                           |
+| ------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| INV-01 | **Actor Authority**        | Infrastructure proposes intents via `play.route` events; Actor decides via XState guards                                       |
+| INV-02 | **Strict Separation**      | No direct dependencies between Actor and Infrastructure layers. `play-xstate` never imports UI frameworks or routing libraries |
+| INV-03 | **Atom-Only Reactivity**   | All Actor→Infrastructure state changes flow through atoms (`Atom`, `ReadonlyAtom`). No subscriptions or event emitters         |
+| INV-04 | **Passive Infrastructure** | Infrastructure observes Actor atoms, never controls state                                                                      |
+| INV-05 | **State-Driven Reset**     | Invalid external navigation is overwritten by Actor-derived state                                                              |
 
 ## Component Diagram
 
@@ -22,7 +22,7 @@ XMachines JS is the JavaScript/TypeScript reference implementation of the **Univ
 graph TD
     subgraph Layer0["Layer 0 — Protocol / Primitives"]
         play["@xmachines/play\n(PlayEvent, PlayError)"]
-        signals["@xmachines/play-signals\n(TC39 Signal, watchSignal)"]
+        atoms["@xmachines/play-atom\n(atoms, watchAtom)"]
         shared["@xmachines/shared\n(tsconfig, oxlint, oxfmt)"]
     end
 
@@ -60,12 +60,12 @@ graph TD
     end
 
     play --> actor
-    signals --> actor
+    atoms --> actor
     actor --> xstate
     actor --> router
     actor --> Views
-    signals --> xstate
-    signals --> router
+    atoms --> xstate
+    atoms --> router
     play --> xstate
     play --> router
     router --> RouterAdapters
@@ -77,11 +77,12 @@ graph TD
 | Package                                                                                           | Responsibility                                          | Key File                                                            |
 | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------- |
 | [`@xmachines/play`](../api/@xmachines/play/README.md)                                             | Core protocol types and error base class                | `packages/play/src/index.ts`                                        |
-| [`@xmachines/play-signals`](../api/@xmachines/play-signals/README.md)                             | TC39 Signal polyfill isolation wrapper                  | `packages/play-signals/src/index.ts`                                |
+| [`@xmachines/play-atom`](../api/@xmachines/play-atom/README.md)                                   | The atom primitives, isolated in one package            | `packages/play-atom/src/index.ts`                                   |
 | [`@xmachines/play-actor`](../api/@xmachines/play-actor/README.md)                                 | `PlayActor`, and nothing else                           | `packages/play-actor/src/play-actor.ts`                             |
 | [`@xmachines/play-view`](../api/@xmachines/play-view/README.md)                                   | `Viewable`, `PlaySpec`, the shared view half            | `packages/play-view/src/view-types.ts`                              |
 | [`@xmachines/play-xstate`](../api/@xmachines/play-xstate/README.md)                               | XState v5 adapter: `definePlayer`, `PlayerActor`        | `packages/play-xstate/src/player-actor.ts`                          |
-| [`@xmachines/play-url`](../api/@xmachines/play-url/README.md)                                     | The URLPattern grammar, a base path, framework params   | `packages/play-url/src/pattern-grammar.ts`                          |
+| [`@xmachines/play-pattern`](../api/@xmachines/play-pattern/README.md)                             | The route pattern language: one parse, and `buildPath`  | `packages/play-pattern/src/pattern-grammar.ts`                      |
+| [`@xmachines/play-url`](../api/@xmachines/play-url/README.md)                                     | The URLPattern API, a base path, framework params       | `packages/play-url/src/url-pattern-utils.ts`                        |
 | [`@xmachines/play-router`](../api/@xmachines/play-router/README.md)                               | `RouteMap`, `RouterBridgeBase`, the provider lifecycle  | `packages/play-router/src/router-bridge-base.ts`                    |
 | [`@xmachines/play-router/xstate`](../api/@xmachines/play-router/README.md)                        | Route extraction from an XState machine                 | `packages/play-router/src/xstate/extract-routes.ts`                 |
 | [`@xmachines/play-react`](../api/@xmachines/play-react/README.md)                                 | React renderer: `ActorProvider`, `PlayRenderer`         | `packages/play-react/src/ActorProvider.tsx`                         |
@@ -98,7 +99,7 @@ graph TD
 | [`@xmachines/play-dom-router`](../api/@xmachines/play-dom-router/README.md)                       | Vanilla DOM hash/history router bridge                  | `packages/play-dom-router/src/dom-router-bridge.ts`                 |
 | [`@xmachines/play-sveltekit-router`](../api/@xmachines/play-sveltekit-router/README.md)           | SvelteKit router bridge                                 | `packages/play-sveltekit-router/src/sveltekit-router-bridge.ts`     |
 | [`@xmachines/play-svelte-spa-router`](../api/@xmachines/play-svelte-spa-router/README.md)         | Svelte SPA Router bridge                                | `packages/play-svelte-spa-router/src/svelte-spa-router-bridge.ts`   |
-| `@xmachines/shared`                                                                               | Shared configs: tsconfig, oxlint, oxfmt, vitest         | `packages/shared/config/`                                           |
+| [`@xmachines/shared`](../api/@xmachines/shared/README.md)                                         | Shared configs: tsconfig, oxlint, oxfmt, vitest         | `packages/shared/config/`                                           |
 | `@xmachines/docs`                                                                                 | API docs and RFC documentation                          | `packages/docs/`                                                    |
 
 ## Data Flow
@@ -109,14 +110,19 @@ graph TD
 flowchart TD
     A["XState machine transition"]
     B["PlayerActor observes its own transitions"]
-    C["actor.state Signal.State updated — synchronous, no batching"]
-    D["actor.currentRoute Signal.Computed recomputes\nderives URL from meta.route + context.params"]
-    E["validateAndCacheView(snapshot)\nactor.currentView Signal.State updated"]
-    F["Framework signal watcher fires\nmicrotask"]
+    C["actor.state atom updated — the ONE write of the transition"]
+    D["actor.currentRoute computed atom recomputes\nderives URL from meta.route + context.params"]
+    E["actor.currentView computed atom recomputes\nderives the PlaySpec from meta.view"]
+    F["Framework atom subscription fires\nmicrotask"]
     G["ActorProvider reads actor.currentView.get()"]
     H["PlayRenderer renders via @xmachines/json-render-* Renderer"]
 
-    A --> B --> C --> D --> E --> F --> G --> H
+    A --> B --> C
+    C --> D
+    C --> E
+    D --> F
+    E --> F
+    F --> G --> H
 ```
 
 ### User Navigation (Browser URL → Actor)
@@ -130,7 +136,7 @@ flowchart TD
     E["buildPlayRouteEvent(path, routeMap)\nresolves stateId from URL via URLPattern"]
     F["actor.send({ type: 'play.route', to: '#stateId', params, query })"]
     G["XState machine guard evaluates transition"]
-    H["machine transitions → signals update\n→ URL bar updated"]
+    H["machine transitions → atoms update\n→ URL bar updated"]
     I["guard blocks → machine stays\n→ router re-syncs to actor's current route"]
 
     A --> B --> C --> D --> E --> F --> G
@@ -142,9 +148,9 @@ flowchart TD
 
 ```mermaid
 flowchart TD
-    A["actor.currentRoute Signal.Computed changes"]
-    B["RouterBridgeBase routeWatcher\nTC39 Signal.subtle.Watcher fires"]
-    C["watchSignal microtask queued\nneedsEnqueue dedup guard"]
+    A["actor.currentRoute computed atom changes"]
+    B["RouterBridgeBase routeWatcher\natom subscription fires"]
+    C["watchAtom microtask queued\nscheduled dedup guard"]
     D["syncRouterFromActor(route) called"]
     E["lastSyncedPath set\necho suppression — prevents circular callback"]
     F["navigateRouter(path)\ncalls framework router's navigate API"]
@@ -179,19 +185,19 @@ flowchart TD
     B["resolveViewMeta(meta)\nfinds deepest meta.view with root + elements\n(its record key becomes viewKey)"]
     C["snapshot.context\nprojected wholesale as the /context slice"]
     D["composePlayState(spec.state, slice)\nstate: { ...authored, context: slice }"]
-    E["reuseComposedState (in validateAndCacheView)\ncarry previous state reference when the slice is value-unchanged"]
-    F["Derived PlaySpec (with viewKey) set on currentView signal"]
+    E["reuseComposedState (in the currentView atom)\ncarry previous state reference when the slice is value-unchanged"]
+    F["Derived PlaySpec (with viewKey) is the value of the currentView atom"]
 
     A --> B --> C --> D --> E --> F
 ```
 
-**State signals on the actor:**
+**State atoms on the actor:**
 
-| Signal               | Type                               | Description                                                                                      |
-| -------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------ |
-| `actor.state`        | `Signal.State<AnyMachineSnapshot>` | XState snapshot; updated synchronously on active states only                                     |
-| `actor.currentRoute` | `Signal.Computed<string \| null>`  | Derived from `meta.route` + `context.params`; `null` when unroutable                             |
-| `actor.currentView`  | `Signal.State<PlaySpec \| null>`   | Set explicitly per-transition (not computed) to ensure watcher notifications on self-transitions |
+| Atom                 | Type                             | Description                                                                                                                                                                                                      |
+| -------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `actor.state`        | `Atom<AnyMachineSnapshot>`       | XState snapshot; the ONE write of a transition, on active states only                                                                                                                                            |
+| `actor.currentRoute` | `ReadonlyAtom<string \| null>`   | Derived from `meta.route` + `context.params`; `null` when unroutable. It carries `compare: () => false`, so EVERY transition notifies — a refused guard derives the same path, and the bridge must still hear it |
+| `actor.currentView`  | `ReadonlyAtom<PlaySpec \| null>` | Derived from `meta.view`; the `previous` value gates an emission, so an unchanged view keeps its reference                                                                                                       |
 
 ## Key Abstractions
 
@@ -220,15 +226,15 @@ if (err instanceof RouterSyncError) {
 
 ### [`PlayActor<TSnapshot, TEvent>`](../api/@xmachines/play-actor/interfaces/PlayActor.md)
 
-The actor contract, as an INTERFACE. It asks for two members: a reactive `state: Signal.State<TSnapshot>`, and a typed `send(event: TEvent): void`. It names no state machine library, so a consumer of the contract installs `xstate` never. An implementation satisfies it (e.g. [`PlayerActor`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md)).
+The actor contract, as an INTERFACE. It asks for two members: a reactive `state: Atom<TSnapshot>`, and a typed `send(event: TEvent): void`. It names no state machine library, so a consumer of the contract installs `xstate` never. An implementation satisfies it (e.g. [`PlayerActor`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md)).
 
 ### [`Routable`](../api/@xmachines/play-router/index/interfaces/Routable.md)
 
-Optional capability interface. Exposes `currentRoute: Signal.Computed<string | null>` (derived URL path) and `readonly initialRoute: string | null` (machine's initial route, fixed at definition time). Router bridges consume this interface directly — they never depend on the concrete [`PlayerActor`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md).
+Optional capability interface. Exposes `currentRoute: ReadonlyAtom<string | null>` (derived URL path) and `readonly initialRoute: string | null` (machine's initial route, fixed at definition time). Router bridges consume this interface directly — they never depend on the concrete [`PlayerActor`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md).
 
 ### [`Viewable`](../api/@xmachines/play-view/index/interfaces/Viewable.md)
 
-Optional capability interface. Exposes `currentView: Signal.State<PlaySpec | null>`. View renderers (`PlayRenderer`) consume this contract to resolve the current view description into UI without coupling to the framework or actor implementation.
+Optional capability interface. Exposes `currentView: ReadonlyAtom<PlaySpec | null>`. View renderers (`PlayRenderer`) consume this contract to resolve the current view description into UI without coupling to the framework or actor implementation.
 
 ### [`PlaySpec`](../api/@xmachines/play-view/index/interfaces/PlaySpec.md)
 
@@ -236,9 +242,9 @@ Extends `@xmachines/json-render-core` `Spec`. `deriveCurrentView` projects the m
 
 ### [`PlayerActor<TMachine>`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md)
 
-Concrete XState v5 actor. It extends XState's own `Actor` directly, and it implements [`PlayActor`](../api/@xmachines/play-actor/interfaces/PlayActor.md). It receives the machine in its constructor, so an instance IS the actor rather than a wrapper around one. Bridges its own subscription to TC39 Signals. Exposes: `state`, `send()`, `start()`, `stop()`, `can()`.
+Concrete XState v5 actor. It extends XState's own `Actor` directly, and it implements [`PlayActor`](../api/@xmachines/play-actor/interfaces/PlayActor.md). It receives the machine in its constructor, so an instance IS the actor rather than a wrapper around one. Bridges its own subscription to atoms. Exposes: `state`, `send()`, `start()`, `stop()`, `can()`.
 
-[`Routable`](../api/@xmachines/play-router/index/interfaces/Routable.md) and [`Viewable`](../api/@xmachines/play-view/index/interfaces/Viewable.md) are OPTIONAL capabilities, and the class implements neither. Each one is a mixin behind its own entry point — `@xmachines/play-xstate/routing` and `@xmachines/play-xstate/view` — and `compose` builds the class that an application needs:
+[`Routable`](../api/@xmachines/play-router/index/interfaces/Routable.md) and [`Viewable`](../api/@xmachines/play-view/index/interfaces/Viewable.md) are OPTIONAL capabilities, and the class implements neither. Each one is a mixin behind its own entry point — [`@xmachines/play-xstate/routing`](../api/@xmachines/play-xstate/README.md) and [`@xmachines/play-xstate/view`](../api/@xmachines/play-xstate/README.md) — and `compose` builds the class that an application needs:
 
 ```typescript
 definePlayer({ machine, actor: compose(PlayerActor, withRouting, withView) });
@@ -246,7 +252,9 @@ definePlayer({ machine, actor: compose(PlayerActor, withRouting, withView) });
 
 The core imports neither capability, so an application that declares no route loads no routing code, and one that renders no view loads no view code and installs no json-render.
 
-**The composition order is the derivation order.** `PlayerActor` owns ONE subscription and calls a protected `onSnapshot` hook after `state` holds the new snapshot. A capability overrides that hook and calls `super.onSnapshot()` first, so `compose(PlayerActor, withRouting, withView)` derives the route before the view. That order is load-bearing: a router bridge must see a guard redirect synchronously, and the view of a state reads the route that the same transition produced.
+**The composition order decides nothing.** `PlayerActor` writes ONE atom for each transition — `state` — and every capability that publishes a value DERIVES it with a computed atom over that one. The engine evaluates `currentRoute` and `currentView` from a single write, in topological order, so a router bridge sees a guard redirect and a renderer sees the view of the same snapshot whatever order `compose` applied.
+
+An earlier release wrote `currentView` from an `onSnapshot` override, and the order was load-bearing there: two writes flushed two times, and an observer of `state` and `currentView` read the new state beside the old view in between. `onSnapshot` remains for a capability that must run an EFFECT on a transition, and an override still calls `super.onSnapshot()` first.
 
 ### [`definePlayer(config)`](../api/@xmachines/play-xstate/index/functions/definePlayer.md) → [`PlayerFactory`](../api/@xmachines/play-xstate/index/type-aliases/PlayerFactory.md)
 
@@ -280,7 +288,7 @@ class MyRouterBridge extends RouterBridgeBase {
 
 ### [`RouteMap`](../api/@xmachines/play-router/index/classes/RouteMap.md) / [`createRouteMap`](../api/@xmachines/play-router/xstate/functions/createRouteMap.md)
 
-Bidirectional `stateId ↔ URL path` lookup. [`createRouteMap(machine)`](../api/@xmachines/play-router/xstate/functions/createRouteMap.md) of `@xmachines/play-router/xstate` → [`RouteMap`](../api/@xmachines/play-router/index/classes/RouteMap.md). [`createRouteMapFromTree(routeTree)`](../api/@xmachines/play-router/index/functions/createRouteMapFromTree.md) of `@xmachines/play-router` takes the output of [`extractMachineRoutes(machine)`](../api/@xmachines/play-router/xstate/functions/extractMachineRoutes.md) directly. Both drop the synthetic root node of the tree, so neither map answers a state ID that the machine does not hold. The match of a parameterized route, for example `/profile/:userId`, uses `URLPattern` of [`@xmachines/play-url`](../api/@xmachines/play-url/README.md).
+Bidirectional `stateId ↔ URL path` lookup. [`createRouteMap(machine)`](../api/@xmachines/play-router/xstate/functions/createRouteMap.md) of [`@xmachines/play-router/xstate`](../api/@xmachines/play-router/README.md) → [`RouteMap`](../api/@xmachines/play-router/index/classes/RouteMap.md). [`createRouteMapFromTree(routeTree)`](../api/@xmachines/play-router/index/functions/createRouteMapFromTree.md) of [`@xmachines/play-router`](../api/@xmachines/play-router/README.md) takes the output of [`extractMachineRoutes(machine)`](../api/@xmachines/play-router/xstate/functions/extractMachineRoutes.md) directly. Both drop the synthetic root node of the tree, so neither map answers a state ID that the machine does not hold. The match of a parameterized route, for example `/profile/:userId`, uses `URLPattern` of [`@xmachines/play-url`](../api/@xmachines/play-url/README.md).
 
 ### [`PlayRouteEvent`](../api/@xmachines/play-router/index/interfaces/PlayRouteEvent.md)
 
@@ -296,9 +304,9 @@ interface PlayRouteEvent {
 }
 ```
 
-### [`watchSignal(signal, callback)`](../api/@xmachines/play-signals/functions/watchSignal.md)
+### [`watchAtom(atom, callback)`](../api/@xmachines/play-atom/functions/watchAtom.md)
 
-Subscribe to a single TC39 signal with microtask batching and memory-safe cleanup. Uses a one-shot `Signal.subtle.Watcher` lifecycle — re-arms after each notification. `disposed` flag guards post-cleanup callbacks; `needsEnqueue` deduplicates rapid synchronous signal changes. Returns a `() => void` cleanup function.
+Subscribe to a single atom with microtask coalescing and memory-safe cleanup. It builds one `subscribe` for the life of the watch, so no code arms anything again. The `disposed` flag guards post-cleanup callbacks, and the `scheduled` guard deduplicates rapid synchronous atom changes. Returns a `Cleanup` function.
 
 ### [`formatPlayRouteTransitions(machineConfig)`](../api/@xmachines/play-xstate/with-routing/functions/formatPlayRouteTransitions.md)
 
@@ -310,16 +318,16 @@ All five view renderer packages follow an identical structural pattern:
 
 | Component        | Role                                                                                             |
 | ---------------- | ------------------------------------------------------------------------------------------------ |
-| `ActorProvider`  | Subscribes to `actor.currentView` signal; owns signal lifecycle; provides view context           |
+| `ActorProvider`  | Subscribes to the `actor.currentView` atom; owns the atom lifecycle; provides view context       |
 | `PlayUIProvider` | Convenience wrapper combining `ActorProvider` + framework's `JSONUIProvider`                     |
 | `PlayRenderer`   | Zero-prop leaf component; reads from context; delegates to `@xmachines/json-render-*` `Renderer` |
 | `useActor()`     | Hook/composable for accessing the raw actor in consuming components                              |
 
-**Framework-specific signal bridging:**
+**Framework-specific atom bridging:**
 
-| Package                                                             | Signal → Render mechanism                                                                                                                                                                                                                         |
+| Package                                                             | Atom → Render mechanism                                                                                                                                                                                                                           |
 | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [`@xmachines/play-react`](../api/@xmachines/play-react/README.md)   | `useSignalEffect` → `useReducer` force-update                                                                                                                                                                                                     |
+| [`@xmachines/play-react`](../api/@xmachines/play-react/README.md)   | `useAtomEffect` → `useReducer` force-update                                                                                                                                                                                                       |
 | [`@xmachines/play-vue`](../api/@xmachines/play-vue/README.md)       | Vue reactivity bridge via `watchEffect` equivalent                                                                                                                                                                                                |
 | [`@xmachines/play-solid`](../api/@xmachines/play-solid/README.md)   | SolidJS native reactive integration                                                                                                                                                                                                               |
 | [`@xmachines/play-svelte`](../api/@xmachines/play-svelte/README.md) | Svelte 5 runes (`$effect`) via `actor-context.svelte.ts`                                                                                                                                                                                          |
@@ -361,20 +369,21 @@ Each adapter also exports a framework-integrated provider component (e.g. `PlayR
 packages/
 ├── shared/                     # Zero-dependency shared configs (tsconfig, oxlint, oxfmt, vitest)
 ├── play/                       # Layer 0: Core protocol: PlayEvent, PlayError, assertNonNullable
-├── play-signals/               # Layer 0: TC39 Signal polyfill wrapper — all signal imports go here
-│   └── src/                    # Re-exports signal-polyfill; watchSignal utility
-├── play-actor/                 # Layer 1: the PlayActor contract — state and send, and nothing else
-├── play-url/                   # Layer 1: the URL language — the URLPattern grammar, a base path, framework params
-├── play-view/                  # Layer 2: Viewable, PlaySpec, the view store lifecycle, the context projection
+├── play-atom/                  # Layer 1: the atom primitives — all atom imports go here
+│   └── src/                    # Declares the atom contract, binds the engine; watchAtom utility
+├── play-actor/                 # Layer 2: the PlayActor contract — state and send, and nothing else
+├── play-pattern/               # Layer 1: the route pattern language — one parse, and the path it builds back
+├── play-url/                   # Layer 2: the URL layer — the URLPattern API, a base path, framework params
+├── play-view/                  # Layer 3: Viewable, PlaySpec, the view store lifecycle, the context projection
 │
-├── play-xstate/                # Layer 2: Concrete XState v5 actor: definePlayer, PlayerActor
+├── play-xstate/                # Layer 5: Concrete XState v5 actor: definePlayer, PlayerActor
 │   └── src/
 │       ├── player-actor.ts              # PlayerActor — concrete actor
 │       ├── define-player.ts             # definePlayer factory
 │       ├── routing/                     # deriveRoute, buildRouteUrl, formatPlayRouteTransitions
 │       └── view/                        # deriveCurrentView (meta.view → PlaySpec)
 │
-├── play-router/                # Layer 2: Route extraction, bidirectional mapping, bridge base
+├── play-router/                # Layer 4: Route extraction, bidirectional mapping, bridge base
 │   └── src/
 │       ├── router-bridge-base.ts        # RouterBridgeBase (Template Method for all adapters)
 │       ├── base-route-map.ts            # RouteMap (bidirectional stateId ↔ path)
@@ -417,65 +426,35 @@ packages/<name>/
 
 ## TypeScript Build Graph
 
-The monorepo uses **TypeScript composite project references** (`"composite": true` per package) for a correct, incremental, dependency-ordered build. The root `tsconfig.json` lists all packages in layer order — leaves first, dependents last. `tsc --build` at the root resolves the full dependency graph automatically.
+The monorepo uses **TypeScript composite project references** (`"composite": true` per package) for a correct, incremental, dependency-ordered build. The root `tsconfig.json` lists every package in layer order — leaves first, dependents last — and it is the ONLY build order of the workspace. `tsc --build` at the root reads that array and resolves the graph.
 
-```mermaid
-flowchart LR
-    subgraph L0["Layer 0 — no internal deps"]
-        ps[play-signals]
-        p[play]
-        d[docs]
-    end
-    subgraph L1["Layer 1 — depends on L0"]
-        pa[play-actor]
-        pu[play-url]
-    end
-    subgraph L2["Layer 2 — the view half"]
-        pvw[play-view]
-    end
-    subgraph L3r["Layer 3 — the routers, which read NO view package"]
-        pr[play-router]
-        pdr[play-dom-router]
-        psk[play-sveltekit-router]
-        ptsr[play-tanstack-react-router]
-        pvr[play-vue-router]
-        psor[play-solid-router]
-        pssr[play-svelte-spa-router]
-        ptss[play-tanstack-solid-router]
-    end
-    subgraph L3v["Layer 3 — the renderers and the xstate adapter, which read L2"]
-        px[play-xstate]
-        prea[play-react]
-        pvue[play-vue]
-        pso[play-solid]
-        psv[play-svelte]
-        pdo[play-dom]
-    end
-    subgraph L4["Layer 4 — examples / play-react-router"]
-        ex["play-react-router\nplay-*/examples/demo"]
-    end
+**The layer table and the diagram live in [development.md](development.md#build-layers).** They stood here too, and the copy drifted: it kept the numbers of an earlier release, so a reader who added a package placed it in the wrong block of the root array. One home for the question, as for the `references` arrays that the root file replaced.
 
-    L0 --> L1
-    L1 --> L2
-    L1 --> L3r
-    L2 --> L3v
-    L3r --> L4
-    L3v --> L4
-```
+Two facts about the graph belong to this document, because they are architecture and not build order:
 
-With `declarationMap: true` in the base tsconfig (from `@xmachines/shared/tsconfig`), IDE "Go to Definition" jumps to TypeScript source files rather than compiled `.d.ts` files, and refactoring works correctly across package boundaries without requiring a build step.
+- **The routers read NO view package.** `play-router` and the eight adapters name `play-view` and the five renderers in no manifest. A consumer that routes and renders nothing of its own therefore installs no json-render.
+- **The renderers read no router.** The two halves meet in the application alone, which is INV-02.
+
+With `declarationMap: true` in the base tsconfig (from [`@xmachines/shared/tsconfig`](../api/@xmachines/shared/README.md)), IDE "Go to Definition" jumps to TypeScript source files rather than compiled `.d.ts` files, and refactoring works correctly across package boundaries without requiring a build step.
 
 **Dependency rules:**
 
-| Layer                                           | May import from                                     | Must not import from             |
-| ----------------------------------------------- | --------------------------------------------------- | -------------------------------- |
-| Protocol (`play`, `play-signals`, `play-actor`) | External libs only                                  | Any other `@xmachines/*` package |
-| View half (`play-view`)                         | Protocol layer, `@xmachines/json-render-core`       | Router adapters, framework code  |
-| Actor logic (`play-xstate`)                     | Protocol layer                                      | View renderers, router adapters  |
-| URL language (`play-url`)                       | Protocol layer, `urlpattern-polyfill`               | Any other `@xmachines/*` package |
-| Router infrastructure (`play-router`)           | Protocol layer, `play-url`, `@statelyai/graph`      | View renderers                   |
-| Router adapters (`play-*-router`)               | `play-router`, protocol layer, framework router lib | Other view renderers             |
-| View renderers (`play-*`)                       | Protocol layer, `@xmachines/json-render-*`          | Router adapters                  |
+The **protocol layer** is `play`, `play-atom` and `play-actor`. The three form a chain — `play-atom` reads `play`, and `play-actor` reads `play-atom` — and none of them reads a package below.
+
+| Layer                                 | May import from                                         | Must not import from             |
+| ------------------------------------- | ------------------------------------------------------- | -------------------------------- |
+| Protocol (`play`)                     | External libs only                                      | Any other `@xmachines/*` package |
+| Protocol (`play-atom`)                | `play`, `@xstate/store`                                 | Any other `@xmachines/*` package |
+| Protocol (`play-actor`)               | `play`, `play-atom`                                     | Any other `@xmachines/*` package |
+| Pattern language (`play-pattern`)     | External libs only                                      | Any other `@xmachines/*` package |
+| URL layer (`play-url`)                | Protocol layer, `play-pattern`, `urlpattern-polyfill`   | Any other `@xmachines/*` package |
+| View half (`play-view`)               | Protocol layer, `@xmachines/json-render-core`           | Router adapters, framework code  |
+| Actor logic (`play-xstate`)           | Protocol layer, `play-pattern`, `xstate`                | View renderers, router adapters  |
+| Router infrastructure (`play-router`) | Protocol layer, `play-url`, `@statelyai/graph`          | View renderers                   |
+| Router adapters (`play-*-router`)     | `play-router`, protocol layer, framework router lib     | View renderers                   |
+| View renderers (`play-*`)             | Protocol layer, `play-view`, `@xmachines/json-render-*` | Router adapters                  |
+
+`play-view` and `play-router` are OPTIONAL peer dependencies of `play-xstate`, because the two capability subpaths carry them: [`@xmachines/play-xstate/view`](../api/@xmachines/play-xstate/README.md) names the first and [`@xmachines/play-xstate/routing`](../api/@xmachines/play-xstate/README.md) names the second. The core entry point imports neither.
 
 ## Error Handling
 
@@ -495,6 +474,7 @@ flowchart TD
     PE --> IEE["InvalidEventError\nPLAY_XSTATE_INVALID_EVENT"]
     PE --> IME["InvalidMachineError\nPLAY_XSTATE_INVALID_MACHINE"]
     PE --> MRP["MissingRouteParamError\nPLAY_XSTATE_ROUTE_PARAM_MISSING"]
+    PE --> IRP["InvalidRouteParamError\nPLAY_XSTATE_ROUTE_PARAM_INVALID"]
     PE --> MSI["MissingStateIdError\nPLAY_XSTATE_MISSING_STATE_ID"]
     PE --> IRE["InvalidRouteMetadataError\nPLAY_XSTATE_INVALID_ROUTE_METADATA"]
     PE --> ATN["ActorThrewNonErrorError\nPLAY_XSTATE_NON_ERROR_THROWN"]
@@ -510,13 +490,14 @@ import { InvalidEventError } from "@xmachines/play-xstate/errors";
 
 **Error behavior by case:**
 
-| Error                     | Package       | Behavior                                                                                   |
-| ------------------------- | ------------- | ------------------------------------------------------------------------------------------ |
-| `MissingRouteParamError`  | `play-xstate` | Transient — `currentRoute` returns `null`; does not throw                                  |
-| `ActorThrewNonErrorError` | `play-xstate` | Constructed for `onError` when the machine throws a non-`Error`; original value on `cause` |
-| `RouterSyncError`         | `play-router` | Wraps router sync failures                                                                 |
-| `DuplicateBridgeError`    | `play-router` | Two bridges registered for the same actor                                                  |
-| View errors               | `play-xstate` | Caught in `validateAndCacheView()`; forwarded to `onError` hook; last valid view retained  |
+| Error                     | Package       | Behavior                                                                                                                                                            |
+| ------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `MissingRouteParamError`  | `play-xstate` | Transient — `currentRoute` returns `null`; does not throw                                                                                                           |
+| `InvalidRouteParamError`  | `play-xstate` | Permanent — `deriveCurrentRoute` passes it on: `currentRoute` reports it through `onError` and keeps its last route, and `initialRoute` throws from the constructor |
+| `ActorThrewNonErrorError` | `play-xstate` | Constructed for `onError` when the machine throws a non-`Error`; original value on `cause`                                                                          |
+| `RouterSyncError`         | `play-router` | Wraps router sync failures                                                                                                                                          |
+| `DuplicateBridgeError`    | `play-router` | Two bridges registered for the same actor                                                                                                                           |
+| View errors               | `play-xstate` | Caught in the `currentView` atom; forwarded to `onError` hook; last valid view retained                                                                             |
 
 ## Application Bootstrap (React example)
 
@@ -580,23 +561,23 @@ function App() {
 
 ## Anti-Patterns
 
-### Importing `signal-polyfill` directly
+### Importing `@xstate/store` directly
 
 ```typescript
-// ❌ Wrong — bypasses the TC39 Signal isolation layer
-import { Signal } from "signal-polyfill";
+// ❌ Wrong — bypasses the atom isolation layer, and names the engine in your own .d.ts
+import { createAtom } from "@xstate/store";
 
-// ✅ Correct — all signal imports go through play-signals
-import { Signal } from "@xmachines/play-signals";
+// ✅ Correct — all atom imports go through play-atom
+import { createAtom } from "@xmachines/play-atom";
 ```
 
 ### Using framework state for business logic
 
 ```typescript
-// ❌ Wrong — violates INV-04 (Signal-Only Reactivity) and INV-02 (Passive Infrastructure)
+// ❌ Wrong — violates INV-03 (Atom-Only Reactivity) and INV-04 (Passive Infrastructure)
 const [currentUser, setCurrentUser] = useState(null);
 
-// ✅ Correct — observe the actor signal directly
+// ✅ Correct — observe the actor atom directly
 const currentUser = useActorSelector(actor, (s) => s.context.currentUser);
 ```
 
@@ -610,7 +591,7 @@ Custom `watchRouterChanges()` implementations that bypass `syncActorFromRouter()
 
 ## Cross-Cutting Concerns
 
-**Circular update prevention:** `lastSyncedPath` in [`RouterBridgeBase`](../api/@xmachines/play-router/index/classes/RouterBridgeBase.md) provides echo suppression for the actor→router direction; `isProcessingNavigation` flag guards against re-entrant guard-redirect loops in `syncActorFromRouter`. `needsEnqueue` in [`watchSignal`](../api/@xmachines/play-signals/functions/watchSignal.md) deduplicates rapid synchronous signal changes via microtask batching.
+**Circular update prevention:** `lastSyncedPath` in [`RouterBridgeBase`](../api/@xmachines/play-router/index/classes/RouterBridgeBase.md) provides echo suppression for the actor→router direction; `isProcessingNavigation` flag guards against re-entrant guard-redirect loops in `syncActorFromRouter`. `scheduled` in [`watchAtom`](../api/@xmachines/play-atom/functions/watchAtom.md) deduplicates rapid synchronous atom changes via microtask coalescing.
 
 **SSR / test injection:** [`WindowLike`](../api/@xmachines/play-router/index/interfaces/WindowLike.md) and [`LocationLike`](../api/@xmachines/play-router/index/interfaces/LocationLike.md) structural interfaces in [`@xmachines/play-router`](../api/@xmachines/play-router/README.md) allow injecting mock objects in router adapters, enabling testing without a real browser environment.
 
@@ -618,15 +599,15 @@ Custom `watchRouterChanges()` implementations that bypass `syncActorFromRouter()
 
 Five paths reach that case. The host gives no `onError` prop. The handler of the host throws, or the producer of the `fallback` throws, or a release of the caller throws — each of those reports the failure of the HOST, which no handler of the host receives. `ActorProvider` of play-vue stops a second report of one error, and `onError` stays silent there on purpose, because the four other renderers see such an error never.
 
-Three other places write to `console.warn`, and each one reports a configuration that the library cannot refuse: `warnOnce` of `@xmachines/play-view` names a `/context` projection that it cannot derive, one time for each spec; `@xmachines/play-xstate` names the `meta.view.contextProps` field that 1.x removed, one time for each spec; and `@xmachines/play-router` names a `basePath` that a bridge with no mount ignores. A warning is the answer where a throw would stop an application for a fault that it can still run with. No other library source calls `console.*`.
+Three other places write to `console.warn`, and each one reports a configuration that the library cannot refuse: `warnOnce` of [`@xmachines/play-view`](../api/@xmachines/play-view/README.md) names a `/context` projection that it cannot derive, one time for each spec; [`@xmachines/play-xstate`](../api/@xmachines/play-xstate/README.md) names the `meta.view.contextProps` field that 1.x removed, one time for each spec; and [`@xmachines/play-router`](../api/@xmachines/play-router/README.md) names a `basePath` that a bridge with no mount ignores. A warning is the answer where a throw would stop an application for a fault that it can still run with. No other library source calls `console.*`.
 
 **Authentication:** Not in scope. Enforced via XState guards on `play.route` transitions. The guard evaluates machine `context` (e.g., `isLoggedIn`) before permitting navigation. No library-level auth primitives — the machine defines all access control.
 
-**TC39 Signal isolation:** All signal imports go through [`@xmachines/play-signals`](../api/@xmachines/play-signals/README.md), which re-exports the `signal-polyfill` reference implementation. This isolates the codebase from Stage-1 API churn — a polyfill version upgrade or API change requires editing only one package.
+**Atom isolation:** All atom imports go through [`@xmachines/play-atom`](../api/@xmachines/play-atom/README.md), which re-exports the atom of `@xstate/store`. This isolates the codebase from churn in that library — a version upgrade or API change requires editing only one package.
 
 **Global state:** An `activeBridges` WeakMap at module level in `packages/play-router/src/router-bridge-base.ts` prevents duplicate bridges per actor. This is the only module-level mutable state in the library.
 
-**Threading:** Single-threaded event loop. No worker threads. XState actor subscription callbacks fire synchronously in `send()`. Signal updates are synchronous to ensure router bridges see guard redirects immediately.
+**Threading:** Single-threaded event loop. No worker threads. XState actor subscription callbacks fire synchronously in `send()`. Atom updates are synchronous to ensure router bridges see guard redirects immediately.
 
 ---