@mastra/mcp-docs-server 1.0.0-beta.9 → 1.0.1

package/.docs/raw/workflows/overview.mdx

@@ -1,6 +1,8 @@
 ---
 title: "Workflows overview | Workflows"
 description: "Workflows in Mastra help you orchestrate complex sequences of tasks with features like branching, parallel execution, resource suspension, and more."
+packages:
+  - "@mastra/core"
 ---
 
 import Tabs from "@theme/Tabs";
@@ -8,7 +10,7 @@ import TabItem from "@theme/TabItem";
 
 # Workflows overview
 
-Workflows let you define complex sequences of tasks using clear, structured steps rather than relying on the reasoning of a single agent. They give you full control over how tasks are broken down, how data moves between them, and what gets executed when.
+Workflows let you define complex sequences of tasks using clear, structured steps rather than relying on the reasoning of a single agent. They give you full control over how tasks are broken down, how data moves between them, and what gets executed when. Workflows run using the built-in execution engine by default, or can be deployed to [workflow runners](/docs/v1/deployment/workflow-runners) like Inngest for managed infrastructure.
 
 ![Workflows overview](/img/workflows/workflows-overview.jpg)
 
@@ -32,7 +34,7 @@ Steps are the building blocks of workflows. Create a step using `createStep()` w
 
 The `execute` function defines what the step does. Use it to call functions in your codebase, external APIs, agents, or tools.
 
-```typescript {6,9,15} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {6,9,15} title="src/mastra/workflows/test-workflow.ts"
 import { createStep } from "@mastra/core/workflows";
 
 const step1 = createStep({
@@ -53,7 +55,11 @@ const step1 = createStep({
 });
 ```
 
-> See the [Step Class](/reference/v1/workflows/step) for a full list of configuration options.
+:::info
+
+Visit [Step Class](/reference/v1/workflows/step) for a full list of configuration options.
+
+:::
 
 ### Using agents and tools
 
@@ -63,7 +69,7 @@ Workflow steps can also call registered agents or import and execute tools direc
 
 Create a workflow using `createWorkflow()` with `inputSchema` and `outputSchema` to define the data it accepts and returns. Add steps using `.then()` and complete the workflow with `.commit()`.
 
-```typescript {9,12,15,16} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {9,12,15,16} title="src/mastra/workflows/test-workflow.ts"
 import { createWorkflow, createStep } from "@mastra/core/workflows";
 import { z } from "zod";
 
@@ -82,7 +88,11 @@ export const testWorkflow = createWorkflow({
   .commit();
 ```
 
-> See the [Workflow Class](/reference/v1/workflows/workflow) for a full list of configuration options.
+:::info
+
+Visit [Workflow Class](/reference/v1/workflows/workflow) for a full list of configuration options.
+
+:::
 
 ### Understanding control flow
 
@@ -92,7 +102,7 @@ Workflows can be composed using a number of different methods. The method you ch
 
 Workflow state lets you share values across steps without passing them through every step's inputSchema and outputSchema. Use state for tracking progress, accumulating results, or sharing configuration across the entire workflow.
 
-```typescript title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript title="src/mastra/workflows/test-workflow.ts"
 const step1 = createStep({
   id: "step-1",
   inputSchema: z.object({ message: z.string() }),
@@ -110,13 +120,17 @@ const step1 = createStep({
 });
 ```
 
-> See [Workflow State](/docs/v1/workflows/workflow-state) for complete documentation on state schemas, initial state, persistence across suspend/resume, and nested workflows.
+:::info
+
+Visit [Workflow State](/docs/v1/workflows/workflow-state) for complete documentation on state schemas, initial state, persistence across suspend/resume, and nested workflows.
+
+:::
 
 ## Workflows as steps
 
 Use a workflow as a step to reuse its logic within a larger composition. Input and output follow the same schema rules described in [Core principles](/docs/v1/workflows/control-flow).
 
-```typescript {26} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {26} title="src/mastra/workflows/test-workflow.ts"
 const step1 = createStep({...});
 const step2 = createStep({...});
 
@@ -150,7 +164,7 @@ export const testWorkflow = createWorkflow({
 
 Clone a workflow using `cloneWorkflow()` when you want to reuse its logic but track it separately under a new ID. Each clone runs independently and appears as a distinct workflow in logs and observability tools.
 
-```typescript {6} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {6} title="src/mastra/workflows/test-workflow.ts"
 import { cloneWorkflow } from "@mastra/core/workflows";
 
 const step1 = createStep({...});
@@ -168,12 +182,11 @@ export const testWorkflow = createWorkflow({...})
 
 Register your workflow in the Mastra instance to make it available throughout your application. Once registered, it can be called from agents or tools and has access to shared resources such as logging and observability features:
 
-```typescript {6} title="src/mastra/index.ts" showLineNumbers copy
+```typescript {5} title="src/mastra/index.ts"
 import { Mastra } from "@mastra/core/mastra";
 import { testWorkflow } from "./workflows/test-workflow";
 
 export const mastra = new Mastra({
-  // ...
   workflows: { testWorkflow },
 });
 ```
@@ -182,7 +195,7 @@ export const mastra = new Mastra({
 
 You can run workflows from agents, tools, the Mastra Client, or the command line. Get a reference by calling `.getWorkflow()` on your `mastra` or `mastraClient` instance, depending on your setup:
 
-```typescript showLineNumbers copy
+```typescript
 const testWorkflow = mastra.getWorkflow("testWorkflow");
 ```
 :::info
@@ -197,7 +210,7 @@ Workflows can be run in two modes: start waits for all steps to complete before
   <TabItem value="start" label="Start">
 Create a workflow run instance using `createRun()`, then call `.start()` with `inputData` matching the workflow's `inputSchema`. The workflow executes all steps and returns the final result.
 
-```typescript showLineNumbers copy
+```typescript
 const run = await testWorkflow.createRun();
 
 const result = await run.start({
@@ -206,42 +219,74 @@ const result = await run.start({
   }
 });
 
-console.log(result);
+if (result.status === "success") {
+  console.log(result.result);
+}
 ```
   </TabItem>
   <TabItem value="stream" label="Stream">
-Create a workflow run instance using `.createRun()`, then call `.stream()` with `inputData` matching the workflow's `inputSchema`. The workflow emits events as each step executes, which you can iterate over to track progress.
+Create a workflow run instance using `.createRun()`, then call `.stream()` with `inputData` matching the workflow's `inputSchema`. Iterate over `fullStream` to track progress, then await `result` to get the final workflow result.
 
-```typescript showLineNumbers copy
+```typescript
 const run = await testWorkflow.createRun();
 
-const result = await run.stream({
+const stream = run.stream({
   inputData: {
     message: "Hello world"
   }
 });
 
-for await (const chunk of result.fullStream) {
+for await (const chunk of stream.fullStream) {
   console.log(chunk);
 }
+
+// Get the final result (same type as run.start())
+const result = await stream.result;
+
+if (result.status === "success") {
+  console.log(result.result);
+}
 ```
   </TabItem>
 </Tabs>
 
 
-### Workflow status types
+### Workflow result type
+
+Both `run.start()` and `stream.result` return a discriminated union based on the `status` property, which can be `success`, `failed`, `suspended`, `tripwire`, or `paused`. You can always safely access `result.status`, `result.input`, `result.steps`, and optionally `result.state` regardless of the status.
+
+Additionally, depending on the status, different properties are available:
+
+| Status      | Unique properties               | Description                                              |
+| ----------- | ------------------------------- | -------------------------------------------------------- |
+| `success`   | `result`                        | The workflow's output data                               |
+| `failed`    | `error`                         | The error that caused the failure                        |
+| `tripwire`  | `tripwire`                      | Contains `reason`, `retry?`, `metadata?`, `processorId?` |
+| `suspended` | `suspendPayload`, `suspended`   | Suspension data and array of suspended step paths        |
+| `paused`    | _(none)_                        | Only common properties available                         |
 
-When running a workflow, its `status` can be `running`, `suspended`, `success`, or `failed`.
+To access status-specific properties, check the `status` first:
+
+```typescript
+const result = await run.start({ inputData: { message: "Hello world" } });
+
+if (result.status === "success") {
+  console.log(result.result); // Only available when status is "success"
+} else if (result.status === "failed") {
+  console.log(result.error.message);
+} else if (result.status === "suspended") {
+  console.log(result.suspendPayload);
+}
+```
 
 ### Workflow output
 
-The workflow output includes the full execution lifecycle, showing the input and output for each step. It also includes the status of each step, the overall workflow status, and the final result. This gives you clear insight into how data moved through the workflow, what each step produced, and how the workflow completed.
+Here's an example of a successful workflow result, showing the `input`, `steps`, and `result` properties:
 
 ```json
 {
   "status": "success",
   "steps": {
-    // ...
     "step-1": {
       "status": "success",
       "payload": {
@@ -249,7 +294,7 @@ The workflow output includes the full execution lifecycle, showing the input and
       },
       "output": {
         "formatted": "HELLO WORLD"
-      },
+      }
     },
     "step-2": {
       "status": "success",
@@ -258,7 +303,7 @@ The workflow output includes the full execution lifecycle, showing the input and
       },
       "output": {
         "emphasized": "HELLO WORLD!!!"
-      },
+      }
     }
   },
   "input": {
@@ -278,7 +323,7 @@ When a workflow run loses connection to the server, it can be restarted from the
 
 Use `restartAllActiveWorkflowRuns()` to restart all active workflow runs of a workflow. This helps restart all active workflow runs of a workflow, without having to manually loop through each run and restart.
 
-```typescript showLineNumbers copy
+```typescript
 workflow.restartAllActiveWorkflowRuns();
 ```
 
@@ -286,13 +331,11 @@ workflow.restartAllActiveWorkflowRuns();
 
 Use `restart()` to restart an active workflow run from the last active step. This will resume execution from the last active step, and the workflow will continue from there.
 
-```typescript showLineNumbers copy
+```typescript
 const run = await workflow.createRun();
 
 const result = await run.start({ inputData: { value: "initial data" } });
 
-//.. server connection lost,
-
 const restartedResult = await run.restart();
 ```
 
@@ -300,14 +343,14 @@ const restartedResult = await run.restart();
 
 When a workflow run is active, it will have a `status` of `running` or `waiting`. You can check the workflow's `status` to confirm it's active, and use `active` to identify the active workflow run.
 
-```typescript showLineNumbers copy
+```typescript
 const activeRuns = await workflow.listActiveWorkflowRuns();
 if (activeRuns.runs.length > 0) {
   console.log(activeRuns.runs);
 }
 ```
 
-:::Note
+:::note
 
 When running the local mastra server, all active workflow runs will be restarted automatically when the server starts.
 
@@ -315,15 +358,14 @@ When running the local mastra server, all active workflow runs will be restarted
 
 ## Using `RequestContext`
 
-Use [RequestContext](/docs/v1/server-db/request-context) to access request-specific values. This lets you conditionally adjust behavior based on the context of the request.
+Use [RequestContext](/docs/v1/server/request-context) to access request-specific values. This lets you conditionally adjust behavior based on the context of the request.
 
-```typescript title="src/mastra/workflows/test-workflow.ts" showLineNumbers
+```typescript title="src/mastra/workflows/test-workflow.ts"
 export type UserTier = {
   "user-tier": "enterprise" | "pro";
 };
 
 const step1 = createStep({
-  // ...
   execute: async ({ requestContext }) => {
     const userTier = requestContext.get("user-tier") as UserTier["user-tier"];
 
@@ -336,7 +378,11 @@ const step1 = createStep({
 });
 ```
 
-> See [Request Context](/docs/v1/server-db/request-context) for more information.
+:::info
+
+Visit [Request Context](/docs/v1/server/request-context) for more information.
+
+:::
 
 ## Testing with Studio
 

package/.docs/raw/workflows/snapshots.mdx

@@ -1,6 +1,9 @@
 ---
 title: "Snapshots | Workflows"
 description: "Learn how to save and resume workflow execution state with snapshots in Mastra"
+packages:
+  - "@mastra/core"
+  - "@mastra/libsql"
 ---
 
 # Snapshots
@@ -84,11 +87,11 @@ Each snapshot includes the `runId`, input, step status (`success`, `suspended`,
 
 ## How snapshots are saved and retrieved
 
-Snapshots are saved to the configured storage system. By default, they use LibSQL, but you can configure Upstash or PostgreSQL instead. Each snapshot is saved in the `workflow_snapshots` table and identified by the workflow’s `runId`.
+Snapshots are saved to the configured storage system. By default, they use libSQL, but you can configure Upstash or PostgreSQL instead. Each snapshot is saved in the `workflow_snapshots` table and identified by the workflow's `runId`.
 
 Read more about:
 
-- [LibSQL Storage](/reference/v1/storage/libsql)
+- [libSQL Storage](/reference/v1/storage/libsql)
 - [Upstash Storage](/reference/v1/storage/upstash)
 - [PostgreSQL Storage](/reference/v1/storage/postgresql)
 
@@ -114,8 +117,9 @@ When a workflow is resumed, Mastra retrieves the persisted snapshot with these s
 
 ```typescript
 const storage = mastra.getStorage();
+const workflowStore = await storage?.getStore('workflows');
 
-const snapshot = await storage!.loadWorkflowSnapshot({
+const snapshot = await workflowStore?.loadWorkflowSnapshot({
   runId: "<run-id>",
   workflowName: "<workflow-id>",
 });
@@ -127,57 +131,27 @@ console.log(snapshot);
 
 Snapshots are persisted using a `storage` instance configured on the `Mastra` class. This storage layer is shared across all workflows registered to that instance. Mastra supports multiple storage options for flexibility in different environments.
 
-### LibSQL `@mastra/libsql`
-
-This example demonstrates how to use snapshots with LibSQL.
-
-```typescript title="src/mastra/index.ts" showLineNumbers copy
+```typescript title="src/mastra/index.ts" 
 import { Mastra } from "@mastra/core";
 import { LibSQLStore } from "@mastra/libsql";
+import { approvalWorkflow } from "./workflows";
 
 export const mastra = new Mastra({
-  // ...
   storage: new LibSQLStore({
     id: 'mastra-storage',
     url: ":memory:",
   }),
+  workflows: { approvalWorkflow },
 });
 ```
 
-### Upstash `@mastra/upstash`
-
-This example demonstrates how to use snapshots with Upstash.
-
-```typescript title="src/mastra/index.ts" showLineNumbers copy
-import { Mastra } from "@mastra/core";
-import { UpstashStore } from "@mastra/upstash";
-
-export const mastra = new Mastra({
-  // ...
-  storage: new UpstashStore({
-  id: 'upstash-storage',
-    url: "<upstash-redis-rest-url>",
-    token: "<upstash-redis-rest-token>",
-  }),
-});
-```
-
-### Postgres `@mastra/pg`
-
-This example demonstrates how to use snapshots with PostgreSQL.
-
-```typescript title="src/mastra/index.ts" showLineNumbers copy
-import { Mastra } from "@mastra/core";
-import { PostgresStore } from "@mastra/pg";
-
-export const mastra = new Mastra({
-  // ...
-  storage: new PostgresStore({
-    id: 'mastra-storage',
-    connectionString: "<database-url>",
-  }),
-});
-```
+- [libSQL Storage](/reference/v1/storage/libsql)
+- [PostgreSQL Storage](/reference/v1/storage/postgresql)
+- [MongoDB Storage](/reference/v1/storage/mongodb)
+- [Upstash Storage](/reference/v1/storage/upstash)
+- [Cloudflare D1](/reference/v1/storage/cloudflare-d1)
+- [DynamoDB](/reference/v1/storage/dynamodb)
+- [More storage providers](/docs/v1/memory/storage)
 
 ## Best practices
 
@@ -191,7 +165,7 @@ export const mastra = new Mastra({
 
 You can attach custom metadata when suspending a workflow by defining a `suspendSchema`. This metadata is stored in the snapshot and made available when the workflow is resumed.
 
-```typescript {30-34} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {30-34} title="src/mastra/workflows/test-workflow.ts"
 import { createWorkflow, createStep } from "@mastra/core/workflows";
 import { z } from "zod";
 
@@ -240,7 +214,7 @@ const approvalStep = createStep({
 
 Use `resumeData` to pass structured input when resuming a suspended step. It must match the step’s `resumeSchema`.
 
-```typescript {14-20} showLineNumbers copy
+```typescript {14-20}
 const workflow = mastra.getWorkflow("approvalWorkflow");
 
 const run = await workflow.createRun();

package/.docs/raw/workflows/suspend-and-resume.mdx

@@ -1,6 +1,8 @@
 ---
 title: "Suspend & Resume | Workflows"
 description: "Suspend and resume in Mastra workflows allows you to pause execution while waiting for external input or resources."
+packages:
+  - "@mastra/core"
 ---
 
 # Suspend & Resume
@@ -15,7 +17,7 @@ Use `suspend()` to pause workflow execution at a specific step. You can define a
 
 ![Pausing a workflow with suspend()](/img/workflows/workflows-suspend.jpg)
 
-```typescript {9-11,16-18} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {9-11,16-18} title="src/mastra/workflows/test-workflow.ts"
 const step1 = createStep({
   id: "step-1",
   inputSchema: z.object({
@@ -60,7 +62,7 @@ Use `resume()` to restart a suspended workflow from the step where it paused. Pa
 
 ![Restarting a workflow with resume()](/img/workflows/workflows-resume.jpg)
 
-```typescript showLineNumbers copy
+```typescript
 import { step1 } from "./workflows/test-workflow";
 
 const workflow = mastra.getWorkflow("testWorkflow");
@@ -82,7 +84,7 @@ const handleResume = async () => {
 
 Passing the `step` object provides full type-safety for `resumeData`. Alternatively, you can pass a step ID for more flexibility when the ID comes from user input or a database.
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.resume({
   step: "step-1",
   resumeData: { approved: true }
@@ -91,11 +93,11 @@ const result = await run.resume({
 
 If only one step is suspended, you can omit the step argument entirely and Mastra will resume the last suspended step in the workflow.
 
-When resuming with only a `runId`, create a run instance first using `createRunAsync()`.
+When resuming with only a `runId`, create a run instance first using `createRun()`.
 
-```typescript showLineNumbers copy
+```typescript
 const workflow = mastra.getWorkflow("testWorkflow");
-const run = await workflow.createRunAsync({ runId: "123" });
+const run = await workflow.createRun({ runId: "123" });
 
 const stream = run.resume({
   resumeData: { approved: true }
@@ -104,7 +106,7 @@ const stream = run.resume({
 
 You can call `resume()` from anywhere in your application, including HTTP endpoints, event handlers, in response to [human input](/docs/v1/workflows/human-in-the-loop), or timers.
 
-```typescript showLineNumbers copy
+```typescript
 const midnight = new Date();
 midnight.setUTCHours(24, 0, 0, 0);
 
@@ -119,7 +121,7 @@ setTimeout(async () => {
 ## Accessing suspend data with `suspendData`
 When a step is suspended, you may want to access the data that was provided to `suspend()` when the step is later resumed. Use the `suspendData` parameter in your step's execute function to access this data.
 
-```typescript {22-25,29-30} title="src/mastra/workflows/user-approval.ts" showLineNumbers copy
+```typescript {22-25,29-30} title="src/mastra/workflows/user-approval.ts"
 const approvalStep = createStep({
   id: "user-approval",
   inputSchema: z.object({
@@ -164,7 +166,7 @@ The `suspendData` parameter is automatically populated when a step is resumed an
 
 When a workflow is suspended, it restarts from the step where it paused. You can check the workflow's `status` to confirm it's suspended, and use `suspended` to identify the paused step or [nested workflow](/docs/v1/workflows/overview#workflows-as-steps).
 
-```typescript {11} showLineNumbers copy
+```typescript {11}
 const workflow = mastra.getWorkflow("testWorkflow");
 const run = await workflow.createRun();
 
@@ -191,16 +193,14 @@ The `suspended` array contains the IDs of any suspended workflows and steps from
 [ 'nested-workflow', 'step-1' ]
 ```
 
-## Sleep & Events
+## Sleep
 
-Sleep and event methods can be used to pause execution at the workflow level, which sets the status to `waiting`. By comparison, `suspend()` pauses execution within a specific step and sets the status to `suspended`.
+Sleep methods can be used to pause execution at the workflow level, which sets the status to `waiting`. By comparison, `suspend()` pauses execution within a specific step and sets the status to `suspended`.
 
 **Available methods:**
 
 - [`.sleep()`](/reference/v1/workflows/workflow-methods/sleep): Pause for a specified number of milliseconds
-- [`.sleepUntil()`](/reference/v1/workflows/workflow-methods/sleepUntil) : Pause until a specific date
-- [`.waitForEvent()`](/reference/v1/workflows/workflow-methods/waitForEvent): Pause until an external event is received
-- [`.sendEvent()`](/reference/v1/workflows/workflow-methods/sendEvent) : Send an event to resume a waiting workflow
+- [`.sleepUntil()`](/reference/v1/workflows/workflow-methods/sleepUntil): Pause until a specific date
 
 ## Related
 

package/.docs/raw/workflows/time-travel.mdx

@@ -1,6 +1,8 @@
 ---
 title: "Time Travel | Workflows"
 description: "Re-execute workflow steps from a specific point using time travel debugging in Mastra"
+packages:
+  - "@mastra/core"
 ---
 
 # Time Travel
@@ -23,7 +25,7 @@ Time travel requires storage to be configured since it relies on persisted workf
 
 Use `run.timeTravel()` to re-execute a workflow from a specific step:
 
-```typescript showLineNumbers copy
+```typescript
 import { mastra } from "./mastra";
 
 const workflow = mastra.getWorkflow("myWorkflow");
@@ -41,7 +43,7 @@ You can specify the target step using either a step reference or a step ID:
 
 ### Using step reference
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: step2,
   inputData: { value: 10 },
@@ -50,7 +52,7 @@ const result = await run.timeTravel({
 
 ### Using step ID
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: "step2",
   inputData: { value: 10 },
@@ -61,7 +63,7 @@ const result = await run.timeTravel({
 
 For steps inside nested workflows, use dot notation, an array of step IDS or an array of step references:
 
-```typescript showLineNumbers copy
+```typescript
 // Using dot notation
 const result = await run.timeTravel({
   step: "nestedWorkflow.step3",
@@ -85,7 +87,7 @@ const result = await run.timeTravel({
 
 You can provide context to specify the state of previous steps when time traveling:
 
-```typescript {3-13} showLineNumbers copy
+```typescript {3-13}
 const result = await run.timeTravel({
   step: "step2",
   context: {
@@ -114,7 +116,7 @@ The context object contains step results keyed by step ID. Each step result incl
 
 Time travel is particularly useful for debugging and recovering from failed workflow executions:
 
-```typescript showLineNumbers copy
+```typescript
 const workflow = mastra.getWorkflow("myWorkflow");
 const run = await workflow.createRun();
 
@@ -136,7 +138,7 @@ if (failedResult.status === "failed") {
 
 You can time travel to resume a suspended workflow from an earlier step:
 
-```typescript showLineNumbers copy
+```typescript
 const run = await workflow.createRun();
 
 // Start workflow - suspends at promptAgent step
@@ -159,28 +161,30 @@ if (initialResult.status === "suspended") {
 
 Use `timeTravelStream()` to receive streaming events during time travel execution:
 
-```typescript showLineNumbers copy
+```typescript
 const run = await workflow.createRun();
 
-const output = run.timeTravelStream({
+const stream = run.timeTravelStream({
   step: "step2",
   inputData: { value: 10 },
 });
 
-// Access the stream
-for await (const event of output.fullStream) {
+for await (const event of stream.fullStream) {
   console.log(event.type, event.payload);
 }
 
-// Get final result
-const result = await output.result;
+const result = await stream.result;
+
+if (result.status === "success") {
+  console.log(result.result);
+}
 ```
 
 ## Time travel with initial state
 
 You can provide initial state when time traveling to set workflow-level state:
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: "step2",
   inputData: { value: 10 },
@@ -199,7 +203,7 @@ Time travel throws errors in specific situations:
 
 You cannot time travel to a workflow that is currently running:
 
-```typescript showLineNumbers copy
+```typescript
 try {
   await run.timeTravel({ step: "step2" });
 } catch (error) {
@@ -211,7 +215,7 @@ try {
 
 Time travel throws if the target step doesn't exist in the workflow:
 
-```typescript showLineNumbers copy
+```typescript
 try {
   await run.timeTravel({ step: "nonExistentStep" });
 } catch (error) {
@@ -223,7 +227,7 @@ try {
 
 When `validateInputs` is enabled, time travel validates the input data against the step's schema:
 
-```typescript showLineNumbers copy
+```typescript
 try {
   await run.timeTravel({
     step: "step2",
@@ -238,7 +242,7 @@ try {
 
 When time traveling into a nested workflow, you can provide context for both the parent and nested workflow steps:
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: "nestedWorkflow.step3",
   context: {
@@ -275,7 +279,7 @@ const result = await run.timeTravel({
 
 Re-run a failed step with the same or modified input to diagnose issues:
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: failedStepId,
   context: originalContext, // Use context from the failed run
@@ -286,7 +290,7 @@ const result = await run.timeTravel({
 
 Test individual steps with specific inputs on a new workflow run, useful for testing a step logic without starting workflow execution from the beginning.
 
-```typescript showLineNumbers copy
+```typescript
 const result = await run.timeTravel({
   step: "processData",
   inputData: { testData: "specific test case" },
@@ -297,7 +301,7 @@ const result = await run.timeTravel({
 
 Re-run steps that failed due to temporary issues (network errors, rate limits):
 
-```typescript showLineNumbers copy
+```typescript
 // After fixing the external service issue
 const result = await run.timeTravel({
   step: "callExternalApi",