@octavus/docs 3.0.0 → 3.2.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

@@ -263,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

@@ -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

@@ -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,7 +92,7 @@ interface WorkerExecuteOptions {
   tools?: ToolHandlers;
   /** Abort signal to cancel the execution */
   signal?: AbortSignal;
-  /** Dynamic tool schemas (e.g., from MCP servers — browser, filesystem, shell) */
+  /** Dynamic tool schemas (e.g., from MCP servers - browser, filesystem, shell) */
   dynamicToolSchemas?: ToolSchema[];
 }
 ```
@@ -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

@@ -45,7 +45,7 @@ const session = client.agentSessions.attach(sessionId, {
 session.setDynamicTools(computer);
 ```
 
-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.
+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
 
@@ -54,7 +54,7 @@ Dynamic tools are registered after attaching via `session.setDynamicTools()`. Pa
 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
 
@@ -160,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();
@@ -228,7 +228,7 @@ interface ToolProvider {
 }
 ```
 
-`setDynamicTools()` accepts any `ToolProvider` directly — the session extracts schemas and handlers automatically:
+`setDynamicTools()` accepts any `ToolProvider` directly - the session extracts schemas and handlers automatically:
 
 ```typescript
 session.setDynamicTools(computer);

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/02-messages.md

@@ -31,7 +31,9 @@ type UIMessagePart =
   | UIOperationPart
   | UISourcePart
   | UIFilePart
-  | UIObjectPart;
+  | UIObjectPart
+  | UITodoPart
+  | UIWorkerPart;
 
 // Text content
 interface UITextPart {
@@ -107,6 +109,31 @@ interface UIObjectPart {
   error?: string;
   thread?: string;
 }
+
+// Structured task list (when the agent uses octavus_todo_write)
+interface UITodoPart {
+  type: 'todo';
+  todos: {
+    id: string;
+    content: string;
+    status: 'pending' | 'in_progress' | 'completed' | 'cancelled';
+  }[];
+  status: 'streaming' | 'done';
+  thread?: string;
+}
+
+// Sub-agent execution container (when an agent invokes a worker)
+interface UIWorkerPart {
+  type: 'worker';
+  workerId: string;
+  workerSlug: string;
+  description?: string;
+  input?: Record<string, unknown>;
+  parts: UIMessagePart[]; // Nested parts from the worker (excluding nested workers)
+  output?: unknown;
+  error?: string;
+  status: 'running' | 'done' | 'error';
+}
 ```
 
 ## Sending Messages

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`:
 

package/content/03-client-sdk/09-error-handling.md

@@ -137,7 +137,7 @@ if (canRetry) {
 }
 ```
 
-`retry()` also works after stopping (cancellation) or when the result is unsatisfactory — not just errors.
+`retry()` also works after stopping (cancellation) or when the result is unsatisfactory - not just errors.
 
 ## Building Error UI
 
@@ -281,7 +281,7 @@ interface ErrorEvent {
 
 ## Tool Errors
 
-Tool errors are handled differently—they appear inline on the tool call:
+Tool errors are handled differently - they appear inline on the tool call:
 
 ```tsx
 function ToolCallPart({ part }: { part: UIToolCallPart }) {
@@ -295,4 +295,4 @@ function ToolCallPart({ part }: { part: UIToolCallPart }) {
 }
 ```
 
-Tool errors don't trigger `onError`—they're captured on the tool call part itself.
+Tool errors don't trigger `onError` - they're captured on the tool call part itself.

package/content/03-client-sdk/10-client-tools.md

@@ -7,9 +7,9 @@ description: Handling tool calls on the client side for interactive UI and brows
 
 By default, tools execute on your server where you have access to databases and APIs. However, some tools are better suited for client-side execution:
 
-- **Browser-only operations** — Geolocation, clipboard, local storage
-- **Interactive UIs** — Confirmation dialogs, form inputs, selections
-- **Real-time feedback** — Progress indicators, approval workflows
+- **Browser-only operations** - Geolocation, clipboard, local storage
+- **Interactive UIs** - Confirmation dialogs, form inputs, selections
+- **Real-time feedback** - Progress indicators, approval workflows
 
 ## How Client Tools Work
 

package/content/04-protocol/01-overview.md

@@ -11,11 +11,11 @@ Agent protocols define how an AI agent behaves. They're written in YAML and spec
 
 Protocols provide:
 
-- **Declarative definition** — Define behavior, not implementation
-- **Portable agents** — Move agents between projects
-- **Versioning** — Track changes with git
-- **Validation** — Catch errors before runtime
-- **Visualization** — Debug execution flows
+- **Declarative definition** - Define behavior, not implementation
+- **Portable agents** - Move agents between projects
+- **Versioning** - Track changes with git
+- **Validation** - Catch errors before runtime
+- **Visualization** - Debug execution flows
 
 ## Agent Formats
 
@@ -26,9 +26,9 @@ Octavus supports two agent formats:
 | `interactive` | Chat and multi-turn dialogue   | `triggers` + `handlers` + `agent` |
 | `worker`      | Background tasks and pipelines | `steps` + `output`                |
 
-**Interactive agents** handle conversations — they respond to triggers (like user messages) and maintain session state across interactions.
+**Interactive agents** handle conversations - they respond to triggers (like user messages) and maintain session state across interactions.
 
-**Worker agents** execute tasks — they run steps sequentially and return an output value. Workers can be called independently or composed into interactive agents.
+**Worker agents** execute tasks - they run steps sequentially and return an output value. Workers can be called independently or composed into interactive agents.
 
 See [Workers](/docs/protocol/workers) for the worker protocol reference.
 
@@ -90,6 +90,7 @@ agent:
   skills: [qr-code] # Enable skills
   imageModel: google/gemini-2.5-flash-image # Enable image generation
   webSearch: true # Enable web search
+  todoList: true # Enable structured task tracking
   agentic: true # Allow multiple tool calls
   thinking: medium # Extended reasoning
 
@@ -192,14 +193,14 @@ The referenced prompt content is inserted before variable interpolation, so vari
 
 ## Next Steps
 
-- [Input & Resources](/docs/protocol/input-resources) — Defining agent inputs
-- [Triggers](/docs/protocol/triggers) — How agents are invoked
-- [Tools](/docs/protocol/tools) — External capabilities
-- [MCP Servers](/docs/protocol/mcp-servers) — Remote services and device capabilities via MCP
-- [Skills](/docs/protocol/skills) — Code execution and knowledge packages
-- [References](/docs/protocol/references) — On-demand context documents
-- [Handlers](/docs/protocol/handlers) — Execution blocks
-- [Agent Config](/docs/protocol/agent-config) — Model and settings
-- [Workers](/docs/protocol/workers) — Worker agent format
-- [Provider Options](/docs/protocol/provider-options) — Provider-specific features
-- [Types](/docs/protocol/types) — Custom type definitions
+- [Input & Resources](/docs/protocol/input-resources) - Defining agent inputs
+- [Triggers](/docs/protocol/triggers) - How agents are invoked
+- [Tools](/docs/protocol/tools) - External capabilities
+- [MCP Servers](/docs/protocol/mcp-servers) - Remote services and device capabilities via MCP
+- [Skills](/docs/protocol/skills) - Code execution and knowledge packages
+- [References](/docs/protocol/references) - On-demand context documents
+- [Handlers](/docs/protocol/handlers) - Execution blocks
+- [Agent Config](/docs/protocol/agent-config) - Model and settings
+- [Workers](/docs/protocol/workers) - Worker agent format
+- [Provider Options](/docs/protocol/provider-options) - Provider-specific features
+- [Types](/docs/protocol/types) - Custom type definitions