workflow 5.0.0-beta.1 → 5.0.0-beta.2

package/docs/migration-guides/migrating-from-aws-step-functions.mdx

@@ -0,0 +1,311 @@
+---
+title: Migrating from AWS Step Functions
+description: Move an AWS Step Functions state machine to the Workflow SDK by replacing JSON state definitions, Task states, Choice/Wait/Parallel states, Retry/Catch blocks, and .waitForTaskToken callbacks with Workflows, Steps, Hooks, and idiomatic TypeScript control flow.
+type: guide
+summary: Translate an AWS Step Functions state machine into the Workflow SDK with side-by-side code examples.
+prerequisites:
+  - /docs/getting-started/next
+  - /docs/foundations/workflows-and-steps
+related:
+  - /docs/foundations/starting-workflows
+  - /docs/foundations/errors-and-retries
+  - /docs/foundations/hooks
+  - /docs/foundations/streaming
+  - /docs/deploying/world/vercel-world
+---
+
+Move an AWS Step Functions state machine to the Workflow SDK by replacing JSON state definitions with TypeScript functions. This guide shows the direct mapping between ASL states and Workflow SDK primitives.
+
+<Callout type="info">
+Install the Workflow SDK migration skill:
+
+```bash
+npx skills add https://github.com/vercel/workflow --skill migrating-to-workflow-sdk
+```
+</Callout>
+
+## Why migrate to the Workflow SDK
+
+- Orchestration code is TypeScript, not JSON ASL. Transitions are `await`, branches are `if`/`switch`, and parallelism is `Promise.all`.
+- Streaming is built in. Write durable progress from steps with `getWritable()` and named streams. No DynamoDB or SNS glue to surface status to clients.
+- Infrastructure lives in one deployment. No separate state machine, per-task Lambda, IAM role wiring, or callback SQS queues.
+- Error handling is TypeScript-native: step-level retries, `RetryableError`, and `FatalError` replace per-state Retry/Catch blocks.
+- Agent-first tooling: the `npx workflow` CLI, `@workflow/ai` integration, and the Claude skill are available out of the box.
+
+## What changes when you leave Step Functions?
+
+AWS Step Functions defines workflows as JSON state machines using Amazon States Language (ASL). Each state (Task, Choice, Wait, Parallel, Map) is a node in a declarative graph. Lambda functions handle tasks, Retry/Catch blocks configure per-state error handling, and `.waitForTaskToken` manages callbacks.
+
+The Workflow SDK replaces that JSON DSL with TypeScript. `"use workflow"` functions orchestrate `"use step"` functions in the same file. Branching is `if`/`else`. Waiting is `sleep()`. Parallelism is `Promise.all()`. Retries move down to the step level.
+
+The migration replaces declarative configuration with idiomatic TypeScript and collapses the orchestrator and compute split. Business logic stays the same.
+
+## Concept mapping
+
+| AWS Step Functions | Workflow SDK | Migration note |
+| --- | --- | --- |
+| State machine (ASL JSON) | `"use workflow"` function | The workflow function is the state machine. |
+| Task state / Lambda | `"use step"` function | Side effects go in steps. No separate Lambda. |
+| Choice state | `if` / `else` / `switch` | Native TypeScript control flow. |
+| Wait state | `sleep()` | Import `sleep` from `workflow`. |
+| Parallel state | `Promise.all()` | Standard concurrency primitives. |
+| Map state | Loop + `Promise.all()` or child workflows | Iterate with `for`/`map`. |
+| Retry / Catch | Step retries, `RetryableError`, `FatalError` | Retry logic moves to step boundaries. |
+| `.waitForTaskToken` | `createHook()` or `createWebhook()` | Hooks for typed signals; webhooks for HTTP. |
+| Child state machine (`StartExecution`) | `"use step"` around `start()` / `getRun()` | Return the `Run` object, await its result from another step. |
+| Execution event history | Workflow event log | Same durable replay model. |
+| Progress via DynamoDB / SNS for client polling | `getWritable()` + named streams | Stream durable updates; clients read from the stream. |
+
+<Callout type="info">
+`.waitForTaskToken` becomes `createHook()` or `createWebhook()`. Choice states become `if`/`else`. Map states become `Promise.all()`. Retry policies move from per-state configuration to step-level defaults.
+</Callout>
+
+## Translate your first workflow
+
+Start with a single Task state. In ASL, even "call one Lambda" requires a state machine shell:
+
+```json title="stateMachine.asl.json (Step Functions)"
+"LoadOrder": {
+  "Type": "Task",
+  "Resource": "arn:aws:states:::lambda:invoke",
+  "Parameters": { "FunctionName": "loadOrder", "Payload.$": "$" },
+  "End": true
+}
+```
+
+```typescript title="workflow/workflows/order.ts (Workflow SDK)"
+export async function processOrder(orderId: string) {
+  'use workflow'; // [!code highlight]
+  return await loadOrder(orderId);
+}
+
+async function loadOrder(orderId: string) {
+  'use step'; // [!code highlight]
+  const res = await fetch(`https://example.com/api/orders/${orderId}`);
+  return res.json() as Promise<{ id: string }>;
+}
+```
+
+What changed: the ASL state machine and its Lambda collapse into two directive-tagged functions in one file.
+
+### Adding a second step
+
+In ASL, a second Task means a new state and a `"Next"` transition. In the Workflow SDK, it's another `await`:
+
+```typescript
+export async function processOrder(orderId: string) {
+  'use workflow';
+  const order = await loadOrder(orderId);
+  await reserveInventory(order.id); // [!code highlight]
+  return { orderId: order.id, status: 'reserved' };
+}
+```
+
+`await` replaces `"Next"`. Each new step is a new function with `"use step"`; no additional deployment.
+
+### Starting from an API route
+
+Step Functions starts a run via `StartExecution` (AWS SDK or API Gateway integration). The Workflow SDK starts a run with `start()` from a route handler:
+
+```typescript title="app/api/orders/route.ts"
+import { start } from 'workflow/api';
+import { processOrder } from '@/workflows/order';
+
+export async function POST(request: Request) {
+  const { orderId } = (await request.json()) as { orderId: string };
+  const run = await start(processOrder, [orderId]); // [!code highlight]
+  return Response.json({ runId: run.runId });
+}
+```
+
+## Wait for an external signal
+
+The minimal ASL for a callback is a Task with `.waitForTaskToken`:
+
+```json title="approval.asl.json (Step Functions)"
+"WaitForApproval": {
+  "Type": "Task",
+  "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
+  "Parameters": {
+    "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/approvals",
+    "MessageBody": {
+      "refundId.$": "$.refundId",
+      "TaskToken.$": "$$.Task.Token"
+    }
+  },
+  "End": true
+}
+```
+
+```typescript title="workflow/workflows/refund.ts (Workflow SDK)"
+import { createHook } from 'workflow';
+
+export async function refundWorkflow(refundId: string) {
+  'use workflow';
+  using approval = createHook<{ approved: boolean }>({ // [!code highlight]
+    token: `refund:${refundId}:approval`,
+  });
+  return await approval;
+}
+```
+
+What changed: no SQS queue, no task token, no callback Lambda. The hook suspends the workflow durably until it is resumed.
+
+### Resuming the hook
+
+Step Functions resumes by calling `SendTaskSuccess` with the task token. The Workflow SDK resumes by calling `resumeHook` with the hook's token:
+
+```typescript title="app/api/refunds/[refundId]/approve/route.ts"
+import { resumeHook } from 'workflow/api';
+
+export async function POST(req: Request, { params }: { params: Promise<{ refundId: string }> }) {
+  const { refundId } = await params;
+  const { approved } = (await req.json()) as { approved: boolean };
+  await resumeHook(`refund:${refundId}:approval`, { approved }); // [!code highlight]
+  return Response.json({ ok: true });
+}
+```
+
+### Branching on the result
+
+In ASL, branching after the wait requires a Choice state. In TypeScript, it's just `if`/`else`:
+
+```json title="approval.asl.json (Step Functions)"
+"CheckApproval": {
+  "Type": "Choice",
+  "Choices": [
+    { "Variable": "$.approved", "BooleanEquals": true, "Next": "Approved" }
+  ],
+  "Default": "Rejected"
+}
+```
+
+{/* @skip-typecheck: continuation snippet */}
+```typescript title="workflow/workflows/refund.ts (Workflow SDK)"
+const { approved } = await approval;
+if (approved) return { refundId, status: 'approved' }; // [!code highlight]
+return { refundId, status: 'rejected' };
+```
+
+## Spawn a child workflow
+
+In ASL, a parent machine calls `StartExecution` (usually via `.sync` or `.waitForTaskToken`) to launch a child. In the Workflow SDK, `start()` and `getRun()` are runtime APIs, so wrap them in `"use step"` functions. Returning the `Run` object from the spawn step lets workflow observability deep-link to the child run.
+
+### Parent starts a child
+
+```typescript title="workflow/workflows/parent.ts"
+import { start } from 'workflow/api';
+
+async function spawnChild(item: string) {
+  'use step'; // [!code highlight]
+  return start(childWorkflow, [item]);
+}
+
+export async function parentWorkflow(item: string) {
+  'use workflow';
+  const run = await spawnChild(item);
+  return { childRunId: run.runId };
+}
+```
+
+### Awaiting the child's result
+
+Add a second step that wraps `getRun()` and awaits `returnValue`:
+
+```typescript
+import { getRun } from 'workflow/api';
+
+async function collectResult(runId: string) {
+  'use step'; // [!code highlight]
+  const run = getRun(runId);
+  return (await run.returnValue) as { item: string; result: string };
+}
+```
+
+Then in the workflow: `const result = await collectResult(run.runId);`. The child workflow itself (`childWorkflow`) is defined elsewhere with `"use workflow"`.
+
+## What you stop operating
+
+Moving off Step Functions removes these surfaces from the application:
+
+- ASL state machine JSON and its reference syntax.
+- Per-task Lambda functions, their IAM roles, and CloudFormation/CDK wiring.
+- Task-token delivery infrastructure (SQS queues, callback Lambdas).
+- Separate progress channels (DynamoDB, SNS) for client-visible updates.
+- CloudWatch and X-Ray configuration for orchestrator observability.
+
+Workflow and step functions live in the same deployment as the application. State transitions are `await` calls. Progress streaming, retries, and observability are built in.
+
+## Step-by-step first migration
+
+Pick one state machine and migrate it end-to-end before touching the rest. The steps below describe the smallest viable path.
+
+### Step 1: Install the Workflow SDK
+
+Add the `workflow` runtime package.
+
+```bash
+pnpm add workflow
+```
+
+### Step 2: Rewrite the state machine as a `"use workflow"` function
+
+Transitions become `await` calls. Control flow (`Choice`, `Wait`, `Parallel`, `Map`) becomes `if`/`switch`, `sleep`, `Promise.all`, and loops.
+
+```ts title="workflows/order.ts"
+export async function processOrder(orderId: string) {
+  "use workflow"; // [!code highlight]
+  const order = await loadOrder(orderId);
+  if (order.total > 1000) await reviewManually(order);
+  await chargePayment(order);
+}
+```
+
+### Step 3: Move each Lambda into a step function
+
+Inline the Lambda body into a function with `"use step"` on the first line. Step functions keep full Node.js access, so existing SDK calls work unchanged.
+
+```ts
+async function loadOrder(id: string) {
+  "use step"; // [!code highlight]
+  return fetch(`/api/orders/${id}`).then((r) => r.json());
+}
+```
+
+### Step 4: Replace `.waitForTaskToken` with a hook
+
+Swap the task-token callback Lambda for `createHook()`. Callers `resumeHook(token, payload)` instead of `SendTaskSuccess`.
+
+### Step 5: Start runs from an API route
+
+Delete the `StartExecution` call and IAM wiring. Launch runs directly from a route handler:
+
+```ts title="app/api/orders/route.ts"
+import { start } from "workflow/api";
+import { processOrder } from "@/workflows/order";
+
+export async function POST(req: Request) {
+  const { orderId } = await req.json();
+  const run = await start(processOrder, [orderId]);
+  return Response.json({ runId: run.runId });
+}
+```
+
+### Step 6: Retire the Step Functions infrastructure
+
+Delete the ASL JSON, per-task Lambda deployments, IAM roles, and callback queues. Remove CloudWatch and X-Ray wiring used for orchestrator observability. Verify the run in `npx workflow web` before shipping.
+
+## Quick-start checklist
+
+- Replace the ASL state machine with a single `"use workflow"` function. Transitions become `await` calls.
+- Convert each Task / Lambda into a `"use step"` function in the same file.
+- Replace Choice states with `if`/`else`/`switch`.
+- Replace Wait states with `sleep()` from `workflow`.
+- Replace Parallel states with `Promise.all()`.
+- Replace Map states with loops or `Promise.all()`. For large fan-outs, wrap `start()` in a step.
+- Replace `StartExecution` child machines with `"use step"` wrappers around `start()` and `getRun()`.
+- Replace `.waitForTaskToken` with `createHook()` (internal callers) or `createWebhook()` (HTTP callers).
+- Move Retry/Catch to step boundaries using `maxRetries`, `RetryableError`, and `FatalError`.
+- Use `getStepMetadata().stepId` as the idempotency key for external side effects.
+- Stream progress from steps with `getWritable()` instead of polling DynamoDB or SNS.
+- Deploy and verify runs end-to-end with built-in observability.

package/docs/migration-guides/migrating-from-inngest.mdx

@@ -0,0 +1,282 @@
+---
+title: Migrating from Inngest
+description: Move an Inngest TypeScript app to the Workflow SDK by replacing createFunction, step.run(), step.sleep(), step.waitForEvent(), and step.invoke() with Workflows, Steps, Hooks, and start()/getRun().
+type: guide
+summary: Translate an Inngest app into the Workflow SDK with side-by-side code examples.
+prerequisites:
+  - /docs/getting-started/next
+  - /docs/foundations/workflows-and-steps
+related:
+  - /docs/foundations/starting-workflows
+  - /docs/foundations/errors-and-retries
+  - /docs/foundations/hooks
+  - /docs/foundations/streaming
+  - /docs/deploying/world/vercel-world
+---
+
+<Callout type="info">
+Install the Workflow SDK migration skill:
+
+```bash
+npx skills add https://github.com/vercel/workflow --skill migrating-to-workflow-sdk
+```
+</Callout>
+
+## Why migrate to the Workflow SDK
+
+- Streaming is built in. Durable progress writes go to named streams via `getWritable()`. There is no separate realtime publish channel or WebSocket layer to operate.
+- Infrastructure and orchestration live in a single deployment. Workflows run where the app runs. There is no separate Inngest Dev Server or event bus to operate.
+- TypeScript-first DX. Steps are named async functions marked with `"use step"`. No inline closures tied to a framework-specific lifecycle.
+- Agent-first tooling: the `npx workflow` CLI, `@workflow/ai` integration for durable AI agents, and a Claude skill for generating workflows.
+
+## What changes when you leave Inngest
+
+Inngest defines functions with `inngest.createFunction()`, registers them through a `serve()` handler, and breaks work into steps with `step.run()`, `step.sleep()`, and `step.waitForEvent()`. The platform routes events, schedules steps, and applies retries.
+
+The Workflow SDK replaces that with `"use workflow"` functions that orchestrate `"use step"` functions in plain TypeScript. There is no function registry, event dispatch layer, or SDK client. Durable replay, automatic retries, and step-level persistence are built into the runtime.
+
+Migration collapses the SDK abstraction into plain async functions. Business logic stays the same.
+
+## Concept mapping
+
+| Inngest | Workflow SDK | Migration note |
+| --- | --- | --- |
+| `inngest.createFunction()` | `"use workflow"` function started with `start()` | No wrapper needed. |
+| `step.run()` | `"use step"` function | Standalone async function with Node.js access. |
+| `step.sleep()` / `step.sleepUntil()` | `sleep()` | Import from `workflow`. |
+| `step.waitForEvent()` | `createHook()` or `createWebhook()` | Hooks for typed signals, webhooks for HTTP. |
+| `step.invoke()` | `"use step"` wrappers around `start()` / `getRun()` | Spawn a child run, pass `runId` forward. |
+| `inngest.send()` / event triggers | `start()` from your app boundary | Start workflows directly. |
+| Retry configuration (`retries`) | `RetryableError`, `FatalError`, `maxRetries` | Retry logic lives at the step level. |
+| `step.sendEvent()` | `"use step"` wrapper around `start()` | Fan out via `start()`, not an event bus. |
+| Realtime / `step.realtime.publish()` | `getWritable()` / `getWritable({ namespace })` | Named streams are the canonical way for clients to read workflow status. No database or `getRun()` polling required. |
+
+## Translate your first workflow
+
+Start with the shell of a function. Inngest wraps it in `createFunction`; Workflow SDK marks it with a directive.
+
+{/* @skip-typecheck: Inngest SDK types not available */}
+```typescript title="inngest/functions/order.ts"
+export const processOrder = inngest.createFunction(
+  {
+    id: 'process-order',
+    triggers: [{ event: 'order/created' }],
+  },
+  async ({ event, step }) => {
+    return { orderId: event.data.orderId, status: 'completed' };
+  }
+);
+```
+
+```typescript title="workflow/workflows/order.ts"
+export async function processOrder(orderId: string) {
+  'use workflow'; // [!code highlight]
+  return { orderId, status: 'completed' };
+}
+```
+
+**What changed:** the factory + event binding collapses into a plain exported function with a `"use workflow"` directive.
+
+### Add a step
+
+`step.run()` closures become named `"use step"` functions.
+
+```typescript title="workflow/workflows/order.ts"
+async function loadOrder(orderId: string) {
+  'use step'; // [!code highlight]
+  const res = await fetch(`https://example.com/api/orders/${orderId}`);
+  return res.json() as Promise<{ id: string }>;
+}
+```
+
+Call it from the workflow like any async function: `const order = await loadOrder(orderId)`. Additional side effects (`reserveInventory`, `chargePayment`) follow the same shape.
+
+### Start the run
+
+Inngest dispatches via `inngest.send({ name: 'order/created', data: { orderId } })`. Workflow SDK launches directly:
+
+```typescript title="app/api/orders/route.ts"
+import { start } from 'workflow/api';
+import { processOrder } from '@/workflows/order';
+
+const run = await start(processOrder, [orderId]); // [!code highlight]
+```
+
+No event bus, no registry. `start()` returns a handle immediately.
+
+## Wait for an external signal
+
+`step.waitForEvent()` becomes `createHook()` plus `await`.
+
+```typescript title="workflow/workflows/refund.ts (Inngest)"
+const approval = await step.waitForEvent('wait-for-approval', {
+  event: 'refund/approved',
+  match: 'data.refundId',
+  timeout: '7d',
+});
+```
+
+{/* @skip-typecheck: snippet without imports */}
+```typescript title="workflow/workflows/refund.ts (Workflow SDK)"
+using approval = createHook<{ approved: boolean }>({ // [!code highlight]
+  token: `refund:${refundId}:approval`,
+});
+const payload = await approval;
+```
+
+**What changed:** event name + match expression collapse into a single `token` string. The caller supplies that token directly, with no event schema.
+
+### Resume from an API route
+
+Inngest resumes with `inngest.send({ name: 'refund/approved', data: { refundId, approved } })`. The SDK equivalent is `resumeHook`:
+
+```typescript title="app/api/refunds/[refundId]/approve/route.ts"
+import { resumeHook } from 'workflow/api';
+
+export async function POST(request: Request, { params }: { params: Promise<{ refundId: string }> }) {
+  const { refundId } = await params;
+  const { approved } = (await request.json()) as { approved: boolean };
+  await resumeHook(`refund:${refundId}:approval`, { approved }); // [!code highlight]
+  return Response.json({ ok: true });
+}
+```
+
+### Add a timeout and branch on the payload
+
+Inngest's `timeout: '7d'` option maps to a `Promise.race()` with `sleep()`:
+
+{/* @skip-typecheck: continuation snippet */}
+```typescript title="workflow/workflows/refund.ts"
+const result = await Promise.race([
+  approval.then((p) => ({ type: 'decision' as const, approved: p.approved })),
+  sleep('7d').then(() => ({ type: 'timeout' as const })), // [!code highlight]
+]);
+
+if (result.type === 'timeout') return { refundId, status: 'timed-out' };
+if (!result.approved) return { refundId, status: 'rejected' };
+return { refundId, status: 'approved' };
+```
+
+<Callout type="info">
+Event matching disappears. A hook's token encodes the routing (for example, `refund:${refundId}:approval`), and the caller supplies that token to `resumeHook()`.
+</Callout>
+
+## Spawn a child workflow
+
+`step.invoke()` splits into two steps: spawn and collect. `start()` and `getRun()` are runtime APIs, so wrap them in `"use step"` functions. Return the `Run` object from the spawn step so observability can deep-link into the child run.
+
+{/* @skip-typecheck: snippet without imports */}
+```typescript title="workflow/workflows/parent.ts"
+async function spawnChild(item: string) {
+  'use step';
+  return start(childWorkflow, [item]); // [!code highlight]
+}
+```
+
+Await the result in a second step, then orchestrate both from the parent:
+
+{/* @skip-typecheck: snippet without imports */}
+```typescript title="workflow/workflows/parent.ts"
+async function collectResult(runId: string) {
+  'use step';
+  const run = getRun(runId);
+  return await run.returnValue; // [!code highlight]
+}
+
+export async function parentWorkflow(item: string) {
+  'use workflow';
+  const child = await spawnChild(item);
+  return await collectResult(child.runId);
+}
+```
+
+## What you stop operating
+
+Dropping the Inngest SDK removes several moving parts:
+
+- **No SDK client or serve handler.** Workflow files carry directive annotations. No registry, no serve endpoint.
+- **No event bus.** `start()` launches workflows directly from API routes, server actions, or other entry points. No event schemas or dispatch layer.
+- **No inline step closures.** Steps are named async functions. They type-check and test like any other TypeScript function.
+- **No separate streaming transport.** `getWritable()` delivers progress to clients without WebSockets or SSE glue.
+- **No idle workers.** Workflows suspended on `sleep()` or a hook consume no compute until resumed.
+
+## Step-by-step first migration
+
+Pick one Inngest function and migrate it end-to-end before touching the rest. The steps below describe the smallest viable path.
+
+### Step 1: Install the Workflow SDK
+
+Add the runtime and the framework integration that matches the app.
+
+```bash
+pnpm add workflow
+```
+
+### Step 2: Convert `createFunction` to a `"use workflow"` export
+
+Replace the factory call with a plain async export. Move the handler body up. The event-binding argument goes away.
+
+```ts title="workflows/order.ts"
+// Before (Inngest)
+// export const processOrder = inngest.createFunction(
+//   { id: "process-order", triggers: [{ event: "order.created" }] },
+//   async ({ event, step }) => { ... }
+// );
+
+// After (Workflow SDK)
+export async function processOrder(orderId: string) {
+  "use workflow"; // [!code highlight]
+  // ...
+}
+```
+
+### Step 3: Convert `step.run` callbacks into named step functions
+
+Each inline callback becomes a named function with `"use step"` on the first line. The workflow calls them with a plain `await`.
+
+```ts
+async function loadOrder(id: string) {
+  "use step"; // [!code highlight]
+  return fetch(`/api/orders/${id}`).then((r) => r.json());
+}
+```
+
+### Step 4: Replace `waitForEvent`, `sleep`, and `invoke`
+
+- `step.waitForEvent(...)` → `createHook({ token })` + `await hook`. Resume it from an API route with `resumeHook(token, payload)`.
+- `step.sleep(...)` → `sleep("5m")` from `workflow`.
+- `step.invoke(child, { data })` → wrap `start(child, [data])` in a `"use step"` function that returns the `Run`, and optionally read its return value with `getRun(run.runId).returnValue`.
+
+### Step 5: Start runs from the app
+
+Delete the `serve()` handler and event dispatch. Launch runs directly from an API route:
+
+```ts title="app/api/orders/route.ts"
+import { start } from "workflow/api";
+import { processOrder } from "@/workflows/order";
+
+export async function POST(req: Request) {
+  const { orderId } = await req.json();
+  const run = await start(processOrder, [orderId]);
+  return Response.json({ runId: run.runId });
+}
+```
+
+### Step 6: Retire the Inngest infrastructure
+
+Remove the `inngest` client, the `serve()` route, event schemas, and the Inngest Dev Server from the app. Verify the run in `npx workflow web` before shipping.
+
+## Quick-start checklist
+
+- Replace `inngest.createFunction()` with a `"use workflow"` function; launch it with `start()`.
+- Convert each `step.run()` callback into a named `"use step"` function.
+- Swap `step.sleep()` / `step.sleepUntil()` for `sleep()` from `workflow`.
+- Swap `step.waitForEvent()` for `createHook()` (internal) or `createWebhook()` (HTTP).
+- Model `waitForEvent` timeouts as `Promise.race()` between the hook and `sleep()`.
+- Replace `step.invoke()` with `"use step"` wrappers around `start()` and `getRun()`.
+- Replace `step.sendEvent()` fan-out with `start()` called from a `"use step"` function.
+- Remove the Inngest client, `serve()` handler, and event definitions.
+- Push retry configuration down to step boundaries via `maxRetries`, `RetryableError`, and `FatalError`.
+- Use `getStepMetadata().stepId` as the idempotency key for external side effects.
+- Replace `step.realtime.publish()` with `getWritable()`.
+- Deploy and verify end-to-end with the built-in observability UI.