@typeonce/effect-machine 0.26.2 → 0.27.1

package/docs/agent-guide.md

@@ -318,6 +318,25 @@ machine.
 Do not start a promise inside a transition callback. A transition has no
 lifetime in which to own that work. A state does.
 
+Give every invocation declared by one state a unique lifecycle ID. Give every
+logic or child process that can be active at the same time a unique runtime
+address as well:
+
+```ts
+Loading: {
+  invoke: (from) => [
+    from.effect("load-document", loadDocument),
+    from.timer("load-timeout", "10 seconds")
+  ]
+}
+```
+
+Invocation outcomes are routed by state path and lifecycle ID, and overlapping
+children cannot own the same runtime address. If work is sequential, represent
+the sequence with separate states and transition from the first outcome. Do
+not depend on one child completing quickly enough for another declaration to
+reuse its identity.
+
 ### Choose state-owned or process-owned children
 
 Use `from.child(...)` when the child belongs to one state and must stop when

package/docs/machine-review.md

@@ -8,6 +8,14 @@ Read the [Effect Machine agent guide](./agent-guide.md) for statechart modeling
 and [Effect Atom and React patterns](./effect-atom-react.md) for integration
 patterns.
 
+Run the recommended rules from
+[`@typeonce/oxlint-plugin-effect-machine`](../../oxlint-plugin/README.md) before
+the manual review. They catch provable duplicate invocation identities,
+asynchronous work, browser access, nondeterminism, and redundant resolvers in
+direct same-module machine definitions. Continue with this review for
+cross-module ownership and architectural questions that syntax alone cannot
+answer.
+
 ## Review the responsibility boundaries
 
 Use this split when deciding where code belongs:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@typeonce/effect-machine",
-  "version": "0.26.2",
+  "version": "0.27.1",
   "description": "Schema-first state machines and statecharts for Effect",
   "author": "Sandro Maglione",
   "repository": {