workflow 5.0.1 → 5.1.0

package/docs/ai/chat-session-modeling.mdx

@@ -267,9 +267,9 @@ Use the multi-turn pattern when:
 
 The multi-turn pattern also supports messages from system events, external services, and multiple users. Every source resumes the same Hook; the workflow queues those messages and processes them between model turns.
 
-<Tabs items={['System event', 'External service', 'Multiple users']}>
+<TabsWithChildren tabs={["System event","External service","Multiple users"]}>
 
-<Tab value="System event">
+<TabContent order={1}>
 
 Scheduled tasks, background jobs, or database triggers can inject updates into an active conversation:
 
@@ -287,9 +287,9 @@ export async function POST(request: Request) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="External service">
+<TabContent order={2}>
 
 A third-party webhook can notify the conversation about an external event:
 
@@ -309,9 +309,9 @@ export async function POST(request: Request) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Multiple users">
+<TabContent order={3}>
 
 Multiple authenticated users can participate in the same workflow-owned session. Include attribution when resuming the Hook:
 
@@ -337,9 +337,9 @@ export async function POST(
 
 To preserve structured attribution across refreshes, persist the corresponding `UIMessage` using the application-history approach described above.
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 
 ## Related documentation
 

package/docs/ai/human-in-the-loop.mdx

@@ -189,7 +189,7 @@ export function BookingApproval({ toolCallId, input, output }: BookingApprovalPr
   if (output) {
     return (
       <div className="border rounded-lg p-4">
-        <p className="text-sm text-muted-foreground">{output}</p>
+        <p className="text-sm text-gray-900">{output}</p>
       </div>
     );
   }
@@ -211,7 +211,7 @@ export function BookingApproval({ toolCallId, input, output }: BookingApprovalPr
     <div className="border rounded-lg p-4 space-y-4">
       <div className="space-y-2">
         <p className="font-medium">Approve this booking?</p>
-        <div className="text-sm text-muted-foreground">
+        <div className="text-sm text-gray-900">
           {input && (
             <div className="space-y-2">
               <div>Flight: {input.flightNumber}</div>

package/docs/ai/index.mdx

@@ -59,9 +59,9 @@ cd workflow-examples/flight-booking-app
 
 ### Configure model access
 
-<Tabs items={['AI Gateway', 'Provider package']}>
+<TabsWithChildren tabs={["AI Gateway","Provider package"]}>
 
-<Tab value="AI Gateway">
+<TabContent order={1}>
 
 AI SDK uses [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) as its default global provider, so plain `"provider/model"` strings need no provider-specific package. Vercel deployments authenticate with OIDC automatically. For local development, link the project and pull a short-lived OIDC token:
 
@@ -72,9 +72,9 @@ vercel env pull .env.local
 
 You can alternatively set `AI_GATEWAY_API_KEY` from the [AI Gateway authentication](https://vercel.com/docs/ai-gateway/authentication) page.
 
-</Tab>
+</TabContent>
 
-<Tab value="Provider package">
+<TabContent order={2}>
 
 `WorkflowAgent` accepts any AI SDK provider. To use OpenAI, install its provider package:
 
@@ -98,9 +98,9 @@ const model = openai("gpt-5.6-sol");
 
 See the [AI SDK provider guide](https://ai-sdk.dev/providers/ai-sdk-providers) for Anthropic, Google, Amazon Bedrock, and other providers.
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 </Step>
 
 <Step>
@@ -111,9 +111,9 @@ Run the app with `npm run dev` and open [http://localhost:3000](http://localhost
 
 The following sections break down the core code. You don't need to make changes yet.
 
-<Tabs items={['API Route', 'Tools', 'Client']}>
+<TabsWithChildren tabs={["API Route","Tools","Client"]}>
 
-<Tab value="API Route">
+<TabContent order={1}>
 
 Our API route calls [AI SDK's `ToolLoopAgent` class](https://ai-sdk.dev/docs/agents/overview), which encapsulates the LLM call, tool execution loop, and stopping conditions on top of [AI SDK's `streamText` function](https://ai-sdk.dev/docs/reference/ai-sdk-core/stream-text#streamtext). This is also where we pass tools to the agent.
 
@@ -137,9 +137,9 @@ export async function POST(req: Request) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Tools">
+<TabContent order={2}>
 
 Our tools are mostly mocked out for the sake of the example. We use AI SDK's `tool` function to define the tool, and pass it to the agent. In your own app, this might be any kind of tool call, like database queries, calls to external services, etc.
 
@@ -160,9 +160,9 @@ async function searchFlights({ from, to, date }: { from: string; to: string; dat
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Client">
+<TabContent order={3}>
 
 Our `ChatPage` component contains logic for displaying chat messages, but its core responsibility is managing input and output for the [`useChat` hook](https://ai-sdk.dev/docs/reference/ai-sdk-ui/use-chat#usechat) from AI SDK.
 
@@ -207,9 +207,9 @@ export default function ChatPage() {
 }
 ```
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 
 </Step>
 

package/docs/ai/streaming-updates-from-tools.mdx

@@ -120,9 +120,9 @@ Update your chat component to detect and render the custom data parts. Data part
       to: string; // [!code highlight]
     }; // [!code highlight]
     return ( // [!code highlight]
-      <div key={`${part.id}-${flight.flightNumber}`} className="p-3 bg-muted rounded-md"> // [!code highlight]
+      <div key={`${part.id}-${flight.flightNumber}`} className="p-3 bg-gray-100 rounded-md"> // [!code highlight]
         <div className="font-medium">{flight.airline} - {flight.flightNumber}</div> // [!code highlight]
-        <div className="text-muted-foreground">{flight.from} → {flight.to}</div> // [!code highlight]
+        <div className="text-gray-900">{flight.from} → {flight.to}</div> // [!code highlight]
       </div> // [!code highlight]
     ); // [!code highlight]
   } // [!code highlight]

package/docs/api-reference/workflow-nest/index.mdx

@@ -10,7 +10,7 @@ related:
 NestJS integration for Workflow SDK. The `WorkflowModule` builds the workflow bundles on application startup and registers the controller that serves the workflow runtime routes.
 
 <Callout>
-NestJS integration is experimental and not yet supported for deployment to Vercel. The same exports are also available from the `@workflow/nest` package.
+NestJS integration is in beta. Both `@nestjs/platform-express` and `@nestjs/platform-fastify` are supported, and deploying to Vercel goes through [`workflow-nest build --vercel`](/docs/getting-started/nestjs#deploy-to-vercel). The same exports are also available from the `@workflow/nest` package.
 </Callout>
 
 ## Exports
@@ -25,6 +25,9 @@ NestJS integration is experimental and not yet supported for deployment to Verce
     <Card title="WorkflowController" href="/docs/api-reference/workflow-nest/workflow-controller">
         Controller that serves the workflow runtime routes under `.well-known/workflow/v1`
     </Card>
+    <Card title="isWorkflowRequest()" href="/docs/api-reference/workflow-nest/is-workflow-request">
+        Recognises a workflow request in a guard, so queue deliveries and webhooks are not rejected by your own auth
+    </Card>
     <Card title="configureWorkflowController()" href="/docs/api-reference/workflow-nest/configure-workflow-controller">
         Points `WorkflowController` at the directory containing the generated workflow bundles
     </Card>

package/docs/api-reference/workflow-nest/is-workflow-request.mdx

@@ -0,0 +1,58 @@
+---
+title: isWorkflowRequest
+description: Recognise a Workflow SDK request inside a NestJS guard or interceptor.
+type: reference
+summary: Let queue deliveries and webhooks past an application guard.
+prerequisites:
+  - /docs/getting-started/nestjs
+---
+
+Returns `true` when NestJS routed the request an `ExecutionContext` is handling to [`WorkflowController`](/docs/api-reference/workflow-nest/workflow-controller), which serves the Workflow SDK's protocol routes under `.well-known/workflow/v1`. The check is on the selected controller rather than the URL, so an application route that can be reached through a URL containing `.well-known/workflow/v1` (a wildcard such as `files/*path`) is still treated as your route.
+
+[`WorkflowController`](/docs/api-reference/workflow-nest/workflow-controller) is a controller inside your application, so a global guard runs for it too. A guard that rejects unauthenticated requests rejects every queue delivery and webhook with `403`, and runs stop making progress with no other symptom. Use this helper to exempt them.
+
+The workflow routes authenticate their own callers — queue deliveries are signed and webhook tokens are single-use secrets — so letting them past an application guard exposes nothing.
+
+## Usage
+
+{/* @skip-typecheck - NestJS decorators require special TypeScript config */}
+
+```typescript title="src/auth.guard.ts" lineNumbers
+import {
+  Injectable,
+  type CanActivate,
+  type ExecutionContext,
+} from "@nestjs/common";
+import { isWorkflowRequest } from "workflow/nest"; // [!code highlight]
+
+@Injectable()
+export class AuthGuard implements CanActivate {
+  canActivate(context: ExecutionContext) {
+    if (isWorkflowRequest(context)) return true; // [!code highlight]
+    return this.authenticate(context);
+  }
+}
+```
+
+## API signature
+
+### Parameters
+
+| Parameter | Type | Description |
+| --- | --- | --- |
+| `context` | `ExecutionContext` | The execution context NestJS passes to a guard or interceptor. |
+
+### Returns
+
+`boolean`. `false` for a request to any other route, and for non-HTTP execution contexts (RPC, WebSockets), where there is no workflow route to match.
+
+## Related exports
+
+| Export | Description |
+| --- | --- |
+| `isWorkflowRoutePath(path, globalPrefix?)` | Whether a raw URL or path addresses a workflow route, for middleware that has a request rather than an `ExecutionContext`. The match is anchored to `globalPrefix` (default `''`), so pass the prefix given to `app.setGlobalPrefix()` unless it excludes the workflow routes. |
+| `WORKFLOW_ROUTE_PREFIX` | `'.well-known/workflow/v1'`, the path the controller is mounted at. |
+
+<Callout type="info">
+Interceptors and exception filters need no exemption. The workflow handlers write through `@Res()`, so the exact status and body the workflow runtime produced reach the caller, which is what the queue and third-party webhook senders key off.
+</Callout>

package/docs/api-reference/workflow-nest/meta.json

@@ -4,6 +4,7 @@
     "workflow-module",
     "nest-local-builder",
     "workflow-controller",
+    "is-workflow-request",
     "configure-workflow-controller"
   ]
 }

package/docs/api-reference/workflow-nest/workflow-controller.mdx

@@ -9,9 +9,13 @@ prerequisites:
 
 NestJS controller that handles the well-known workflow endpoints under `.well-known/workflow/v1`. It dynamically imports the generated workflow bundles and converts between Express/Fastify requests and the Web API `Request`/`Response` objects the workflow runtime expects. Both the Express and Fastify HTTP adapters are supported.
 
-The conversion preserves bytes in both directions: request bodies come from `req.rawBody` when the app is created with `{ rawBody: true }`, from a `Buffer`/string body left by a parser, or read directly from the request stream when no parser claimed the content type. Responses are written as bytes, and every `set-cookie` value is kept. See [Raw request bodies](/docs/getting-started/nestjs#raw-request-bodies).
+The conversion preserves bytes in both directions. [`WorkflowModule`](/docs/api-reference/workflow-nest/workflow-module) keeps the application's body parsers off these routes, so the request body is normally read straight from the stream; a `req.rawBody` left by `{ rawBody: true }`, or a `Buffer`/string body left by a parser, is used when one is present. Responses are written as bytes, and every `set-cookie` value is kept. See [Request bodies and body parsers](/docs/getting-started/nestjs#request-bodies-and-body-parsers).
 
-Handlers take `@Res()`, so the application's interceptors and exception filters do not wrap these routes. That is deliberate: the queue and third-party webhook senders key off the exact status and body the workflow runtime produces.
+Handlers take `@Res()` and write the response themselves, so an interceptor or exception filter cannot reshape it. That is deliberate: the queue and third-party webhook senders key off the exact status and body the workflow runtime produces.
+
+Guards do run, because NestJS runs them before the handler. A global guard that rejects unauthenticated requests rejects queue deliveries too; see [`isWorkflowRequest`](/docs/api-reference/workflow-nest/is-workflow-request).
+
+The controller is registered as `VERSION_NEUTRAL`, so `app.enableVersioning()` does not move these routes away from the paths the SDK generates URLs for. A global prefix does apply, and `WorkflowModule` adopts it automatically.
 
 [`WorkflowModule.forRoot()`](/docs/api-reference/workflow-nest/workflow-module) registers this controller automatically. You only register it yourself if you are not using `WorkflowModule`.
 

package/docs/api-reference/workflow-nest/workflow-module.mdx

@@ -86,6 +86,7 @@ Extends [`NestBuilderOptions`](/docs/api-reference/workflow-nest/nest-local-buil
 | `basePath` | `string` | adopted from `app.setGlobalPrefix()` | Route prefix the workflow endpoints are served under, applied to generated callback and webhook URLs. Set it when a reverse proxy mounts the app on a sub-path NestJS cannot see. |
 | `manageWorldLifecycle` | `boolean` | `false` | Start the target World's background workers with the app and close them on shutdown. Required for self-hosted Worlds, which otherwise never pick up runs. |
 | `preloadBundles` | `boolean` | `false` when `VERCEL` is set, else `true` | Load the generated bundles during startup instead of on the first request. On Vercel, dedicated functions serve the bundles, so there is nothing to preload. |
+| `bypassBodyParser` | `boolean` | `true` | Keep the application's body parsers away from `.well-known/workflow/v1`, so queue deliveries are not rejected by Express's 100 KB limit and signed webhook bodies stay byte-exact. The application's own routes are untouched. On Fastify, where the body limit is enforced per instance rather than per route, nothing is patched and a limit low enough to reject deliveries is reported at startup instead. |
 | `workingDir` | `string` | `process.cwd()` | Working directory for the NestJS application. |
 | `dirs` | `string[]` | `['src']` | Directories to scan for workflow files. |
 | `outDir` | `string` | `'.nestjs/workflow'` (relative to `workingDir`) | Output directory for generated workflow bundles. |
@@ -126,9 +127,16 @@ The older `WORKFLOW_OPTIONS` token resolves to the same value and is kept for co
 
 | Hook | Behaviour |
 | --- | --- |
-| `onModuleInit` | Reconciles the base path against `app.setGlobalPrefix()`, builds the bundles (or verifies they exist when `skipBuild` is set), optionally starts the World, and preloads the bundles. |
+| `onModuleInit` | Takes the application's body parsers off the workflow routes (unless `bypassBodyParser` is `false`), reconciles the base path against `app.setGlobalPrefix()`, builds the bundles (or verifies they exist when `skipBuild` is set), optionally starts the World, and preloads the bundles. |
 | `onApplicationShutdown` | Closes the World when `manageWorldLifecycle` is set. Call `app.enableShutdownHooks()` so this runs on a signal. |
 
+<Callout type="warn">
+`WorkflowModule` reads NestJS's global prefix and HTTP adapter through the
+injector, which only works while a single copy of `@nestjs/core` is installed.
+With two copies the injection tokens differ, prefix handling and the
+body-parser bypass both stop working, and a warning is logged at startup.
+</Callout>
+
 <Callout type="warn">
 Workflows and steps run outside the NestJS injector, so providers cannot be injected into `"use workflow"` or `"use step"` code. See [NestJS dependency injection is not available in workflows and steps](/docs/getting-started/nestjs#nestjs-dependency-injection-is-not-available-in-workflows-and-steps).
 </Callout>

package/docs/configuration/framework-options.mdx

@@ -126,6 +126,12 @@ Configure Workflow through `WorkflowModule.forRoot()`.
 - Default: `false`
 - Skips bundle generation when bundles are already pre-built.
 
+### `bypassBodyParser`
+
+- Environment override: none
+- Default: `true`
+- Keeps the application's body parsers away from `.well-known/workflow/v1`, so queue deliveries are not rejected by Express's 100 KB limit and signed webhook bodies stay byte-exact. Other routes are untouched. On Fastify, where the body limit is enforced per instance rather than per route, nothing is patched and a limit low enough to reject deliveries is reported at startup instead.
+
 ## Astro
 
 ### `sourcemap`

package/docs/configuration/runtime-tuning.mdx

@@ -284,6 +284,7 @@ What a snapshot contains, and how it is protected:
 - Default: automatic
 - Forces the write-side codec to `zstd` or `gzip`.
 - Invalid values are ignored. Automatic mode prefers `zstd` when the current Node.js runtime supports it, otherwise it falls back to `gzip`.
+- Writes for a run on another deployment (for example `resumeHook()` reaching a run that started before the project moved to a newer Node.js version) use `zstd` only when that run's deployment runs Node.js 22.15+ (or 23.8+), and `gzip` otherwise, since older Node.js versions cannot decode `zstd`. Runs created before `@workflow/core` recorded the Node.js version always receive `gzip`. Setting this to `zstd` does not override that check.
 
 ### `WORKFLOW_TRACE_MODE`
 
@@ -315,7 +316,7 @@ What a snapshot contains, and how it is protected:
 
 Node's own modules do less than the client they replace, so enabling this drops the per-call-site tuning the Worlds configure:
 
-- Event-log requests lose HTTP/2, so concurrent reads and writes no longer share one connection, and the enlarged HTTP/2 receive windows no longer apply. This is the largest difference, and it slows down replays that read a big event log. It does not apply to event writes on the opt-in [WebSocket events transport](/docs/configuration/worlds#workflow_events_transport), which takes neither transport.
+- Event-log requests lose HTTP/2, so concurrent reads and writes no longer share one connection, and the enlarged HTTP/2 receive windows no longer apply. This is the largest difference, and it slows down replays that read a big event log. It does not apply to event writes on the [WebSocket events transport](/docs/configuration/worlds#workflow_events_transport), which is the default and takes neither transport.
 - Requests lose their transport-level retry. Failures still surface to the layers above, which retry event writes and redeliver queue messages, so nothing is silently dropped, but a failure that a same-connection retry would have hidden now costs a full redelivery.
 - Stream close loses its retry of retriable server errors. A transient failure at close can leave a stream marked closing until the run expires, where it would previously have resolved on the retry.
 

package/docs/configuration/worlds.mdx

@@ -317,8 +317,8 @@ When enabled (the default), a suspension's eager `step_created` and `wait_create
 
 - Factory option: none
 - CLI flag: none
-- Default: `http`
-- Set to `ws` to ship workflow run events to the Vercel World over a WebSocket instead of one HTTP request each. Only `ws` (case-insensitive) opts in; any other value, including unset, empty, or `http`, keeps HTTP.
+- Default: `ws`
+- Ships workflow run events to the Vercel World over a WebSocket instead of one HTTP request each. Set to exactly `http` to opt out; any other value, including unset or empty, uses the WebSocket.
 - Ignored when the World is configured with `projectConfig` and routes through the `api-workflow` proxy: that endpoint is an HTTP-only REST gateway and does not forward a WebSocket upgrade, so events stay on HTTP.
 
 ### `WORKFLOW_EVENTS_TRANSPORT_WS_OVERRIDE_WORKFLOWS`
@@ -326,8 +326,8 @@ When enabled (the default), a suspension's eager `step_created` and `wait_create
 - Factory option: none
 - CLI flag: none
 - Default: none
-- Comma-separated workflows whose runs use the WebSocket events transport even when `WORKFLOW_EVENTS_TRANSPORT` is `http` or unset. Each entry is a function name (`processOrder`) or a full workflow name (`workflow//./src/workflows/order//processOrder`), matched exactly and case-sensitively.
-- Has no effect when `WORKFLOW_EVENTS_TRANSPORT=ws`, which already enables every workflow.
+- Comma-separated workflows whose runs use the WebSocket events transport even when `WORKFLOW_EVENTS_TRANSPORT` is `http`. Each entry is a function name (`processOrder`) or a full workflow name (`workflow//./src/workflows/order//processOrder`), matched exactly and case-sensitively.
+- Has no effect unless `WORKFLOW_EVENTS_TRANSPORT=http`, since every workflow already uses the WebSocket by default.
 - See [`WORKFLOW_EVENTS_TRANSPORT_WS_OVERRIDE_WORKFLOWS`](/worlds/vercel#workflow_events_transport_ws_override_workflows) for details.
 
 ### `WORKFLOW_WS_MAX_MESSAGE_BYTES`

package/docs/cookbook/integrations/ai-sdk.mdx

@@ -41,9 +41,9 @@ One workflow run represents one full conversation. The workflow suspends between
 Because the conversation is one workflow run, it stays on the deployment that started it. If each turn should run on the latest deployment while preserving selected state or streams, see [Versioning](/docs/foundations/versioning) for the child-run continuation pattern.
 </Callout>
 
-<Tabs items={['Workflow', 'API Route', 'Client']}>
+<TabsWithChildren tabs={["Workflow","API Route","Client"]}>
 
-<Tab value="Workflow">
+<TabContent order={1}>
 
 ```typescript title="workflows/support.ts" lineNumbers
 import { streamText, stepCountIs } from "ai";
@@ -129,9 +129,9 @@ export async function supportWorkflow(initialMessages: ModelMessage[]) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="API Route">
+<TabContent order={2}>
 
 One endpoint handles first turn, follow-ups, and the `/done` exit. The client sends `runId` in the body to distinguish first vs follow-up.
 
@@ -246,9 +246,9 @@ export async function POST(req: Request) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Client">
+<TabContent order={3}>
 
 Store the `runId` in a ref and pass it in the body of every follow-up. `WorkflowChatTransport` forwards it for you.
 
@@ -299,9 +299,9 @@ export function SupportChat() {
 }
 ```
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 
 ## How it works
 

package/docs/cookbook/integrations/chat-sdk.mdx

@@ -66,9 +66,9 @@ Because the session *is* a workflow run, its history is recoverable from the eve
 
 This pattern uses three files. The bot definition is separate from the workflow so adapter packages stay out of the workflow sandbox.
 
-<Tabs items={['Bot Setup', 'Workflow', 'Event Handlers']}>
+<TabsWithChildren tabs={["Bot Setup","Workflow","Event Handlers"]}>
 
-<Tab value="Bot Setup">
+<TabContent order={1}>
 
 Register the `Chat` instance as a singleton so step functions can dynamically import it and resolve adapters + state:
 
@@ -95,9 +95,9 @@ export const bot = new Chat<typeof adapters, ThreadState>({
 
 `registerSingleton()` is important: Chat SDK re-hydrates `Thread` objects inside step functions, and it needs a registered singleton to resolve adapters and state for those rehydrated instances.
 
-</Tab>
+</TabContent>
 
-<Tab value="Workflow">
+<TabContent order={2}>
 
 The workflow is a plain loop over a hook. It receives the serialized thread + first message from the handler, revives them via Chat SDK's standalone `reviver`, and every platform-side effect goes inside a `"use step"` helper:
 
@@ -174,9 +174,9 @@ export type ChatTurnPayload = {
 };
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Event Handlers">
+<TabContent order={3}>
 
 Handlers live outside the workflow file so adapter dependencies don't leak in. They decide whether to start a new workflow or resume an existing one, then store the `runId` in thread state:
 
@@ -256,9 +256,9 @@ export async function POST(
 }
 ```
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 
 ## How it works
 

package/docs/cookbook/integrations/sandbox.mdx

@@ -88,9 +88,9 @@ When the timer wins:
 
 The only way out is an explicit `/destroy` command.
 
-<Tabs items={['Workflow', 'API Routes', 'Client']}>
+<TabsWithChildren tabs={["Workflow","API Routes","Client"]}>
 
-<Tab value="Workflow">
+<TabContent order={1}>
 
 ```typescript title="workflows/sandbox-session.ts" lineNumbers
 import { defineHook, sleep, getWritable, getWorkflowMetadata } from "workflow";
@@ -298,9 +298,9 @@ export async function sandboxSessionWorkflow() {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="API Routes">
+<TabContent order={2}>
 
 Two endpoints manage the session. `/start` accepts an optional `{ runId }`: if the run still exists, it replays the event log from index 0 so a returning client fully rehydrates. `/command` resumes the hook and returns immediately; command output lands on the `/start` stream.
 
@@ -379,9 +379,9 @@ export async function POST(req: Request) {
 }
 ```
 
-</Tab>
+</TabContent>
 
-<Tab value="Client">
+<TabContent order={3}>
 
 On mount, reconnect to the existing run if `localStorage` contains a `runId`. Otherwise, start a new run. Send commands to `/command` with POST requests. Output arrives on the `/start` stream.
 
@@ -472,9 +472,9 @@ export function SandboxRunner() {
 }
 ```
 
-</Tab>
+</TabContent>
 
-</Tabs>
+</TabsWithChildren>
 
 ## How it works
 

package/docs/errors/node-js-module-in-workflow.mdx

@@ -27,6 +27,42 @@ Workflow functions run in a sandboxed environment without full Node.js runtime a
 
 Node.js modules have side effects and non-deterministic behavior that could break workflow replay guarantees.
 
+## Transitive dependencies and dynamic `require()`
+
+The same error is reported for a module the workflow bundle could not inline, even when your own code never imports it directly:
+
+```text
+Workflow bundle cannot run in the workflow sandbox.
+
+Imports left external (1):
+  • "node:fs"
+    imported by node_modules/leaky-pkg/index.js
+    via app/workflows/order.ts → node_modules/wrapper-pkg/index.js → node_modules/leaky-pkg/index.js
+
+Unresolved require() calls (1):
+  • dynamic require() in node_modules/lazy-pkg/index.js (bundle 412:31)
+```
+
+The workflow sandbox has no `require`, so both would throw `ReferenceError: require is not defined` when the bundle loads. Follow the import chain to the first file you own and move that work into a step function, or replace a dynamic `require()` with a static import so the bundler can inline it.
+
+A `require()` wrapped in `try`/`catch`, or behind a `typeof require` check, is not reported — that is how packages probe for an optional dependency or for a CommonJS environment, and in the sandbox the error is caught or the call never runs:
+
+```js
+try {
+  loadOptional(require("@emotion/is-prop-valid").default);
+} catch {
+  // optional dependency, fall back
+}
+
+if (typeof require !== "undefined") {
+  crypto = require("crypto");
+}
+```
+
+A `typeof require` check only excuses the branch it skips when `require` is undefined, so `typeof require === "undefined" ? require(x) : y` is still reported. A `try` only counts when it has a `catch`. The checks read the code's structure without running it, so a `catch` that rethrows the error is still treated as a guard, and the bundle fails at runtime if that code is reached.
+
+As a last resort — for example a `require()` that can never run — set `WORKFLOW_ALLOW_UNSAFE_FLOW_BUNDLE=1` to downgrade the build failure to a warning. The bundle still fails at runtime if the code is reached.
+
 ## Quick fix
 
 Move any code using Node.js modules to a step function. Step functions have full Node.js runtime access.

package/docs/foundations/serialization.mdx

@@ -36,7 +36,7 @@ The following types can be serialized and passed through workflow functions:
 - `BigInt64Array`, `BigUint64Array`
 - `DataView`
 - `Date`
-- `Float32Array`, `Float64Array`
+- `Float16Array`, `Float32Array`, `Float64Array`
 - `Int8Array`, `Int16Array`, `Int32Array`
 - `Map<Serializable, Serializable>`
 - `RegExp`

package/docs/foundations/streaming.mdx

@@ -337,7 +337,7 @@ async function runTurn(holderRunId: string, turn: number) {
 Pass `{ namespace: "name" }` to target a [namespaced stream](#namespaced-streams). The writable can also be forwarded through `start()` and into steps.
 
 <Callout type="warn">
-Contributors should call `releaseLock()`, which flushes pending writes. Calling `close()` closes the shared stream for every writer.
+Contributors should call `releaseLock()`, which flushes pending writes. Calling `close()` closes the shared stream for every writer. Calling `abort()` keeps the chunks already written and leaves the shared stream open.
 </Callout>
 
 The API grants append access, not read access or additional authorization. The owning run controls the stream's lifecycle, and writes to an unknown run fail.

package/docs/getting-started/astro.mdx

@@ -61,12 +61,12 @@ export default defineConfig({
 | --- | --- | --- | --- |
 | `sourcemap` | `boolean \| 'inline' \| 'linked' \| 'external' \| 'both'` | `'inline'` (dev) / `false` (prod) | Controls source maps on generated workflow bundles. Accepts the same values as esbuild's `sourcemap` option. Defaults to `'inline'` in development and `false` in production (smaller function bundles, which helps stay under the Vercel 250 MB function size limit). Set it explicitly, or use the `WORKFLOW_SOURCEMAP` environment variable, to override in either environment. |
 
-<Accordion type="single" collapsible>
-  <AccordionItem value="typescript-intellisense" className="[&_h3]:my-0">
-    <AccordionTrigger className="text-sm">
-      ### Set up IntelliSense for TypeScript (optional)
-    </AccordionTrigger>
-    <AccordionContent className="[&_p]:my-2">
+<Details>
+<Summary className="[&_h3]:my-0">
+
+### Set up IntelliSense for TypeScript (optional)
+
+</Summary>
 
 To enable helpful hints in your IDE, set up the workflow plugin in `tsconfig.json`:
 
@@ -83,9 +83,7 @@ To enable helpful hints in your IDE, set up the workflow plugin in `tsconfig.jso
 }
 ```
 
-    </AccordionContent>
-  </AccordionItem>
-</Accordion>
+</Details>
 
 </Step>
 

package/docs/getting-started/express.mdx

@@ -72,12 +72,9 @@ export default defineNitroConfig({
 });
 ```
 
-<Accordion type="single" collapsible>
-  <AccordionItem value="typescript-intellisense" className="[&_h3]:my-0">
-    <AccordionTrigger className="[&_p]:my-0 text-lg [&_p]:text-foreground">
-      Setup IntelliSense for TypeScript (Optional)
-    </AccordionTrigger>
-    <AccordionContent className="[&_p]:my-2">
+<Details>
+<Summary>Setup IntelliSense for TypeScript (Optional)</Summary>
+
 To enable helpful hints in your IDE, setup the workflow plugin in `tsconfig.json`:
 
 ```json title="tsconfig.json" lineNumbers
@@ -93,10 +90,7 @@ To enable helpful hints in your IDE, setup the workflow plugin in `tsconfig.json
 }
 ```
 
-    </AccordionContent>
-
-  </AccordionItem>
-</Accordion>
+</Details>
 
 ### Update `package.json`