eve 0.34.0 → 0.35.0

package/docs/guides/deployment/overview.md

@@ -34,7 +34,7 @@ Keep credentials in your deployment environment or secret manager. Don’t inclu
 
 Your model configuration determines the required credential. A string model ID uses the [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) and requires Vercel project OpenID Connect (OIDC) or `AI_GATEWAY_API_KEY`. A provider-authored model uses that provider’s package and API key. See [Agent configuration](../../agent-config#set-the-model) for both forms.
 
-Configure production route authentication separately from model access. The default policy rejects browser traffic in production. See [Auth and route protection](../auth-and-route-protection) for the available policies and secret requirements.
+Configure production route authentication separately from model access. The default policy rejects browser traffic in production. See [Authentication](../auth-and-route-protection) for the available policies and secret requirements.
 
 ## Verify the deployment
 

package/docs/guides/deployment/self-hosting.md

@@ -1,5 +1,5 @@
 ---
-title: "Self-host eve"
+title: "Self-Host eve"
 description: "Run an eve agent as a Node service with your own workflow storage, sandbox backend, and routing."
 ---
 
@@ -22,7 +22,7 @@ Run this process under the same process manager or container platform you use fo
 
 Set `AI_GATEWAY_API_KEY` to use a string model ID through the Vercel AI Gateway from a non-Vercel host. To call a provider directly, install its [AI SDK provider package](https://ai-sdk.dev/docs/foundations/providers-and-models). Then pass its model object in `agent.ts` and set its API key. See [Agent configuration](../../agent-config#set-the-model) for examples.
 
-Don’t rely on `vercelOidc()` as the only production authenticator outside Vercel. Configure Basic auth, JSON Web Token (JWT) verification, generic OpenID Connect (OIDC), or a custom verifier that your host can validate. See [Auth and route protection](../auth-and-route-protection).
+Don’t rely on `vercelOidc()` as the only production authenticator outside Vercel. Configure Basic auth, JSON Web Token (JWT) verification, generic OpenID Connect (OIDC), or a custom verifier that your host can validate. See [Authentication](../auth-and-route-protection).
 
 ## Persist workflow state
 
@@ -83,6 +83,6 @@ eve dev https://your_agent.example.com
 
 Use these guides to secure and observe the deployed agent:
 
-- [Auth and route protection](../auth-and-route-protection): configure the host’s route policy
+- [Authentication](../auth-and-route-protection): configure the host’s route policy
 - [Observability](../instrumentation): export traces and diagnose runtime failures
 - [Sandbox](../../sandbox): select and secure a sandbox backend

package/docs/guides/deployment/vercel.mdx

@@ -85,6 +85,6 @@ The Agent Runs tab requires enablement for your Vercel team. Contact your Vercel
 
 Use these guides to secure and observe the deployed agent:
 
-- [Auth and route protection](../auth-and-route-protection): configure who can call the deployed agent
+- [Authentication](../auth-and-route-protection): configure who can call the deployed agent
 - [Observability](../instrumentation): export traces and diagnose runtime failures
 - [Sandbox](../../sandbox): configure resources, isolation, and network access

package/docs/guides/dev-tui.md

@@ -1,5 +1,5 @@
 ---
-title: "Dev TUI"
+title: "Terminal UI"
 description: "Use eve locally or connect to a deployed agent from an interactive terminal UI."
 ---
 
@@ -57,23 +57,13 @@ Use `/traces` to inspect traces recorded during local development. See [Instrume
 
 ## Display options
 
-Use `eve dev` flags to control how much detail the UI renders:
+Use `eve dev` flags to control tool calls, reasoning, subagents, connection authorization, response statistics, context usage, and logs:
 
 ```bash
 eve dev --tools full --reasoning collapsed --logs all
 ```
 
-| Flag                         | Values                                          | Description                                        |
-| ---------------------------- | ----------------------------------------------- | -------------------------------------------------- |
-| `--tools`                    | `full`, `collapsed`, `auto-collapsed`, `hidden` | Tool-call display.                                 |
-| `--reasoning`                | `full`, `collapsed`, `auto-collapsed`, `hidden` | Reasoning display.                                 |
-| `--subagents`                | `full`, `collapsed`, `auto-collapsed`, `hidden` | Subagent display.                                  |
-| `--connection-auth`          | `full`, `collapsed`, `auto-collapsed`, `hidden` | Connection-authorization display.                  |
-| `--assistant-response-stats` | `tokens`, `tokensPerSecond`                     | Assistant response statistic.                      |
-| `--context-size`             | Token count                                     | Model context-window size for the usage indicator. |
-| `--logs`                     | `all`, `stderr`, `sandbox`, `none`              | Initial log display mode.                          |
-
-Use `--host` and `--port` to bind the local server, or `--no-ui` to run without the terminal UI. See the [CLI reference](../reference/cli#eve-dev) for all options.
+Use `--host` and `--port` to bind the local server, or `--no-ui` to run without the terminal UI. See the [`eve dev` CLI reference](../reference/cli#eve-dev) for the complete option list, accepted values, and defaults.
 
 ## Connect to a deployment
 

package/docs/guides/dynamic-capabilities.md

@@ -212,7 +212,7 @@ Skills follow the same naming rule as tools: a single `defineSkill(...)` is name
 
 ## Dynamic instructions
 
-A dynamic instructions file resolves the per-session system prompt the same way, returning `defineInstructions(...)` built from the principal, tenant, or external data:
+A dynamic instructions file returns `defineInstructions({ content, role? })` built from the principal, tenant, channel, or external data. Omit `role` for system context:
 
 ```ts title="agent/instructions/persona.ts"
 import { defineDynamic, defineInstructions } from "eve/instructions";
@@ -222,14 +222,36 @@ export default defineDynamic({
     "session.started": (_event, ctx) => {
       const plan = ctx.session.auth.current?.attributes.plan ?? "free";
       return defineInstructions({
-        markdown: `The caller is on the ${plan} plan. Match the depth of your answers to it.`,
+        content: `The caller is on the ${plan} plan. Match the depth of your answers to it.`,
       });
     },
   },
 });
 ```
 
-Both resolve before the prompt is assembled, so the model sees the right instructions and skill set for whoever is calling, without that context reaching anyone else.
+Use `role: "user"` when the resolved value is application or user context that should become part of durable history:
+
+```ts title="agent/instructions/brief.ts"
+import { defineDynamic, defineInstructions } from "eve/instructions";
+import { loadBrief } from "../lib/briefs";
+
+export default defineDynamic({
+  events: {
+    "turn.started": async (_event, ctx) => {
+      const brief = await loadBrief(ctx.session.auth.current);
+      return brief ? defineInstructions({ content: brief, role: "user" }) : null;
+    },
+  },
+});
+```
+
+Instruction resolvers support `session.started` and `turn.started` only. A system result lives in that scope and stays outside history. A user result is appended to history at the lifecycle boundary, with session results before turn results and both before the current delivery. There is no automatic deduplication: returning the same user content on a later turn intentionally appends another message.
+
+Resolver snapshots reflect that order. At `session.started`, `ctx.messages` includes static user-role instructions. At `turn.started`, it also includes user-role results from `session.started`. These augmented snapshots are specific to instruction resolvers; tools, skills, models, and subagents keep their existing message snapshots.
+
+Returning `null` or blank content contributes nothing. A throwing or invalid session resolver leaves any wider valid system selection in place. Every turn starts with fresh turn-scoped system instructions, so a failed or empty turn result cannot leak the previous turn's value. Completed lifecycle steps are replay-safe: parking, resuming, or replaying them does not duplicate user-role messages.
+
+Dynamic system content that changes frequently can reduce provider prompt-cache reuse. Prefer session scope for stable values and use turn scope only when the context must be refreshed. Cache behavior remains provider-specific.
 
 ## What to read next
 
@@ -237,4 +259,4 @@ Both resolve before the prompt is assembled, so the model sees the right instruc
 - The static tool basics this builds on → [Tools](../tools)
 - The built-in tools and how to override them → [Default harness](../concepts/default-harness)
 - Authenticate a tool or connection to an external service → [Auth & route protection](./auth-and-route-protection)
-- Durable per-session memory for resolvers to read → [State](./state)
+- Durable per-session memory for resolvers to read → [State](../concepts/state)

package/docs/guides/frontend/meta.json

@@ -1,4 +1,5 @@
 {
-  "title": "Frontend",
+  "title": "Frontend Frameworks",
+  "defaultOpen": false,
   "pages": ["overview", "nextjs", "nuxt", "sveltekit", "use-eve-agent-vue", "use-eve-agent-svelte"]
 }

package/docs/guides/frontend/nextjs.mdx

@@ -88,16 +88,7 @@ const agent = useEveAgent({
 });
 ```
 
-The default eve channel is fail-closed. With no `agent/channels/eve.ts` authored, eve registers `eveChannel({ auth: [vercelOidc(), localDev(), placeholderAuth()] })`: `vercelOidc()` gets the first chance to resolve a Vercel caller, `localDev()` authenticates while the process is an `eve dev` or `vercel dev` server, and everything else gets a `401`. To run your app's own auth policy, add `agent/channels/eve.ts`:
-
-```ts title="agent/channels/eve.ts"
-import { eveChannel } from "eve/channels/eve";
-import { localDev, vercelOidc } from "eve/channels/auth";
-
-export default eveChannel({ auth: [vercelOidc(), localDev()] });
-```
-
-For a public demo, use `none()` (also from `eve/channels/auth`) to skip authentication. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
+The browser still needs a production authentication policy. See [Authenticate browser requests](./overview#authenticate-browser-requests) for the default fail-closed behavior and channel configuration.
 
 ## Dev vs deploy topology
 

package/docs/guides/frontend/nuxt.mdx

@@ -60,16 +60,7 @@ async function handleSubmit() {
 </template>
 ```
 
-The default eve channel is fail-closed. With no `agent/channels/eve.ts` authored, eve registers `eveChannel({ auth: [vercelOidc(), localDev(), placeholderAuth()] })`: `vercelOidc()` gets the first chance to resolve a Vercel caller, `localDev()` authenticates while the process is an `eve dev` or `vercel dev` server, and everything else gets a `401`. To run your own auth policy, add `agent/channels/eve.ts`:
-
-```ts title="agent/channels/eve.ts"
-import { eveChannel } from "eve/channels/eve";
-import { localDev, vercelOidc } from "eve/channels/auth";
-
-export default eveChannel({ auth: [vercelOidc(), localDev()] });
-```
-
-For a public demo, use `none()` (also from `eve/channels/auth`) to skip authentication. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
+The browser still needs a production authentication policy. See [Authenticate browser requests](./overview#authenticate-browser-requests) for the default fail-closed behavior and channel configuration.
 
 ## Dev vs deploy topology
 

package/docs/guides/frontend/overview.mdx

@@ -14,7 +14,15 @@ A browser UI is a client of the agent's HTTP routes (the [eve channel](../../cha
 
 The per-framework pages below walk through the wiring step by step: [Next.js](./nextjs), [Nuxt](./nuxt), and [SvelteKit](./sveltekit).
 
-For scripts, server-to-server calls, evals, tests, or custom clients that do not need framework UI state, use the [TypeScript SDK](../client/overview) directly.
+For scripts, server-to-server calls, evals, tests, or custom clients that do not need framework UI state, use the [Client SDK](../client/overview) directly.
+
+## Authenticate browser requests
+
+A same-origin framework integration sends your application cookies with every eve request. For bearer tokens or another non-cookie scheme, pass `auth` or `headers` to `useEveAgent`.
+
+The default eve channel fails closed. Without an authored `agent/channels/eve.ts`, production browser traffic receives `401` from the default `[vercelOidc(), localDev(), placeholderAuth()]` policy. Add the channel file with an `AuthFn` that verifies your application session or token.
+
+For a public demo, use `none()` from `eve/channels/auth` to admit anonymous requests explicitly. Do not use `none()` for an agent that handles private or production data. See [Authentication](../auth-and-route-protection) for application-session examples, token verifiers, and the default policy.
 
 ## Basic chat (React)
 
@@ -204,11 +212,12 @@ const agent = useEveAgent({
 
 ## Lifecycle callbacks
 
-On top of `onSessionChange`, the hook takes a few per-turn callbacks:
+The hook accepts these lifecycle callbacks:
 
 - `onEvent(event)`: fires for each eve stream event as it arrives.
 - `onError(error)`: fires with the last `Error` when a turn fails.
 - `onFinish(snapshot)`: fires with the final `{ data, status, session, ... }` snapshot once a turn settles.
+- `onSessionChange(session)`: fires when the session cursor advances. Persist it to resume across reloads.
 
 ```tsx
 const agent = useEveAgent({
@@ -320,5 +329,5 @@ const support = useEveAgent({ agent: "support" });
 
 - [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming): the event stream and session cursor
 - [Channels](../../channels/overview): the HTTP routes the hook talks to
-- [TypeScript SDK](../client/overview): the lower-level client underneath the frontend hooks
+- [Client SDK](../client/overview): the lower-level client underneath the frontend hooks
 - [Next.js](./nextjs): step-by-step setup for wiring eve into a Next.js app

package/docs/guides/frontend/sveltekit.mdx

@@ -69,16 +69,7 @@ With the plugin in `vite.config.ts`, components call [`useEveAgent`](./use-eve-a
 </form>
 ```
 
-The default eve channel is fail-closed. With no `agent/channels/eve.ts` authored, eve registers `eveChannel({ auth: [vercelOidc(), localDev(), placeholderAuth()] })`: `vercelOidc()` gets the first chance to resolve a Vercel caller, `localDev()` authenticates while the process is an `eve dev` or `vercel dev` server, and everything else gets a `401`. To set your own auth policy, add `agent/channels/eve.ts`:
-
-```ts title="agent/channels/eve.ts"
-import { eveChannel } from "eve/channels/eve";
-import { localDev, vercelOidc } from "eve/channels/auth";
-
-export default eveChannel({ auth: [vercelOidc(), localDev()] });
-```
-
-For a public demo, use `none()` (also from `eve/channels/auth`) to skip authentication. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
+The browser still needs a production authentication policy. See [Authenticate browser requests](./overview#authenticate-browser-requests) for the default fail-closed behavior and channel configuration.
 
 ## Dev vs deploy topology
 

package/docs/guides/frontend/use-eve-agent-svelte.mdx

@@ -1,43 +1,15 @@
 ---
 title: "useEveAgent (Svelte)"
-description: "Svelte 5 binding that drives an eve agent session from the browser."
+description: "Use the eve Svelte binding and its Svelte-specific reactive interface."
 ---
 
-`useEveAgent()` from `eve/svelte` is the browser side of an eve session in a Svelte 5 app. Call it once for a long-lived session you can send turns to, with every stream event projected into rune-friendly reactive data. On SvelteKit, the [Vite plugin](./sveltekit) wires up the routes. The [frontend overview](./overview) covers the model shared across frameworks.
+`useEveAgent()` from `eve/svelte` exposes the shared eve frontend client through Svelte 5 reactive getters and methods. Read the [frontend overview](./overview) for session behavior, messages, human input, authorization, callbacks, reducers, and persistence. This page covers the Svelte-specific interface.
 
-## Basic usage
-
-Import from `eve/svelte` and read the reactive getters directly. No `$` prefix:
-
-```svelte
-<script lang="ts">
-  import { useEveAgent } from "eve/svelte";
-
-  const agent = useEveAgent();
-</script>
-
-{#each agent.data.messages as message}
-  <p>{message.role}: {JSON.stringify(message.parts)}</p>
-{/each}
-```
-
-## What it returns
+On SvelteKit, register the [`eveSvelteKit` Vite plugin](./sveltekit) to mount the agent routes on the application origin.
 
-| Property  | Type                                          | Description                                                               |
-| --------- | --------------------------------------------- | ------------------------------------------------------------------------- |
-| `data`    | `TData`                                       | Projected state. With the default reducer, `EveMessageData` (`messages`). |
-| `status`  | `UseEveAgentStatus`                           | `"ready"`, `"submitted"`, `"streaming"`, or `"error"`.                    |
-| `error`   | `Error \| undefined`                          | Last transport-level error.                                               |
-| `events`  | `readonly MessageStreamEvent[]`               | Raw server events for this session.                                       |
-| `session` | `ClientSessionState \| undefined`             | Fixed session ID and stream cursor.                                       |
-| `send`    | `(message, options?) => Promise<void>`        | Send text or a multi-part message.                                        |
-| `respond` | `(inputResponses, options?) => Promise<void>` | Answer pending HITL input requests.                                       |
-| `stop`    | `() => void`                                  | Abort the client's in-flight stream.                                      |
-| `reset`   | `() => void`                                  | Clear state and start a new session.                                      |
-
-These state fields are reactive getters, so read them straight from templates, `$derived`, or `$effect`. They are not stores, so don't prefix them with `$`.
+## Basic usage
 
-## Send a message
+Call the binding once for a conversation and read its reactive getters directly. The returned object is not a Svelte store, so its fields do not use the `$` prefix:
 
 ```svelte
 <script lang="ts">
@@ -45,39 +17,51 @@ These state fields are reactive getters, so read them straight from templates, `
 
   const agent = useEveAgent();
   let message = $state("");
+  let isBusy = $derived(agent.status === "submitted" || agent.status === "streaming");
 
   async function handleSubmit() {
     const text = message.trim();
-    if (!text) return;
+    if (!text || isBusy) return;
     message = "";
     await agent.send(text);
   }
 </script>
 
+{#each agent.data.messages as item}
+  <p>{item.role}: {JSON.stringify(item.parts)}</p>
+{/each}
+
 <form onsubmit={(event) => {
   event.preventDefault();
   void handleSubmit();
 }}>
-  <input bind:value={message} placeholder="Type a message..." />
-  <button type="submit">Send</button>
+  <input bind:value={message} disabled={isBusy} />
+  <button type="submit" disabled={isBusy}>Send</button>
 </form>
 ```
 
-When a turn is more than plain text, reach for `send()`. Attachments follow the AI SDK `UserContent` format. Send file data as a base64 `data:` URL so it survives the JSON transport:
+## What it returns
 
-```ts
-const bytes = new Uint8Array(await file.arrayBuffer());
-const base64 = btoa(String.fromCodePoint(...bytes));
+The state fields are reactive getters; the commands are ordinary methods:
 
-await agent.send([
-  { type: "text", text: "Describe this image." },
-  { type: "file", data: `data:${file.type};base64,${base64}`, mediaType: file.type },
-]);
-```
+| Property                           | Svelte shape                      |
+| ---------------------------------- | --------------------------------- |
+| `data`                             | `TData`                           |
+| `status`                           | `UseEveAgentStatus`               |
+| `error`                            | `Error \| undefined`              |
+| `events`                           | `readonly MessageStreamEvent[]`   |
+| `session`                          | `ClientSessionState \| undefined` |
+| `send`, `respond`, `stop`, `reset` | Methods                           |
+
+Read the getters directly in templates, `$derived`, or `$effect`. The [shared returned-state reference](./overview#returned-state) describes what each value and command does.
+
+## Send a message
+
+Call `agent.send(text)` for text or pass content parts for attachments. The API and transport behavior match the [shared sending guide](./overview#sending-and-streaming); only reactive access differs in Svelte.
 
 ## Human-in-the-loop prompts
 
-A tool opts into approval with `approval` ([Tools](../../tools)). When one fires, the pending request rides along on a `dynamic-tool` part at `part.toolMetadata?.eve?.inputRequest`. Scan every message because an unrelated turn can add newer messages while the approval stays open, then answer through the same session with `agent.respond(inputResponses)`:
+Pending requests appear in `agent.data.messages`. Use the Svelte exports when narrowing message parts, then answer through `agent.respond()`:
 
 ```svelte
 <script lang="ts">
@@ -118,101 +102,30 @@ A tool opts into approval with `approval` ([Tools](../../tools)). When one fires
 {/each}
 ```
 
-For a question with `allowFreeform`, bind a text input and send `{ requestId, text }`. The [React hook reference](./overview) covers the shared behavior.
+See [Human-in-the-loop prompts](./overview#human-in-the-loop-prompts) for request semantics and rendering guidance.
 
 ## Stop, reset, and resume
 
-`stop()` aborts the in-flight stream; the server-side turn keeps running and remains attachable — to stop the turn itself, POST the session's [cancel route](../../channels/eve#routes). `reset()` wipes state and starts a fresh session. To resume across reloads, hand `initialSession` the state you saved earlier and use `onSessionChange` to persist the cursor as it advances:
-
-```ts
-const agent = useEveAgent({
-  initialSession: savedSessionState,
-  initialEvents: savedEvents,
-  onSessionChange: (session) => {
-    localStorage.setItem("eve-session", JSON.stringify(session));
-  },
-});
-```
+Call `agent.stop()` to detach the browser stream without cancelling server-side work, and `agent.reset()` to clear local state and start a new session. Pass `initialSession` and `initialEvents` to restore a saved conversation. See [Resumable sessions](./overview#resumable-sessions) for the persistence contract and [Sending and streaming](./overview#sending-and-streaming) for cancellation behavior.
 
 ## Custom host and credentials
 
-Point `host` at an eve server on a different origin, and pass credentials through `auth` or `headers`. When you supply a function, it re-resolves before every request:
-
-```ts
-const agent = useEveAgent({
-  host: "https://agent.example.com",
-  headers: async () => ({
-    authorization: `Bearer ${await getAccessToken()}`,
-  }),
-});
-```
+Pass `host`, `auth`, or `headers` to the binding using the same options as the other frontend bindings. See [Custom hosts and headers](./overview#custom-hosts-and-headers).
 
 ## Attach page context per turn
 
-`clientContext` adds ephemeral context for the next model call and nothing more. Strings (or an array of strings) become user-role context messages; an object is JSON-serialized into one. It rides along with a message or HITL response, never dispatches a turn on its own, and never lands in durable session history. Pass it to `send()`:
-
-```ts
-await agent.send("What should I do on this screen?", {
-  clientContext: { route: "/billing", plan: "pro", seatsUsed: 4 },
-});
-```
-
-To attach the same context to every turn without threading it through each call site, pass `prepareSend`. It runs right before each send and returns the (possibly augmented) turn:
-
-```ts
-const agent = useEveAgent({
-  prepareSend: (input) => ({
-    ...input,
-    clientContext: { route: location.pathname },
-  }),
-});
-```
+Pass `clientContext` to `send()` or `respond()`, or use `prepareSend` to add context before every turn. See [Attach page context per turn](./overview#attach-page-context-per-turn).
 
 ## Lifecycle callbacks
 
-The binding takes a few per-turn callbacks:
-
-- `onEvent(event)`: fires for each eve stream event as it arrives.
-- `onError(error)`: fires with the last `Error` when a turn fails.
-- `onFinish(snapshot)`: fires with the final snapshot once a turn settles.
-- `onSessionChange(session)`: fires when the session cursor advances. Persist it to resume across reloads.
-
-```ts
-const agent = useEveAgent({
-  onEvent: (event) => console.debug(event.type),
-  onError: (error) => console.error(error.message),
-  onFinish: (snapshot) => console.log(snapshot.status),
-});
-```
-
-The `optimistic` option (default `true`) projects submitted user messages into `data` before eve confirms them with a `message.received` event. These are reducer-facing projection events only; `events` stays the authoritative eve stream.
+Pass `onEvent`, `onError`, `onFinish`, or `onSessionChange` when the application needs lifecycle notifications. See [Lifecycle callbacks](./overview#lifecycle-callbacks) for callback timing and optimistic projection behavior.
 
 ## Custom reducer
 
-The default reducer projects events into `{ messages }` (`EveMessageData`). To shape `data` differently, pass a `reducer` implementing `EveAgentReducer<TData>`:
-
-```ts
-import { useEveAgent } from "eve/svelte";
-import type { EveAgentReducer } from "eve/svelte";
-
-interface ToolLog {
-  readonly toolCalls: number;
-}
-
-const toolCounter: EveAgentReducer<ToolLog> = {
-  initial: () => ({ toolCalls: 0 }),
-  reduce: (data, event) =>
-    event.type === "actions.requested" ? { toolCalls: data.toolCalls + 1 } : data,
-};
-
-const agent = useEveAgent({ reducer: toolCounter });
-// agent.data is ToolLog
-```
-
-`reduce(data, event)` receives both authoritative eve stream events and client projection events (`client.message.submitted`, `client.message.failed`, `client.input.responded`). Handle the client events too if you want optimistic and HITL state in your projection. Otherwise, return `data` unchanged for them.
+Import `EveAgentReducer` from `eve/svelte` when projecting events into application-specific state. The resulting `agent.data` uses the reducer's `TData` type. See [Custom reducer](./overview#custom-reducer) for the reducer contract and client projection events.
 
 ## What to read next
 
-- [SvelteKit](./sveltekit): Vite plugin setup
-- [Frontend overview](./overview): the shared integration model
-- [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming)
+- [SvelteKit](./sveltekit): register the Vite plugin and mount the eve runtime.
+- [Frontend overview](./overview): use the shared frontend API.
+- [Sessions, runs, and streaming](../../concepts/sessions-runs-and-streaming): understand the underlying session protocol.