@workflow/core 4.2.0-beta.73 → 4.2.0-beta.75

package/docs/how-it-works/event-sourcing.mdx

@@ -1,6 +1,6 @@
 ---
 title: Event Sourcing
-description: Learn how Workflow DevKit uses event sourcing internally for debugging and observability.
+description: Learn how Workflow SDK uses event sourcing internally for debugging and observability.
 type: conceptual
 summary: Understand the event log that powers workflow replay and debugging.
 prerequisites:
@@ -10,10 +10,10 @@ related:
 ---
 
 <Callout>
-This guide explores how the Workflow DevKit uses event sourcing internally. Understanding these concepts is helpful for debugging and building observability tools, but is not required to use workflows. For getting started with workflows, see the [getting started](/docs/getting-started) guides for your framework.
+This guide explores how the Workflow SDK uses event sourcing internally. Understanding these concepts is helpful for debugging and building observability tools, but is not required to use workflows. For getting started with workflows, see the [getting started](/docs/getting-started) guides for your framework.
 </Callout>
 
-The Workflow DevKit uses event sourcing to track all state changes in workflow executions. Every mutation creates an event that is persisted to the event log, and entity state is derived by replaying these events.
+The Workflow SDK uses event sourcing to track all state changes in workflow executions. Every mutation creates an event that is persisted to the event log, and entity state is derived by replaying these events.
 
 This page explains the event sourcing model and entity lifecycles.
 
@@ -28,7 +28,7 @@ Event sourcing is a persistence pattern where state changes are stored as a sequ
 - **Consistency**: Events provide a single source of truth for all entity state
 - **Recoverability**: State can be reconstructed from the event log after failures
 
-In the Workflow DevKit, the following entity types are managed through events:
+In the Workflow SDK, the following entity types are managed through events:
 
 - **Runs**: Workflow execution instances (materialized in storage)
 - **Steps**: Individual atomic operations within a workflow (materialized in storage)
@@ -243,7 +243,7 @@ This correlation enables:
 
 ## Entity IDs
 
-All entities in the Workflow DevKit use a consistent ID format: a 4-character prefix followed by an underscore and a [ULID](https://github.com/ulid/spec) (Universally Unique Lexicographically Sortable Identifier).
+All entities in the Workflow SDK use a consistent ID format: a 4-character prefix followed by an underscore and a [ULID](https://github.com/ulid/spec) (Universally Unique Lexicographically Sortable Identifier).
 
 | Entity | Prefix | Example |
 |--------|--------|---------|

package/docs/how-it-works/framework-integrations.mdx

@@ -1,8 +1,8 @@
 ---
 title: Framework Integrations
-description: Guide for framework authors to integrate Workflow DevKit with custom frameworks or runtimes.
+description: Guide for framework authors to integrate Workflow SDK with custom frameworks or runtimes.
 type: guide
-summary: Build a custom framework integration using the Workflow DevKit compiler and runtime.
+summary: Build a custom framework integration using the Workflow SDK compiler and runtime.
 prerequisites:
   - /docs/foundations/workflows-and-steps
 related:
@@ -10,13 +10,13 @@ related:
 ---
 
 <Callout>
-  **For users:** If you just want to use Workflow DevKit with an existing framework, check out the [Getting Started](/docs/getting-started) guide instead. This page is for framework authors who want to integrate Workflow DevKit with their framework or runtime.
+  **For users:** If you just want to use Workflow SDK with an existing framework, check out the [Getting Started](/docs/getting-started) guide instead. This page is for framework authors who want to integrate Workflow SDK with their framework or runtime.
 </Callout>
 
-This guide walks you through building a framework integration for Workflow DevKit using Bun as a concrete example. The same principles apply to any JavaScript runtime (Node.js, Deno, Cloudflare Workers, etc.).
+This guide walks you through building a framework integration for Workflow SDK using Bun as a concrete example. The same principles apply to any JavaScript runtime (Node.js, Deno, Cloudflare Workers, etc.).
 
 <Callout type="info">
-  **Prerequisites:** Before building a framework integration, we recommend reading [How the Directives Work](/docs/how-it-works/code-transform) to understand the transformation system that powers Workflow DevKit.
+  **Prerequisites:** Before building a framework integration, we recommend reading [How the Directives Work](/docs/how-it-works/code-transform) to understand the transformation system that powers Workflow SDK.
 </Callout>
 
 ## What You'll Build
@@ -46,7 +46,7 @@ flowchart TD
     style J fill:#a78bfa,stroke:#8b5cf6,color:#000
 ```
 
-The purple boxes are what you implement—everything else is provided by Workflow DevKit.
+The purple boxes are what you implement—everything else is provided by Workflow SDK.
 
 ## Example: Bun Integration
 
@@ -259,7 +259,7 @@ class MyFrameworkBuilder extends BaseBuilder {
 }
 ```
 
-If your framework supports virtual server routes and dev mode watching, make sure to adapt accordingly. Please open a PR to the Workflow DevKit if the base builder class is missing necessary functionality.
+If your framework supports virtual server routes and dev mode watching, make sure to adapt accordingly. Please open a PR to the Workflow SDK if the base builder class is missing necessary functionality.
 
 Hook into your framework's build:
 
@@ -341,8 +341,8 @@ const server = Bun.serve({
 ```
 
 Production framework integrations should handle this routing in the plugin instead of leaving it to the user, and this depends on each framework's unique implementaiton.
-Check the Workflow DevKit source code for examples of production framework implementations.
-In the future, the Workflow DevKit will emit more routes under the `.well-known/workflow` namespace.
+Check the Workflow SDK source code for examples of production framework implementations.
+In the future, the Workflow SDK will emit more routes under the `.well-known/workflow` namespace.
 
 ## Security
 

package/docs/how-it-works/understanding-directives.mdx

@@ -1,6 +1,6 @@
 ---
 title: Understanding Directives
-description: Explore how JavaScript directives enable the Workflow DevKit's durable execution model.
+description: Explore how JavaScript directives enable the Workflow SDK's durable execution model.
 type: conceptual
 summary: Explore the design decisions behind "use workflow" and "use step" directives.
 prerequisites:
@@ -12,18 +12,18 @@ related:
 import { File, Folder, Files } from "fumadocs-ui/components/files";
 
 <Callout>
-This guide explores how JavaScript directives enable the Workflow DevKit's execution model. For getting started with workflows, see the [getting started](/docs/getting-started) guides for your framework.
+This guide explores how JavaScript directives enable the Workflow SDK's execution model. For getting started with workflows, see the [getting started](/docs/getting-started) guides for your framework.
 </Callout>
 
 The Workflow Development Kit uses JavaScript directives (`"use workflow"` and `"use step"`) as the foundation for its durable execution model. Directives provide the compile-time semantic boundary necessary for workflows to suspend, resume, and maintain deterministic behavior across replays.
 
 This page explores how directives enable this execution model and the design principles that led us here.
 
-To understand how directives work, let's first understand what workflows and steps are in the Workflow DevKit.
+To understand how directives work, let's first understand what workflows and steps are in the Workflow SDK.
 
 ## Workflows and Steps Primer
 
-The Workflow DevKit has two types of functions:
+The Workflow SDK has two types of functions:
 
 **Step functions** are side-effecting operations with full Node.js runtime access. Think of them like named RPC calls - they run once, their result is persisted, and they can be [retried on failure](/docs/foundations/errors-and-retries):
 
@@ -60,7 +60,7 @@ export async function onboardUser(userId: string) {
 - **If already executed:** Returns the cached result immediately from the event log
 - **If not yet executed:** Suspends the workflow, enqueues the step for background execution, and resumes later with the result
 
-This replay mechanism requires deterministic code. If `Math.random()` weren't seeded, the first execution might return `0.7` (sending the email) but replay might return `0.3` (skipping it), thus breaking resumption. The Workflow DevKit sandbox provides seeded `Math.random()` and `Date` to ensure consistent behavior across replays.
+This replay mechanism requires deterministic code. If `Math.random()` weren't seeded, the first execution might return `0.7` (sending the email) but replay might return `0.3` (skipping it), thus breaking resumption. The Workflow SDK sandbox provides seeded `Math.random()` and `Date` to ensure consistent behavior across replays.
 
 <Callout>
 For a deeper dive into workflows and steps, see [Workflows and Steps](/docs/foundations/workflows-and-steps).
@@ -85,11 +85,11 @@ JavaScript directives have precedent for changing execution semantics within a d
 
 - `"use strict"` (introduced in ECMAScript 5 in 2009, TC39-standardized) changes language rules to make the runtime faster, safer, and more predictable.
 - `"use client"` and `"use server"` (introduced by [React Server Components](https://react.dev/reference/rsc/server-components)) define an explicit boundary of "where" code gets executed - client-side browser JavaScript vs server-side Node.js.
-- `"use workflow"` (introduced by the Workflow DevKit) defines both "where" code runs (in a deterministic sandbox environment) and "how" it runs (deterministic, resumable, sandboxed execution semantics).
+- `"use workflow"` (introduced by the Workflow SDK) defines both "where" code runs (in a deterministic sandbox environment) and "how" it runs (deterministic, resumable, sandboxed execution semantics).
 
 Directives provide a build-time contract.
 
-When the Workflow DevKit sees `"use workflow"`, it:
+When the Workflow SDK sees `"use workflow"`, it:
 
 - Bundles the workflow and its dependencies into code that can be run in a sandbox
 - Restricts access to Node.js APIs in that sandbox
@@ -99,7 +99,7 @@ When the Workflow DevKit sees `"use workflow"`, it:
 In addition to being important to the compiler, `"use workflow"` explicitly signals to the developer that you are entering a different execution mode.
 
 <Callout type="info">
-The `"use workflow"` directive is also used by the Language Server Plugin shipped with Workflow DevKit to provide IntelliSense to your IDE. Check the [getting started instructions](/docs/getting-started) for your framework for details on setting up the Language Server Plugin.
+The `"use workflow"` directive is also used by the Language Server Plugin shipped with Workflow SDK to provide IntelliSense to your IDE. Check the [getting started instructions](/docs/getting-started) for your framework for details on setting up the Language Server Plugin.
 </Callout>
 
 But we didn't get here immediately. This took some discovery to arrive at:
@@ -298,7 +298,7 @@ Different frameworks and developers have strong opinions about project structure
 
 **2. No support for publishable, reusable functions**
 
-We want developers to be able to publish libraries to npm that include step and workflow directives. Ideally, logic that is isomorphic so it could be used with and without Workflow DevKit. File system conventions made this impossible.
+We want developers to be able to publish libraries to npm that include step and workflow directives. Ideally, logic that is isomorphic so it could be used with and without Workflow SDK. File system conventions made this impossible.
 
 **3. Migration and code reuse became difficult**
 
@@ -375,7 +375,7 @@ class MyWorkflow {
 }
 ```
 
-The compiler could transform both to be equivalent to WDK's directive approach:
+The compiler could transform both to be equivalent to Workflow SDK's directive approach:
 
 ```typescript lineNumbers
 export const processOrder = async (orderId: string) => {
@@ -461,7 +461,7 @@ export async function badWorkflow() {
 }
 ```
 
-In fact, Workflow DevKit will throw an error that links to this error page: [Node.js module in workflow](/docs/errors/node-js-module-in-workflow)
+In fact, Workflow SDK will throw an error that links to this error page: [Node.js module in workflow](/docs/errors/node-js-module-in-workflow)
 
 **3. No closure ambiguity**
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@workflow/core",
-  "version": "4.2.0-beta.73",
-  "description": "Core runtime and engine for Workflow DevKit",
+  "version": "4.2.0-beta.75",
+  "description": "Core runtime and engine for Workflow SDK",
   "type": "module",
   "main": "dist/index.js",
   "files": [
@@ -77,18 +77,20 @@
     "ms": "2.1.3",
     "nanoid": "5.1.6",
     "seedrandom": "3.0.5",
+    "semver": "7.7.4",
     "ulid": "~3.0.1",
     "zod": "4.3.6",
-    "@workflow/errors": "4.1.0-beta.19",
+    "@workflow/errors": "4.1.0-beta.20",
     "@workflow/serde": "4.1.0-beta.2",
     "@workflow/utils": "4.1.0-beta.13",
-    "@workflow/world": "4.1.0-beta.14",
-    "@workflow/world-local": "4.1.0-beta.46",
-    "@workflow/world-vercel": "4.1.0-beta.45"
+    "@workflow/world": "4.1.0-beta.15",
+    "@workflow/world-local": "4.1.0-beta.48",
+    "@workflow/world-vercel": "4.1.0-beta.46"
   },
   "devDependencies": {
     "@opentelemetry/api": "1.9.0",
     "@types/debug": "4.1.12",
+    "@types/semver": "7.7.1",
     "@types/node": "22.19.0",
     "@types/seedrandom": "3.0.8",
     "cross-env": "10.1.0",