docs: align documentation with View-based write and navigation API

Updates 17 doc pages to reflect the architecture changes where
send/regenerate/edit moved from ClientTransport to View, and branch
navigation (select, getSelectedIndex) moved from Tree to View.

- Feature pages: transport.send() → view.send(), tree.select() → view.select()
- React hook reference: ViewHandle now includes write ops and navigation;
  useSend/useRegenerate/useEdit accept View; useTree has structural queries only
- Internals: Tree is a pure data structure; selection lives on View;
  transport exposes _internalSend via SendDelegate
- Glossary: updated own-turn and flatten definitions

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: mschristensen

README.md

@@ -376,7 +376,7 @@ Detailed documentation lives in the [`docs/`](./docs/) directory:
 - **[Concepts](./docs/concepts/)** - [Transport architecture](./docs/concepts/transport.md), [Turns](./docs/concepts/turns.md)
 - **[Get started](./docs/get-started/)** - [Vercel AI SDK with useChat](./docs/get-started/vercel-use-chat.md), [Vercel AI SDK with useClientTransport](./docs/get-started/vercel-use-client-transport.md)
 - **[Frameworks](./docs/frameworks/)** - [Vercel AI SDK](./docs/frameworks/vercel-ai-sdk.md)
-- **[Features](./docs/features/)** - [Streaming](./docs/features/streaming.md), [Cancellation](./docs/features/cancel.md), [Barge-in](./docs/features/barge-in.md), [Optimistic updates](./docs/features/optimistic-updates.md), [History](./docs/features/history.md), [Branching](./docs/features/branching.md), [Multi-client sync](./docs/features/multi-client.md), [Tool calls](./docs/features/tool-calls.md), [Concurrent turns](./docs/features/concurrent-turns.md)
+- **[Features](./docs/features/)** - [Streaming](./docs/features/streaming.md), [Cancellation](./docs/features/cancel.md), [Interruption](./docs/features/interruption.md), [Optimistic updates](./docs/features/optimistic-updates.md), [History](./docs/features/history.md), [Branching](./docs/features/branching.md), [Multi-client sync](./docs/features/multi-client.md), [Concurrent turns](./docs/features/concurrent-turns.md)
 - **[Reference](./docs/reference/)** - [React hooks](./docs/reference/react-hooks.md), [Error codes](./docs/reference/error-codes.md)
 - **[Internals](./docs/internals/)** - Architecture details for contributors
 

docs/concepts/transport.md

@@ -62,13 +62,14 @@ The client transport manages conversation state: the message list, conversation
 import { createClientTransport } from '@ably/ai-transport/vercel';
 
 const transport = createClientTransport({ channel, clientId });
+const view = transport.view;
 
 // Send a message - returns immediately with a turn handle
-const turn = await transport.send(userMessage);
+const turn = await view.send(userMessage);
 
 // Subscribe to accumulated messages - updates on every token
-transport.view.on('update', () => {
-  const messages = transport.view.flattenNodes().map(n => n.message);
+view.on('update', () => {
+  const messages = view.flattenNodes().map(n => n.message);
   // the last assistant message grows as tokens stream in
 });
 
@@ -79,12 +80,11 @@ transport.view.on('update', () => {
 In React, the hooks handle subscriptions and state management:
 
 ```typescript
-import { useClientTransport, useView, useSend } from '@ably/ai-transport/react';
+import { useClientTransport, useView } from '@ably/ai-transport/react';
 import { UIMessageCodec } from '@ably/ai-transport/vercel';
 
 const transport = useClientTransport({ channel, codec: UIMessageCodec, clientId });
-const { nodes } = useView(transport);
-const send = useSend(transport);
+const { nodes, send } = useView(transport);
 ```
 
 ## The codec

docs/concepts/turns.md

@@ -40,10 +40,10 @@ Pass `reason` to `end()` so all clients see why the turn ended.
 
 ### Client side
 
-The client transport creates turns implicitly when you call `send()`, `regenerate()`, or `edit()`:
+The client creates turns implicitly when you call `view.send()`, `view.regenerate()`, or `view.edit()`:
 
 ```typescript
-const turn = await transport.send(userMessage);
+const turn = await view.send(userMessage);
 
 // turn.turnId - the unique turn identifier
 // turn.stream - a ReadableStream of decoded events

docs/features/branching.md

@@ -27,9 +27,9 @@ User: "What is Rust?"                     (msg-1, parent: null)
 Regeneration forks an assistant message - the server produces a new response for the same prompt:
 
 ```typescript
-import { useRegenerate } from '@ably/ai-transport/react';
+import { useView } from '@ably/ai-transport/react';
 
-const regenerate = useRegenerate(transport);
+const { regenerate } = useView(transport);
 
 // Fork the assistant message - starts a new turn with no new user messages.
 // nodeId is the x-ably-msg-id (see treeMsgId helper in the quickstart).
@@ -43,9 +43,9 @@ The transport automatically computes `forkOf` (the assistant message being repla
 Editing forks a user message - the user provides replacement content, and the server produces a new response:
 
 ```typescript
-import { useEdit } from '@ably/ai-transport/react';
+import { useView } from '@ably/ai-transport/react';
 
-const edit = useEdit(transport);
+const { edit } = useView(transport);
 
 const newMessage = {
   id: crypto.randomUUID(),
@@ -61,48 +61,48 @@ await edit(nodeId, [newMessage]);
 
 ## Branch navigation
 
-`useTree` provides the tree state and navigation:
+`useView` provides branch navigation alongside message state:
 
 ```typescript
-import { useTree } from '@ably/ai-transport/react';
+import { useView } from '@ably/ai-transport/react';
 
-const tree = useTree(transport);
+const view = useView(transport);
 
-// tree.hasSiblings(nodeId) - does this message have alternatives?
-// tree.getSiblings(nodeId) - all alternatives at this fork point
-// tree.getSelectedIndex(nodeId) - which sibling is currently selected
-// tree.select(nodeId, index) - switch to a different sibling
-// tree.getNode(nodeId) - look up a node by msgId
+// view.hasSiblings(nodeId) - does this message have alternatives?
+// view.getSiblings(nodeId) - all alternatives at this fork point
+// view.getSelectedIndex(nodeId) - which sibling is currently selected
+// view.select(nodeId, index) - switch to a different sibling
+// view.getNode(nodeId) - look up a node by msgId
 //
-// nodeId is the msgId on each TreeNode — iterate tree.flattenNodes():
-//   transport.tree.flattenNodes().map((node) => {
+// nodeId is the msgId on each TreeNode — iterate view.nodes:
+//   view.nodes.map((node) => {
 //     const nodeId = node.msgId;
 //   });
 ```
 
 Build a sibling navigator (where `nodeId` is the resolved `x-ably-msg-id` for the message):
 
 ```typescript
-{tree.hasSiblings(nodeId) && (
+{view.hasSiblings(nodeId) && (
   <div>
     <button
-      onClick={() => tree.select(nodeId, tree.getSelectedIndex(nodeId) - 1)}
-      disabled={tree.getSelectedIndex(nodeId) === 0}
+      onClick={() => view.select(nodeId, view.getSelectedIndex(nodeId) - 1)}
+      disabled={view.getSelectedIndex(nodeId) === 0}
     >
       ←
     </button>
-    <span>{tree.getSelectedIndex(nodeId) + 1} / {tree.getSiblings(nodeId).length}</span>
+    <span>{view.getSelectedIndex(nodeId) + 1} / {view.getSiblings(nodeId).length}</span>
     <button
-      onClick={() => tree.select(nodeId, tree.getSelectedIndex(nodeId) + 1)}
-      disabled={tree.getSelectedIndex(nodeId) === tree.getSiblings(nodeId).length - 1}
+      onClick={() => view.select(nodeId, view.getSelectedIndex(nodeId) + 1)}
+      disabled={view.getSelectedIndex(nodeId) === view.getSiblings(nodeId).length - 1}
     >
       →
     </button>
   </div>
 )}
 ```
 
-Calling `select` updates the tree's active branch. The view re-renders with the selected path.
+Calling `select` updates the view's active branch and re-renders with the selected path.
 
 ## Server handling
 

docs/features/cancel.md

@@ -10,7 +10,7 @@ Cancel a specific turn or all matching turns:
 
 ```typescript
 // Cancel a specific turn (returned by send/regenerate/edit)
-const turn = await transport.send(userMessage);
+const turn = await view.send(userMessage);
 await turn.cancel();
 
 // Cancel all your own active turns

docs/features/concurrent-turns.md

@@ -6,12 +6,12 @@ Without concurrent turn support, a transport must serialize interactions: one re
 
 ## How it works
 
-Each call to `send()`, `regenerate()`, or `edit()` on the client creates a new turn. On the server, each incoming request calls `newTurn()`. Turns are identified by `turnId` and tracked by `clientId`.
+Each call to `view.send()`, `view.regenerate()`, or `view.edit()` on the client creates a new turn. On the server, each incoming request calls `newTurn()`. Turns are identified by `turnId` and tracked by `clientId`.
 
 ```typescript
 // Client: two sends in quick succession create two concurrent turns
-const turnA = await transport.send(messageA);
-const turnB = await transport.send(messageB);
+const turnA = await view.send(messageA);
+const turnB = await view.send(messageB);
 
 // Each has its own stream
 const readerA = turnA.stream.getReader();
@@ -97,4 +97,3 @@ Concurrent turns happen in these scenarios:
 - **Interruption without cancel** - user sends a new message without stopping the current response (see [Interruption](interruption.md))
 - **Multi-user** - two users on the same channel both send messages (see [Multi-client sync](multi-client.md))
 - **Multi-agent** - a server creates multiple turns for different agents responding to the same prompt
-- **Parallel tool execution** - a server creates separate turns for parallel tool call results

docs/features/history.md

@@ -1,6 +1,6 @@
 # History and replay
 
-`transport.view.loadOlder(limit)` loads conversation history from the Ably channel. A new client - after a page refresh, on a new device, or joining mid-conversation - can hydrate the full conversation from channel history without a separate database.
+`view.loadOlder(limit)` loads conversation history from the Ably channel. A new client - after a page refresh, on a new device, or joining mid-conversation - can hydrate the full conversation from channel history without a separate database.
 
 Without persistent history, page refresh means starting over. With AI Transport, messages are persisted on the Ably channel and decoded through the same codec used for live streaming.
 
@@ -14,7 +14,7 @@ await view.loadOlder(30);
 // Call loadOlder again to fetch more older messages
 ```
 
-History messages are inserted into the transport's conversation tree and trigger an `'update'` notification on the view. After loading history, `transport.view.flattenNodes().map(n => n.message)` returns the combined history + live messages - flattened along the currently selected branch. If the history contains forks (from regeneration or editing), only the active branch is included. Use the conversation tree to navigate between branches (see [Conversation branching](branching.md)).
+History messages are inserted into the transport's conversation tree and trigger an `'update'` notification on the view. After loading history, `view.flattenNodes().map(n => n.message)` returns the combined history + live messages - flattened along the currently selected branch. If the history contains forks (from regeneration or editing), only the active branch is included. Use the conversation tree to navigate between branches (see [Conversation branching](branching.md)).
 
 The `limit` parameter controls how many **complete domain messages** to return, not how many Ably wire messages to fetch. A single assistant message may span dozens of Ably messages (one per append). The implementation pages through Ably history until `limit` complete messages have been assembled.
 
@@ -66,7 +66,7 @@ const { nodes, hasOlder, loading, loadOlder } = useView(transport, { limit: 30 }
 
 History messages carry the same `x-ably-parent` and `x-ably-fork-of` headers as live messages. When loaded, they're inserted into the conversation tree with their full branch structure intact. A client loading history sees the same tree of branches and can navigate siblings just like a client that was present for the original conversation.
 
-Because the tree may contain multiple branches, the view's `flattenNodes()` returns only the messages along the currently selected path - not every message ever published. To see alternative branches, use `useTree` or the tree's `getSiblings()` / `select()` methods.
+Because the tree may contain multiple branches, the view's `flattenNodes()` returns only the messages along the currently selected path - not every message ever published. To see alternative branches, use `useView` or the view's `getSiblings()` / `select()` methods.
 
 See [Conversation branching](branching.md) for the tree model.
 

docs/features/interruption.md

@@ -18,10 +18,10 @@ Two patterns:
 The most common pattern: cancel active turns before sending the new message.
 
 ```typescript
-import { useActiveTurns, useSend } from '@ably/ai-transport/react';
+import { useActiveTurns, useView } from '@ably/ai-transport/react';
 
 const activeTurns = useActiveTurns(transport);
-const send = useSend(transport);
+const { send } = useView(transport);
 const isStreaming = activeTurns.size > 0;
 
 async function handleSend(text: string) {

docs/features/optimistic-updates.md

@@ -6,7 +6,7 @@ Without optimistic insertion, the user would see a gap between pressing "send" a
 
 ## How it works
 
-The client generates a unique message ID (`x-ably-msg-id`) for each user message and inserts it into the conversation tree with no [serial](../internals/glossary.md#serial-ably) (Ably's server-assigned ordering identifier). The message is visible via `transport.view.flattenNodes()` immediately. The HTTP POST to the server is [fire-and-forget](../internals/glossary.md#fire-and-forget) - `send()` returns without waiting for the server to respond.
+The client generates a unique message ID (`x-ably-msg-id`) for each user message and inserts it into the conversation tree with no [serial](../internals/glossary.md#serial-ably) (Ably's server-assigned ordering identifier). The message is visible via `view.flattenNodes()` immediately. The HTTP POST to the server is [fire-and-forget](../internals/glossary.md#fire-and-forget) - `send()` returns without waiting for the server to respond.
 
 The server receives the user message and relays it onto the Ably channel, preserving the original `x-ably-msg-id`. All clients on the channel - including the sender - receive this relay. The sending client recognises its own message by matching the `x-ably-msg-id` against the set of IDs it optimistically inserted. Instead of creating a duplicate, it updates the existing entry with the server-assigned serial, which moves the message from the end of the list to its correct position in serial order. This process is called [optimistic reconciliation](../internals/glossary.md#optimistic-reconciliation).
 
@@ -30,20 +30,20 @@ sequenceDiagram
 Optimistic updates are automatic - there is no opt-in or configuration. Every call to `send()`, `edit()`, or `regenerate()` that includes user messages uses the same mechanism.
 
 ```typescript
-const turn = await transport.send(userMessage);
+const view = transport.view;
+const turn = await view.send(userMessage);
 
 // The user message is already in the view - no waiting for the server
-const messages = transport.view.flattenNodes().map(n => n.message);
+const messages = view.flattenNodes().map(n => n.message);
 // messages includes userMessage at the end of the conversation
 ```
 
 In React, `useView()` re-renders immediately after `send()` because the optimistic insert triggers an `update` event on the view:
 
 ```typescript
-import { useView, useSend } from '@ably/ai-transport/react';
+import { useView } from '@ably/ai-transport/react';
 
-const { nodes } = useView(transport);
-const send = useSend(transport);
+const { nodes, send } = useView(transport);
 
 // After send(), messages updates instantly with the new user message
 await send([userMessage]);
@@ -69,7 +69,7 @@ When `send()` receives an array of messages, each gets its own `x-ably-msg-id` a
 
 ```typescript
 // Both messages appear immediately, chained in order
-const turn = await transport.send([questionOne, questionTwo]);
+const turn = await view.send([questionOne, questionTwo]);
 ```
 
 ## Edge cases

docs/features/streaming.md

@@ -6,7 +6,7 @@ Without a durable transport, streaming responses are ephemeral: if the connectio
 
 ## How it works
 
-The server encoder creates an Ably message for each content stream (text, reasoning, tool input) and appends token deltas as they arrive. The client decoder accumulates these appends into complete messages.
+The server encoder creates an Ably message for each content stream (text, reasoning) and appends token deltas as they arrive. The client decoder accumulates these appends into complete messages.
 
 ```mermaid
 sequenceDiagram
@@ -64,11 +64,12 @@ transport.close();
 On the client, every streaming event is accumulated into the conversation tree as it arrives. The view updates on every event, so the last assistant message grows token by token:
 
 ```typescript
-const turn = await transport.send(userMessage);
+const view = transport.view;
+const turn = await view.send(userMessage);
 
 // Subscribe to accumulated messages - updates on every token
-const unsubscribe = transport.view.on('update', () => {
-  const messages = transport.view.flattenNodes().map(n => n.message);
+const unsubscribe = view.on('update', () => {
+  const messages = view.flattenNodes().map(n => n.message);
   // the last assistant message grows as tokens arrive
 });
 ```
@@ -81,7 +82,7 @@ This is the primary consumption path. In React, the `useView()` hook handles the
 
 ```typescript
 // Framework adapter usage - most apps won't consume this directly
-const turn = await transport.send(userMessage);
+const turn = await view.send(userMessage);
 const reader = turn.stream.getReader();
 while (true) {
   const { done, value } = await reader.read();
@@ -106,11 +107,9 @@ The transport streams whatever events the codec produces. For the Vercel AI SDK
 |---|---|
 | `text-delta` | Message append |
 | `reasoning-delta` | Message append (separate stream) |
-| `tool-input-delta` | Message append (per tool call) |
-| `tool-output-available` | Discrete message |
 | `finish` | Discrete message (terminal - closes the stream) |
 | `error` | Discrete message (terminal - closes the stream with error) |
 
-Multiple content streams can be active within a single turn (e.g., reasoning + text, or multiple tool calls). Each gets its own message with its own stream ID.
+Multiple content streams can be active within a single turn (e.g., reasoning + text). Each gets its own message with its own stream ID.
 
 See [React hooks reference](../reference/react-hooks.md) for the full `useView` and `useClientTransport` API. See [Cancel](cancel.md) for how streams are aborted. For the internal mechanics of message encoding, decoding, and recovery, see the [Encoder](../internals/encoder.md), [Decoder](../internals/decoder.md), and [Wire protocol](../internals/wire-protocol.md) internals pages.