eve 0.11.1 → 0.11.3

package/docs/channels/eve.mdx

@@ -1,9 +1,9 @@
 ---
-title: "Eve"
+title: "eve"
 description: "The default HTTP API for an agent, covering session routes, auth, and customization."
 ---
 
-The Eve channel is the framework's default HTTP API. It's what the terminal UI, [`useEveAgent`](../guides/frontend/overview), `curl`, and any SDK client talk to when they start sessions, send messages, and stream events. `eveChannel()` mounts the canonical session routes under `/eve/v1/session*`, and they are enabled by default even when `agent/channels/eve.ts` does not exist.
+The eve channel is the framework's default HTTP API. It's what the terminal UI, [`useEveAgent`](../guides/frontend/overview), `curl`, and any SDK client talk to when they start sessions, send messages, and stream events. `eveChannel()` mounts the canonical session routes under `/eve/v1/session*`, and they are enabled by default even when `agent/channels/eve.ts` does not exist.
 
 Reach for it when something needs HTTP access to your agent, including local tooling, a browser frontend, the terminal UI, or another API client. Most apps never write this file. Add `agent/channels/eve.ts` only to override the defaults, usually the route auth policy.
 
@@ -54,7 +54,7 @@ The `auth` option decides who can call these routes. The built-in helpers cover
 
 Neither admits browser users or external clients in production. For a public app, wire the channel to your own auth (Clerk, Auth.js, or your own OIDC/JWT verification).
 
-`eve init` scaffolds an `agent/channels/eve.ts` with a production placeholder so you replace it before going live. The generated channel allows Vercel OIDC and localhost, and includes `placeholderAuth()`, which returns a setup-focused 401 in production until you swap it for real auth. Delete the file and Eve falls back to `[localDev(), vercelOidc()]`, which still does not admit browser users in production.
+`eve init` scaffolds an `agent/channels/eve.ts` with a production placeholder so you replace it before going live. The generated channel allows Vercel OIDC and localhost, and includes `placeholderAuth()`, which returns a setup-focused 401 in production until you swap it for real auth. Delete the file and eve falls back to `[localDev(), vercelOidc()]`, which still does not admit browser users in production.
 
 For the full auth model and helper list, see [Auth & route protection](../guides/auth-and-route-protection).
 
@@ -77,7 +77,7 @@ export default eveChannel({
   },
   events: {
     "message.completed"(eventData, channel, ctx) {
-      console.log("Eve response completed", {
+      console.log("eve response completed", {
         continuationToken: channel.continuationToken,
         sessionId: ctx.session.id,
       });
@@ -88,13 +88,13 @@ export default eveChannel({
 
 ## Clients
 
-The browser side of this API lives in the [Frontend](../guides/frontend/overview) docs, where `useEveAgent` drives the Eve channel from React UI.
+The browser side of this API lives in the [Frontend](../guides/frontend/overview) docs, where `useEveAgent` drives the eve channel from React UI.
 
 For scripts, server-to-server calls, evals, tests, and custom clients, use the [TypeScript SDK](../guides/client/overview). It wraps the session routes, continuation token, stream cursor, and reconnect loop.
 
 ## What to read next
 
-- [Frontend](../guides/frontend/overview): drive the Eve channel from browser UI with `useEveAgent`
-- [TypeScript SDK](../guides/client/overview): call the Eve channel from TypeScript
+- [Frontend](../guides/frontend/overview): drive the eve channel from browser UI with `useEveAgent`
+- [TypeScript SDK](../guides/client/overview): call the eve channel from TypeScript
 - [Auth & route protection](../guides/auth-and-route-protection): the route auth policy
 - [Sessions, runs & streaming](../concepts/sessions-runs-and-streaming): the routes this channel exposes

package/docs/channels/linear.mdx

@@ -4,7 +4,7 @@ description: "Reach your agent through Linear Agent Sessions, with native Agent
 type: integration
 ---
 
-The Linear channel uses Linear's Agent Session surface rather than ordinary comments. Users delegate work to the agent from Linear, Eve receives `AgentSessionEvent` webhooks at `/eve/v1/linear`, and the channel replies with native Agent Activities, including `thought`, `action`, `elicitation`, `response`, and `error`. See [Channels](./overview) for the contract this builds on.
+The Linear channel uses Linear's Agent Session surface rather than ordinary comments. Users delegate work to the agent from Linear, eve receives `AgentSessionEvent` webhooks at `/eve/v1/linear`, and the channel replies with native Agent Activities, including `thought`, `action`, `elicitation`, `response`, and `error`. See [Channels](./overview) for the contract this builds on.
 
 ## Add the channel
 
@@ -36,21 +36,21 @@ https://<deployment>/eve/v1/linear
 
 For Linear's agent surface, configure the OAuth authorize URL with `actor=app` and grant the app scopes that let it appear as an agent in Linear, including `app:assignable` and `app:mentionable`. Subscribe to the `AgentSessionEvent` webhook category so Linear sends `created` events when the agent is delegated or mentioned and `prompted` events when the user continues the session.
 
-Linear sends webhook signatures in `Linear-Signature`; Eve verifies the HMAC over the raw body and rejects stale `webhookTimestamp` values. If a trusted gateway verifies Linear before the request reaches Eve, pass `credentials.webhookVerifier` instead of a webhook secret.
+Linear sends webhook signatures in `Linear-Signature`; eve verifies the HMAC over the raw body and rejects stale `webhookTimestamp` values. If a trusted gateway verifies Linear before the request reaches eve, pass `credentials.webhookVerifier` instead of a webhook secret.
 
 ## How the channel handles messages
 
 ### Dispatch
 
-The default hook dispatches `created` and `prompted` Agent Session events. Eve adds a Linear context block with the agent session, issue, comment, and organization identifiers, then continues the same session with `agent-session:<id>`.
+The default hook dispatches `created` and `prompted` Agent Session events. eve adds a Linear context block with the agent session, issue, comment, and organization identifiers, then continues the same session with `agent-session:<id>`.
 
 ### Delivery
 
-Turn start posts an ephemeral `thought`, tool calls post ephemeral `action` activities, final assistant text posts a durable `response`, and failures post `error` activities. When the model emits text before a tool call, Eve buffers the first non-empty line and uses it as the next ephemeral Linear `thought`, mirroring Slack's typing-status behavior.
+Turn start posts an ephemeral `thought`, tool calls post ephemeral `action` activities, final assistant text posts a durable `response`, and failures post `error` activities. When the model emits text before a tool call, eve buffers the first non-empty line and uses it as the next ephemeral Linear `thought`, mirroring Slack's typing-status behavior.
 
 ### Human-in-the-loop (HITL)
 
-Human-in-the-loop (HITL) input requests render as Linear `elicitation` activities. When the user replies to the Agent Session, the channel resolves that prompt back to the pending Eve input request and resumes with `inputResponses`.
+Human-in-the-loop (HITL) input requests render as Linear `elicitation` activities. When the user replies to the Agent Session, the channel resolves that prompt back to the pending eve input request and resumes with `inputResponses`.
 
 ### Proactive sessions
 
@@ -153,7 +153,7 @@ export default defineSchedule({
 });
 ```
 
-For issue or comment targets, the channel calls Linear's proactive Agent Session mutations before starting the Eve turn. For an existing `agentSessionId`, it skips session creation and only seeds the continuation token.
+For issue or comment targets, the channel calls Linear's proactive Agent Session mutations before starting the eve turn. For an existing `agentSessionId`, it skips session creation and only seeds the continuation token.
 
 ## What to read next
 

package/docs/channels/overview.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Overview"
-description: "How users reach your agent: the channel contract, the base Eve HTTP channel, and authoring custom channels."
+description: "How users reach your agent: the channel contract, the base eve HTTP channel, and authoring custom channels."
 ---
 
 A channel is the edge adapter between a platform and your agent. It does three things:
@@ -9,7 +9,7 @@ A channel is the edge adapter between a platform and your agent. It does three t
 - Owns the `continuationToken`, the resume handle for a conversation on that surface.
 - Decides delivery, meaning how, where, and whether a response goes back.
 
-Eve ships a base HTTP channel plus first-class platform channels, and you can author your own. Browse the full set in the [Integrations](/integrations) gallery.
+eve ships a base HTTP channel plus first-class platform channels, and you can author your own. Browse the full set in the [Integrations](/integrations) gallery.
 
 Each channel has its own provider terms, data flow, auth model, and user-consent expectations. Before sending non-public, sensitive, regulated, or production data through a channel, confirm that the channel provider and your configured scopes, signature checks, route auth, and delivery behavior are appropriate for your use case.
 
@@ -28,26 +28,26 @@ agent/
 
 Scaffold a channel file with `eve channels add` (interactive), or pass a kind: `eve channels add slack` or `eve channels add web`. You can also author the file by hand.
 
-## The Eve HTTP channel (default)
+## The eve HTTP channel (default)
 
-The Eve channel is the framework's default HTTP session API, the routes the terminal UI, [`useEveAgent`](../guides/frontend/overview), and `curl` all talk to. It is enabled by default, even with no `agent/channels/eve.ts` file. Add that file only to override the defaults, most often the route auth policy. See [HTTP channel](./eve) for routes, auth, and customization.
+The eve channel is the framework's default HTTP session API, the routes the terminal UI, [`useEveAgent`](../guides/frontend/overview), and `curl` all talk to. It is enabled by default, even with no `agent/channels/eve.ts` file. Add that file only to override the defaults, most often the route auth policy. See [HTTP channel](./eve) for routes, auth, and customization.
 
 ## Custom channels
 
-When Eve doesn't ship a channel for your surface, build one with `defineChannel` from `eve/channels`. A custom channel declares route handlers (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `WS`), an `events` map, and a `send` call inside a handler to start or resume a session. See [Custom channels](./custom) for the full walkthrough, including WebSocket routes, cross-channel hand-off, channel metadata, continuation tokens, and file uploads.
+When eve doesn't ship a channel for your surface, build one with `defineChannel` from `eve/channels`. A custom channel declares route handlers (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `WS`), an `events` map, and a `send` call inside a handler to start or resume a session. See [Custom channels](./custom) for the full walkthrough, including WebSocket routes, cross-channel hand-off, channel metadata, continuation tokens, and file uploads.
 
 ## Relationship to the Chat SDK
 
-Eve uses the Chat SDK's **card-builder components** (Cards, Buttons, Actions, etc.) for composing rich Slack messages. When you build a card with the [Slack channel](./slack), the underlying primitives come from the Chat SDK and get converted to Slack Block Kit at post time.
+eve uses the Chat SDK's **card-builder components** (Cards, Buttons, Actions, etc.) for composing rich Slack messages. When you build a card with the [Slack channel](./slack), the underlying primitives come from the Chat SDK and get converted to Slack Block Kit at post time.
 
-Eve does **not** use the Chat SDK's runtime. The `Chat`, `Adapter`, and `Thread` primitives are never imported or reachable through Eve's public API. Eve implements its own channel layer (webhook handling, signature verification, event parsing, and thread management). Building Slack messages works like Chat SDK cards, but wiring a channel means authoring against Eve's `defineChannel(...)` API, not a Chat SDK adapter.
+eve does **not** use the Chat SDK's runtime. The `Chat`, `Adapter`, and `Thread` primitives are never imported or reachable through eve's public API. eve implements its own channel layer (webhook handling, signature verification, event parsing, and thread management). Building Slack messages works like Chat SDK cards, but wiring a channel means authoring against eve's `defineChannel(...)` API, not a Chat SDK adapter.
 
 ## Which channel?
 
 | You want…                                   | Use                                                        |
 | ------------------------------------------- | ---------------------------------------------------------- |
-| A web app / browser chat UI                 | Eve channel + [`useEveAgent`](../guides/frontend/overview) |
-| Local tooling, SDK clients, `curl`          | Eve channel (default)                                      |
+| A web app / browser chat UI                 | eve channel + [`useEveAgent`](../guides/frontend/overview) |
+| Local tooling, SDK clients, `curl`          | eve channel (default)                                      |
 | Slack mentions, DMs, buttons                | [Slack](./slack)                                           |
 | Discord slash commands, components          | [Discord](./discord)                                       |
 | Microsoft Teams messages + Adaptive Cards   | [Teams](./teams)                                           |
@@ -61,11 +61,11 @@ Eve does **not** use the Chat SDK's runtime. The `Chat`, `Adapter`, and `Thread`
 
 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
 
 - [Slack](./slack): the most common platform channel, end to end
 - [Custom channels](./custom): build a channel for any surface with `defineChannel`
-- [Frontend](../guides/frontend/overview): browser chat on the Eve channel with `useEveAgent`
+- [Frontend](../guides/frontend/overview): browser chat on the eve channel with `useEveAgent`
 - [Integrations](/integrations): browse every built-in channel and connection in one gallery

package/docs/channels/slack.mdx

@@ -8,7 +8,7 @@ The Slack channel puts your agent inside a workspace. It answers `@mentions` and
 
 ## Set up Connect
 
-Create a Slack Connect client and copy its UID (e.g. `slack/my-agent`), then attach this project as the trigger destination at Eve's Slack route:
+Create a Slack Connect client and copy its UID (e.g. `slack/my-agent`), then attach this project as the trigger destination at eve's Slack route:
 
 ```bash
 npm install -g vercel@latest && export FF_CONNECT_ENABLED=1
@@ -17,7 +17,7 @@ vercel connect detach <uid> --yes
 vercel connect attach <uid> --triggers --trigger-path /eve/v1/slack --yes
 ```
 
-`FF_CONNECT_ENABLED=1` turns on the Connect commands, which are feature-flagged in the Vercel CLI today. The `create` step provisions a destination at the default Connect path. `detach` then `attach --trigger-path /eve/v1/slack` re-points the trigger at the Eve Slack route, since Eve does not serve the default Connect path. `--triggers` turns on Slack Event Subscriptions; without it, Slack never delivers `app_mention` or `message.im`. You can also create the client from the [Connect dashboard](https://vercel.com/d?to=/%5Bteam%5D/~/connect&title=Go+to+Connect).
+`FF_CONNECT_ENABLED=1` turns on the Connect commands, which are feature-flagged in the Vercel CLI today. The `create` step provisions a destination at the default Connect path. `detach` then `attach --trigger-path /eve/v1/slack` re-points the trigger at the eve Slack route, since eve does not serve the default Connect path. `--triggers` turns on Slack Event Subscriptions; without it, Slack never delivers `app_mention` or `message.im`. You can also create the client from the [Connect dashboard](https://vercel.com/d?to=/%5Bteam%5D/~/connect&title=Go+to+Connect).
 
 ## Add the channel
 
@@ -42,7 +42,7 @@ export default slackChannel({
 VERCEL_USE_EXPERIMENTAL_FRAMEWORKS=1 vercel deploy --prod
 ```
 
-`VERCEL_USE_EXPERIMENTAL_FRAMEWORKS=1` lets the Vercel CLI recognize Eve as a framework during the build. Eve's own setup commands set the same flag.
+`VERCEL_USE_EXPERIMENTAL_FRAMEWORKS=1` lets the Vercel CLI recognize eve as a framework during the build. eve's own setup commands set the same flag.
 
 ## How the channel handles messages
 
@@ -54,7 +54,7 @@ Inbound hooks decide whether to dispatch a turn and with what `auth`. Return `{
 - `onDirectMessage(ctx, message)` handles `message.im` events (needs `im:history` scope). Bot-authored messages and edits are filtered out first.
 - `onInteraction(action, ctx)` handles `block_actions` callbacks not consumed by HITL.
 
-You get the triggering mention by default, but not the earlier replies in the thread. Pull them in with `loadThreadContextMessages` and return them as `context`, which Eve appends to history as user messages the model sees on every later turn. Use `since: "last-agent-reply"` so repeated mentions in one thread inject only what is new:
+You get the triggering mention by default, but not the earlier replies in the thread. Pull them in with `loadThreadContextMessages` and return them as `context`, which eve appends to history as user messages the model sees on every later turn. Use `since: "last-agent-reply"` so repeated mentions in one thread inject only what is new:
 
 ```ts
 import { defaultSlackAuth, loadThreadContextMessages, slackChannel } from "eve/channels/slack";

package/docs/channels/teams.mdx

@@ -26,7 +26,7 @@ By default the channel mounts at `POST /eve/v1/teams`. Point your Azure Bot or T
 
 ### Dispatch
 
-The default `onMessage` handles two cases: personal-chat messages, and channel or group-chat messages that mention the bot directly. Ambient resource-specific-consent messages are dropped unless you override it. Before dispatch, Eve strips the mention, adds a `<teams_context>` block, and scopes channel and group threads by root activity id (`replyToId ?? id`).
+The default `onMessage` handles two cases: personal-chat messages, and channel or group-chat messages that mention the bot directly. Ambient resource-specific-consent messages are dropped unless you override it. Before dispatch, eve strips the mention, adds a `<teams_context>` block, and scopes channel and group threads by root activity id (`replyToId ?? id`).
 
 ```ts
 import { defaultTeamsAuth, teamsChannel } from "eve/channels/teams";
@@ -45,7 +45,7 @@ Replies post as Markdown (`textFormat: "markdown"`), with oversized text split a
 
 ### Human-in-the-loop (HITL)
 
-A human-in-the-loop (HITL) `input.requested` event renders as an Adaptive Card. Buttons and options map to `Action.Submit`, selects to `Input.ChoiceSet`, and freeform to `Input.Text`. When the user submits, the activity converts to Eve `inputResponses` for you. For invokes that aren't HITL, handle them in `onInvoke(ctx, activity)`.
+A human-in-the-loop (HITL) `input.requested` event renders as an Adaptive Card. Buttons and options map to `Action.Submit`, selects to `Input.ChoiceSet`, and freeform to `Input.Text`. When the user submits, the activity converts to eve `inputResponses` for you. For invokes that aren't HITL, handle them in `onInvoke(ctx, activity)`.
 
 ### Proactive sessions
 

package/docs/channels/telegram.mdx

@@ -21,7 +21,7 @@ TELEGRAM_BOT_TOKEN=123456:...        # replies, typing, callbacks, proactive sen
 TELEGRAM_WEBHOOK_SECRET_TOKEN=...    # must match the secret_token you register
 ```
 
-You can pass the same values via `credentials: { botToken, webhookSecretToken }`. The channel mounts `POST /eve/v1/telegram`. Register the deployed URL yourself; Eve does not call `setWebhook`:
+You can pass the same values via `credentials: { botToken, webhookSecretToken }`. The channel mounts `POST /eve/v1/telegram`. Register the deployed URL yourself; eve does not call `setWebhook`:
 
 ```bash
 curl -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/setWebhook" \
@@ -47,7 +47,7 @@ The default `message.completed` handler sends plain text via `sendMessage`. It p
 
 ### Human-in-the-loop (HITL)
 
-Human-in-the-loop (HITL) turns option requests into inline-keyboard buttons and freeform requests into `ForceReply`. Telegram caps `callback_data` at 64 bytes, so Eve keeps compact callback ids in channel state instead. It acknowledges its own callbacks with `answerCallbackQuery`; anything it doesn't recognize goes to `onCallbackQuery`.
+Human-in-the-loop (HITL) turns option requests into inline-keyboard buttons and freeform requests into `ForceReply`. Telegram caps `callback_data` at 64 bytes, so eve keeps compact callback ids in channel state instead. It acknowledges its own callbacks with `answerCallbackQuery`; anything it doesn't recognize goes to `onCallbackQuery`.
 
 ### Proactive sessions
 
@@ -55,7 +55,7 @@ Start a session without an inbound message through `receive(telegram, { message,
 
 ### Attachments
 
-Inbound photos and documents are supported. Eve fetches them on demand via `getFile`, only when an upload policy allows the type:
+Inbound photos and documents are supported. eve fetches them on demand via `getFile`, only when an upload policy allows the type:
 
 ```ts
 export default telegramChannel({

package/docs/channels/twilio.mdx

@@ -4,7 +4,7 @@ description: "Reach your agent over SMS and speech-transcribed phone calls with
 type: integration
 ---
 
-The Twilio channel puts your agent on a phone number, so people can text it or call it. Inbound SMS arrives as a webhook. Inbound calls are answered with TwiML `<Gather input="speech">`, and the resulting transcript feeds the same Eve session that SMS uses, so a caller and a texter look identical downstream. Every request is checked against `X-Twilio-Signature` before anything else runs. The raw continuation token is `From:To`. See [Channels](./overview) for the contract this builds on.
+The Twilio channel puts your agent on a phone number, so people can text it or call it. Inbound SMS arrives as a webhook. Inbound calls are answered with TwiML `<Gather input="speech">`, and the resulting transcript feeds the same eve session that SMS uses, so a caller and a texter look identical downstream. Every request is checked against `X-Twilio-Signature` before anything else runs. The raw continuation token is `From:To`. See [Channels](./overview) for the contract this builds on.
 
 ## Add the channel
 

package/docs/concepts/context-control.md

@@ -1,9 +1,9 @@
 ---
 title: "Context Control"
-description: "Control what an Eve agent's model sees and when, across instructions, skills, the workspace, and subagents."
+description: "Control what an eve agent's model sees and when, across instructions, skills, the workspace, and subagents."
 ---
 
-Eve gives you a few levers for controlling what the model sees and when. `instructions.md` (or `instructions.ts`) is always on, `skills/` are available but loaded on demand, and the workspace and sandbox are visible through tools rather than pasted into the prompt.
+eve gives you a few levers for controlling what the model sees and when. `instructions.md` (or `instructions.ts`) is always on, `skills/` are available but loaded on demand, and the workspace and sandbox are visible through tools rather than pasted into the prompt.
 
 ## Base identity with `instructions.md`
 
@@ -29,11 +29,11 @@ export default defineInstructions({
 });
 ```
 
-Module-backed instructions run once at build time. Eve captures the resulting markdown into the compiled manifest, so the runtime serves the same prompt every session without re-running the module.
+Module-backed instructions run once at build time. eve captures the resulting markdown into the compiled manifest, so the runtime serves the same prompt every session without re-running the module.
 
 ## Load procedures on demand with `skills/`
 
-Skills stay out of the always-on prompt by default, which keeps rich procedures available without bloating every turn. Eve advertises the available skills and adds a framework-owned `load_skill` tool. When the request clearly matches a skill description, or the user names a skill explicitly, the model activates that skill, and Eve appends the skill's markdown to the active instructions for later turn work.
+Skills stay out of the always-on prompt by default, which keeps rich procedures available without bloating every turn. eve advertises the available skills and adds a framework-owned `load_skill` tool. When the request clearly matches a skill description, or the user names a skill explicitly, the model activates that skill, and eve appends the skill's markdown to the active instructions for later turn work.
 
 ### Flat skill
 
@@ -58,7 +58,7 @@ See [Skills](../skills) for the full authoring model and install notes.
 
 ## Put runtime files in the workspace, not the prompt
 
-Eve does not inline the entire authored surface into the prompt. Instead, it gives the model a shallow workspace hint and runtime tools to inspect deeper when needed. Skill files are available under the active workspace root, and the model inspects them with the shared `bash` tool, which keeps prompts smaller and makes file and command work explicit.
+eve does not inline the entire authored surface into the prompt. Instead, it gives the model a shallow workspace hint and runtime tools to inspect deeper when needed. Skill files are available under the active workspace root, and the model inspects them with the shared `bash` tool, which keeps prompts smaller and makes file and command work explicit.
 
 See [Sandbox](../sandbox) for the workspace and sandbox model.
 

package/docs/concepts/default-harness.md

@@ -1,9 +1,9 @@
 ---
 title: "The Harness"
-description: "The out-of-the-box Eve agent loop and the built-in tools every agent ships with, plus how to override or disable them."
+description: "The out-of-the-box eve agent loop and the built-in tools every agent ships with, plus how to override or disable them."
 ---
 
-The default harness is what every Eve agent ships with. It includes the framework-owned agent loop plus a set of built-in tools the model can call without you writing a line. You extend it with capabilities specific to your agent. The loop itself, how a turn runs and checkpoints and resumes, lives in [Execution model and durability](./execution-model-and-durability).
+The default harness is what every eve agent ships with. It includes the framework-owned agent loop plus a set of built-in tools the model can call without you writing a line. You extend it with capabilities specific to your agent. The loop itself, how a turn runs and checkpoints and resumes, lives in [Execution model and durability](./execution-model-and-durability).
 
 ## Compaction
 
@@ -24,20 +24,20 @@ Compaction also preserves the framework's own tool state automatically. It reset
 
 These ship with every agent, no imports. The harness shows the model the tool descriptors first, then executes only what the model actually calls; discovery never runs them. The shell and file tools (`bash`, `read_file`, `write_file`, `glob`, `grep`) live in the app runtime and proxy their work into the agent's single [sandbox](../sandbox); the rest run in the app runtime. The "Where it runs" column below names where each tool's effect lands.
 
-| Tool                | Does                                                                                                                                                              | Where it runs |
-| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
-| `bash`              | Run a shell command.                                                                                                                                              | Sandbox       |
-| `read_file`         | Read a text file with line-numbered output (enables read-before-write).                                                                                           | Sandbox FS    |
-| `write_file`        | Write a complete file; enforces read-before-write and stale-read detection.                                                                                       | Sandbox FS    |
-| `glob`              | Find files by glob pattern.                                                                                                                                       | Sandbox FS    |
-| `grep`              | Search file contents by regex.                                                                                                                                    | Sandbox FS    |
-| `web_fetch`         | Fetch a URL.                                                                                                                                                      | App runtime   |
-| `web_search`        | Search the web (provider-managed; resolved from the model provider).                                                                                              | Provider      |
-| `todo`              | Maintain a durable per-session todo list.                                                                                                                         | App runtime   |
-| `ask_question`      | Ask the user a clarifying question or a choice mid-turn and park until they answer. No `execute`; the model calls it with `{ prompt, options?, allowFreeform? }`. | App runtime   |
-| `agent`             | Delegate a subtask to a copy of itself (shares the parent sandbox + tools, fresh history/state).                                                                  | App runtime   |
-| `load_skill`        | Pull an on-demand [skill](../skills)'s instructions into the current turn. Present only when the agent declares skills.                                           | App runtime   |
-| `connection_search` | Discover tools across declared [connections](../connections); matched tools become directly callable. Present only when the agent declares connections.           | App runtime   |
+| Tool                | Does                                                                                                                                                                                                                   | Where it runs |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
+| `bash`              | Run a shell command.                                                                                                                                                                                                   | Sandbox       |
+| `read_file`         | Read a text file with line-numbered output (enables read-before-write).                                                                                                                                                | Sandbox FS    |
+| `write_file`        | Write a complete file; enforces read-before-write and stale-read detection.                                                                                                                                            | Sandbox FS    |
+| `glob`              | Find files by glob pattern.                                                                                                                                                                                            | Sandbox FS    |
+| `grep`              | Search file contents by regex.                                                                                                                                                                                         | Sandbox FS    |
+| `web_fetch`         | Fetch a URL.                                                                                                                                                                                                           | App runtime   |
+| `web_search`        | Search the web (provider-managed; resolved from the model provider).                                                                                                                                                   | Provider      |
+| `todo`              | Maintain a durable per-session todo list.                                                                                                                                                                              | App runtime   |
+| `ask_question`      | Ask the user a clarifying question or a choice mid-turn and park until they answer. No `execute`; the model calls it with `{ prompt, options?, allowFreeform? }`. See [Human-in-the-loop](../tools/human-in-the-loop). | App runtime   |
+| `agent`             | Delegate a subtask to a copy of itself (shares the parent sandbox + tools, fresh history/state).                                                                                                                       | App runtime   |
+| `load_skill`        | Pull an on-demand [skill](../skills)'s instructions into the current turn. Present only when the agent declares skills.                                                                                                | App runtime   |
+| `connection_search` | Discover tools across declared [connections](../connections); matched tools become directly callable. Present only when the agent declares connections.                                                                | App runtime   |
 
 Notes:
 

package/docs/concepts/execution-model-and-durability.md

@@ -1,9 +1,9 @@
 ---
 title: "Execution Model and Durability"
-description: "How an Eve session runs. Durable conversations, turns that checkpoint at steps, and parked work that resumes later."
+description: "How an eve session runs. Durable conversations, turns that checkpoint at steps, and parked work that resumes later."
 ---
 
-An Eve session is a durable conversation. It can run for days and survives process restarts and redeploys without any work on your part. You write the capabilities (tools, instructions, channels) and Eve runs the loop.
+An eve session is a durable conversation. It can run for days and survives process restarts and redeploys without any work on your part. You write the capabilities (tools, instructions, channels) and eve runs the loop.
 
 ## Sessions, turns, and steps
 
@@ -13,15 +13,15 @@ Work nests in three levels:
 - **turn**: one user message and all the work it triggers (model calls, tool calls, reasoning) until the agent produces its response.
 - **step**: a durable checkpoint inside a turn (one model call and the tool calls it makes).
 
-Every turn runs as a durable workflow, built on the open-source [Workflow SDK](https://workflow-sdk.dev/) (Vercel Workflow when you deploy on Vercel). Eve checkpoints progress and serializes durable state at each step boundary. Your code runs inside a managed step, so tools, the sandbox, and subagents feel synchronous even though the session underneath them is durable.
+Every turn runs as a durable workflow, built on the open-source [Workflow SDK](https://workflow-sdk.dev/) (Vercel Workflow when you deploy on Vercel). eve checkpoints progress and serializes durable state at each step boundary. Your code runs inside a managed step, so tools, the sandbox, and subagents feel synchronous even though the session underneath them is durable.
 
 ## Resuming after a crash
 
-Crash the process, hit a timeout, or redeploy mid-turn, and the run picks up from the last completed step rather than replaying the whole turn. Completed steps never re-run; Eve replays the recorded result. A step interrupted mid-execution re-runs, so make non-idempotent side effects like charges or emails idempotent, or gate them with approval.
+Crash the process, hit a timeout, or redeploy mid-turn, and the run picks up from the last completed step rather than replaying the whole turn. Completed steps never re-run; eve replays the recorded result. A step interrupted mid-execution re-runs, so make non-idempotent side effects like charges or emails idempotent, or gate them with approval.
 
-There's nothing to configure. Eve owns the workflow lifecycle, and sessions are durable by default.
+There's nothing to configure. eve owns the workflow lifecycle, and sessions are durable by default.
 
-You don't write workflow code directly. Workflow primitives (`start()`, `resumeHook()`, etc.) are an implementation detail of Eve's runtime layer; channels, tools, and hooks never touch them. Two surfaces give your own code session data: tools read the current session's metadata (id, turn, auth, parent lineage) via `ctx.session`, and [`defineState`](../guides/state) reads or writes session-scoped durable state. See [State](../guides/state) for the read/write model.
+You don't write workflow code directly. Workflow primitives (`start()`, `resumeHook()`, etc.) are an implementation detail of eve's runtime layer; channels, tools, and hooks never touch them. Two surfaces give your own code session data: tools read the current session's metadata (id, turn, auth, parent lineage) via `ctx.session`, and [`defineState`](../guides/state) reads or writes session-scoped durable state. See [State](../guides/state) for the read/write model.
 
 ## Parked work
 
@@ -29,9 +29,9 @@ Some work has to wait, including a human approving a [tool](../tools), an intera
 
 ## Message delivery and queueing
 
-Eve does not maintain a durable FIFO queue of user messages for a session. The `continuationToken` is a resume handle for the session's current workflow hook, not a general message-queue address.
+eve does not maintain a durable FIFO queue of user messages for a session. The `continuationToken` is a resume handle for the session's current workflow hook, not a general message-queue address.
 
-When a session is waiting, a delivery to the current continuation token wakes the session and starts the next turn. When a turn is already active, the hook may accept additional deliveries, but the runtime only drains them at specific workflow boundaries. If more than one delivery is ready when the driver checks, Eve may fold them into the next turn; that drain is best-effort and depends on workflow and transport timing.
+When a session is waiting, a delivery to the current continuation token wakes the session and starts the next turn. When a turn is already active, the hook may accept additional deliveries, but the runtime only drains them at specific workflow boundaries. If more than one delivery is ready when the driver checks, eve may fold them into the next turn; that drain is best-effort and depends on workflow and transport timing.
 
 So don't rely on concurrent sends to the same session behaving like a typical ordered chat queue. For deterministic behavior, send one user turn at a time and wait for `session.waiting` before sending the next message to the same session. If your channel can receive bursts while the agent is working, keep your own per-session queue in the channel or app layer, then deliver the next message after the session parks again. Separate sessions still run independently.
 
@@ -39,7 +39,7 @@ So don't rely on concurrent sends to the same session behaving like a typical or
 
 A turn can hand work off to a [subagent](../subagents). Each subagent gets its own context and its own durable session; a declared subagent also gets its own sandbox, skills, and state. Nothing crosses the boundary implicitly.
 
-## How Eve orders session history
+## How eve orders session history
 
 Conversation history within a session is append-only. Turns land in order, and the tool calls inside a turn (plus their results) keep their order too. Read a session back and you see events in the order they happened.
 

package/docs/concepts/security-model.md

@@ -1,9 +1,9 @@
 ---
 title: "Security Model"
-description: "Eve's trust boundaries, where secrets live, how credentials reach hosts, and what fails closed by default."
+description: "eve's trust boundaries, where secrets live, how credentials reach hosts, and what fails closed by default."
 ---
 
-Your Eve agent runs across two contexts, with a trust boundary between them and every secret kept on the trusted side. Use this mental model when deciding what an agent (and the model driving it) is allowed to reach.
+Your eve agent runs across two contexts, with a trust boundary between them and every secret kept on the trusted side. Use this mental model when deciding what an agent (and the model driving it) is allowed to reach.
 
 ## Trust boundaries
 
@@ -25,7 +25,7 @@ A concrete trace makes the boundary clear. When the model calls a custom `charge
 ```mermaid
 flowchart LR
   User["User or channel provider"] --> Channel["Channel route and route auth"]
-  Channel --> Runtime["Eve app runtime and durable session"]
+  Channel --> Runtime["eve app runtime and durable session"]
   Runtime --> Model["Configured model provider or Vercel AI Gateway"]
   Runtime --> Tools["Authored tools and connections"]
   Tools --> Services["Customer-selected external services"]
@@ -34,23 +34,23 @@ flowchart LR
   Runtime --> Telemetry["Configured telemetry or eval provider"]
 ```
 
-Eve sends data where your agent configuration and runtime choices send it:
+eve sends data where your agent configuration and runtime choices send it:
 
-- Inbound channel data flows through the channel provider you configure, then into the Eve app runtime.
+- Inbound channel data flows through the channel provider you configure, then into the eve app runtime.
 - Model inputs and outputs flow to the model or routing path selected in `agent.ts`, such as a Vercel AI Gateway model id or a provider-authored `LanguageModel`.
 - Tool and connection calls flow to the external services, MCP servers, OpenAPI endpoints, and channels you configure.
 - Sandbox commands can reach network destinations allowed by the sandbox network policy.
 - Telemetry and eval data flows to the exporters and providers you configure in `instrumentation.ts` or eval settings.
 
-Eve stores durable session and workflow state needed to resume conversations, stream events, replay completed steps, and show run observability. You are responsible for deciding whether the selected channels, model providers, connected services, sandbox egress destinations, telemetry exporters, retention settings, and deletion controls are appropriate for your data and use case.
+eve stores durable session and workflow state needed to resume conversations, stream events, replay completed steps, and show run observability. You are responsible for deciding whether the selected channels, model providers, connected services, sandbox egress destinations, telemetry exporters, retention settings, and deletion controls are appropriate for your data and use case.
 
 ## Credential brokering
 
-Credential brokering gives the model _authenticated_ network access from inside the sandbox, like a `git clone` of a private repo or an authenticated `curl`, when there's no [tool](../tools) or [connection](../connections) to route it through. On the Vercel Sandbox backend, auth headers get injected at the sandbox's network firewall for matching domains. The secret stays in the app runtime; the sandbox process only ever sees the response. See [Vercel Sandbox Credential Brokering](https://vercel.com/docs/sandbox/concepts/firewall#credentials-brokering) for the platform mechanism, and [Sandbox](../sandbox) for the Eve policy API.
+Credential brokering gives the model _authenticated_ network access from inside the sandbox, like a `git clone` of a private repo or an authenticated `curl`, when there's no [tool](../tools) or [connection](../connections) to route it through. On the Vercel Sandbox backend, auth headers get injected at the sandbox's network firewall for matching domains. The secret stays in the app runtime; the sandbox process only ever sees the response. See [Vercel Sandbox Credential Brokering](https://vercel.com/docs/sandbox/concepts/firewall#credentials-brokering) for the platform mechanism, and [Sandbox](../sandbox) for the eve policy API.
 
 ## Connection credentials
 
-[Connection](../connections) tokens (MCP and OpenAPI) come from either `getToken()` or an interactive OAuth flow, and Eve injects the resolved token into every outbound request. The token is cached per step and never serialized to durable state.
+[Connection](../connections) tokens (MCP and OpenAPI) come from either `getToken()` or an interactive OAuth flow, and eve injects the resolved token into every outbound request. The token is cached per step and never serialized to durable state.
 
 ## Channel verification
 
@@ -70,7 +70,7 @@ A custom channel that accepts dashboard-style webhooks should follow the same sh
 
 ## Authored markdown is data
 
-[Skill](../skills) and [schedule](../schedules) files are markdown with YAML frontmatter, and Eve treats that frontmatter strictly as data. The code-capable engines (`---js` / `---javascript`, which would `eval()` the frontmatter body the moment the file is parsed) are disabled, so such a fence throws rather than running. Frontmatter has to parse to a plain YAML object.
+[Skill](../skills) and [schedule](../schedules) files are markdown with YAML frontmatter, and eve treats that frontmatter strictly as data. The code-capable engines (`---js` / `---javascript`, which would `eval()` the frontmatter body the moment the file is parsed) are disabled, so such a fence throws rather than running. Frontmatter has to parse to a plain YAML object.
 
 ## Auth fails closed
 

package/docs/concepts/sessions-runs-and-streaming.md

@@ -3,7 +3,7 @@ title: "Sessions, Runs & Streaming"
 description: "The session and run contract you touch: continuation tokens, stream handles, the NDJSON event stream, and reconnecting."
 ---
 
-Every Eve app speaks the same stable HTTP API to a [durable session](./execution-model-and-durability). This page is the contract you hold: the handles you get back, the events you stream, and how to reconnect.
+Every eve app speaks the same stable HTTP API to a [durable session](./execution-model-and-durability). This page is the contract you hold: the handles you get back, the events you stream, and how to reconnect.
 
 ## The two handles
 
@@ -14,7 +14,7 @@ Two handles do two jobs, and mixing them up is the most common mistake. One hand
 
 A session has one active continuation at a time: each follow-up uses the current `continuationToken`, and a stale one is rejected.
 
-React, Vue, and Svelte apps reach for [`useEveAgent()`](../guides/frontend/overview) instead of calling these routes by hand. Next.js and Nuxt apps can proxy them to the Eve runtime from the same origin.
+React, Vue, and Svelte apps reach for [`useEveAgent()`](../guides/frontend/overview) instead of calling these routes by hand. Next.js and Nuxt apps can proxy them to the eve runtime from the same origin.
 
 ## Start a session
 
@@ -24,7 +24,7 @@ curl -X POST http://127.0.0.1:3000/eve/v1/session \
   -d '{"message":"Summarize the latest forecast."}'
 ```
 
-Eve responds right away. The JSON body carries a `sessionId` and a `continuationToken`, and the `x-eve-session-id` header names the durable session to stream.
+eve responds right away. The JSON body carries a `sessionId` and a `continuationToken`, and the `x-eve-session-id` header names the durable session to stream.
 
 ## Stream a session
 
@@ -34,33 +34,33 @@ curl http://127.0.0.1:3000/eve/v1/session/<sessionId>/stream
 
 The stream is newline-delimited JSON (NDJSON), one event per line:
 
-| Event                     | Meaning                                                                                        |
-| ------------------------- | ---------------------------------------------------------------------------------------------- |
-| `session.started`         | A durable session was created.                                                                 |
-| `turn.started`            | A new turn began.                                                                              |
-| `message.received`        | An inbound user message was accepted.                                                          |
-| `step.started`            | A model step began.                                                                            |
-| `actions.requested`       | The model requested tool calls.                                                                |
-| `action.result`           | A tool call returned.                                                                          |
-| `input.requested`         | The run paused for human input (HITL approval or `ask_question`); carries `requests`.          |
-| `subagent.called`         | A subagent was delegated; carries `childSessionId` to attach to.                               |
-| `subagent.completed`      | A delegated subagent finished.                                                                 |
-| `reasoning.appended`      | A reasoning delta (incremental, with cumulative text so far).                                  |
-| `reasoning.completed`     | The finalized reasoning block.                                                                 |
-| `message.appended`        | An assistant text delta (incremental, with cumulative text so far).                            |
-| `message.completed`       | A finalized assistant text block.                                                              |
-| `result.completed`        | The finalized structured result for a turn that requested an output schema; carries `result`.  |
-| `compaction.requested`    | Context-window compaction began; carries `modelId`, `sessionId`, `turnId`, `usageInputTokens`. |
-| `compaction.completed`    | A compaction checkpoint was written to durable history.                                        |
-| `authorization.required`  | A connection needs OAuth; carries `name`, `description`, and an `authorization` challenge.     |
-| `authorization.completed` | A connection's authorization resolved; carries `outcome`.                                      |
-| `step.completed`          | A model step finished; carries `finishReason` and usage.                                       |
-| `step.failed`             | A model step failed; carries `{ code, message, details? }`.                                    |
-| `turn.completed`          | The turn finished.                                                                             |
-| `turn.failed`             | The turn failed; carries `{ code, message, details? }`.                                        |
-| `session.waiting`         | The session parked, waiting for the next input (a message, an answer).                         |
-| `session.failed`          | The session failed.                                                                            |
-| `session.completed`       | The session reached a terminal end.                                                            |
+| Event                     | Meaning                                                                                                             |
+| ------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `session.started`         | A durable session was created.                                                                                      |
+| `turn.started`            | A new turn began.                                                                                                   |
+| `message.received`        | An inbound user message was accepted.                                                                               |
+| `step.started`            | A model step began.                                                                                                 |
+| `actions.requested`       | The model requested tool calls.                                                                                     |
+| `action.result`           | A tool call returned.                                                                                               |
+| `input.requested`         | The run paused for human input ([HITL](../tools/human-in-the-loop) approval or `ask_question`); carries `requests`. |
+| `subagent.called`         | A subagent was delegated; carries `childSessionId` to attach to.                                                    |
+| `subagent.completed`      | A delegated subagent finished.                                                                                      |
+| `reasoning.appended`      | A reasoning delta (incremental, with cumulative text so far).                                                       |
+| `reasoning.completed`     | The finalized reasoning block.                                                                                      |
+| `message.appended`        | An assistant text delta (incremental, with cumulative text so far).                                                 |
+| `message.completed`       | A finalized assistant text block.                                                                                   |
+| `result.completed`        | The finalized structured result for a turn that requested an output schema; carries `result`.                       |
+| `compaction.requested`    | Context-window compaction began; carries `modelId`, `sessionId`, `turnId`, `usageInputTokens`.                      |
+| `compaction.completed`    | A compaction checkpoint was written to durable history.                                                             |
+| `authorization.required`  | A connection needs OAuth; carries `name`, `description`, and an `authorization` challenge.                          |
+| `authorization.completed` | A connection's authorization resolved; carries `outcome`.                                                           |
+| `step.completed`          | A model step finished; carries `finishReason` and usage.                                                            |
+| `step.failed`             | A model step failed; carries `{ code, message, details? }`.                                                         |
+| `turn.completed`          | The turn finished.                                                                                                  |
+| `turn.failed`             | The turn failed; carries `{ code, message, details? }`.                                                             |
+| `session.waiting`         | The session parked, waiting for the next input (a message, an answer).                                              |
+| `session.failed`          | The session failed.                                                                                                 |
+| `session.completed`       | The session reached a terminal end.                                                                                 |
 
 `reasoning.appended` and `message.appended` stream deltas as they arrive, and each one carries both the new delta and the cumulative text for the current block. The finalized block shows up on `message.completed` and `reasoning.completed`, which is the compatibility path for clients that don't render incremental streaming.