@xmachines/docs 7.3.0 → 7.4.1

package/api/@xmachines/play-xstate/with-routing/interfaces/RouteObject.md

@@ -2,7 +2,7 @@
 
 # Interface: RouteObject
 
-Defined in: [packages/play-router/src/types.ts:33](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L33)
+Defined in: [packages/play-router/src/types.ts:33](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L33)
 
 A route object, with more metadata.
 
@@ -25,7 +25,7 @@ the literal `true` alone turns the reentry on. Give a field of your own another
 
 | Property                                 | Type                                                                                                          | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | Defined in                                                                                                                                    |
 | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| <a id="property-data"></a> `data?`       | \| [`RouteData`](../type-aliases/RouteData.md) \| [`RouteDataResolver`](../type-aliases/RouteDataResolver.md) | The extra data that the state threads into its `play.route` event. The shape follows `WithDynamicParams` of XState, which is how XState itself parameterizes an action and a guard: the field holds a literal value, OR a function of `{ context, event }` that returns one. `// The literal form. It survives a serialization of the machine. meta: { route: { path: "/doc/:docId", data: { titleKey: "doc.view" } } } // The function form, for a value that depends on the route. meta: { route: { path: "/doc/:docId", data: ({ event }) => ({ title: `Document ${event.params?.docId}` }), }, }` The generated transition resolves the value and assigns it to the `data` field of the context, beside `params` and `query`. The data of a state does NOT merge with the data of its ancestors: each state declares the whole value that its own route carries. This field and [PlayRouteEvent.data](../../../play-dom-router/interfaces/PlayRouteEvent.md#property-data) are two different things, and they meet in the resolver. This field is what the STATE declares, in its machine. `PlayRouteEvent.data` is what the SENDER of the event supplies, such as a router bridge or the code of an application. A resolver reads `event.data` and returns whatever mix of the two the state needs. CAUTION: the function form holds a function inside `meta`, and a function does not survive `JSON.stringify`. A machine that Stately Studio reads, or that a process sends over a wire, must use the literal form.                                                                                                                                                                                                                                                                            | [packages/play-router/src/types.ts:134](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L134) |
-| <a id="property-handler"></a> `handler?` | `"root"` \| `"local"` \| `"both"`                                                                             | Where the generated `play.route` transition sits. `"root"` is the default, and it is what XState does: `formatRouteTransitions` installs every route transition on the ROOT of the machine, and each one targets its state by the ID. A route from any state therefore reaches this state. The cost is that the root is the domain of the transition, so XState re-enters each ancestor on the path to the target, and those ancestors run their `entry` actions again although they stay active. `"local"` installs the transition on the PARENT of this state instead, and it targets this state relatively. XState offers the transitions of the deepest active state node first, so the parent answers the event itself. The parent then runs its `exit` and its `entry` actions again only where the state declares `reenter: true`. `"both"` installs one transition in each place. The local one answers while the parent is active, and the root one answers a route that arrives from outside the parent. Use `"both"` where an ancestor holds an `entry` action that must run one time for each real entry, such as an analytics event or an audit record. CAUTION: `"local"` makes this state reachable by a route ONLY while its parent is active. A `play.route` event that arrives from anywhere else matches no transition and the actor does not move. A browser URL for this state therefore leaves the URL and the actor divergent. Choose `"local"` to SCOPE a route on purpose, for example a step that a person reaches only inside its wizard. Choose `"both"` where the state must stay reachable from everywhere. The field has no effect on a state whose parent IS the root: the root transition of such a state is already local to its parent, so all three values agree. | [packages/play-router/src/types.ts:98](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L98)   |
-| <a id="property-path"></a> `path`        | `string`                                                                                                      | The template of the route path, for example `"/user/:id"`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | [packages/play-router/src/types.ts:35](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L35)   |
-| <a id="property-reenter"></a> `reenter?` | `boolean`                                                                                                     | The `reenter` flag of the generated `play.route` transition. The default is `false`, which is also the default of XState. The flag spares the DOMAIN of the transition, and not every ancestor that stays active. Under the default placement `handler: "root"` the domain is the root of the machine, so `false` spares the root alone: each ancestor BETWEEN the root and the target still runs its `exit` and its `entry` actions, because XState re-enters every descendant of the domain that lies on the path to the target. A move between two siblings therefore still runs the `entry` action of their shared parent. [RouteObject.handler](#property-handler) is the field that spares those intermediate ancestors: `"local"` and `"both"` move the domain down to the parent of the state, while the parent is active. Use the two fields together where an `entry` action must run one time for each state that the actor really enters. The target itself re-enters under both settings, so a route to the state that the actor already holds runs the `exit` and `entry` actions of that state again. The ROOT of the machine is the one exception: a route to the root has the root as its domain, so the flag decides. Set the field to `true` where the domain must run its `entry` actions again on each route to this state. The flag of a state applies to the routes to that state alone, and not to the routes to its descendants. The flag does not decide the destination. The value of the machine after a route is identical under both settings. A route to a state that has children still enters the `initial` child of that state, because XState enters the initial child of a compound target under both settings. **See** [Play RFC](../../../../../rfc/play.md)    | [packages/play-router/src/types.ts:67](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L67)   |
+| <a id="property-data"></a> `data?`       | \| [`RouteData`](../type-aliases/RouteData.md) \| [`RouteDataResolver`](../type-aliases/RouteDataResolver.md) | The extra data that the state threads into its `play.route` event. The shape follows `WithDynamicParams` of XState, which is how XState itself parameterizes an action and a guard: the field holds a literal value, OR a function of `{ context, event }` that returns one. `// The literal form. It survives a serialization of the machine. meta: { route: { path: "/doc/:docId", data: { titleKey: "doc.view" } } } // The function form, for a value that depends on the route. meta: { route: { path: "/doc/:docId", data: ({ event }) => ({ title: `Document ${event.params?.docId}` }), }, }` The generated transition resolves the value and assigns it to the `data` field of the context, beside `params` and `query`. The data of a state does NOT merge with the data of its ancestors: each state declares the whole value that its own route carries. This field and [PlayRouteEvent.data](../../../play-dom-router/interfaces/PlayRouteEvent.md#property-data) are two different things, and they meet in the resolver. This field is what the STATE declares, in its machine. `PlayRouteEvent.data` is what the SENDER of the event supplies, such as a router bridge or the code of an application. A resolver reads `event.data` and returns whatever mix of the two the state needs. CAUTION: the function form holds a function inside `meta`, and a function does not survive `JSON.stringify`. A machine that Stately Studio reads, or that a process sends over a wire, must use the literal form.                                                                                                                                                                                                                                                                            | [packages/play-router/src/types.ts:134](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L134) |
+| <a id="property-handler"></a> `handler?` | `"root"` \| `"local"` \| `"both"`                                                                             | Where the generated `play.route` transition sits. `"root"` is the default, and it is what XState does: `formatRouteTransitions` installs every route transition on the ROOT of the machine, and each one targets its state by the ID. A route from any state therefore reaches this state. The cost is that the root is the domain of the transition, so XState re-enters each ancestor on the path to the target, and those ancestors run their `entry` actions again although they stay active. `"local"` installs the transition on the PARENT of this state instead, and it targets this state relatively. XState offers the transitions of the deepest active state node first, so the parent answers the event itself. The parent then runs its `exit` and its `entry` actions again only where the state declares `reenter: true`. `"both"` installs one transition in each place. The local one answers while the parent is active, and the root one answers a route that arrives from outside the parent. Use `"both"` where an ancestor holds an `entry` action that must run one time for each real entry, such as an analytics event or an audit record. CAUTION: `"local"` makes this state reachable by a route ONLY while its parent is active. A `play.route` event that arrives from anywhere else matches no transition and the actor does not move. A browser URL for this state therefore leaves the URL and the actor divergent. Choose `"local"` to SCOPE a route on purpose, for example a step that a person reaches only inside its wizard. Choose `"both"` where the state must stay reachable from everywhere. The field has no effect on a state whose parent IS the root: the root transition of such a state is already local to its parent, so all three values agree. | [packages/play-router/src/types.ts:98](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L98)   |
+| <a id="property-path"></a> `path`        | `string`                                                                                                      | The template of the route path, for example `"/user/:id"`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | [packages/play-router/src/types.ts:35](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L35)   |
+| <a id="property-reenter"></a> `reenter?` | `boolean`                                                                                                     | The `reenter` flag of the generated `play.route` transition. The default is `false`, which is also the default of XState. The flag spares the DOMAIN of the transition, and not every ancestor that stays active. Under the default placement `handler: "root"` the domain is the root of the machine, so `false` spares the root alone: each ancestor BETWEEN the root and the target still runs its `exit` and its `entry` actions, because XState re-enters every descendant of the domain that lies on the path to the target. A move between two siblings therefore still runs the `entry` action of their shared parent. [RouteObject.handler](#property-handler) is the field that spares those intermediate ancestors: `"local"` and `"both"` move the domain down to the parent of the state, while the parent is active. Use the two fields together where an `entry` action must run one time for each state that the actor really enters. The target itself re-enters under both settings, so a route to the state that the actor already holds runs the `exit` and `entry` actions of that state again. The ROOT of the machine is the one exception: a route to the root has the root as its domain, so the flag decides. Set the field to `true` where the domain must run its `entry` actions again on each route to this state. The flag of a state applies to the routes to that state alone, and not to the routes to its descendants. The flag does not decide the destination. The value of the machine after a route is identical under both settings. A route to a state that has children still enters the `initial` child of that state, because XState enters the initial child of a compound target under both settings. **See** [Play RFC](../../../../../rfc/play.md)    | [packages/play-router/src/types.ts:67](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L67)   |

package/api/@xmachines/play-xstate/with-routing/type-aliases/RouteData.md

@@ -6,7 +6,7 @@
 type RouteData = Record<string, unknown>;
 ```
 
-Defined in: [packages/play-router/src/types.ts:15](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L15)
+Defined in: [packages/play-router/src/types.ts:15](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L15)
 
 The resolved extra data of a route. It reaches the consumer on the `data` field of a
 `play.route` event.

package/api/@xmachines/play-xstate/with-routing/type-aliases/RouteDataResolver.md

@@ -6,7 +6,7 @@
 type RouteDataResolver = (args) => RouteData;
 ```
 
-Defined in: [packages/play-router/src/types.ts:28](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L28)
+Defined in: [packages/play-router/src/types.ts:28](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L28)
 
 The function form of [RouteObject.data](../interfaces/RouteObject.md#property-data).
 

package/api/@xmachines/play-xstate/with-routing/type-aliases/RouteMachineConfig.md

@@ -6,7 +6,7 @@
 type RouteMachineConfig = object;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:177](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L177)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:177](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L177)
 
 The minimal structural constraint of a machine config that
 `formatPlayRouteTransitions` accepts.
@@ -32,7 +32,7 @@ original concrete type through the transform. Therefore
 context?: unknown;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:178](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L178)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:178](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L178)
 
 ---
 
@@ -42,7 +42,7 @@ Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:1
 on?: Record<string, unknown>;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L180)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L180)
 
 ---
 
@@ -52,4 +52,4 @@ Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:1
 states?: Record<string, unknown>;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:179](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L179)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:179](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L179)

package/api/@xmachines/play-xstate/with-routing/type-aliases/RouteMetadata.md

@@ -6,6 +6,6 @@
 type RouteMetadata = string | RouteObject;
 ```
 
-Defined in: [packages/play-router/src/types.ts:151](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-router/src/types.ts#L151)
+Defined in: [packages/play-router/src/types.ts:151](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-router/src/types.ts#L151)
 
 The route metadata of the `meta.route` field of a state machine.

package/api/@xmachines/play-xstate/with-routing/type-aliases/RouteStateNode.md

@@ -6,7 +6,7 @@
 type RouteStateNode = object;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:30](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L30)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:30](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L30)
 
 The minimal structural shape of one XState state node, as
 `formatPlayRouteTransitions` reads it during its walk over the machine config.
@@ -29,7 +29,7 @@ signature without a change.
 id?: string;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:34](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L34)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:34](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L34)
 
 The optional explicit state ID, for example `"home"` or `"settings"`. It is the `#id` target of a `play.route` event.
 
@@ -41,7 +41,7 @@ The optional explicit state ID, for example `"home"` or `"settings"`. It is the
 meta?: object;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:36](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L36)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:36](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L36)
 
 The state metadata. A `meta.route` field gives the state a route.
 
@@ -64,7 +64,7 @@ generated transition, and that flag defaults to `false`.
 on?: Record<string, unknown>;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:51](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L51)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:51](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L51)
 
 The event handlers of this state. The function reads them where a child asks for a
 local `play.route` handler, so that the transitions of the user survive the merge.
@@ -77,6 +77,6 @@ local `play.route` handler, so that the transitions of the user survive the merg
 states?: Record<string, RouteStateNode>;
 ```
 
-Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:46](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/routing/format-play-route-transitions.ts#L46)
+Defined in: [packages/play-xstate/src/routing/format-play-route-transitions.ts:46](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/routing/format-play-route-transitions.ts#L46)
 
 The nested child states. The function walks them for each further route declaration.

package/api/@xmachines/play-xstate/with-view/functions/withView.md

@@ -6,7 +6,7 @@
 function withView<TMachine>(Base): PlayerConstructor<TMachine, Viewable>;
 ```
 
-Defined in: [packages/play-xstate/src/with-view.ts:61](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-xstate/src/with-view.ts#L61)
+Defined in: [packages/play-xstate/src/with-view.ts:61](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-xstate/src/with-view.ts#L61)
 
 Adds the view capability to an actor class.
 

package/api/@xmachines/runtime-wasi/variables/component.md

@@ -6,6 +6,6 @@
 const component: URL;
 ```
 
-Defined in: [index.ts:17](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/runtime-wasi/src/index.ts#L17)
+Defined in: [index.ts:17](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/runtime-wasi/src/index.ts#L17)
 
 The WASI 0.2 component (`wasm32-wasip2`), of the world `xmachines:runtime/runtime`.

package/api/@xmachines/runtime-wasi/variables/schemas.md

@@ -6,6 +6,6 @@
 const schemas: URL;
 ```
 
-Defined in: [index.ts:26](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/runtime-wasi/src/index.ts#L26)
+Defined in: [index.ts:26](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/runtime-wasi/src/index.ts#L26)
 
 The folder of the JSON Schemas (draft 2020-12) of the JSON text that the WIT names, with a `/` at its end.

package/api/@xmachines/runtime-wasi/variables/wit.md

@@ -6,6 +6,6 @@
 const wit: URL;
 ```
 
-Defined in: [index.ts:23](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/runtime-wasi/src/index.ts#L23)
+Defined in: [index.ts:23](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/runtime-wasi/src/index.ts#L23)
 
 The WIT package `xmachines:runtime`, of the world that the component exports and imports.

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

@@ -6,7 +6,7 @@
 function xmAliases(importMetaUrl, target?): Record<string, string>;
 ```
 
-Defined in: [vite-aliases.ts:311](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L311)
+Defined in: [vite-aliases.ts:311](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L311)
 
 Vite resolve.alias entries for all @xmachines/* workspace packages.
 

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

@@ -6,7 +6,7 @@
 function xmBuildOutput(importMetaUrl): Plugin;
 ```
 
-Defined in: [vite-aliases.ts:407](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L407)
+Defined in: [vite-aliases.ts:407](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L407)
 
 The Vite plugin of the dist run: it moves each `src/` file of a published package to its
 counterpart in `dist/`.

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

@@ -6,7 +6,7 @@
 function xmBuildOutputFile(packageDir, sourceFile): string;
 ```
 
-Defined in: [vite-aliases.ts:378](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L378)
+Defined in: [vite-aliases.ts:378](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L378)
 
 The file in `dist/` that the build writes for one source file of a package.
 

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

@@ -6,7 +6,7 @@
 function xmCacheDir(importMetaUrl, name): string;
 ```
 
-Defined in: [vite-aliases.ts:514](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L514)
+Defined in: [vite-aliases.ts:514](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L514)
 
 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:467](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L467)
+Defined in: [vite-aliases.ts:467](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L467)
 
 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:352](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L352)
+Defined in: [vite-aliases.ts:352](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L352)
 
 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:493](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L493)
+Defined in: [vite-aliases.ts:493](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L493)
 
 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:494](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L494) |
+| `dynamicCompileOptions()` | (`data`) => \| \{ `runes`: `boolean`; \} \| `undefined` | [vite-aliases.ts:494](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L494) |

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

@@ -6,7 +6,7 @@
 function xmTestTarget(env?): XmTestTarget;
 ```
 
-Defined in: [vite-aliases.ts:25](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L25)
+Defined in: [vite-aliases.ts:25](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L25)
 
 Reads the test target from the `XM_TEST_TARGET` environment variable.
 

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

@@ -6,7 +6,7 @@
 type XmTestTarget = "source" | "dist";
 ```
 
-Defined in: [vite-aliases.ts:13](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vite-aliases.ts#L13)
+Defined in: [vite-aliases.ts:13](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vite-aliases.ts#L13)
 
 The code that a test run loads for each published `@xmachines/*` package.
 

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

@@ -6,7 +6,7 @@
 function defineXmBrowserConfig(importMetaUrl, overrides, options?): UserConfig;
 ```
 
-Defined in: [vitest.ts:230](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L230)
+Defined in: [vitest.ts:230](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L230)
 
 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:76](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L76)
+Defined in: [vitest.ts:76](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L76)
 
 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:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L180)
+Defined in: [vitest.ts:180](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L180)
 
 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:188](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L188) |
-| <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:195](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L195) |
-| <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:201](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/shared/config/vitest.ts#L201) |
+| <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:188](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L188) |
+| <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:195](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L195) |
+| <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:201](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/shared/config/vitest.ts#L201) |

package/api/trains.json

@@ -27,5 +27,57 @@
     ],
     "runtime": ["@xmachines/runtime-wasi"],
     "docs": ["@xmachines/docs"]
+  },
+  "examples": {
+    "core": [],
+    "play": [
+      "@xmachines/play-dom-gallery-demo",
+      "@xmachines/play-dom-router-demo",
+      "@xmachines/play-dom-router-donut-demo",
+      "@xmachines/play-dom-router-flight-demo",
+      "@xmachines/play-dom-router-todomvc-demo",
+      "@xmachines/play-dom-router-trivia-demo",
+      "@xmachines/play-react-gallery-demo",
+      "@xmachines/play-react-router-demo",
+      "@xmachines/play-react-router-donut-demo",
+      "@xmachines/play-react-router-flight-demo",
+      "@xmachines/play-react-router-todomvc-demo",
+      "@xmachines/play-react-router-trivia-demo",
+      "@xmachines/play-solid-gallery-demo",
+      "@xmachines/play-solid-router-demo",
+      "@xmachines/play-solid-router-donut-demo",
+      "@xmachines/play-solid-router-flight-demo",
+      "@xmachines/play-solid-router-todomvc-demo",
+      "@xmachines/play-solid-router-trivia-demo",
+      "@xmachines/play-svelte-gallery-demo",
+      "@xmachines/play-svelte-spa-router-demo",
+      "@xmachines/play-svelte-spa-router-donut-demo",
+      "@xmachines/play-svelte-spa-router-flight-demo",
+      "@xmachines/play-svelte-spa-router-todomvc-demo",
+      "@xmachines/play-svelte-spa-router-trivia-demo",
+      "@xmachines/play-sveltekit-router-demo",
+      "@xmachines/play-sveltekit-router-donut-demo",
+      "@xmachines/play-sveltekit-router-flight-demo",
+      "@xmachines/play-sveltekit-router-todomvc-demo",
+      "@xmachines/play-sveltekit-router-trivia-demo",
+      "@xmachines/play-tanstack-react-router-demo",
+      "@xmachines/play-tanstack-react-router-donut-demo",
+      "@xmachines/play-tanstack-react-router-flight-demo",
+      "@xmachines/play-tanstack-react-router-todomvc-demo",
+      "@xmachines/play-tanstack-react-router-trivia-demo",
+      "@xmachines/play-tanstack-solid-router-demo",
+      "@xmachines/play-tanstack-solid-router-donut-demo",
+      "@xmachines/play-tanstack-solid-router-flight-demo",
+      "@xmachines/play-tanstack-solid-router-todomvc-demo",
+      "@xmachines/play-tanstack-solid-router-trivia-demo",
+      "@xmachines/play-vue-gallery-demo",
+      "@xmachines/play-vue-router-demo",
+      "@xmachines/play-vue-router-donut-demo",
+      "@xmachines/play-vue-router-flight-demo",
+      "@xmachines/play-vue-router-todomvc-demo",
+      "@xmachines/play-vue-router-trivia-demo"
+    ],
+    "runtime": [],
+    "docs": []
   }
 }

package/contributing/configuration.md

@@ -419,6 +419,8 @@ Defines the trains, the release branches, and the plugins of each run: the run o
 
 **Trains:** `core` (`packages/core`), `play` (`packages/play`, `packages/play-*`), `runtime` (`packages/runtime-wasi`) and `docs` (`packages/docs`, with every file of `core`, `play` and `runtime` counting for it too). The build files of the root and `packages/shared` count for every train.
 
+**Ecosystems:** `@wtf/semantic-release-npm/ecosystem`, the ecosystem of npm, by which the trains read the packages of each `package.json` git tracks: which train holds each, and what each depends on. It is the `./ecosystem` of the npm plugin, which the trains plugin finds beside the plugin in the global install of semantic-release, so `semrel-required-plugins.txt` names the plugin alone.
+
 **Tag format:** `<train>-v${version}`, as `play-v7.1.0`.
 
 **Plugin order of a branch's run:**
@@ -437,7 +439,7 @@ Defines the trains, the release branches, and the plugins of each run: the run o
 
 5. `@semantic-release/git` — commits the changelog, the READMEs of the train, and of `docs` the generated docs (`api/`, `examples/@xmachines/` and the demo lists of `examples/README.md`), then pushes the commit and the tag
 
-**Plugin order of a tag's run:** the notes generator on the train; `@wtf/semantic-release-trains-publish`, which packs, smoke-tests and publishes the train's packages and packs its demos; `@semantic-release/gitlab`, the GitLab release with the tarballs. [deployment.md](deployment.md) states the whole sequence and the reason.
+**Plugin order of a tag's run:** the notes generator on the train; `@wtf/semantic-release-npm`, which packs, smoke-tests and publishes the train's packages and packs its demos; `@semantic-release/gitlab`, the GitLab release with the tarballs. [deployment.md](deployment.md) states the whole sequence and the reason.
 
 ---
 

package/contributing/deployment.md

@@ -137,10 +137,10 @@ The `release-pack-smoke` job runs automatically on `main` and in a merge train,
 
 ```bash
 pnpm run build
-semantic-release-trains-smoke
+semantic-release-npm-smoke
 ```
 
-`semantic-release-trains-smoke`, of `@wtf/semantic-release-trains-publish`, reads the trains of `release.config.mjs` and:
+`semantic-release-npm-smoke`, of `@wtf/semantic-release-npm`, reads the trains of `release.config.mjs` and:
 
 1. Packs every package of every train, and each private package of its `pack` globs, as the release packs it: each `workspace:` range resolved, the `source` export condition stripped. The globs name the demos, and the shared package of the demos, which each demo depends on and which no registry holds.
 2. Checks each tarball: every entry of its `files` present, no `source` condition left, and no file a `forbid` glob names, as a typecheck build.
@@ -194,7 +194,7 @@ Release the trains in order: `core`, then `play`, then `runtime`, then `docs`. `
 
 The job of a train runs these plugins, in this order:
 
-1. **The analyzer and the notes generator**, each wrapped by an entry of `@wtf/semantic-release-trains` (`wrap`), which gives it the train's commits alone. Each entry of the trains plugin also checks the trains: no file on two of them, and the trains the train depends on released. `type!:` is a breaking change, by `parserOpts` at the root of the config.
+1. **The analyzer and the notes generator**, each wrapped by an entry of `@wtf/semantic-release-trains` (`wrap`), which gives it the train's commits alone. Each entry of the trains plugin also checks the trains, of the packages that the ecosystem of npm, `@wtf/semantic-release-npm/ecosystem` of the config's `ecosystems`, reads of each `package.json`: no file on two of them, and the trains the train depends on released. `type!:` is a breaking change, by `parserOpts` at the root of the config.
 2. **`@semantic-release/changelog`** writes the train's changelog, the `CHANGELOG.md` of its first path: `packages/core/CHANGELOG.md`, `packages/play/CHANGELOG.md`, `packages/runtime-wasi/CHANGELOG.md`, `packages/docs/CHANGELOG.md`. The root `CHANGELOG.md` holds the history up to 7.0.0.
 3. **`@wtf/semantic-release-replace`** writes the version into the badge of each README of the train, by the `badge` template at the root of the config: a RegExp of the badge of shields.io, its version written as `shields` escapes it. `tests/readme-badges.test.ts` holds the template to every badge of the READMEs.
 4. **Of `docs` alone**, the reference: `corepack enable`, `pnpm install --frozen-lockfile`, `pnpm run build`, TypeDoc at the revision `docs-v${nextRelease.version}`, and `oxfmt` of the docs package, each a `@semantic-release/exec` step. Then an entry of `@wtf/semantic-release-trains` of `generated: true` stages the trees TypeDoc writes, deletions too: the git plugin stages what `git ls-files -m -o` reports, which never reports a deletion, so a page of an export that was renamed or removed would stay in git for ever.
@@ -215,7 +215,7 @@ The job of a train runs these plugins, in this order:
 The tag's pipeline builds the tagged commit, and its `publish-release` job runs `semantic-release-trains-tag`, of `@wtf/semantic-release-trains`. It runs semantic-release's own config, plugins and branches for the tag, with its version and its channel, and the plugins of the tag's run of `release.config.mjs`:
 
 1. **The notes generator**, on the train, writes the notes again of the same commits.
-2. **`@wtf/semantic-release-trains-publish`** packs each package of the train into `dist/releases/`, the demos too, with each `workspace:` range resolved (a package of the same train to the release's version, one of another train to that train's last release) and the `source` export condition stripped; runs the smoke test of the tarballs; and publishes each package that is not private, in the order of their dependencies, under the dist-tag of the channel, with provenance. `NPM_DIST_TAG` overrides the dist-tag for a one-off.
+2. **`@wtf/semantic-release-npm`** packs each package of the train into `dist/releases/`, the demos too, with each `workspace:` range resolved (a package of the same train to the release's version, one of another train to that train's last release) and the `source` export condition stripped; runs the smoke test of the tarballs; and publishes each package that is not private, in the order of their dependencies, under the dist-tag of the channel, with provenance. `NPM_DIST_TAG` overrides the dist-tag for a one-off.
 3. **`@semantic-release/gitlab`** creates the GitLab release of the tag, its notes those of the release, its assets every tarball of `dist/releases/` — after the publish succeeded, so a release entry never advertises a tarball that npm refused.
 
 The tag pipeline is what makes the provenance attestation meaningful. npm records the commit of the pipeline in the attestation. On a tag pipeline that commit IS the commit that the tag names. A publish from the branch pipeline attests the PARENT of the release commit instead: a revision that the tag does not name.
@@ -375,9 +375,7 @@ Then, for EACH package:
 To preview what the release of a train would do, without a tag and without a publish:
 
 ```bash
-npm install --global semantic-release@25 @semantic-release/changelog @semantic-release/exec \
-  @semantic-release/git @semantic-release/gitlab @wtf/semantic-release-trains \
-  @wtf/semantic-release-replace @wtf/semantic-release-trains-publish
+npm install --global semantic-release@25 $(cat semrel-required-plugins.txt)
 RELEASE_TRAIN=play semantic-release --dry-run --no-ci
 ```
 
@@ -385,7 +383,7 @@ To test the packaging locally (the same check run by `release-pack-smoke` in CI)
 
 ```bash
 pnpm run build
-semantic-release-trains-smoke
+semantic-release-npm-smoke
 ```
 
 **Do not run `npm publish` manually.** All publishing must go through the release in CI to keep the changelogs, git tags, and npm versions in sync. [Bootstrapping a New Package](#bootstrapping-a-new-package) is the ONE exception, and it publishes a version that holds no code.

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

@@ -6,7 +6,7 @@
 function createConfirmDialog(confirm): Promise<boolean>;
 ```
 
-Defined in: [packages/play-dom/examples/gallery/src/components/ConfirmDialog.ts:18](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/components/ConfirmDialog.ts#L18)
+Defined in: [packages/play-dom/examples/gallery/src/components/ConfirmDialog.ts:18](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/components/ConfirmDialog.ts#L18)
 
 ConfirmDialog — the gallery's `onConfirm` implementation.
 

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

@@ -6,7 +6,7 @@
 function createDebugPanel(actor, container, inspector): () => void;
 ```
 
-Defined in: [packages/play-dom/examples/gallery/src/components/DebugPanel.ts:17](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/components/DebugPanel.ts#L17)
+Defined in: [packages/play-dom/examples/gallery/src/components/DebugPanel.ts:17](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/components/DebugPanel.ts#L17)
 
 DebugPanel — live debug footer factory. Appends the footer to `container`,
 shows the current state value, renders the button that opens the Stately

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

@@ -6,7 +6,7 @@
 function initApp(container): () => void;
 ```
 
-Defined in: [packages/play-dom/examples/gallery/src/App.ts:33](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/App.ts#L33)
+Defined in: [packages/play-dom/examples/gallery/src/App.ts:33](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/App.ts#L33)
 
 Mount the gallery into `container` and return a cleanup function that stops
 whatever actor is live and empties the container.

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

@@ -6,7 +6,7 @@
 function initShell(container, options): () => void;
 ```
 
-Defined in: [packages/play-dom/examples/gallery/src/components/Shell.ts:35](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/components/Shell.ts#L35)
+Defined in: [packages/play-dom/examples/gallery/src/components/Shell.ts:35](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/components/Shell.ts#L35)
 
 Shell — DOM shell layout factory.
 

package/examples/@xmachines/play-dom-gallery-demo/interfaces/GalleryMachineEntry.md

@@ -2,12 +2,12 @@
 
 # Interface: GalleryMachineEntry
 
-Defined in: [packages/play-dom/examples/gallery/src/machines.ts:85](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L85)
+Defined in: [packages/play-dom/examples/gallery/src/machines.ts:85](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L85)
 
 ## Properties
 
 | Property                                            | Type                                                 | Description                                                                                                                              | Defined in                                                                                                                                                                    |
 | --------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| <a id="property-createruntime"></a> `createRuntime` | (`inspect`) => [`GalleryRuntime`](GalleryRuntime.md) | Create a fresh, STARTED actor and its registry for one selection. The caller owns the runtime and must stop the actor when done with it. | [packages/play-dom/examples/gallery/src/machines.ts:93](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L93) |
-| <a id="property-label"></a> `label`                 | `string`                                             | Picker button label and machine-view title.                                                                                              | [packages/play-dom/examples/gallery/src/machines.ts:88](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L88) |
-| <a id="property-slug"></a> `slug`                   | [`GallerySlug`](../type-aliases/GallerySlug.md)      | -                                                                                                                                        | [packages/play-dom/examples/gallery/src/machines.ts:86](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L86) |
+| <a id="property-createruntime"></a> `createRuntime` | (`inspect`) => [`GalleryRuntime`](GalleryRuntime.md) | Create a fresh, STARTED actor and its registry for one selection. The caller owns the runtime and must stop the actor when done with it. | [packages/play-dom/examples/gallery/src/machines.ts:93](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L93) |
+| <a id="property-label"></a> `label`                 | `string`                                             | Picker button label and machine-view title.                                                                                              | [packages/play-dom/examples/gallery/src/machines.ts:88](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L88) |
+| <a id="property-slug"></a> `slug`                   | [`GallerySlug`](../type-aliases/GallerySlug.md)      | -                                                                                                                                        | [packages/play-dom/examples/gallery/src/machines.ts:86](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L86) |

package/examples/@xmachines/play-dom-gallery-demo/interfaces/GalleryRuntime.md

@@ -2,7 +2,7 @@
 
 # Interface: GalleryRuntime
 
-Defined in: [packages/play-dom/examples/gallery/src/machines.ts:80](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L80)
+Defined in: [packages/play-dom/examples/gallery/src/machines.ts:80](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L80)
 
 One live selection: the started actor plus its registry.
 
@@ -10,5 +10,5 @@ One live selection: the started actor plus its registry.
 
 | Property                                              | Type                                                                                             | Defined in                                                                                                                                                                    |
 | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| <a id="property-actor"></a> `actor`                   | [`GalleryActor`](../type-aliases/GalleryActor.md)                                                | [packages/play-dom/examples/gallery/src/machines.ts:81](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L81) |
-| <a id="property-registryresult"></a> `registryResult` | [`DefineRegistryResult`](../../../../api/@xmachines/play-dom/interfaces/DefineRegistryResult.md) | [packages/play-dom/examples/gallery/src/machines.ts:82](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.3.0/packages/play-dom/examples/gallery/src/machines.ts#L82) |
+| <a id="property-actor"></a> `actor`                   | [`GalleryActor`](../type-aliases/GalleryActor.md)                                                | [packages/play-dom/examples/gallery/src/machines.ts:81](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L81) |
+| <a id="property-registryresult"></a> `registryResult` | [`DefineRegistryResult`](../../../../api/@xmachines/play-dom/interfaces/DefineRegistryResult.md) | [packages/play-dom/examples/gallery/src/machines.ts:82](https://gitlab.com/xmachin-es/xmachines-js/-/blob/docs-v7.4.1/packages/play-dom/examples/gallery/src/machines.ts#L82) |