@xmachines/docs 6.0.0 → 6.1.0

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

@@ -0,0 +1,28 @@
+[API](../../../../README.md) / [@xmachines/shared](../../README.md) / [vite-aliases](../README.md) / xmBuildOutputFile
+
+# Function: xmBuildOutputFile()
+
+```ts
+function xmBuildOutputFile(packageDir, sourceFile): string;
+```
+
+Defined in: [vite-aliases.ts:359](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L359)
+
+The file in `dist/` that the build writes for one source file of a package.
+
+The library build keeps the module structure (`preserveModules`, with `src/` as the root),
+and tsc writes the same layout. So `src/a/b.ts` becomes `dist/a/b.js`. A `.tsx`, `.vue` or
+`.svelte` file becomes `.js` too. A runes module `x.svelte.ts` becomes `x.js`: the build of
+play-svelte drops the infix, because a consumer's Svelte plugin compiles each `*.svelte.js`
+again (see `packages/play-svelte/vite.config.ts`).
+
+## Parameters
+
+| Parameter    | Type     | Description                                 |
+| ------------ | -------- | ------------------------------------------- |
+| `packageDir` | `string` | The package directory.                      |
+| `sourceFile` | `string` | An absolute path under `<packageDir>/src/`. |
+
+## Returns
+
+`string`

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

@@ -6,7 +6,7 @@
 function xmCacheDir(importMetaUrl, name): string;
 ```
 
-Defined in: [vite-aliases.ts:355](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/shared/config/vite-aliases.ts#L355)
+Defined in: [vite-aliases.ts:495](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L495)
 
 Returns the shared Vite `cacheDir` for this workspace package.
 

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

@@ -6,7 +6,7 @@
 function xmOptimizeDeps(include?): DepOptimizationOptions;
 ```
 
-Defined in: [vite-aliases.ts:308](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/shared/config/vite-aliases.ts#L308)
+Defined in: [vite-aliases.ts:448](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L448)
 
 Returns the standard Vite `optimizeDeps` config for browser test projects.
 

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/v6.0.0/packages/shared/config/vite-aliases.ts#L275)
+Defined in: [vite-aliases.ts:333](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L333)
 
 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/v6.0.0/packages/shared/config/vite-aliases.ts#L334)
+Defined in: [vite-aliases.ts:474](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L474)
 
 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/v6.0.0/packages/shared/config/vite-aliases.ts#L335) |
+| `dynamicCompileOptions()` | (`data`) => \| \{ `runes`: `boolean`; \} \| `undefined` | [vite-aliases.ts:475](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L475) |

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

@@ -0,0 +1,26 @@
+[API](../../../../README.md) / [@xmachines/shared](../../README.md) / [vite-aliases](../README.md) / xmTestTarget
+
+# Function: xmTestTarget()
+
+```ts
+function xmTestTarget(env?): XmTestTarget;
+```
+
+Defined in: [vite-aliases.ts:25](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L25)
+
+Reads the test target from the `XM_TEST_TARGET` environment variable.
+
+The variable is the one switch of the dist run. The config helpers of this package read
+it, so no package config holds a second copy of the dist setup. An unset or empty variable
+gives `source`. Any other value than `source` or `dist` is an error: a typo must not run
+the suite against the source and report the result as a run against the build.
+
+## Parameters
+
+| Parameter | Type         | Default value | Description                                            |
+| --------- | ------------ | ------------- | ------------------------------------------------------ |
+| `env`     | `ProcessEnv` | `process.env` | The environment to read. The default is `process.env`. |
+
+## Returns
+
+[`XmTestTarget`](../type-aliases/XmTestTarget.md)

package/api/@xmachines/shared/vite-aliases/type-aliases/XmTestTarget.md

@@ -0,0 +1,15 @@
+[API](../../../../README.md) / [@xmachines/shared](../../README.md) / [vite-aliases](../README.md) / XmTestTarget
+
+# Type Alias: XmTestTarget
+
+```ts
+type XmTestTarget = "source" | "dist";
+```
+
+Defined in: [vite-aliases.ts:13](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vite-aliases.ts#L13)
+
+The code that a test run loads for each published `@xmachines/*` package.
+
+- `source` — the TypeScript under `src/`. `pnpm test` runs this way, and it needs no build.
+- `dist` — the build output under `dist/`, through the `exports` map of each package, as
+  a consumer gets it. `pnpm run test:dist` runs this way, after `pnpm run build`.

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/v6.0.0/packages/shared/config/vitest.ts#L209)
+Defined in: [vitest.ts:224](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L224)
 
 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/v6.0.0/packages/shared/config/vitest.ts#L65)
+Defined in: [vitest.ts:76](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L76)
 
 Create a Vitest config with XMachines workspace defaults.
 
@@ -14,6 +14,10 @@ What this applies automatically:
 
 - `resolve.alias` from `xmAliases(importMetaUrl)` so `@xmachines/*` imports
   resolve to source in local/dev test runs.
+- In the dist run (`XM_TEST_TARGET=dist`), the `xmBuildOutput` plugin, and an
+  alias map with no published package in it: each `@xmachines/*` import then
+  resolves through its `exports` map to `dist/`, and each `src/` file that a
+  test imports by path resolves to its counterpart in `dist/`.
 - `config/vitest.setup.ts` when missing.
 - `config/vitest.node.setup.ts` for non-browser projects when missing.
 - `pool: "vmThreads"` for jsdom projects that declare no pool.

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/v6.0.0/packages/shared/config/vitest.ts#L159)
+Defined in: [vitest.ts:174](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L174)
 
 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/v6.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/v6.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/v6.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:182](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L182) |
+| <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:189](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L189) |
+| <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:195](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/shared/config/vitest.ts#L195) |

package/api/llms.txt

@@ -64,8 +64,7 @@ import { withRouting } from '@xmachines/play-xstate/routing';
 import { withView } from '@xmachines/play-xstate/view';
 import { createRouteMapFromTree, extractRouteParams } from '@xmachines/play-router';
 import { extractMachineRoutes } from '@xmachines/play-router/xstate';
-import { defineRegistry } from '@xmachines/json-render-react';
-import { PlayRenderer } from '@xmachines/play-react';
+import { PlayUIProvider, PlayRenderer, defineRegistry } from '@xmachines/play-react';
 
 const createPlayer = definePlayer({ machine, actor: compose(PlayerActor, withRouting, withView) });
 const actor = createPlayer();
@@ -77,6 +76,11 @@ const routeTree = extractMachineRoutes(machine);
 const routeMap = createRouteMapFromTree(routeTree);
 const stateId = routeMap.getStateIdByPath(currentRoute ?? '/');
 
-const { registry } = defineRegistry(catalog, { components, actions });
-<PlayRenderer actor={actor} registry={registry} actions={{ login: 'auth.login' }} />
+const registryResult = defineRegistry(catalog, {
+  components,
+  actions: { login: async ({ username }) => actor.send({ type: 'auth.login', username }) },
+});
+<PlayUIProvider actor={actor} registryResult={registryResult}>
+  <PlayRenderer />
+</PlayUIProvider>
 ```

package/contributing/architecture.md

@@ -184,20 +184,30 @@ flowchart TD
     F -->|"URL = machine initial state"| H
 ```
 
-### View Prop Enrichment
+### View derivation
 
 ```mermaid
 flowchart TD
-    A["XState snapshot.getMeta()"]
-    B["resolveViewMeta(meta)\nfinds deepest meta.view with root + elements\n(its record key becomes viewKey)"]
+    A["XState snapshot"]
+    O{"a state node of the machine\ndeclares meta.view.outlets?\n(cached for each machine)"}
+    T["resolveViewTree(root, snapshot.value)\na view with outlets composes its active children;\nany other node keeps its deepest view"]
+    G["composeViews(tree) in play-view\ncached for each tree: elements, authored state, viewParts\nviewKey = the id of the outermost composing state"]
+    B["resolveViewMeta(active branch: the routed region first)\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 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
+    A --> O
+    O -->|"yes"| T
+    T -->|"an active view composes"| G --> C
+    T -->|"no active view composes:\nthe view that the walk resolved"| C
+    O -->|"no"| B --> C
+    C --> D --> E --> F
 ```
 
+The composition keeps each element of the outer view by reference, except an element that receives a child view. It prefixes each key of a child view with the id of its state. `composeViews` caches the result for each tree of view objects. A context assign therefore emits the same `elements` and `viewParts` references, and the emit gate of `withView` walks no element. When the `viewKey` stays and the `viewParts` value changes, `createViewStoreLifecycle` writes the authored keys that the store does not hold. play-dom then gives the new spec to `setSpec` of the incremental renderer, which keeps each node whose element did not change.
+
 **State atoms on the actor:**
 
 | Atom                 | Type                             | Description                                                                                                                                                                                                      |
@@ -245,7 +255,7 @@ Optional capability interface. Exposes `currentView: ReadonlyAtom<PlaySpec | nul
 
 ### [`PlaySpec`](../api/@xmachines/play-view/index/interfaces/PlaySpec.md)
 
-Extends `@xmachines/json-render-core` `Spec`. `deriveCurrentView` projects the machine's whole context into the derived spec's `state` under the read-only `/context` subtree, and stamps a `viewKey` from the selected meta entry so providers can reseed vs refresh their store. Specs read context through the ordinary `{ $state: "/context/…" }` grammar; element props are never enriched. `typedSpec()` type-checks the spec literal at the definition site (XState's `meta` is untyped).
+Extends `@xmachines/json-render-core` `Spec`. `deriveCurrentView` projects the machine's whole context into the derived spec's `state` under the read-only `/context` subtree, and stamps a `viewKey` from the selected meta entry so providers can reseed vs refresh their store. An authored `outlets` field composes the views of the active substates into the view of their parent, and the composed spec also carries `viewParts`. Specs read context through the ordinary `{ $state: "/context/…" }` grammar; element props are never enriched. `typedSpec()` type-checks the spec literal at the definition site (XState's `meta` is untyped).
 
 ### [`PlayerActor<TMachine>`](../api/@xmachines/play-xstate/index/classes/PlayerActor.md)
 
@@ -261,7 +271,7 @@ The core imports neither capability, so an application that declares no route lo
 
 **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.
+A capability that must run an EFFECT on a transition overrides `onSnapshot`, and the override calls `super.onSnapshot()` first.
 
 ### [`definePlayer(config)`](../api/@xmachines/play-xstate/index/functions/definePlayer.md) → [`PlayerFactory`](../api/@xmachines/play-xstate/index/type-aliases/PlayerFactory.md)
 
@@ -436,7 +446,7 @@ packages/<name>/
 
 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.
 
-**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.
+**The layer table and the diagram live in [development.md](development.md#build-layers).**
 
 Two facts about the graph belong to this document, because they are architecture and not build order:
 
@@ -614,7 +624,7 @@ 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`](../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.*`.
+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 a `meta.view.contextProps` field, which the view does not read, 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.
 

package/contributing/configuration.md

@@ -6,12 +6,20 @@ This document describes every configuration file, environment variable, and per-
 
 ## Environment Variables
 
-The monorepo itself has no application runtime that reads environment variables. The only variables are for the **dev container** tooling and the **CI/CD release pipeline**.
+The monorepo itself has no application runtime that reads environment variables. The only variables are for the **dev container** tooling, the **test runs**, and the **CI/CD release pipeline**.
 
 ### Dev Container Variables
 
 The dev container currently defines no workspace-specific environment variables; `.devcontainer/.env` (loaded via `env_file` in `.devcontainer/compose.yaml`) is available for local overrides if a future tool needs one. Copy `.devcontainer/.env.sample` to `.devcontainer/.env` to get started.
 
+### Test Run Variable
+
+| Variable         | Required | Default  | Description                                                                                                                                                      |
+| ---------------- | -------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `XM_TEST_TARGET` | Optional | `source` | The code that a test run loads for each published package: `source` (the `src/` tree) or `dist` (the build output). Any other value stops the run with an error. |
+
+**Defined in:** the `test:dist` and `test:browser:dist` scripts of the root `package.json`. **Read by:** `xmTestTarget` of [`@xmachines/shared/vite-aliases`](../api/@xmachines/shared/README.md), which every config helper of that package calls. Do not set it by hand: run `pnpm run test:dist`. See [testing.md](testing.md#tests-on-the-build-output).
+
 ### CI / Release Pipeline Variable
 
 | Variable            | Required | Default                      | Description                                                                                                                                                                         |
@@ -329,7 +337,7 @@ stays.
 
 **Location:** `/vitest.config.ts`
 **Tool:** [Vitest](https://vitest.dev/) `^4.1.5`
-**Run:** `pnpm test` / `pnpm run test:coverage`
+**Run:** `pnpm test` / `pnpm run test:coverage` / `pnpm run test:dist`
 
 Root Vitest config is a **workspace coordinator** that lists all per-package configs under `test.projects`. It sets conservative monorepo-wide defaults:
 
@@ -354,8 +362,10 @@ Root Vitest config is a **workspace coordinator** that lists all per-package con
 
 Coverage provider: `v8`. Individual packages may declare higher per-package thresholds in their own `vitest.config.ts`.
 
+The JUnit file is `test-results.xml`. The dist run (`XM_TEST_TARGET=dist`) writes `test-results-dist.xml`, and it prefixes each class name with `dist:`, so the two runs stay apart in the merge request widget.
+
 **Browser test config:** `/vitest.browser.config.ts`
-Run with `pnpm run test:browser`. Uses Playwright Chromium via Vitest browser mode. `testTimeout` is `20000` ms; `maxWorkers` is `2` (default; demo integration projects override with `pool: "threads"` + `maxWorkers: 2`).
+Run with `pnpm run test:browser`, or with `pnpm run test:browser:dist` against the build output. Uses Playwright Chromium via Vitest browser mode. `testTimeout` is `20000` ms; `maxWorkers` is `2` (default; demo integration projects override with `pool: "threads"` + `maxWorkers: 2`).
 
 ### Per-Package Vitest Config — `@xmachines/shared/vitest`
 
@@ -365,6 +375,8 @@ Run with `pnpm run test:browser`. Uses Playwright Chromium via Vitest browser mo
 Packages use `defineXmVitestConfig(import.meta.url, overrides)` to create their config. It automatically injects:
 
 - `resolve.alias` via `xmAliases()` so `@xmachines/*` imports resolve to TypeScript source without a prior build.
+- In the dist run, the `xmBuildOutput` plugin. The alias map then holds no published package, so each `@xmachines/*` import resolves through its `exports` map to `dist/`. The plugin moves each `src/` file that a test imports by path to its counterpart in `dist/`.
+- `test.provide.xmTestTarget`, which a test reads with `inject("xmTestTarget")`.
 - `vitest.node.setup.ts` for non-browser projects (if not already present).
 - `vitest.setup.ts` for all projects (if not already present).
 
@@ -387,10 +399,12 @@ export default defineXmVitestConfig(import.meta.url, {
 **Location:** `packages/shared/config/vite-aliases.ts`
 **Exported as:** [`@xmachines/shared/vite-aliases`](../api/@xmachines/shared/README.md)
 
-Provides two helpers used in all `vitest.config.ts` and `vite.config.ts` files:
+Provides the helpers used in all `vitest.config.ts` and `vite.config.ts` files:
 
-- **`xmAliases(import.meta.url)`** — returns a `Record<string, string>` mapping every `@xmachines/*` package to its TypeScript source entry. Enables tests and dev servers to run without a prior `pnpm run build`.
-- **`xmResolve(import.meta.url)`** — returns a full Vite `resolve` config with `xmAliases` plus `preserveSymlinks: true` and `conditions: ["source"]`.
+- **`xmAliases(import.meta.url)`** — returns a `Record<string, string>` mapping every `@xmachines/*` package to its TypeScript source entry. Enables tests and dev servers to run without a prior `pnpm run build`. In the dist run, the map holds no entry for a published package except `<name>/src`.
+- **`xmResolve(import.meta.url)`** — returns a full Vite `resolve` config with `xmAliases` plus `preserveSymlinks: false`. It sets no `conditions`: the aliases do the work that the `source` condition does for TypeScript.
+- **`xmTestTarget()`** — reads `XM_TEST_TARGET`, and returns `source` or `dist`.
+- **`xmBuildOutput(import.meta.url)`** — the Vite plugin of the dist run. It moves each `src/` file of a published package to its counterpart in `dist/`, and it fails the import when the build output holds no such file. It also fails the run when anything loads a `src/` file of a published package.
 - **`xmCacheDir(import.meta.url, name)`** — returns a shared Vite cache path under `node_modules/.vite/<name>` to prevent redundant dep optimizer runs across projects.
 - **`xmOptimizeDeps(include?)`** — returns an `optimizeDeps.include` list holding exactly the specifiers passed in. Nothing is pre-bundled by default, and every entry has to be a package the calling project declares: pnpm gives each package its own `node_modules`, so Vite cannot resolve an undeclared specifier — it warns on stderr and carries on, which reads as a failure in a passing job.
 
@@ -436,6 +450,25 @@ Any step above can be skipped with the `SEMREL_SKIP_STEPS` CI variable, which th
 
 ---
 
+### Dependency Updates — `renovate.json5`
+
+**Location:** `/renovate.json5`
+**Tool:** [Renovate](https://docs.renovatebot.com/), from the `xmachin-es/renovate` project
+
+Renovate updates the npm dependencies of every package of the workspace, the demos under `packages/*/examples/*` too. It also updates the to-be-continuous components that `.gitlab-ci.yml` includes. The bot runs one time each week. For each new version, it opens a merge request, and the pipeline of that merge request tests the new version. The Dependency Dashboard issue lists every update that Renovate knows.
+
+The rules of the file:
+
+- **Three days of cooldown.** The renovate component waits 3 days for a new version, which also covers the cooldown of one day in pnpm 11. The `@xmachines/*` packages have no cooldown, as in `pnpm-workspace.yaml`.
+- **One merge request for json-render.** The `@xmachines/json-render-*` packages move together. The merge request moves every range, the `peerDependencies` too, as a `feat(deps):` commit. Renovate proposes the prereleases of the fork (`0.22.0-xm.1`), which it skips by default. Update the ranges that the README files name on the branch of that merge request.
+- **No new major for an audit floor.** An override with a major in its key, for example `brace-expansion@2`, gets no update to the next major.
+- **Approval for a patched package.** `pnpm-workspace.yaml` patches `@testing-library/jest-dom` and `@vitest/mocker` at one version. An update of these packages, or of vitest, needs a new patch. Approve it in the Dependency Dashboard, then move the patch on its branch.
+- **Commit types.** A component update is a `ci:` commit, so semantic-release makes no release from it. An npm update is a `fix(deps):` commit for a `dependencies` entry, and a `chore(deps):` commit for any other type.
+
+A new version of a component can rename an input and not say so. A pipeline that fails with no job is then an error in the inputs. Compare the inputs in `.gitlab-ci.yml` with the `spec` of the new version before you merge.
+
+---
+
 ## Per-Environment Overrides
 
 This monorepo has no application-level config with per-environment overrides (no `.env.development` / `.env.production` files). All configuration is tool-level (TypeScript, linter, formatter, test runner) and is environment-agnostic.

package/contributing/development.md

@@ -135,9 +135,11 @@ All commands are run from the **repository root** unless otherwise noted.
 | `pnpm run build`                           | Incremental build — all packages in dependency order (not a type-check)   |
 | `pnpm --filter @xmachines/<pkg> run build` | Build a single package (and its deps)                                     |
 | `pnpm run clean`                           | Remove coverage, Vite caches, and all `dist/` directories in packages     |
-| `pnpm test`                                | Run all unit/integration tests once                                       |
+| `pnpm test`                                | Run all unit/integration tests once, on the source                        |
+| `pnpm run test:dist`                       | Run the same tests on the build output (run `pnpm run build` first)       |
 | `pnpm run test:watch`                      | Re-run tests on file changes (interactive)                                |
 | `pnpm run test:browser`                    | Run Playwright browser tests                                              |
+| `pnpm run test:browser:dist`               | Run Playwright browser tests on the build output                          |
 | `pnpm run test:coverage`                   | Run tests with V8 coverage reporting                                      |
 | `pnpm run test:browser:coverage`           | Run browser tests with coverage reporting                                 |
 | `pnpm run test:build`                      | Complete type-check of every package and its tests (`tsconfig.test.json`) |

package/contributing/migrating-to-play-atom.md

@@ -205,6 +205,6 @@ this.state = createWritableAtom(this.getSnapshot());
 
 ## See also
 
-- [Understanding Atoms](../guides/atoms.md) — the concepts, and the invariants
+- [Atoms](../guides/atoms.md) — the concepts, and the invariants
 - [`@xmachines/play-atom`](../api/@xmachines/play-atom/README.md) — the API reference
 - [Play RFC](../rfc/play.md) — section 5.1.1 defines the reactive substrate

package/contributing/testing.md

@@ -8,7 +8,7 @@ The monorepo uses **[Vitest](https://vitest.dev/) `^5.0.1`** as its test framewo
 
 All packages extend the shared Vitest configuration helper `defineXmVitestConfig` (from [`@xmachines/shared/vitest`](../api/@xmachines/shared/README.md)) which automatically applies:
 
-- `@xmachines/*` source aliases so imports resolve to source during test runs
+- `@xmachines/*` source aliases so imports resolve to source during test runs — or, in the dist run, to the build output (see [Tests on the build output](#tests-on-the-build-output))
 - [`@xmachines/shared/vitest-setup`](../api/@xmachines/shared/README.md) — extends Vitest matchers with `@testing-library/jest-dom`
 - [`@xmachines/shared/vitest-node-setup`](../api/@xmachines/shared/README.md) — enforces Node.js ≥ 24 on non-browser projects
 
@@ -77,6 +77,33 @@ pnpm run test:browser
 
 Runs `vitest run --config vitest.browser.config.ts`. Launches all browser-mode projects using headless Chromium via Playwright. Includes both package-level browser unit tests and full demo-app integration flows. The browser global setup (`vitest.browser.global-setup.ts`) raises `process.setMaxListeners` to 32 before workers spawn to prevent false-positive `MaxListenersExceededWarning` with multiple parallel browser projects.
 
+### Tests on the build output
+
+```bash
+pnpm run build
+pnpm run test:dist           # the node suites
+pnpm run test:browser:dist   # the browser suites
+```
+
+`pnpm test` runs every suite on the SOURCE of each package. It needs no build, and it cannot see a defect of the build. `pnpm run test:dist` runs the same test files on the BUILD OUTPUT, as a consumer installs it. The 6.0.0 release shows why both runs are necessary. [`@xmachines/play-vue`](../api/@xmachines/play-vue/README.md) and [`@xmachines/play-svelte`](../api/@xmachines/play-svelte/README.md) shipped compiled for server-side rendering, and neither rendered in a browser. Every source suite was green. The node dist run fails 14 test files on that output, and the browser dist run fails the Vue suites.
+
+The two scripts set `XM_TEST_TARGET=dist`, and the config helpers of [`@xmachines/shared/vite-aliases`](../api/@xmachines/shared/README.md) read it. No package config holds a copy of the dist setup. The variable changes two things:
+
+- **A specifier.** The alias map drops each published package. [`@xmachines/play-xstate/routing`](../api/@xmachines/play-xstate/README.md) then resolves through the `exports` map of the package to `dist/with-routing.js`. The `source` condition is not set either, so the resolution is the one that a consumer gets.
+- **A path into `src/`.** A test imports the module under test by path, as `../src/define-player.js`, and that import reaches no exports map. The `xmBuildOutput` plugin moves it to `dist/define-player.js`, which is the file that the package entry imports. The test and the package then share ONE module, and a `vi.mock` of the `src/` path replaces the module of the build. The build keeps the module structure, so each source file has one counterpart.
+
+The private packages — the demos and the `examples/shared` fixtures — reach no consumer, and the build does not compile them for one. Both runs read their source, and that source imports the packages from `dist/`.
+
+The plugin fails an import when the build output holds no counterpart. The import then names both files. A fallback to the source would hide the defect that the dist run exists to find. The plugin also fails the run when anything loads a `src/` file of a published package by another route.
+
+**Keep one file set.** Both runs collect the same files. A test that cannot run on the build output imports an internal module that the package does not ship. Import that module through the public entry of the package. If that is not possible, exclude the test from the dist run in its project config, and write the reason beside the exclusion. No test is excluded today.
+
+**The proof.** `packages/play-xstate/test/test-target.test.ts` (node) and `packages/play-dom/test/browser/test-target.browser.test.ts` (browser) run in both runs. Each reads the target with `inject("xmTestTarget")`, and it asserts which file each kind of import loads. `import.meta.resolve` cannot answer that question, because it asks the resolver of Node. A stack trace cannot answer it either, because Vite applies the source maps of `dist/` and names `src/` in both runs.
+
+Run `pnpm run build` first. The dist run reads whatever `dist/` holds, and it does not build. A change to `src/` reaches the dist run only through a new build.
+
+Coverage stays on the source run. The build output carries none of the lines that the gate measures.
+
 ### With coverage
 
 ```bash
@@ -400,12 +427,12 @@ stop(); // Always clean up
 For type-only assertions, use `@ts-expect-error` in `.spec.ts` files:
 
 ```typescript
-const bad: PlaySpec = typedSpec({
+const bad: ViewMeta = typedSpec({
 	root: "root",
 	elements: {},
-	// @ts-expect-error "stat" is not a PlaySpec field — typedSpec flags it on an
+	// @ts-expect-error "stat" is not a ViewMeta field — typedSpec flags it on an
 	// inline literal (excess-property checking does not reach aliased or spread
-	// objects; use `satisfies PlaySpec` at the literal for those)
+	// objects; use `satisfies ViewMeta` at the literal for those)
 	stat: {},
 });
 // At runtime the object exists; only the compile-time error is being tested
@@ -536,6 +563,8 @@ pnpm run test:coverage
 
 The job passes no reporter flag. `vitest.config.ts` owns the reporters, the JUnit file and the coverage directory, and it reads `COVERAGE_REPORTS_DIR` — which the `test` job sets to `reports/`. A new package therefore needs no CI change.
 
+**Tests on the build output:** `test:dist` runs `pnpm run test:dist`, and `test:browser:dist` runs `pnpm run test:browser:dist` on the Playwright image. Both take `dist/` from `node-build` through `needs:`, so they test the build that the pipeline produced. They follow the rules of `test`, and they block: a failure is a defect of the tarball that a consumer installs, and it holds the release, because `semantic-release` runs in a later stage. They write `reports/test-results-dist.xml` and `reports/browser-results-dist.xml`, and each test case carries a `dist:` class name, so the widget of the merge request keeps them apart from the source runs. Neither job collects coverage.
+
 **Artifacts:** The `test` job publishes:
 
 - JUnit XML report at `reports/test-results.xml` (surfaced in GitLab's test results panel)

package/examples/@xmachines/play-dom-demo/functions/createAuthActionHandlers.md

@@ -6,7 +6,7 @@
 function createAuthActionHandlers(actor): object;
 ```
 
-Defined in: [packages/play-actor/examples/shared/src/actions.ts:48](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L48)
+Defined in: [packages/play-actor/examples/shared/src/actions.ts:48](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L48)
 
 Build the demo action handler map for one actor.
 
@@ -25,11 +25,11 @@ framework's `defineRegistry` accepts; spread the result into its `actions`.
 
 | Name             | Type                                                    | Defined in                                                                                                                                                               |
 | ---------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `addTask()`      | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:65](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L65) |
-| `completeTask()` | (`params`, `_setState`, `state`) => `Promise`\<`void`\> | [packages/play-actor/examples/shared/src/actions.ts:72](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L72) |
-| `login()`        | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:50](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L50) |
-| `logout()`       | () => `Promise`\<`void`\>                               | [packages/play-actor/examples/shared/src/actions.ts:54](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L54) |
-| `removeTask()`   | (`params`, `_setState`, `state`) => `Promise`\<`void`\> | [packages/play-actor/examples/shared/src/actions.ts:81](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L81) |
-| `resetForm()`    | (`params`, `setState`) => `Promise`\<`void`\>           | [packages/play-actor/examples/shared/src/actions.ts:99](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L99) |
-| `route()`        | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:55](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L55) |
-| `submitForm()`   | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:92](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-actor/examples/shared/src/actions.ts#L92) |
+| `addTask()`      | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:65](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L65) |
+| `completeTask()` | (`params`, `_setState`, `state`) => `Promise`\<`void`\> | [packages/play-actor/examples/shared/src/actions.ts:72](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L72) |
+| `login()`        | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:50](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L50) |
+| `logout()`       | () => `Promise`\<`void`\>                               | [packages/play-actor/examples/shared/src/actions.ts:54](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L54) |
+| `removeTask()`   | (`params`, `_setState`, `state`) => `Promise`\<`void`\> | [packages/play-actor/examples/shared/src/actions.ts:81](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L81) |
+| `resetForm()`    | (`params`, `setState`) => `Promise`\<`void`\>           | [packages/play-actor/examples/shared/src/actions.ts:99](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L99) |
+| `route()`        | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:55](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L55) |
+| `submitForm()`   | (`params?`) => `Promise`\<`void`\>                      | [packages/play-actor/examples/shared/src/actions.ts:92](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-actor/examples/shared/src/actions.ts#L92) |

package/examples/@xmachines/play-dom-demo/functions/createConfirmDialog.md

@@ -6,7 +6,7 @@
 function createConfirmDialog(confirm): Promise<boolean>;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/ConfirmDialog.ts:12](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/ConfirmDialog.ts#L12)
+Defined in: [packages/play-dom/examples/demo/src/components/ConfirmDialog.ts:12](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/ConfirmDialog.ts#L12)
 
 ConfirmDialog — the DOM demo's onConfirm implementation.
 

package/examples/@xmachines/play-dom-demo/functions/createNavBar.md

@@ -6,7 +6,7 @@
 function createNavBar(actor, container): () => void;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/NavBar.ts:9](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/NavBar.ts#L9)
+Defined in: [packages/play-dom/examples/demo/src/components/NavBar.ts:9](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/NavBar.ts#L9)
 
 NavBar — App-shell navigation factory. Mounts a reactive nav into
 `container`, observes actor.state via watchAtom, and updates button

package/examples/@xmachines/play-dom-demo/functions/initShell.md

@@ -6,7 +6,7 @@
 function initShell(actor, appElement, inspector): () => void;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/Shell.ts:18](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/Shell.ts#L18)
+Defined in: [packages/play-dom/examples/demo/src/components/Shell.ts:18](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/Shell.ts#L18)
 
 Shell — DOM shell layout factory. Renders demo chrome (header + main +
 debug panel), mounts NavBar, connects DOM renderer, and wires DebugPanel.

package/examples/@xmachines/play-dom-demo/type-aliases/AuthCatalog.md

@@ -6,4 +6,4 @@
 type AuthCatalog = typeof authCatalog;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/catalog.ts:6](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/catalog.ts#L6)
+Defined in: [packages/play-dom/examples/demo/src/catalog.ts:6](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/catalog.ts#L6)

package/examples/@xmachines/play-dom-demo/variables/About.md

@@ -6,7 +6,7 @@
 const About: ComponentFn<AuthCatalog, "About">;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/About.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/About.ts#L8)
+Defined in: [packages/play-dom/examples/demo/src/components/About.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/About.ts#L8)
 
 About — Public information page. Catalog-typed DOM component
 (ComponentFn<AuthCatalog, 'About'>). Renders static content from props.

package/examples/@xmachines/play-dom-demo/variables/Button.md

@@ -6,7 +6,7 @@
 const Button: ComponentFn<AuthCatalog, "Button">;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/Button.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/Button.ts#L8)
+Defined in: [packages/play-dom/examples/demo/src/components/Button.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/Button.ts#L8)
 
 Button — emits `press`; the spec's `on.press` binding decides what happens
 (a host action sending a machine event, or a built-in like setState).

package/examples/@xmachines/play-dom-demo/variables/Contact.md

@@ -6,7 +6,7 @@
 const Contact: ComponentFn<AuthCatalog, "Contact">;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/Contact.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/Contact.ts#L8)
+Defined in: [packages/play-dom/examples/demo/src/components/Contact.ts:8](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/Contact.ts#L8)
 
 Contact — Public contact page. Catalog-typed DOM component
 (ComponentFn<AuthCatalog, 'Contact'>). Renders static content from props.

package/examples/@xmachines/play-dom-demo/variables/Dashboard.md

@@ -6,7 +6,7 @@
 const Dashboard: ComponentFn<AuthCatalog, "Dashboard">;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/Dashboard.ts:9](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/Dashboard.ts#L9)
+Defined in: [packages/play-dom/examples/demo/src/components/Dashboard.ts:9](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/Dashboard.ts#L9)
 
 Dashboard — Protected authenticated home. Catalog-typed DOM component
 (ComponentFn<AuthCatalog, 'Dashboard'>). Renders welcome message; logout

package/examples/@xmachines/play-dom-demo/variables/Field.md

@@ -6,7 +6,7 @@
 const Field: ComponentFn<AuthCatalog, "Field">;
 ```
 
-Defined in: [packages/play-dom/examples/demo/src/components/Field.ts:15](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.0.0/packages/play-dom/examples/demo/src/components/Field.ts#L15)
+Defined in: [packages/play-dom/examples/demo/src/components/Field.ts:15](https://gitlab.com/xmachin-es/xmachines-js/-/blob/v6.1.0/packages/play-dom/examples/demo/src/components/Field.ts#L15)
 
 Field — labelled input with two-way $bindState binding and declarative
 validation checks.