eve 0.11.1 → 0.11.3

package/docs/guides/frontend/overview.mdx

@@ -1,16 +1,16 @@
 ---
 title: "Overview"
-description: "Put an Eve agent behind a browser chat UI with useEveAgent."
+description: "Put an eve agent behind a browser chat UI with useEveAgent."
 ---
 
-The frontend helpers put a browser chat or agent UI on top of an Eve agent. `useEveAgent()` opens a durable session, sends turns, streams the reply back, and turns the raw event stream into render-ready state. React is the reference implementation; [Vue](./use-eve-agent-vue) and [Svelte](./use-eve-agent-svelte) ship the same surface.
+The frontend helpers put a browser chat or agent UI on top of an eve agent. `useEveAgent()` opens a durable session, sends turns, streams the reply back, and turns the raw event stream into render-ready state. React is the reference implementation; [Vue](./use-eve-agent-vue) and [Svelte](./use-eve-agent-svelte) ship the same surface.
 
 ## The integration model
 
-A browser UI is a client of the agent's HTTP routes (the [Eve channel](../../channels/overview)). Two layers wire it up:
+A browser UI is a client of the agent's HTTP routes (the [eve channel](../../channels/overview)). Two layers wire it up:
 
-- **The framework integration** mounts the Eve routes on your app's origin, so the browser never crosses a CORS boundary or reads an env var to find the agent. Pick yours: [Next.js](./nextjs) (`withEve`), [Nuxt](./nuxt) (the `eve/nuxt` module), or [SvelteKit](./sveltekit) (the `eveSvelteKit` Vite plugin). On any other stack the hook talks to same-origin `/eve/v1/*` routes directly, or you pass an explicit `host`.
-- **The hook** (`useEveAgent`) holds the session state, streaming, errors, and composer status. It defaults to same-origin Eve routes such as `/eve/v1/session`.
+- **The framework integration** mounts the eve routes on your app's origin, so the browser never crosses a CORS boundary or reads an env var to find the agent. Pick yours: [Next.js](./nextjs) (`withEve`), [Nuxt](./nuxt) (the `eve/nuxt` module), or [SvelteKit](./sveltekit) (the `eveSvelteKit` Vite plugin). On any other stack the hook talks to same-origin `/eve/v1/*` routes directly, or you pass an explicit `host`.
+- **The hook** (`useEveAgent`) holds the session state, streaming, errors, and composer status. It defaults to same-origin eve routes such as `/eve/v1/session`.
 
 The per-framework pages below walk through the wiring step by step: [Next.js](./nextjs), [Nuxt](./nuxt), and [SvelteKit](./sveltekit).
 
@@ -66,7 +66,7 @@ export function Chat() {
 | `data`    | Projected UI state from the reducer. Defaults to `{ messages }`.               |
 | `status`  | `"ready"`, `"submitted"`, `"streaming"`, or `"error"`. Drives the composer.    |
 | `error`   | The last `Error` thrown, if any.                                               |
-| `events`  | Raw Eve stream events for this session.                                        |
+| `events`  | Raw eve stream events for this session.                                        |
 | `session` | Serializable session cursor (`sessionId`, `continuationToken`, `streamIndex`). |
 | `send`    | Send text or the full turn payload (multi-part messages, HITL responses).      |
 | `stop`    | Abort the active request.                                                      |
@@ -100,7 +100,7 @@ Assistant text, reasoning, tool calls, and tool results stream into `data` as th
 
 ## Human-in-the-loop prompts
 
-Tools opt into approval with `needsApproval` on the [server side](../../tools), and the model can also ask a question with `ask_question`. Either way the stream emits an `input.requested` event, and the pending request rides on a `dynamic-tool` part of the latest message at `part.toolMetadata?.eve?.inputRequest`. Read it, then answer through the same session with `send()`:
+Tools opt into approval with `needsApproval`, and the model can also ask a question with `ask_question` — see [Human-in-the-loop](../../tools/human-in-the-loop) for the server-side model. Either way the stream emits an `input.requested` event, and the pending request rides on a `dynamic-tool` part of the latest message at `part.toolMetadata?.eve?.inputRequest`. Read it, then answer through the same session with `send()`:
 
 ```tsx
 const request = agent.data.messages
@@ -115,7 +115,7 @@ if (request) {
 }
 ```
 
-`request.prompt` and `request.options` give you what you need to render the approve and deny UI. The default reducer marks the part as responded immediately, then updates it again once Eve streams the resumed result.
+`request.prompt` and `request.options` give you what you need to render the approve and deny UI. The default reducer marks the part as responded immediately, then updates it again once eve streams the resumed result.
 
 ## Attach page context per turn
 
@@ -143,7 +143,7 @@ const agent = useEveAgent({
 
 On top of `onSessionChange`, the hook takes a few per-turn callbacks:
 
-- `onEvent(event)`: fires for each Eve stream event as it arrives.
+- `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.
 
@@ -157,7 +157,7 @@ const agent = useEveAgent({
 
 Two more options tune turn behavior:
 
-- `optimistic` (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.
+- `optimistic` (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.
 - `maxReconnectAttempts` (default `3`): stream reconnection budget per turn.
 
 ## Custom reducer
@@ -182,7 +182,7 @@ 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.
+`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.
 
 ## Resumable sessions
 
@@ -206,7 +206,7 @@ Store the full `session` object (`sessionId`, `continuationToken`, `streamIndex`
 
 ## Custom hosts and headers
 
-Pass `host` when the Eve server isn't same-origin, and pass `auth` or `headers` when the channel needs credentials. Function values are re-resolved before every HTTP request, reconnects included:
+Pass `host` when the eve server isn't same-origin, and pass `auth` or `headers` when the channel needs credentials. Function values are re-resolved before every HTTP request, reconnects included:
 
 ```tsx
 const agent = useEveAgent({
@@ -231,4 +231,4 @@ const agent = useEveAgent({
 - [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
-- [Next.js](./nextjs): step-by-step setup for wiring Eve into a Next.js app
+- [Next.js](./nextjs): step-by-step setup for wiring eve into a Next.js app

package/docs/guides/frontend/sveltekit.mdx

@@ -1,14 +1,14 @@
 ---
 title: "SvelteKit"
-description: "Run an Eve agent and a SvelteKit app as one project with the eveSvelteKit Vite plugin."
+description: "Run an eve agent and a SvelteKit app as one project with the eveSvelteKit Vite plugin."
 ---
 
-`eve/sveltekit` runs a SvelteKit frontend and an Eve agent as one project instead of two services. The `eveSvelteKit()` Vite plugin puts both on one dev server and one Vercel deploy, and [`useEveAgent`](./use-eve-agent-svelte) finds the mounted routes on its own. There's no CORS to configure and no URL env vars to keep in sync.
+`eve/sveltekit` runs a SvelteKit frontend and an eve agent as one project instead of two services. The `eveSvelteKit()` Vite plugin puts both on one dev server and one Vercel deploy, and [`useEveAgent`](./use-eve-agent-svelte) finds the mounted routes on its own. There's no CORS to configure and no URL env vars to keep in sync.
 
 ## Prerequisites
 
 - The `eve` package installed in your project (`npm install eve@latest`).
-- An existing Eve agent directory. If you don't have one, start from [Getting started](../../getting-started).
+- An existing eve agent directory. If you don't have one, start from [Getting started](../../getting-started).
 - A SvelteKit app to mount the agent in.
 
 ## Register the Vite plugin
@@ -69,7 +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: [localDev(), vercelOidc()] })`: `localDev()` opens the routes on localhost, `vercelOidc()` admits Vercel OIDC callers in production, and everything else gets a `401`. To set your own auth policy, add `agent/channels/eve.ts`:
+The default eve channel is fail-closed. With no `agent/channels/eve.ts` authored, eve registers `eveChannel({ auth: [localDev(), vercelOidc()] })`: `localDev()` opens the routes on localhost, `vercelOidc()` admits Vercel OIDC callers in production, 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";
@@ -82,8 +82,8 @@ For a public demo, use `none()` (also from `eve/channels/auth`) to skip authenti
 
 ## Dev vs deploy topology
 
-- **Local dev.** `npm run dev` boots the Eve dev server next to SvelteKit and proxies the Eve routes to it, so the browser only ever hits the SvelteKit origin. `npm run build && npm run preview` behaves the same way: the preview server gets its own Eve route proxy and either reuses the shared Eve server or starts one.
-- **Vercel.** The SvelteKit app and the Eve runtime deploy as a single project. The web app is public; the Eve runtime sits behind it on the same origin. Use `eveBuildCommand` for a project-specific agent build:
+- **Local dev.** `npm run dev` boots the eve dev server next to SvelteKit and proxies the eve routes to it, so the browser only ever hits the SvelteKit origin. `npm run build && npm run preview` behaves the same way: the preview server gets its own eve route proxy and either reuses the shared eve server or starts one.
+- **Vercel.** The SvelteKit app and the eve runtime deploy as a single project. The web app is public; the eve runtime sits behind it on the same origin. Use `eveBuildCommand` for a project-specific agent build:
 
   ```ts
   export default defineConfig({
@@ -96,7 +96,7 @@ For a public demo, use `none()` (also from `eve/channels/auth`) to skip authenti
   });
   ```
 
-- **Non-Vercel hosts.** When the Eve service runs on a separate origin, pass `host` directly to `useEveAgent`:
+- **Non-Vercel hosts.** When the eve service runs on a separate origin, pass `host` directly to `useEveAgent`:
 
   ```ts
   const agent = useEveAgent({

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

@@ -1,9 +1,9 @@
 ---
 title: "useEveAgent (Svelte)"
-description: "Svelte 5 binding that drives an Eve agent session from the browser."
+description: "Svelte 5 binding that drives an eve agent session from the browser."
 ---
 
-`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` 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.
 
 ## Basic usage
 
@@ -117,7 +117,7 @@ const agent = useEveAgent({
 
 ## 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:
+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({
@@ -154,7 +154,7 @@ const agent = useEveAgent({
 
 The binding takes a few per-turn callbacks:
 
-- `onEvent(event)`: fires for each Eve stream event as it arrives.
+- `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.
@@ -169,7 +169,7 @@ const agent = useEveAgent({
 
 Two more options tune turn behavior:
 
-- `optimistic` (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.
+- `optimistic` (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.
 - `maxReconnectAttempts` (default `3`): stream reconnection budget per turn.
 
 ## Custom reducer
@@ -194,7 +194,7 @@ 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.
+`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.
 
 ## What to read next
 

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

@@ -1,9 +1,9 @@
 ---
 title: "useEveAgent (Vue)"
-description: "Vue composable that drives an Eve agent session from the browser."
+description: "Vue composable that drives an eve agent session from the browser."
 ---
 
-`useEveAgent()` from `eve/vue` is how a Vue app talks to an Eve session. It opens a long-lived session, sends turns, and folds every stream event into reactive data you can bind in a template. Nuxt auto-imports it through the [module](./nuxt), and the [frontend overview](./overview) covers the shared model.
+`useEveAgent()` from `eve/vue` is how a Vue app talks to an eve session. It opens a long-lived session, sends turns, and folds every stream event into reactive data you can bind in a template. Nuxt auto-imports it through the [module](./nuxt), and the [frontend overview](./overview) covers the shared model.
 
 ## Basic usage
 
@@ -130,7 +130,7 @@ const agent = useEveAgent({
 
 ## Custom host and credentials
 
-When your Eve server lives somewhere other than the same origin, point at it with `host` and attach credentials through `auth` or `headers`. Pass a function and it re-resolves before each request:
+When your eve server lives somewhere other than the same origin, point at it with `host` and attach credentials through `auth` or `headers`. Pass a function and it re-resolves before each request:
 
 ```ts
 const agent = useEveAgent({
@@ -167,7 +167,7 @@ const agent = useEveAgent({
 
 The composable takes a few per-turn callbacks:
 
-- `onEvent(event)`: fires for each Eve stream event as it arrives.
+- `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.
@@ -182,7 +182,7 @@ const agent = useEveAgent({
 
 Two more options tune turn behavior:
 
-- `optimistic` (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.
+- `optimistic` (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.
 - `maxReconnectAttempts` (default `3`): stream reconnection budget per turn.
 
 ## Custom reducer
@@ -207,7 +207,7 @@ const agent = useEveAgent({ reducer: toolCounter });
 // agent.data.value 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.
+`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.
 
 ## What to read next
 

package/docs/guides/hooks.md

@@ -3,7 +3,7 @@ title: "Hooks"
 description: "Subscribe to runtime stream events from agent/hooks/."
 ---
 
-Hooks are Eve's authored extension points for the runtime event stream. A hook subscribes to stream events and runs side effects after each event is durably recorded, such as audit logging, metrics and alerting, or persisting every session and message to your own database for analytics. Reach for one to observe what the agent does without writing a tool, a context provider (a value made available across a step), or a channel adapter handler (a handler defined on a channel's adapter; see [Channels](../channels)).
+Hooks are eve's authored extension points for the runtime event stream. A hook subscribes to stream events and runs side effects after each event is durably recorded, such as audit logging, metrics and alerting, or persisting every session and message to your own database for analytics. Reach for one to observe what the agent does without writing a tool, a context provider (a value made available across a step), or a channel adapter handler (a handler defined on a channel's adapter; see [Channels](../channels)).
 
 ## Define a hook
 
@@ -83,7 +83,7 @@ Hooks always run after the event is durably recorded, so if a hook throws, the s
 
 ## What happens when a hook throws
 
-A thrown handler propagates through the emit composer and surfaces as `turn.failed`. If a hook subscribed to a failure-cascade event also throws, it escalates to `session.failed`. For belt-and-suspenders semantics inside a hook, wrap the body in `try`/`catch`. Eve treats a thrown hook as a real failure.
+A thrown handler propagates through the emit composer and surfaces as `turn.failed`. If a hook subscribed to a failure-cascade event also throws, it escalates to `session.failed`. For belt-and-suspenders semantics inside a hook, wrap the body in `try`/`catch`. eve treats a thrown hook as a real failure.
 
 ## Subagent isolation
 

package/docs/guides/instrumentation.md

@@ -1,15 +1,15 @@
 ---
 title: "instrumentation.ts"
-description: "Trace an agent with OpenTelemetry in instrumentation.ts, read the workflow run tags Eve emits, and debug discovery with eve info and the common-failures table."
+description: "Trace an agent with OpenTelemetry in instrumentation.ts, read the workflow run tags eve emits, and debug discovery with eve info and the common-failures table."
 ---
 
-`instrumentation.ts` is where you configure how an Eve agent is observed. The framework auto-discovers `agent/instrumentation.ts` and runs it at server startup before any agent code. Its presence implicitly enables telemetry, so there is no separate `isEnabled` toggle.
+`instrumentation.ts` is where you configure how an eve agent is observed. The framework auto-discovers `agent/instrumentation.ts` and runs it at server startup before any agent code. Its presence implicitly enables telemetry, so there is no separate `isEnabled` toggle.
 
 If you intend to export telemetry, review the exporter destination, data categories, and required legal approvals before enabling telemetry.
 
 ## Three observability surfaces
 
-Eve observes an agent through three distinct surfaces. They do not all live in this file, and they write to different places:
+eve observes an agent through three distinct surfaces. They do not all live in this file, and they write to different places:
 
 | Surface                          | Configured in `instrumentation.ts`?                         | What it is                                                                                                                                                    |
 | -------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -17,7 +17,7 @@ Eve observes an agent through three distinct surfaces. They do not all live in t
 | **OpenTelemetry export**         | Yes: `setup`, `recordInputs`, `recordOutputs`, `functionId` | Where AI SDK spans are exported and what they record.                                                                                                         |
 | **Runtime context events**       | Yes: `events["step.started"]`                               | Per-model-call values written into the AI SDK's runtime context, which the AI SDK carries onto its spans.                                                     |
 
-The two configurable surfaces send AI SDK spans to your OpenTelemetry backend. Workflow run tags are a separate system, queryable in the Workflow dashboard rather than on your OTel spans. The sections below cover what you configure here; [Workflow run tags](#workflow-run-tags) documents what Eve emits on its own.
+The two configurable surfaces send AI SDK spans to your OpenTelemetry backend. Workflow run tags are a separate system, queryable in the Workflow dashboard rather than on your OTel spans. The sections below cover what you configure here; [Workflow run tags](#workflow-run-tags) documents what eve emits on its own.
 
 ## Define instrumentation
 
@@ -60,7 +60,7 @@ The third configurable surface, [runtime context events](#runtime-context), atta
 
 ## Runtime context
 
-_Runtime context_ is an [AI SDK concept](https://ai-sdk.dev/docs/reference/ai-sdk-core/stream-text): a user-defined object that flows through a generation lifecycle. Eve exposes it through `events["step.started"]`, a callback that runs once Eve has assembled the model input for an attempt and returns `{ runtimeContext }`. Because Eve registers the AI SDK's OpenTelemetry integration with runtime context enabled, those returned values ride onto the model-call span and its children. The field is named `runtimeContext`, not `metadata`, because AI SDK v7 carries per-call attributes on runtime context rather than a dedicated metadata field.
+_Runtime context_ is an [AI SDK concept](https://ai-sdk.dev/docs/reference/ai-sdk-core/stream-text): a user-defined object that flows through a generation lifecycle. eve exposes it through `events["step.started"]`, a callback that runs once eve has assembled the model input for an attempt and returns `{ runtimeContext }`. Because eve registers the AI SDK's OpenTelemetry integration with runtime context enabled, those returned values ride onto the model-call span and its children. The field is named `runtimeContext`, not `metadata`, because AI SDK v7 carries per-call attributes on runtime context rather than a dedicated metadata field.
 
 Use it when the values depend on the current session, turn, step, channel, or model input:
 
@@ -94,7 +94,7 @@ The callback receives:
 - `channel`: the channel's `kind` and the metadata projected by the active channel
 - `modelInput`: the final instructions and messages passed to the model call
 
-A channel exposes its identity through `kind`, the discriminant you narrow on. For authored channels it is `channel:<name>`, where `<name>` is the channel's filename under `agent/channels/`, so `agent/channels/support.ts` is `channel:support`. Framework channels use `http`, `schedule`, or `subagent`, and an unrecognized or absent kind normalizes to `unknown`. The kind is also emitted as the `eve.channel.kind` span attribute. Eve emits compiler-owned typings keyed by the channel filename, so you can narrow either by checking `input.channel.kind === "channel:support"` or by using `isChannel(input.channel, supportChannel)`.
+A channel exposes its identity through `kind`, the discriminant you narrow on. For authored channels it is `channel:<name>`, where `<name>` is the channel's filename under `agent/channels/`, so `agent/channels/support.ts` is `channel:support`. Framework channels use `http`, `schedule`, or `subagent`, and an unrecognized or absent kind normalizes to `unknown`. The kind is also emitted as the `eve.channel.kind` span attribute. eve emits compiler-owned typings keyed by the channel filename, so you can narrow either by checking `input.channel.kind === "channel:support"` or by using `isChannel(input.channel, supportChannel)`.
 
 Channel metadata is channel-owned. Built-in channels expose only the fields they choose to make observable; Slack, for example, projects `channelId`, `teamId`, `threadTs`, and `triggeringUserId` from its durable channel state. User-authored channels expose their own projection by returning `metadata(state)` from `defineChannel`. Runtime instrumentation never falls back to raw channel state.
 
@@ -113,11 +113,11 @@ ai.eve.turn  {eve.session.id}
   +-- ai.streamText                           step 3 (final text)
 ```
 
-Eve creates the `ai.eve.turn` parent span per turn and passes enriched telemetry to the AI SDK so model calls and tool executions are traced automatically. Session, turn, step, and channel context is injected as the framework half of the runtime context (`eve.version`, `eve.session.id`, `eve.environment`, `eve.turn.id`, `eve.turn.sequence`, `eve.step.index`, `eve.channel.kind`) and rides onto the spans alongside any values your `events["step.started"]` callback returns under `runtimeContext`.
+eve creates the `ai.eve.turn` parent span per turn and passes enriched telemetry to the AI SDK so model calls and tool executions are traced automatically. Session, turn, step, and channel context is injected as the framework half of the runtime context (`eve.version`, `eve.session.id`, `eve.environment`, `eve.turn.id`, `eve.turn.sequence`, `eve.step.index`, `eve.channel.kind`) and rides onto the spans alongside any values your `events["step.started"]` callback returns under `runtimeContext`.
 
 ## Workflow run tags
 
-Separately from OpenTelemetry, Eve tags every workflow run with reserved `$eve.*` attributes. These live on the Vercel Workflow run, queryable in the Workflow dashboard, not on OTel spans, and you do not configure them: they are framework-owned and emitted automatically on every session, turn, and subagent run, whether or not an `instrumentation.ts` file is present. Authored code cannot set or override the `$eve.` namespace.
+Separately from OpenTelemetry, eve tags every workflow run with reserved `$eve.*` attributes. These live on the Vercel Workflow run, queryable in the Workflow dashboard, not on OTel spans, and you do not configure them: they are framework-owned and emitted automatically on every session, turn, and subagent run, whether or not an `instrumentation.ts` file is present. Authored code cannot set or override the `$eve.` namespace.
 
 They let a dashboard reconstruct the tree of runs behind a single agent invocation and surface model and token usage without reading run bodies.
 
@@ -144,14 +144,14 @@ Note: By default, telemetry records full message history and model outputs You m
 
 ## Debugging
 
-`eve info` is the fastest way to see what Eve actually picked up: the active tools, skills, subagents, schedules, routes, and discovery diagnostics. Eve also writes inspectable artifacts under `.eve/`, kept even when discovery hits errors:
+`eve info` is the fastest way to see what eve actually picked up: the active tools, skills, subagents, schedules, routes, and discovery diagnostics. eve also writes inspectable artifacts under `.eve/`, kept even when discovery hits errors:
 
 | Artifact                        | Tells you                                   |
 | ------------------------------- | ------------------------------------------- |
-| `agent-discovery-manifest.json` | what Eve found on disk                      |
+| `agent-discovery-manifest.json` | what eve found on disk                      |
 | `diagnostics.json`              | authored-shape errors and warnings          |
-| `compiled-agent-manifest.json`  | the serialized surface Eve loads at runtime |
-| `module-map.mjs`                | compiled module entrypoints Eve imports     |
+| `compiled-agent-manifest.json`  | the serialized surface eve loads at runtime |
+| `module-map.mjs`                | compiled module entrypoints eve imports     |
 
 When `eve build` fails on discovery errors, the CLI prints the full diagnostics report (severity, message, source path) and the path to the diagnostics artifact.
 

package/docs/guides/remote-agents.md

@@ -1,9 +1,9 @@
 ---
 title: "Remote Agents"
-description: "Call another Eve deployment as a subagent with defineRemoteAgent: same lowered tool shape, outbound auth, durable callback dispatch."
+description: "Call another eve deployment as a subagent with defineRemoteAgent: same lowered tool shape, outbound auth, durable callback dispatch."
 ---
 
-`defineRemoteAgent` calls a separately deployed Eve agent as if it were a local subagent. Reach for it when the specialist you delegate to is a separately owned agent behind its own URL rather than a directory in your repo.
+`defineRemoteAgent` calls a separately deployed eve agent as if it were a local subagent. Reach for it when the specialist you delegate to is a separately owned agent behind its own URL rather than a directory in your repo.
 
 The file lives under `agent/subagents/`, so its tool name is derived from the path. There's no `name` field.
 
@@ -22,7 +22,7 @@ export default defineRemoteAgent({
 
 | Parameter      | Type                            | Required | Default           | Description                                                                                                                                     |
 | -------------- | ------------------------------- | -------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| `url`          | `string`                        | Yes      | n/a               | Base URL of the remote Eve deployment to call.                                                                                                  |
+| `url`          | `string`                        | Yes      | n/a               | Base URL of the remote eve deployment to call.                                                                                                  |
 | `description`  | `string`                        | Yes      | n/a               | Model-visible delegation description.                                                                                                           |
 | `auth`         | `OutboundAuthFn`                | No       | none              | Outbound auth hook from `eve/agents/auth`.                                                                                                      |
 | `headers`      | `HeadersValue`                  | No       | none              | Static or lazily resolved request headers.                                                                                                      |
@@ -43,7 +43,7 @@ A remote agent lowers to the same `{ message, outputSchema? }` tool shape as a l
 | `bearer(token)`                 | `Authorization: Bearer <token>` (static or lazily resolved)                  |
 | `basic({ username, password })` | `Authorization: Basic …`                                                     |
 
-If you are calling another Vercel-deployed Eve agent, reach for `vercelOidc()`. The remote verifies the OIDC token to authorize the caller. See [Auth & route protection](./auth-and-route-protection) for the receiving side.
+If you are calling another Vercel-deployed eve agent, reach for `vercelOidc()`. The remote verifies the OIDC token to authorize the caller. See [Auth & route protection](./auth-and-route-protection) for the receiving side.
 
 ## How remote dispatch and callbacks work
 

package/docs/guides/session-context.md

@@ -3,7 +3,7 @@ title: "Session Context"
 description: "Runtime helpers: ctx.session, ctx.getSandbox, ctx.getSkill, and defineState."
 ---
 
-Eve exposes runtime state through the `ctx` parameter passed to tool `execute`, hook handlers, and channel event handlers:
+eve exposes runtime state through the `ctx` parameter passed to tool `execute`, hook handlers, and channel event handlers:
 
 - `ctx.session`: session metadata, turn, auth, and parent lineage
 - `ctx.getSandbox()`: live sandbox handle for the current agent
@@ -66,7 +66,7 @@ const result = await sandbox.run({ command: "npm test" });
 Behavior:
 
 - It takes no arguments. Each agent has exactly one sandbox.
-- It is async because Eve binds or restores sandbox state lazily.
+- It is async because eve binds or restores sandbox state lazily.
 - It only works when sandbox access is attached to the active runtime path.
 - Visibility is node-local. A subagent sees its own sandbox, not the parent's.
 
@@ -119,7 +119,7 @@ export const budget = defineState<BudgetState>("myapp.budget", () => ({
 Safe places:
 
 - inside `defineTool(...).execute(input, ctx)`
-- inside authored callbacks Eve runs inside the runtime
+- inside authored callbacks eve runs inside the runtime
 - after asynchronous boundaries inside the same authored execution chain
 
 Unsafe places:
@@ -128,7 +128,7 @@ Unsafe places:
 - build scripts
 - discovery-time code paths
 
-If you call them outside an active Eve runtime context, they throw immediately with a message explaining the required scope.
+If you call them outside an active eve runtime context, they throw immediately with a message explaining the required scope.
 
 ## How it works
 

package/docs/guides/state.md

@@ -42,7 +42,7 @@ export default defineTool({
 });
 ```
 
-`get()` and `update()` require an active Eve context. Calling them outside tools, hooks, or framework-managed code throws.
+`get()` and `update()` require an active eve context. Calling them outside tools, hooks, or framework-managed code throws.
 
 ## Reset state between turns
 

package/docs/instructions.mdx

@@ -3,7 +3,7 @@ title: "Instructions"
 description: "Author the agent's always-on system prompt with instructions.md or instructions.ts."
 ---
 
-Instructions are the always-on system prompt, the agent's permanent identity rather than a procedure it pulls in when the moment calls for it. Use them for anything that should hold on every turn, such as a rule, a persona, or a constraint. Eve prepends the instructions to every model call in the session.
+Instructions are the always-on system prompt, the agent's permanent identity rather than a procedure it pulls in when the moment calls for it. Use them for anything that should hold on every turn, such as a rule, a persona, or a constraint. eve prepends the instructions to every model call in the session.
 
 ## Author instructions
 
@@ -28,11 +28,11 @@ export default defineInstructions({
 });
 ```
 
-`defineInstructions` takes one field, `markdown`, the resolved prompt text. A module-backed prompt runs once at build time. Eve captures the resulting markdown into the compiled manifest, so the runtime serves the same prompt every session and never re-runs the module.
+`defineInstructions` takes one field, `markdown`, the resolved prompt text. A module-backed prompt runs once at build time. eve captures the resulting markdown into the compiled manifest, so the runtime serves the same prompt every session and never re-runs the module.
 
 ## Split instructions across a directory
 
-For more than one file, add an `agent/instructions/` directory. Eve reads its entries non-recursively and accepts both `.md` files and `.ts` modules (a `.ts` file can wrap `defineInstructions` or `defineDynamic`). Entries combine in alphabetical order by filename (`localeCompare`).
+For more than one file, add an `agent/instructions/` directory. eve reads its entries non-recursively and accepts both `.md` files and `.ts` modules (a `.ts` file can wrap `defineInstructions` or `defineDynamic`). Entries combine in alphabetical order by filename (`localeCompare`).
 
 A flat `agent/instructions.md` (or `.ts`) at the agent root and the directory can coexist. The root file's content comes first, then the sorted directory entries. You cannot author both `instructions.md` and `instructions.ts` at the root; that pairing is a build error.
 
@@ -57,7 +57,7 @@ To resolve the prompt at runtime from session context (auth, tenant, or channel)
 
 As the deployer, it is your responsibility to ensure your agent complies with applicable laws.
 
-Where an Eve agent communicates with people, you may be required to disclose that they are interacting with an automated AI system where law requires it. Eve does not add this disclosure automatically; configure it in your instructions and/or channel responses.
+Where an eve agent communicates with people, you may be required to disclose that they are interacting with an automated AI system where law requires it. eve does not add this disclosure automatically; configure it in your instructions and/or channel responses.
 
 ## What to read next
 

package/docs/introduction.mdx

@@ -1,19 +1,21 @@
 ---
 title: "Introduction"
-description: "How an Eve agent is laid out as files, what runs when a message arrives, and the building blocks you add as it grows."
+description: "How an eve agent is laid out as files, what runs when a message arrives, and the building blocks you add as it grows."
 ---
 
-Eve is a framework for building durable agents as ordinary files in a TypeScript project.
+eve is a framework for building durable agents as ordinary files in a TypeScript project.
 
-Instead of one large configuration object, each part of your agent gets a clear home. Instructions go in one file, tools in one folder, channels in another. Eve discovers that structure and turns it into an agent that runs locally, serves HTTP, connects to other platforms, and keeps working across many turns.
+Instead of one large configuration object, each part of your agent gets a clear home. Instructions go in one file, tools in one folder, channels in another. eve discovers that structure and turns it into an agent that runs locally, serves HTTP, connects to other platforms, and keeps working across many turns.
 
 <Callout>
-  Eve is currently in beta and subject to the [Vercel beta terms](https://vercel.com/docs/release-phases/public-beta-agreement); the framework, APIs, documentation, and behavior may change before general availability.
+  eve is currently in beta and subject to the [Vercel beta
+  terms](https://vercel.com/docs/release-phases/public-beta-agreement); the framework, APIs,
+  documentation, and behavior may change before general availability.
 </Callout>
 
-## An Eve project at a glance
+## An eve project at a glance
 
-A small Eve app looks like this:
+A small eve app looks like this:
 
 ```text
 my-agent/
@@ -29,7 +31,7 @@ my-agent/
         └── slack.ts
 ```
 
-You can understand most Eve projects by reading that tree:
+You can understand most eve projects by reading that tree:
 
 - `instructions.md` tells the agent who it is and how it should behave.
 - [`agent.ts`](./agent-config) chooses the model and configures runtime options.
@@ -41,7 +43,7 @@ Start with only `instructions.md` and `agent.ts`. Add the other folders when the
 
 ## The files are the interface
 
-Eve is [filesystem-first](./reference/project-layout). A file's location says what it does, and its path usually gives it a name. For example, this file:
+eve is [filesystem-first](./reference/project-layout). A file's location says what it does, and its path usually gives it a name. For example, this file:
 
 ```text
 agent/tools/get_weather.ts
@@ -62,17 +64,17 @@ export default defineTool({
 });
 ```
 
-There is no separate registry to keep in sync. Add the file and Eve discovers it; move or rename it and its identity moves with it. See [Tools](./tools) for the complete API.
+There is no separate registry to keep in sync. Add the file and eve discovers it; move or rename it and its identity moves with it. See [Tools](./tools) for the complete API.
 
 ## What happens when a message arrives
 
-The same flow runs whether a message comes from a web app, the terminal, or Slack. Eve turns the platform input into a message, gives the model its instructions, skills, tools, and conversation history, runs the work (calling tools and subagents as needed), saves the session and streams events, then delivers the result back in the form the platform expects.
+The same flow runs whether a message comes from a web app, the terminal, or Slack. eve turns the platform input into a message, gives the model its instructions, skills, tools, and conversation history, runs the work (calling tools and subagents as needed), saves the session and streams events, then delivers the result back in the form the platform expects.
 
 That keeps agent behavior portable. Your weather tool does not need to know whether the question came from a browser or from Slack.
 
 ## Durable by default
 
-An Eve session is more than one request and one response. It can:
+An eve session is more than one request and one response. It can:
 
 - Stream progress while work is happening
 - Call tools and subagents
@@ -80,7 +82,7 @@ An Eve session is more than one request and one response. It can:
 - Resume after that answer arrives
 - Keep durable state across turns
 
-Under the hood, Eve uses the open-source [Workflow SDK](https://workflow-sdk.dev) to make sessions durable, resumable, and crash-safe. Eve handles that machinery so your tools focus on the work itself.
+Under the hood, eve uses the open-source [Workflow SDK](https://workflow-sdk.dev) to make sessions durable, resumable, and crash-safe. eve handles that machinery so your tools focus on the work itself.
 
 ## Grow the project by adding capabilities
 

package/docs/reference/cli.md

@@ -65,11 +65,11 @@ Useful artifacts written under `.eve/` (preserved even on partial failure):
 
 | Artifact                                       | Description                                          |
 | ---------------------------------------------- | ---------------------------------------------------- |
-| `.eve/discovery/agent-discovery-manifest.json` | What Eve found on disk                               |
+| `.eve/discovery/agent-discovery-manifest.json` | What eve found on disk                               |
 | `.eve/discovery/diagnostics.json`              | Authored-shape errors and warnings                   |
-| `.eve/compile/compiled-agent-manifest.json`    | The serialized authored surface Eve loads at runtime |
+| `.eve/compile/compiled-agent-manifest.json`    | The serialized authored surface eve loads at runtime |
 | `.eve/compile/compile-metadata.json`           | Build-time metadata and paths                        |
-| `.eve/compile/module-map.mjs`                  | Compiled module entrypoints Eve imports at runtime   |
+| `.eve/compile/module-map.mjs`                  | Compiled module entrypoints eve imports at runtime   |
 
 ## `eve start`
 
@@ -109,7 +109,7 @@ Pass a bare URL as the only argument and the UI connects to that server instead
 | `--context-size <tokens>`           | number | none               | Model context window size, shown as a usage percentage                                    |
 | `--logs <mode>`                     | enum   | `stderr`           | Server/agent logs to show: `all` \| `stderr` \| `sandbox` \| `none`                       |
 
-Local dev writes the active server process ID to `.eve/dev-process.pid`. If another `eve dev` starts for the same agent while that process is still running, Eve exits with a message that includes the command to stop the existing server.
+Local dev writes the active server process ID to `.eve/dev-process.pid`. If another `eve dev` starts for the same agent while that process is still running, eve exits with a message that includes the command to stop the existing server.
 
 Local dev keeps immutable runtime source snapshots under `.eve/dev-runtime/snapshots/` so in-flight sessions hold a consistent code revision while new prompts pick up rebuilds. On startup, `eve dev` prunes stale runtime snapshots and old local sandbox templates in the background. For manual cleanup, stop `eve dev` and delete `.eve/dev-runtime/snapshots/` or `.eve/sandbox-cache/local/templates/`.
 
@@ -119,7 +119,7 @@ Local dev keeps immutable runtime source snapshots under `.eve/dev-runtime/snaps
 eve link
 ```
 
-Links the current directory to an existing Vercel project. You select a team and then a project, and Eve pulls the project's environment so an AI Gateway credential (`VERCEL_OIDC_TOKEN` or `AI_GATEWAY_API_KEY`) lands in `.env.local`, then verifies one actually did. Running it again re-links: the pickers always run, and the new choice wins. The command is interactive only; in CI, use `vercel link --project <name> --yes` instead. A running `eve dev` reloads env files automatically, so you don't need to restart after the pull.
+Links the current directory to an existing Vercel project. You select a team and then a project, and eve pulls the project's environment so an AI Gateway credential (`VERCEL_OIDC_TOKEN` or `AI_GATEWAY_API_KEY`) lands in `.env.local`, then verifies one actually did. Running it again re-links: the pickers always run, and the new choice wins. The command is interactive only; in CI, use `vercel link --project <name> --yes` instead. A running `eve dev` reloads env files automatically, so you don't need to restart after the pull.
 
 ## `eve deploy`
 

package/docs/reference/project-layout.md

@@ -3,7 +3,7 @@ title: "Project Layout"
 description: "Authored slots under agent/ and the path-derived naming rule."
 ---
 
-Eve builds an agent by walking the filesystem under `agent/`. Each directory is an authored slot, and the slot a file lands in determines how Eve loads it.
+eve builds an agent by walking the filesystem under `agent/`. Each directory is an authored slot, and the slot a file lands in determines how eve loads it.
 
 ## Naming rule
 
@@ -64,7 +64,7 @@ The Subagents column states whether a local subagent (`subagents/<id>/`) can aut
 
 ## What reaches the runtime workspace
 
-Eve does not mount the whole tree. Only two sources land in the sandbox workspace:
+eve does not mount the whole tree. Only two sources land in the sandbox workspace:
 
 - `skills/` files → `/workspace/skills/...`
 - `agent/sandbox/workspace/**` → `/workspace/...` at session bootstrap
@@ -111,9 +111,9 @@ my-agent/
 
 Prefer the nested layout. It keeps the app root separate from the authored surface.
 
-## Why didn't Eve discover my file?
+## Why didn't eve discover my file?
 
-Run `eve info`. It lists the discovered surface and prints discovery diagnostics. From there, check that the file sits in the right authored slot (per the slot table above) and that the root-vs-subagent boundary is valid. Eve also writes inspectable artifacts under `.eve/`. See the debugging artifacts in [instrumentation.ts](../guides/instrumentation) and the [CLI](./cli) reference.
+Run `eve info`. It lists the discovered surface and prints discovery diagnostics. From there, check that the file sits in the right authored slot (per the slot table above) and that the root-vs-subagent boundary is valid. eve also writes inspectable artifacts under `.eve/`. See the debugging artifacts in [instrumentation.ts](../guides/instrumentation) and the [CLI](./cli) reference.
 
 ## What to read next
 

package/docs/responsible-use.md

@@ -1,14 +1,14 @@
 ---
 title: "Responsible Use"
-description: "Deployer responsibility and safeguards to review before using Eve with sensitive, regulated, or production data."
+description: "Deployer responsibility and safeguards to review before using eve with sensitive, regulated, or production data."
 ---
 
 As the deployer, it is your responsibility to ensure your agent complies with applicable laws.
 
 You are responsible for configuring approval policies, tool restrictions, connection scopes, route/session authorization, sandbox controls, telemetry exports, and other safeguards appropriate for your use case.
 
-Before using Eve with non-public, sensitive, regulated, or production data, review which default tools, custom tools, MCP tools, shell/file/web tools, connected services, subagents, schedules, and external actions are available to the agent.
+Before using eve with non-public, sensitive, regulated, or production data, review which default tools, custom tools, MCP tools, shell/file/web tools, connected services, subagents, schedules, and external actions are available to the agent.
 
 Require human approval or other safeguards for sensitive, irreversible, regulated, financial, healthcare, employment, housing, legal, safety-impacting, user-impacting, or external side-effecting actions.
 
-Unless you configure stricter controls, Eve agents may operate with permissive settings, including tool execution without human approval where approval is omitted and sandbox network egress that is not deny-all. Do not rely on model behavior alone to prevent sensitive or irreversible actions.
+Unless you configure stricter controls, eve agents may operate with permissive settings, including tool execution without human approval where approval is omitted and sandbox network egress that is not deny-all. Do not rely on model behavior alone to prevent sensitive or irreversible actions.