workflow 4.2.0-beta.73 → 4.2.0-beta.75

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/docs/observability/index.mdx

@@ -10,7 +10,7 @@ related:
   - /docs/how-it-works/encryption
 ---
 
-Workflow DevKit provides powerful tools to inspect, monitor, and debug your workflows through the CLI and Web UI. These tools allow you to inspect workflow runs, steps, webhooks, [events](/docs/how-it-works/event-sourcing), and stream output.
+Workflow SDK provides powerful tools to inspect, monitor, and debug your workflows through the CLI and Web UI. These tools allow you to inspect workflow runs, steps, webhooks, [events](/docs/how-it-works/event-sourcing), and stream output.
 
 ## Quick Start
 
@@ -18,7 +18,7 @@ Workflow DevKit provides powerful tools to inspect, monitor, and debug your work
 npx workflow
 ```
 
-The CLI comes pre-installed with the Workflow DevKit and registers the `workflow` command. If the `workflow` package is not already installed, `npx workflow` will install it globally, or use the local installed version if available.
+The CLI comes pre-installed with the Workflow SDK and registers the `workflow` command. If the `workflow` package is not already installed, `npx workflow` will install it globally, or use the local installed version if available.
 
 Get started inspecting your local workflows:
 
@@ -32,7 +32,7 @@ npx workflow inspect runs
 
 ## Web UI
 
-Workflow DevKit ships with a local web UI for inspecting your workflows. The CLI
+Workflow SDK ships with a local web UI for inspecting your workflows. The CLI
 will locally serve the Web UI when using the `--web` flag.
 
 ```bash
@@ -40,11 +40,11 @@ will locally serve the Web UI when using the `--web` flag.
 npx workflow inspect runs --web
 ```
 
-![Workflow DevKit Web UI](/o11y-ui.png)
+![Workflow SDK Web UI](/o11y-ui.png)
 
 ## Backends
 
-The Workflow DevKit CLI can inspect data from any [World](/docs/deploying). By default, it inspects data in your local development environment. For example, if you are using Next.js to develop workflows locally, the
+The Workflow SDK CLI can inspect data from any [World](/docs/deploying). By default, it inspects data in your local development environment. For example, if you are using Next.js to develop workflows locally, the
 CLI will find the data in your `.next/workflow-data/` directory.
 
 If you're deploying workflows to a production environment, but want to inspect the data by using the CLI, you can specify the world you are using by setting the `--backend` flag to your world's name or package name, e.g. `vercel`.

package/docs/testing/index.mdx

@@ -3,7 +3,7 @@ title: Testing
 description: Unit test individual steps and integration test entire workflows using Vitest.
 ---
 
-Testing is a critical part of building reliable workflows. Because steps are just functions annotated with directives, they can be unit tested like any other JavaScript function. Workflow DevKit also provides a Vitest plugin that runs full workflows in-process — no running server required.
+Testing is a critical part of building reliable workflows. Because steps are just functions annotated with directives, they can be unit tested like any other JavaScript function. Workflow SDK also provides a Vitest plugin that runs full workflows in-process — no running server required.
 
 This guide covers two approaches:
 
@@ -356,7 +356,7 @@ For advanced setups that require a running server (e.g. testing against your act
 
 ## Debugging Test Runs
 
-When integration tests fail, the [Workflow DevKit CLI and Web UI](/docs/observability) can help you inspect what happened. Because integration tests persist workflow state locally, you can use the same observability tools you would use in development.
+When integration tests fail, the [Workflow SDK CLI and Web UI](/docs/observability) can help you inspect what happened. Because integration tests persist workflow state locally, you can use the same observability tools you would use in development.
 
 Launch the Web UI to visually explore your test workflow runs:
 
@@ -376,7 +376,7 @@ npx workflow inspect runs <run-id>
 
 The Web UI shows each step, its inputs and outputs, retry attempts, hook state, and timing. This is especially useful for diagnosing issues with hooks that were not resumed, steps that failed unexpectedly, or workflows that timed out.
 
-![Workflow DevKit Web UI](/o11y-ui.png)
+![Workflow SDK Web UI](/o11y-ui.png)
 
 <Callout type="info">
 See the [Observability](/docs/observability) docs for the full set of CLI commands and Web UI features.
@@ -418,5 +418,5 @@ Integration tests are the right place to verify that your workflows handle error
 ---
 
 <Callout type="info">
-This guide was inspired by the testing approach described in Mux's article [*Launching durable AI workflows for video with @mux/ai*](https://www.mux.com/blog/launching-durable-ai-workflows-for-video-with-mux-ai#testing), which demonstrates how Mux uses the `workflow/vite` plugin with Vitest to integration test their durable AI video workflows built on Workflow DevKit.
+This guide was inspired by the testing approach described in Mux's article [*Launching durable AI workflows for video with @mux/ai*](https://www.mux.com/blog/launching-durable-ai-workflows-for-video-with-mux-ai#testing), which demonstrates how Mux uses the `workflow/vite` plugin with Vitest to integration test their durable AI video workflows built on Workflow SDK.
 </Callout>

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "workflow",
-  "version": "4.2.0-beta.73",
-  "description": "Workflow DevKit - Build durable, resilient, and observable workflows",
+  "version": "4.2.0-beta.75",
+  "description": "Workflow SDK - Build durable, resilient, and observable workflows",
   "main": "dist/typescript-plugin.cjs",
   "type": "module",
   "bin": {
@@ -57,18 +57,18 @@
   },
   "dependencies": {
     "ms": "2.1.3",
-    "@workflow/astro": "4.0.0-beta.47",
-    "@workflow/cli": "4.2.0-beta.73",
-    "@workflow/core": "4.2.0-beta.73",
-    "@workflow/errors": "4.1.0-beta.19",
+    "@workflow/astro": "4.0.0-beta.49",
+    "@workflow/cli": "4.2.0-beta.75",
+    "@workflow/core": "4.2.0-beta.75",
+    "@workflow/errors": "4.1.0-beta.20",
     "@workflow/typescript-plugin": "4.0.1-beta.5",
     "@workflow/utils": "4.1.0-beta.13",
-    "@workflow/next": "4.0.1-beta.69",
-    "@workflow/nest": "0.0.0-beta.22",
-    "@workflow/nitro": "4.0.1-beta.68",
-    "@workflow/nuxt": "4.0.1-beta.57",
-    "@workflow/sveltekit": "4.0.0-beta.62",
-    "@workflow/rollup": "4.0.0-beta.30"
+    "@workflow/next": "4.0.1-beta.71",
+    "@workflow/nest": "0.0.0-beta.24",
+    "@workflow/nitro": "4.0.1-beta.70",
+    "@workflow/nuxt": "4.0.1-beta.59",
+    "@workflow/sveltekit": "4.0.0-beta.64",
+    "@workflow/rollup": "4.0.0-beta.32"
   },
   "devDependencies": {
     "@types/ms": "2.1.0",