eve 0.47.7 → 0.49.0

package/dist/src/compiled/@workflow/core/runtime/world-compatibility.d.ts

@@ -3,18 +3,29 @@ type WorldSpecVersionMetadata = Pick<World, 'specVersion'>;
 /**
  * Rejects a World this runtime cannot speak to.
  *
- * The accepted range is `[SPEC_VERSION_CURRENT, SPEC_VERSION_MAX_SUPPORTED]`.
- * Below the current version means an old World package paired with a new
- * runtime, which cannot serve the protocol this runtime speaks. Above the
+ * The accepted range is
+ * `[SPEC_VERSION_SUPPORTS_SLOT_IDENTITY, SPEC_VERSION_MAX_SUPPORTED]`. Below
+ * the floor means an old World package paired with a new runtime, which cannot
+ * serve the protocol this runtime speaks. A World that does not number events
+ * by position allocates ids the runtime cannot read positions out of. Above the
  * ceiling means a World built against a newer spec than this runtime knows how
  * to read.
  *
- * Both bounds are the same version today, so this currently admits exactly one.
- * It stays written as a range because the two constants answer different
- * questions and come apart while a spec bump is staged: the ceiling rises when
- * this runtime learns to read the next version, the floor when that version
- * becomes the one Worlds stamp. An equality check against either constant alone
- * would reject a World during that window.
+ * The floor is deliberately the slot-identity version rather than
+ * `SPEC_VERSION_CURRENT`, which now sits one above it at the sealed log. Two
+ * reasons, and both are about the window a spec bump is staged over:
+ *
+ * - `WORKFLOW_SEALED_LOG=0` puts a deployment back on slot identity, so its
+ *   World declares the lower version. Flooring at the version we stamp by
+ *   default would make that kill switch reject the very World it selects,
+ *   turning a rollback into a startup failure.
+ * - A World package one version behind the runtime it ships alongside is the
+ *   normal state mid-bump, and it can still serve the protocol: slot identity
+ *   is what the runtime actually requires, and sealed logs are a capability on
+ *   top of it that only the backend implements.
+ *
+ * The range narrows again when the sealed log becomes mandatory and the flag
+ * goes away, exactly as slot identity's own floor did.
  */
 export declare function assertWorldSupportsRuntimeProtocol(world: WorldSpecVersionMetadata): void;
 export {};

package/dist/src/compiled/@workflow/core/runtime/world-init.d.ts

@@ -1,15 +1,15 @@
 /**
  * Server-only side-effect module that ensures `world.ts` is loaded so its
- * module-load side effect — `globalThis[GetWorldFnKey] ??= getWorld` —
+ * module-load side effect (`globalThis[GetWorldFnKey] ??= getWorld`)
  * fires in host bundles.
  *
  * # Why this exists
  *
  * `getWorldLazy()` in `./get-world-lazy.ts` checks the globalThis cache
  * populated by `world.ts`'s module-load side effect. When a server route
- * only consumes a helper that goes through `getWorldLazy` — for example
- * `start` from `workflow/api`, or `defineHook().resume()` from `workflow`
- * — webpack/turbopack can tree-shake the named import `{ getWorld }` out
+ * only consumes a helper that goes through `getWorldLazy` (for example
+ * `start` from `workflow/api`, or `defineHook().resume()` from `workflow`),
+ * webpack/turbopack can tree-shake the named import `{ getWorld }` out
  * of `runtime.ts`, taking `world.ts`'s module evaluation with it. The
  * globalThis registration never fires.
  *
@@ -41,7 +41,7 @@
  *
  * If you add another `getWorldLazy()` consumer that's reachable from a
  * host route without going through `workflow` or `workflow/api`, make
- * sure that entry also imports this module — or that it transitively
+ * sure that entry also imports this module, or that it transitively
  * reaches `world.ts` via a non-tree-shakeable path. Adding a regression
  * test in `world-init.test.ts` is preferred to relying on careful manual
  * tracing.