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

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();

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

@@ -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();

docs/frameworks/vercel-ai-sdk.md

@@ -47,32 +47,24 @@ Use the generic React hooks directly. You manage message state through the trans
 import {
   useClientTransport,
   useView,
-  useTree,
-  useSend,
-  useRegenerate,
-  useEdit,
   useActiveTurns,
 } from '@ably/ai-transport/react';
 import { UIMessageCodec } from '@ably/ai-transport/vercel';
 
 const transport = useClientTransport({ channel, codec: UIMessageCodec, clientId });
-const { nodes, hasOlder, loading, loadOlder } = useView(transport, { limit: 30 });
-const tree = useTree(transport);
-const send = useSend(transport);
-const regenerate = useRegenerate(transport);
-const edit = useEdit(transport);
+const { nodes, hasOlder, loading, loadOlder, send, regenerate, edit, select, getSelectedIndex, getSiblings, hasSiblings } = useView(transport, { limit: 30 });
 const activeTurns = useActiveTurns(transport);
 ```
 
-This path gives you conversation branching UI (sibling navigation), per-operation hooks, and direct access to the tree state.
+This path gives you conversation branching UI (sibling navigation), write operations, and direct access to the view state.
 
 ### When to use which
 
 | Use useChat when... | Use generic hooks when... |
 |---|---|
 | You want the simplest integration | You need conversation branching UI |
 | `useChat`'s message state management is sufficient | You need custom message construction |
-| You don't need edit or branch navigation | You need `edit()` or `tree.select()` |
+| You don't need edit or branch navigation | You need `edit()` or `view.select()` |
 | You're already using `useChat` and adding AI Transport | You're building a custom chat UI from scratch |
 
 ## Entry points