@octavus/docs 2.21.0 → 3.1.0

package/content/01-getting-started/01-introduction.md

@@ -11,11 +11,11 @@ Octavus is an agent orchestration platform that lets developers define, manage,
 
 Building and managing AI agents is complex. Developers face challenges with:
 
-- **Fragmented tooling** — No unified way to define, manage, and deploy agents
-- **Prompt management** — Prompts are scattered across codebases, hard to version and iterate
-- **Integration complexity** — Connecting agents to tools, resources, and other agents requires significant custom work
-- **Observability** — Difficult to debug, monitor, and understand agent behavior in production
-- **Infrastructure overhead** — Teams rebuild the same agent infrastructure repeatedly
+- **Fragmented tooling** - No unified way to define, manage, and deploy agents
+- **Prompt management** - Prompts are scattered across codebases, hard to version and iterate
+- **Integration complexity** - Connecting agents to tools, resources, and other agents requires significant custom work
+- **Observability** - Difficult to debug, monitor, and understand agent behavior in production
+- **Infrastructure overhead** - Teams rebuild the same agent infrastructure repeatedly
 
 Octavus solves these problems by providing:
 
@@ -30,7 +30,7 @@ Octavus solves these problems by providing:
 
 ### Agents
 
-An **Agent** is the main entity in Octavus — a self-contained unit that defines how an AI agent behaves. Agents are defined using YAML protocols that specify:
+An **Agent** is the main entity in Octavus - a self-contained unit that defines how an AI agent behaves. Agents are defined using YAML protocols that specify:
 
 - Input variables the agent accepts
 - Triggers that invoke the agent (user messages, button clicks, API calls)
@@ -49,16 +49,16 @@ A **Session** represents a conversation with an agent. Sessions:
 
 **Triggers** define how an agent is invoked:
 
-- **User Message** — Respond to a text message in a chat interface
-- **User Action** — Respond to UI actions (button clicks, form submissions)
-- **API Call** — Direct invocation via SDK
+- **User Message** - Respond to a text message in a chat interface
+- **User Action** - Respond to UI actions (button clicks, form submissions)
+- **API Call** - Direct invocation via SDK
 
 ### Tools
 
 **Tools** extend what agents can do:
 
-- **External Tools** — Consumer-defined tools that call back to your systems
-- **Internal Tools** — Built-in capabilities (web search, code execution)
+- **External Tools** - Consumer-defined tools that call back to your systems
+- **Internal Tools** - Built-in capabilities (web search, code execution)
 
 Tools execute on your server, not on Octavus, giving you full control over data and authentication.
 
@@ -87,7 +87,7 @@ sequenceDiagram
 
 ## Next Steps
 
-- [Quick Start](/docs/getting-started/quickstart) — Get your first agent running in minutes
-- [Server SDK](/docs/server-sdk/overview) — Learn about backend integration
-- [Client SDK](/docs/client-sdk/overview) — Build chat interfaces with React (or other frameworks)
-- [Protocol Reference](/docs/protocol/overview) — Deep dive into agent protocols
+- [Quick Start](/docs/getting-started/quickstart) - Get your first agent running in minutes
+- [Server SDK](/docs/server-sdk/overview) - Learn about backend integration
+- [Client SDK](/docs/client-sdk/overview) - Build chat interfaces with React (or other frameworks)
+- [Protocol Reference](/docs/protocol/overview) - Deep dive into agent protocols

package/content/01-getting-started/02-quickstart.md

@@ -17,7 +17,7 @@ This guide will walk you through integrating Octavus into your application in un
 
 Before integrating with SDKs, use **Agent Preview** to test your agent directly in the platform:
 
-1. Open your agent in the platform at `octavus.ai/platform/agents/[agentId]`
+1. Open your agent in the platform (navigate to your project, then select the agent)
 2. Click the **Preview** tab
 3. Configure session inputs and tool mock responses
 4. Start a conversation to test agent behavior
@@ -81,7 +81,7 @@ There are two ways to create and manage agents:
 **Option 1: Platform UI (Recommended for getting started)**
 
 1. Go to [octavus.ai](https://octavus.ai) and create an agent in the web editor
-2. Copy the agent ID from the URL (e.g., `octavus.ai/platform/agents/clxyz123abc456`)
+2. Copy the agent ID from the URL (e.g., `octavus.ai/projects/.../agents/clxyz123abc456`)
 3. Add it to your `.env.local`: `OCTAVUS_SUPPORT_AGENT_ID=clxyz123abc456`
 
 **Option 2: Local Development with CLI**

package/content/02-server-sdk/01-overview.md

@@ -117,8 +117,9 @@ const session = client.agentSessions.attach(sessionId, {
   tools: {
     'set-chat-title': async (args) => ({ title: args.title }),
   },
-  computer,
 });
+
+session.setDynamicTools(computer);
 ```
 
 ### Workers
@@ -210,6 +211,9 @@ class AgentSession {
 
   // Get the session ID
   getSessionId(): string;
+
+  // Register dynamic tools (e.g., pass a Computer or explicit DynamicTool[])
+  setDynamicTools(source: ToolProvider | DynamicTool[]): void;
 }
 
 type SessionRequest = TriggerRequest | ContinueRequest;
@@ -259,9 +263,9 @@ The client uploads files directly to S3 using the presigned upload URL. See [Fil
 
 ## Next Steps
 
-- [Sessions](/docs/server-sdk/sessions) — Deep dive into session management
-- [Tools](/docs/server-sdk/tools) — Implementing tool handlers
-- [Streaming](/docs/server-sdk/streaming) — Understanding stream events
-- [Workers](/docs/server-sdk/workers) — Executing worker agents
-- [Debugging](/docs/server-sdk/debugging) — Model request tracing and debugging
-- [Computer](/docs/server-sdk/computer) — Browser, filesystem, and shell via MCP
+- [Sessions](/docs/server-sdk/sessions) - Deep dive into session management
+- [Tools](/docs/server-sdk/tools) - Implementing tool handlers
+- [Streaming](/docs/server-sdk/streaming) - Understanding stream events
+- [Workers](/docs/server-sdk/workers) - Executing worker agents
+- [Debugging](/docs/server-sdk/debugging) - Model request tracing and debugging
+- [Computer](/docs/server-sdk/computer) - Browser, filesystem, and shell via MCP

package/content/02-server-sdk/02-sessions.md

@@ -87,19 +87,19 @@ const session = client.agentSessions.attach(sessionId, {
   resources: [
     // Resource watchers (optional)
   ],
-  computer: computer, // Computer capabilities (optional, see Computer documentation)
 });
 ```
 
 ### Attach Options
 
-| Option      | Type           | Description                                                |
-| ----------- | -------------- | ---------------------------------------------------------- |
-| `tools`     | `ToolHandlers` | Server-side tool handler functions                         |
-| `resources` | `Resource[]`   | Resource watchers for real-time updates                    |
-| `computer`  | `ToolProvider` | Computer capabilities — browser, filesystem, shell via MCP |
+| Option                  | Type                              | Description                                                                     |
+| ----------------------- | --------------------------------- | ------------------------------------------------------------------------------- |
+| `tools`                 | `ToolHandlers`                    | Server-side tool handler functions                                              |
+| `resources`             | `Resource[]`                      | Resource watchers for real-time updates                                         |
+| `onToolResults`         | `(results: ToolResult[]) => void` | Callback invoked after server-side tool results are produced                    |
+| `rejectClientToolCalls` | `boolean`                         | If `true`, reject tool calls that have no server handler (no client forwarding) |
 
-When `computer` is provided, its tool handlers are merged with `tools` (manual handlers take priority on conflict), and its tool schemas are sent to the platform. See [Computer](/docs/server-sdk/computer) for details.
+For MCP tool integration (browser, filesystem, shell via `@octavus/computer`), register dynamic tools after attaching with `session.setDynamicTools()`. See [Computer](/docs/server-sdk/computer) for details.
 
 ## Executing Requests
 
@@ -416,7 +416,7 @@ interface ClearSessionResult {
 }
 ```
 
-This is idempotent — calling `clear()` on an already expired session succeeds without error.
+This is idempotent - calling `clear()` on an already expired session succeeds without error.
 
 ## Error Handling
 

package/content/02-server-sdk/03-tools.md

@@ -9,18 +9,18 @@ Tools extend what agents can do. In Octavus, tools can execute either on your se
 
 ## Server Tools vs Client Tools
 
-| Location   | Use Case                                          | Registration                            |
-| ---------- | ------------------------------------------------- | --------------------------------------- |
-| **Server** | Database queries, API calls, sensitive operations | Register handler in `attach()`          |
-| **MCP**    | Browser, filesystem, shell, external services     | Via `computer` option in `attach()`     |
-| **Client** | Browser APIs, interactive UIs, confirmations      | No server handler (forwarded to client) |
+| Location   | Use Case                                          | Registration                                     |
+| ---------- | ------------------------------------------------- | ------------------------------------------------ |
+| **Server** | Database queries, API calls, sensitive operations | Register handler in `attach()`                   |
+| **MCP**    | Browser, filesystem, shell, external services     | Via `session.setDynamicTools()` after `attach()` |
+| **Client** | Browser APIs, interactive UIs, confirmations      | No server handler (forwarded to client)          |
 
 When the Server SDK encounters a tool call:
 
-1. **Handler exists** (server or MCP) → Execute on server, continue automatically
+1. **Handler exists** (server or dynamic) → Execute on server, continue automatically
 2. **No handler** → Forward to client via `client-tool-request` event
 
-MCP tool handlers from `@octavus/computer` are merged with your manual handlers — they work identically from the platform's perspective. See [Computer](/docs/server-sdk/computer) for MCP tool integration.
+MCP tool handlers registered via `session.setDynamicTools()` (e.g., from `@octavus/computer`) work identically to manual handlers from the platform's perspective. See [Computer](/docs/server-sdk/computer) for MCP tool integration.
 
 For client-side tool handling, see [Client Tools](/docs/client-sdk/client-tools).
 
@@ -28,10 +28,10 @@ For client-side tool handling, see [Client Tools](/docs/client-sdk/client-tools)
 
 Server-side tools give you full control:
 
-- ✅ **Full data access** — Query your database directly
-- ✅ **Your authentication** — Use your existing auth context
-- ✅ **No data exposure** — Sensitive data never leaves your infrastructure
-- ✅ **Custom logic** — Any complexity you need
+- ✅ **Full data access** - Query your database directly
+- ✅ **Your authentication** - Use your existing auth context
+- ✅ **No data exposure** - Sensitive data never leaves your infrastructure
+- ✅ **Custom logic** - Any complexity you need
 
 ## Defining Tool Handlers
 

package/content/02-server-sdk/04-streaming.md

@@ -41,7 +41,7 @@ The `X-Accel-Buffering: no` header disables proxy buffering on Nginx-based infra
 
 ### Heartbeat
 
-`toSSEStream` automatically sends SSE comment lines (`: heartbeat`) every 15 seconds during idle periods. This prevents proxies and load balancers from closing the connection due to inactivity — particularly important during multi-step executions where the stream may be silent while waiting for tool processing or LLM responses.
+`toSSEStream` automatically sends SSE comment lines (`: heartbeat`) every 15 seconds during idle periods. This prevents proxies and load balancers from closing the connection due to inactivity - particularly important during multi-step executions where the stream may be silent while waiting for tool processing or LLM responses.
 
 Heartbeat comments are ignored by all SSE parsers per the spec. No client-side handling is needed.
 

package/content/02-server-sdk/05-cli.md

@@ -88,8 +88,8 @@ octavus sync ./agents/my-agent
 
 **Options:**
 
-- `--json` — Output as JSON (for CI/CD parsing)
-- `--quiet` — Suppress non-essential output
+- `--json` - Output as JSON (for CI/CD parsing)
+- `--quiet` - Suppress non-essential output
 
 **Example output:**
 
@@ -110,9 +110,9 @@ octavus validate ./agents/my-agent
 
 **Exit codes:**
 
-- `0` — Validation passed
-- `1` — Validation errors
-- `2` — Configuration errors (missing API key, etc.)
+- `0` - Validation passed
+- `1` - Validation errors
+- `2` - Configuration errors (missing API key, etc.)
 
 ### `octavus list`
 
@@ -150,8 +150,8 @@ octavus archive support-chat
 
 **Options:**
 
-- `--json` — Output as JSON (for CI/CD parsing)
-- `--quiet` — Suppress non-essential output
+- `--json` - Output as JSON (for CI/CD parsing)
+- `--quiet` - Suppress non-essential output
 
 **Example output:**
 
@@ -171,8 +171,8 @@ octavus skills sync ./skills/github
 
 **Options:**
 
-- `--json` — Output as JSON (for CI/CD parsing)
-- `--quiet` — Suppress non-essential output
+- `--json` - Output as JSON (for CI/CD parsing)
+- `--quiet` - Suppress non-essential output
 
 **Example output:**
 
@@ -187,7 +187,7 @@ octavus skills sync ./skills/github
 
 **Secret handling:**
 
-If the skill directory contains a `.env` file, secrets are pushed alongside the bundle. Secrets are cross-validated against the `secrets` declarations in `SKILL.md` — warnings are shown for undeclared or missing required secrets.
+If the skill directory contains a `.env` file, secrets are pushed alongside the bundle. Secrets are cross-validated against the `secrets` declarations in `SKILL.md` - warnings are shown for undeclared or missing required secrets.
 
 ```
 my-skill/
@@ -289,11 +289,11 @@ Add sync scripts to your `package.json`:
 
 The recommended workflow for managing agents:
 
-1. **Define agent locally** — Create `settings.json`, `protocol.yaml`, and prompts
-2. **Validate** — Run `octavus validate ./my-agent` to check for errors
-3. **Sync** — Run `octavus sync ./my-agent` to push to platform
-4. **Store agent ID** — Save the output ID in an environment variable
-5. **Use in app** — Read the ID from env and pass to `client.agentSessions.create()`
+1. **Define agent locally** - Create `settings.json`, `protocol.yaml`, and prompts
+2. **Validate** - Run `octavus validate ./my-agent` to check for errors
+3. **Sync** - Run `octavus sync ./my-agent` to push to platform
+4. **Store agent ID** - Save the output ID in an environment variable
+5. **Use in app** - Read the ID from env and pass to `client.agentSessions.create()`
 
 ```bash
 # After syncing: octavus sync ./agents/support-chat

package/content/02-server-sdk/06-workers.md

@@ -92,8 +92,8 @@ interface WorkerExecuteOptions {
   tools?: ToolHandlers;
   /** Abort signal to cancel the execution */
   signal?: AbortSignal;
-  /** Tool schemas from device MCPs (browser, filesystem, shell, etc.) */
-  additionalToolSchemas?: ToolSchema[];
+  /** Dynamic tool schemas (e.g., from MCP servers - browser, filesystem, shell) */
+  dynamicToolSchemas?: ToolSchema[];
 }
 ```
 
@@ -105,7 +105,7 @@ interface WorkerExecuteOptions {
 | `input`   | `Record<string, unknown>` | Input values for the worker |
 | `options` | `WorkerExecuteOptions`    | Optional configuration      |
 
-The `additionalToolSchemas` option enables device MCP support for workers executed via the SDK. Pass tool schemas from `@octavus/computer` (or any `ToolProvider`) so the worker can use device MCP tools. Schemas are sent on the first request and cached for continuation rounds.
+The `dynamicToolSchemas` option enables MCP tool support for workers executed via the SDK. Pass tool schemas from `@octavus/computer` (or any `ToolProvider`) so the worker can use MCP tools like browser, filesystem, and shell. Schemas are sent on the first request and cached for continuation rounds.
 
 ## Tool Handlers
 
@@ -128,7 +128,7 @@ const { output } = await client.workers.generate(
 );
 ```
 
-Tools defined in the worker protocol but not provided as handlers become client tools — the execution pauses and emits a `client-tool-request` event.
+Tools defined in the worker protocol but not provided as handlers become client tools - the execution pauses and emits a `client-tool-request` event.
 
 ## Error Handling
 
@@ -146,7 +146,7 @@ try {
   if (error instanceof WorkerError) {
     console.error('Worker failed:', error.message);
     if (error.sessionId) {
-      console.error(`Debug: ${client.baseUrl}/platform/sessions/${error.sessionId}`);
+      console.error(`Debug: ${client.baseUrl}/sessions/${error.sessionId}`);
     }
   }
 }
@@ -211,7 +211,7 @@ try {
 
 ## Streaming
 
-When you need real-time visibility into the worker's execution — text generation, tool calls, or progress — use `execute()` instead of `generate()`.
+When you need real-time visibility into the worker's execution - text generation, tool calls, or progress - use `execute()` instead of `generate()`.
 
 ### Basic Streaming
 
@@ -359,7 +359,7 @@ try {
   if (error instanceof WorkerError) {
     console.error('Failed:', error.message);
     if (error.sessionId) {
-      console.error(`Debug: ${client.baseUrl}/platform/sessions/${error.sessionId}`);
+      console.error(`Debug: ${client.baseUrl}/sessions/${error.sessionId}`);
     }
   }
 }
@@ -434,6 +434,6 @@ console.log('Result:', result);
 
 ## Next Steps
 
-- [Workers Protocol](/docs/protocol/workers) — Worker protocol reference
-- [Streaming](/docs/server-sdk/streaming) — Understanding stream events
-- [Tools](/docs/server-sdk/tools) — Tool handler patterns
+- [Workers Protocol](/docs/protocol/workers) - Worker protocol reference
+- [Streaming](/docs/server-sdk/streaming) - Understanding stream events
+- [Tools](/docs/server-sdk/tools) - Tool handler patterns

package/content/02-server-sdk/07-debugging.md

@@ -7,7 +7,7 @@ description: Model request tracing and debugging tools for Octavus agents.
 
 ## Model Request Tracing
 
-Model request tracing captures the full payload sent to model providers (LLM and image) during agent execution. This helps you understand exactly what was sent — system prompts, messages, tool definitions, and provider options — making it easier to debug agent behavior.
+Model request tracing captures the full payload sent to model providers (LLM and image) during agent execution. This helps you understand exactly what was sent - system prompts, messages, tool definitions, and provider options - making it easier to debug agent behavior.
 
 ### Enabling Tracing
 
@@ -57,8 +57,8 @@ Traces appear as **Model Request** entries in the execution log timeline, alongs
 
 In the Octavus dashboard:
 
-- **Session debug view** — Full execution log with expandable model request entries
-- **Agent preview** — Activity panel shows model requests in the execution steps
+- **Session debug view** - Full execution log with expandable model request entries
+- **Agent preview** - Activity panel shows model requests in the execution steps
 
 Each entry shows the raw JSON payload with a copy button for easy inspection.
 
@@ -70,10 +70,10 @@ Traces are stored in Redis alongside other execution log entries with a 24-hour
 
 | Environment | Recommendation                                             |
 | ----------- | ---------------------------------------------------------- |
-| Development | Enable — helps debug agent behavior during development     |
-| Staging     | Enable — useful for pre-production testing                 |
-| Production  | Disable (default) — saves storage for high-volume sessions |
+| Development | Enable - helps debug agent behavior during development     |
+| Staging     | Enable - useful for pre-production testing                 |
+| Production  | Disable (default) - saves storage for high-volume sessions |
 
 ### Preview Sessions
 
-Model request tracing is always enabled for preview sessions in the Octavus dashboard. No configuration needed — the platform automatically traces all model requests when using the agent preview.
+Model request tracing is always enabled for preview sessions in the Octavus dashboard. No configuration needed - the platform automatically traces all model requests when using the agent preview.

package/content/02-server-sdk/08-computer.md

@@ -40,11 +40,12 @@ const session = client.agentSessions.attach(sessionId, {
   tools: {
     'set-chat-title': async (args) => ({ title: args.title }),
   },
-  computer,
 });
+
+session.setDynamicTools(computer);
 ```
 
-The `computer` is passed to `attach()` — the server-sdk handles the rest. Tool schemas are sent to the platform, and tool calls flow back through the existing execution loop.
+Dynamic tools are registered after attaching via `session.setDynamicTools()`. Pass the `computer` directly - the session extracts schemas and handlers from the `ToolProvider`. Tool schemas are sent to the platform on the next `execute()` call, and tool calls flow back through the existing execution loop.
 
 ## How It Works
 
@@ -53,7 +54,7 @@ The `computer` is passed to `attach()` — the server-sdk handles the rest. Tool
 3. Each tool is namespaced with `__` (e.g., `browser__navigate_page`, `filesystem__read_file`)
 4. The server-sdk sends tool schemas to the platform and handles tool call execution
 
-The agent's protocol must declare matching `mcpServers` with `source: device` — see [MCP Servers](/docs/protocol/mcp-servers).
+The agent's protocol must declare matching `mcpServers` with `source: device` - see [MCP Servers](/docs/protocol/mcp-servers).
 
 ## Entry Types
 
@@ -159,7 +160,7 @@ When `allowedPatterns` is set, only matching commands are permitted. When `block
 
 ### Starting
 
-`computer.start()` connects to all configured MCP servers in parallel. If some servers fail to connect, the computer still starts with the remaining servers — only if _all_ connections fail does it throw an error.
+`computer.start()` connects to all configured MCP servers in parallel. If some servers fail to connect, the computer still starts with the remaining servers - only if _all_ connections fail does it throw an error.
 
 ```typescript
 const { errors } = await computer.start();
@@ -227,7 +228,13 @@ interface ToolProvider {
 }
 ```
 
-The server-sdk accepts any `ToolProvider` on the `computer` option — you can implement your own if `@octavus/computer` doesn't fit your use case:
+`setDynamicTools()` accepts any `ToolProvider` directly - the session extracts schemas and handlers automatically:
+
+```typescript
+session.setDynamicTools(computer);
+```
+
+You can also pass a custom `ToolProvider`:
 
 ```typescript
 const customProvider: ToolProvider = {
@@ -257,8 +264,18 @@ const customProvider: ToolProvider = {
 
 const session = client.agentSessions.attach(sessionId, {
   tools: { 'set-chat-title': titleHandler },
-  computer: customProvider,
 });
+
+session.setDynamicTools(customProvider);
+```
+
+For cases where you need explicit control, `setDynamicTools()` also accepts a `DynamicTool[]` array:
+
+```typescript
+interface DynamicTool {
+  schema: ToolSchema;
+  handler: ToolHandler;
+}
 ```
 
 ## Complete Example
@@ -300,7 +317,7 @@ async function startSession(sessionId: string) {
     console.warn('Failed to connect:', errors);
   }
 
-  // 4. Attach to session with computer
+  // 4. Attach to session and register dynamic tools
   const client = new OctavusClient({
     baseUrl: process.env.OCTAVUS_API_URL!,
     apiKey: process.env.OCTAVUS_API_KEY!,
@@ -313,9 +330,10 @@ async function startSession(sessionId: string) {
         return { success: true };
       },
     },
-    computer,
   });
 
+  session.setDynamicTools(computer);
+
   // 5. Execute and stream
   const events = session.execute({
     type: 'trigger',

package/content/03-client-sdk/01-overview.md

@@ -12,7 +12,7 @@ Octavus provides two packages for frontend integration:
 | `@octavus/react`      | React hooks and bindings | Building React applications                           |
 | `@octavus/client-sdk` | Framework-agnostic core  | Using Vue, Svelte, vanilla JS, or custom integrations |
 
-**Most users should install `@octavus/react`** — it includes everything from `@octavus/client-sdk` plus React-specific hooks.
+**Most users should install `@octavus/react`** - it includes everything from `@octavus/client-sdk` plus React-specific hooks.
 
 ## Installation
 
@@ -271,7 +271,7 @@ interface UserMessageInput {
 
 ### useAutoScroll
 
-Smart auto-scroll for chat containers. Scrolls to bottom when content updates, but pauses if the user has scrolled up. See [Streaming — Auto-Scroll](/docs/client-sdk/streaming#auto-scroll) for full usage.
+Smart auto-scroll for chat containers. Scrolls to bottom when content updates, but pauses if the user has scrolled up. See [Streaming - Auto-Scroll](/docs/client-sdk/streaming#auto-scroll) for full usage.
 
 ```typescript
 function useAutoScroll(options?: UseAutoScrollOptions): {
@@ -373,12 +373,12 @@ class OctavusChat {
 
 ## Next Steps
 
-- [HTTP Transport](/docs/client-sdk/http-transport) — HTTP/SSE integration (recommended)
-- [Socket Transport](/docs/client-sdk/socket-transport) — WebSocket and SockJS integration
-- [Messages](/docs/client-sdk/messages) — Working with message state
-- [Streaming](/docs/client-sdk/streaming) — Building streaming UIs
-- [Client Tools](/docs/client-sdk/client-tools) — Interactive browser-side tool handling
-- [Operations](/docs/client-sdk/execution-blocks) — Showing agent progress
-- [Error Handling](/docs/client-sdk/error-handling) — Handling errors with type guards
-- [File Uploads](/docs/client-sdk/file-uploads) — Uploading images and documents
-- [Examples](/docs/examples/overview) — Complete working examples
+- [HTTP Transport](/docs/client-sdk/http-transport) - HTTP/SSE integration (recommended)
+- [Socket Transport](/docs/client-sdk/socket-transport) - WebSocket and SockJS integration
+- [Messages](/docs/client-sdk/messages) - Working with message state
+- [Streaming](/docs/client-sdk/streaming) - Building streaming UIs
+- [Client Tools](/docs/client-sdk/client-tools) - Interactive browser-side tool handling
+- [Operations](/docs/client-sdk/execution-blocks) - Showing agent progress
+- [Error Handling](/docs/client-sdk/error-handling) - Handling errors with type guards
+- [File Uploads](/docs/client-sdk/file-uploads) - Uploading images and documents
+- [Examples](/docs/examples/overview) - Complete working examples

package/content/03-client-sdk/03-streaming.md

@@ -256,9 +256,9 @@ The hook returns four values:
 | Return Value      | Purpose                                                                                           |
 | ----------------- | ------------------------------------------------------------------------------------------------- |
 | `scrollRef`       | Attach to the scrollable container's `ref`                                                        |
-| `handleScroll`    | Attach to the container's `onScroll` — tracks whether the user is near the bottom                 |
-| `scrollOnUpdate`  | Call inside a `useEffect` when messages change — scrolls to bottom if the user hasn't scrolled up |
-| `resetAutoScroll` | Call when the user sends a message — forces the next update to scroll to bottom                   |
+| `handleScroll`    | Attach to the container's `onScroll` - tracks whether the user is near the bottom                 |
+| `scrollOnUpdate`  | Call inside a `useEffect` when messages change - scrolls to bottom if the user hasn't scrolled up |
+| `resetAutoScroll` | Call when the user sends a message - forces the next update to scroll to bottom                   |
 
 You can customize the hook with options:
 

package/content/03-client-sdk/04-execution-blocks.md

@@ -111,7 +111,7 @@ function EscalationProgress({ message }: { message: UIMessage }) {
 
 Operations are only sent to the client if their protocol block has a visible display mode (`name`, `description`, or `stream`). Hidden operations (`display: hidden`) are filtered out by the platform before reaching the client.
 
-This means you can safely render all operations without checking display mode — hidden ones won't be in the message parts.
+This means you can safely render all operations without checking display mode - hidden ones won't be in the message parts.
 
 ## Named Thread Operations
 

package/content/03-client-sdk/05-socket-transport.md

@@ -19,7 +19,7 @@ The socket transport enables real-time bidirectional communication using WebSock
 
 ## Connection Lifecycle
 
-By default, socket transport uses **lazy connection** — the socket connects only when you first call `send()`. This is efficient but can be surprising if you want to show connection status.
+By default, socket transport uses **lazy connection** - the socket connects only when you first call `send()`. This is efficient but can be surprising if you want to show connection status.
 
 For UI indicators, use **eager connection**:
 
@@ -86,7 +86,7 @@ There are two main patterns for socket-based integrations:
 
 ## Server-Managed Sessions (Recommended)
 
-The cleanest pattern is to have the server manage session lifecycle. The client never needs to know about `sessionId` — the server creates it lazily on first message.
+The cleanest pattern is to have the server manage session lifecycle. The client never needs to know about `sessionId` - the server creates it lazily on first message.
 
 ### Client Setup
 
@@ -104,7 +104,7 @@ function connectSocket(): Promise<SocketLike> {
 }
 
 function Chat() {
-  // Transport is stable — no dependencies on sessionId
+  // Transport is stable - no dependencies on sessionId
   const transport = useMemo(() => createSocketTransport({ connect: connectSocket }), []);
 
   const { messages, status, send, stop, connectionState, connect, disconnect } = useOctavusChat({
@@ -185,7 +185,7 @@ sockServer.installHandlers(httpServer);
 
 **Benefits of this pattern:**
 
-- Client code is simple — no sessionId management
+- Client code is simple - no sessionId management
 - No transport caching issues
 - Session is created only when needed
 - Server controls session configuration
@@ -300,7 +300,7 @@ function ChatPage() {
 }
 ```
 
-This is the cleanest approach — the `Chat` component always receives a valid `sessionId`.
+This is the cleanest approach - the `Chat` component always receives a valid `sessionId`.
 
 ### Option 2: Server-Managed Sessions
 

package/content/03-client-sdk/06-http-transport.md

@@ -364,8 +364,8 @@ See [Streaming Events](/docs/server-sdk/streaming#event-types) for the full list
 
 ## Next Steps
 
-- [Quick Start](/docs/getting-started/quickstart) — Complete Next.js integration guide
-- [Client Tools](/docs/client-sdk/client-tools) — Handling tools on the client side
-- [Messages](/docs/client-sdk/messages) — Working with message state
-- [Streaming](/docs/client-sdk/streaming) — Building streaming UIs
-- [Error Handling](/docs/client-sdk/error-handling) — Handling errors with type guards
+- [Quick Start](/docs/getting-started/quickstart) - Complete Next.js integration guide
+- [Client Tools](/docs/client-sdk/client-tools) - Handling tools on the client side
+- [Messages](/docs/client-sdk/messages) - Working with message state
+- [Streaming](/docs/client-sdk/streaming) - Building streaming UIs
+- [Error Handling](/docs/client-sdk/error-handling) - Handling errors with type guards

package/content/03-client-sdk/07-structured-output.md

@@ -373,9 +373,9 @@ The `responseType` in your protocol must be an **object type** (regular custom t
 
 The following cannot be used directly as `responseType`:
 
-- **Discriminated unions** — LLM providers don't allow `anyOf` at the schema root
-- **Array types** — Must be wrapped in an object
-- **Primitives** — `string`, `number`, etc. are not valid
+- **Discriminated unions** - LLM providers don't allow `anyOf` at the schema root
+- **Array types** - Must be wrapped in an object
+- **Primitives** - `string`, `number`, etc. are not valid
 
 If you need variant responses, wrap the discriminated union in an object:
 

package/content/03-client-sdk/08-file-uploads.md

@@ -188,12 +188,12 @@ Uploads include built-in timeout and retry logic for handling transient failures
 
 **Default behavior:**
 
-- **Timeout**: 60 seconds per file — prevents uploads from hanging on stalled connections
+- **Timeout**: 60 seconds per file - prevents uploads from hanging on stalled connections
 - **Retries**: 2 automatic retries on transient failures (network errors, 5xx, 429)
 - **Retry delay**: 1 second between retries
 - **Non-retryable errors** (4xx like 403, 404) fail immediately without retrying
 
-Only the S3 upload is retried — the presigned URL stays valid for 15 minutes. On retry, the progress callback resets to 0%.
+Only the S3 upload is retried - the presigned URL stays valid for 15 minutes. On retry, the progress callback resets to 0%.
 
 Configure via `uploadOptions`: