eve 0.11.2 → 0.11.3

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
 

package/docs/connections.mdx

@@ -3,7 +3,7 @@ title: "Connections"
 description: "Expose external MCP and OpenAPI servers to the model, with connection tokens the model never sees."
 ---
 
-A connection wires an agent into an external server you don't author, either an MCP server (Linear, GitHub, a warehouse) or any HTTP API with an OpenAPI document. Eve handles the parts you'd otherwise hand-roll, discovering the remote tools, surfacing them to the model, and brokering auth.
+A connection wires an agent into an external server you don't author, either an MCP server (Linear, GitHub, a warehouse) or any HTTP API with an OpenAPI document. eve handles the parts you'd otherwise hand-roll, discovering the remote tools, surfacing them to the model, and brokering auth.
 
 Connections live under `agent/connections/`. The runtime name comes from the filename, so `agent/connections/linear.ts` registers as `"linear"`. The model never sees a connection's URL or credentials. It discovers tools through the built-in `connection__search` and calls them by their qualified name, `connection__<connection>__<tool>` (e.g. `connection__linear__list_issues`).
 
@@ -27,11 +27,11 @@ The `url` must speak Streamable HTTP or SSE. Write the `description` for the mod
 
 ### Static-token auth
 
-`getToken` returns a `TokenResult` (`{ token, expiresAt? }`), and Eve sends it as `Authorization: Bearer <token>` on every request. Because it runs on each connection attempt, you can mint a fresh token from wherever you keep secrets, including an env var, a secrets manager, an internal vault, or your own OAuth exchange. If the token has a known TTL, set `expiresAt` (milliseconds since epoch) and Eve refreshes ahead of time rather than waiting for a `401`.
+`getToken` returns a `TokenResult` (`{ token, expiresAt? }`), and eve sends it as `Authorization: Bearer <token>` on every request. Because it runs on each connection attempt, you can mint a fresh token from wherever you keep secrets, including an env var, a secrets manager, an internal vault, or your own OAuth exchange. If the token has a known TTL, set `expiresAt` (milliseconds since epoch) and eve refreshes ahead of time rather than waiting for a `401`.
 
 When `getToken` is the only auth, `principalType` defaults to `"app"`: one shared credential keyed across all sessions. Switch to `principalType: "user"` when each end-user carries their own token.
 
-Eve resolves and caches connection tokens per step; they never land in conversation history or reach the model.
+eve resolves and caches connection tokens per step; they never land in conversation history or reach the model.
 
 ### No auth
 
@@ -44,7 +44,7 @@ export default defineMcpClientConnection({
 });
 ```
 
-We recommend using no-auth connections only for services that are intentionally public, local-only, or otherwise protected outside Eve. Do not use no-auth connections for sensitive third-party services.
+We recommend using no-auth connections only for services that are intentionally public, local-only, or otherwise protected outside eve. Do not use no-auth connections for sensitive third-party services.
 
 ### Headers
 
@@ -92,7 +92,7 @@ For connection tools that can create, modify, delete, transmit, purchase, messag
 
 ## OpenAPI connections
 
-`defineOpenAPIConnection` turns any OpenAPI 3.x document into connection tools, one per operation. Pass an HTTPS URL Eve fetches at runtime, or an inline parsed object:
+`defineOpenAPIConnection` turns any OpenAPI 3.x document into connection tools, one per operation. Pass an HTTPS URL eve fetches at runtime, or an inline parsed object:
 
 ```ts title="agent/connections/petstore.ts"
 import { defineOpenAPIConnection } from "eve/connections";
@@ -104,7 +104,7 @@ export default defineOpenAPIConnection({
 });
 ```
 
-Each operation becomes `connection__<connection>__<operationId>` (e.g. `connection__petstore__getInventory`). When an operation has no `operationId`, Eve derives a deterministic `<method>_<sanitized-path>` name instead.
+Each operation becomes `connection__<connection>__<operationId>` (e.g. `connection__petstore__getInventory`). When an operation has no `operationId`, eve derives a deterministic `<method>_<sanitized-path>` name instead.
 
 `auth`, `headers`, and `approval` work exactly as they do for MCP. There are two fields specific to OpenAPI:
 
@@ -115,7 +115,7 @@ Each operation becomes `connection__<connection>__<operationId>` (e.g. `connecti
 
 ## Interactive OAuth via Vercel Connect
 
-When the server uses OAuth and you want each end-user to sign in through their own browser, turn on interactive authorization with [Vercel Connect](https://vercel.com/docs/connect). The `connect()` helper from `@vercel/connect/eve` handles consent, encrypted token storage, and refresh, then hooks all of that into Eve's authorization flow:
+When the server uses OAuth and you want each end-user to sign in through their own browser, turn on interactive authorization with [Vercel Connect](https://vercel.com/docs/connect). The `connect()` helper from `@vercel/connect/eve` handles consent, encrypted token storage, and refresh, then hooks all of that into eve's authorization flow:
 
 ```ts title="agent/connections/linear.ts"
 import { connect } from "@vercel/connect/eve";
@@ -132,7 +132,7 @@ export default defineMcpClientConnection({
 
 ## Self-hosted interactive OAuth
 
-To run your own OAuth, use `defineInteractiveAuthorization` from `eve/connections`, which takes a three-method form and needs no Vercel Connect. Eve mints a callback URL, parks (durably suspends) the turn on a framework-owned webhook, and resumes once the token comes back. Interactive auth is always `principalType: "user"`, and the factory pins that for you.
+To run your own OAuth, use `defineInteractiveAuthorization` from `eve/connections`, which takes a three-method form and needs no Vercel Connect. eve mints a callback URL, parks (durably suspends) the turn on a framework-owned webhook, and resumes once the token comes back. Interactive auth is always `principalType: "user"`, and the factory pins that for you.
 
 ```ts title="agent/connections/linear.ts"
 import {
@@ -205,7 +205,7 @@ To narrow a caught error, use `isConnectionAuthorizationRequiredError(err)` and
 
 ### Handling a revoked token mid-call
 
-`getToken` only runs _before_ a tool call, so a grant revoked while a tool is mid-flight first surfaces as a downstream `401` inside your `execute`. A plain throw there is only a tool error, so the model sees a failure and the cached bearer sticks around. Instead, map a provider `401` to `ctx.requireAuth()` (or rethrow `ConnectionAuthorizationRequiredError`). Eve then evicts the rejected token from its per-step cache and re-runs the consent flow with a fresh one, exactly as it does for a connection whose server rejects the bearer.
+`getToken` only runs _before_ a tool call, so a grant revoked while a tool is mid-flight first surfaces as a downstream `401` inside your `execute`. A plain throw there is only a tool error, so the model sees a failure and the cached bearer sticks around. Instead, map a provider `401` to `ctx.requireAuth()` (or rethrow `ConnectionAuthorizationRequiredError`). eve then evicts the rejected token from its per-step cache and re-runs the consent flow with a fresh one, exactly as it does for a connection whose server rejects the bearer.
 
 ```ts title="agent/tools/list_issues.ts"
 import { defineTool } from "eve/tools";
@@ -229,11 +229,11 @@ export default defineTool({
 
 ### Authorization and approval together
 
-A tool can require both sign-in (`auth`) and a human approval. The model's approval gate runs before the tool's `execute`, so the order the user sees is **approve, then sign in**. Eve records the approval on session state the moment it's granted, and that record survives the sign-in park, so when the turn resumes after authorization the tool is not put through approval again. You get one approval and one sign-in, never a double prompt.
+A tool can require both sign-in (`auth`) and a human approval. The model's approval gate runs before the tool's `execute`, so the order the user sees is **approve, then sign in**. eve records the approval on session state the moment it's granted, and that record survives the sign-in park, so when the turn resumes after authorization the tool is not put through approval again. You get one approval and one sign-in, never a double prompt.
 
 ## What to read next
 
-- [Integrations](/integrations): browse every channel and connection Eve ships, in one gallery.
+- [Integrations](/integrations): browse every channel and connection eve ships, in one gallery.
 - [Tools](./tools): authored tools live alongside connection-provided tools; the same approval helpers apply.
 - [Auth & route protection](./guides/auth-and-route-protection): the full interactive-OAuth flow with Vercel Connect.
 - [Security model](./concepts/security-model): how connection credentials stay out of the model's reach.

package/docs/evals/judge.mdx

@@ -3,7 +3,7 @@ title: "Judge"
 description: "Grade evals with an LLM judge via t.judge.autoevals, set thresholds on the assertion, and configure the judge model."
 ---
 
-When no deterministic [assertion](./assertions) captures what "good" means (factual correctness, summary quality, free-form criteria), grade the run with an LLM judge. The `t.judge.*` assertions are the only model-backed ones, and they use a judge model that is resolved separately from the agent under test. Eve only uses it for scoring, never to swap out the agent.
+When no deterministic [assertion](./assertions) captures what "good" means (factual correctness, summary quality, free-form criteria), grade the run with an LLM judge. The `t.judge.*` assertions are the only model-backed ones, and they use a judge model that is resolved separately from the agent under test. eve only uses it for scoring, never to swap out the agent.
 
 ```ts
 import { defineEval } from "eve/evals";
@@ -19,7 +19,7 @@ export default defineEval({
 
 ## The graders
 
-The judges live under `t.judge.autoevals`. The namespace names the [Braintrust autoevals](https://github.com/braintrustdata/autoevals) grader family, so the factuality and closedQA semantics are autoevals', not Eve-invented. Each grader scores `t.reply` by default and is soft by default (tracked, no gate):
+The judges live under `t.judge.autoevals`. The namespace names the [Braintrust autoevals](https://github.com/braintrustdata/autoevals) grader family, so the factuality and closedQA semantics are autoevals', not eve-invented. Each grader scores `t.reply` by default and is soft by default (tracked, no gate):
 
 | Grader                                   | Grades                                                                                 |
 | ---------------------------------------- | -------------------------------------------------------------------------------------- |

package/docs/evals/overview.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Overview"
-description: "Define repeatable scored checks for an Eve agent with defineEval and run them with eve eval."
+description: "Define repeatable scored checks for an eve agent with defineEval and run them with eve eval."
 ---
 
 An eval is a scored check that runs your agent against real sessions and grades the result, catching regressions when you change a prompt or a tool. Drive the agent through one or more turns, assert on what it did (the run completed, the right tool ran, the reply contains the right text), and optionally ship the results to Braintrust.
@@ -9,7 +9,7 @@ Evals exercise the same HTTP surface your users hit. The runner boots (or target
 
 ## `defineEval`
 
-Eve discovers evals under the app-root `evals/` directory, in `.eval.ts` files. Each file is one eval by default. A file can also default-export an array to fan out over a dataset (see [Cases](./cases)). The file path is the eval's identity, so you don't author an `id` or `name`. Directories group related evals (`evals/weather/brooklyn-forecast.eval.ts` becomes id `weather/brooklyn-forecast`).
+eve discovers evals under the app-root `evals/` directory, in `.eval.ts` files. Each file is one eval by default. A file can also default-export an array to fan out over a dataset (see [Cases](./cases)). The file path is the eval's identity, so you don't author an `id` or `name`. Directories group related evals (`evals/weather/brooklyn-forecast.eval.ts` becomes id `weather/brooklyn-forecast`).
 
 ```text
 my-agent/

package/docs/evals/reporters.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Reporters"
-description: "Ship eval results to Braintrust experiments or JUnit XML. Eve runs and scores everything itself."
+description: "Ship eval results to Braintrust experiments or JUnit XML. eve runs and scores everything itself."
 ---
 
-Eve runs and grades everything itself; reporters ship the results out. The CLI prints a console summary by default (one line per eval, with failed assertions and their messages), and reporters from `eve/evals/reporters` add destinations on top.
+eve runs and grades everything itself; reporters ship the results out. The CLI prints a console summary by default (one line per eval, with failed assertions and their messages), and reporters from `eve/evals/reporters` add destinations on top.
 
 You are responsible for ensuring any observability or eval provider is approved for the data exported to it.
 

package/docs/getting-started.mdx

@@ -1,12 +1,12 @@
 ---
 title: "Getting Started"
-description: "Install Eve, scaffold your first agent, give it a tool, and run it locally."
+description: "Install eve, scaffold your first agent, give it a tool, and run it locally."
 ---
 
-Eve is a filesystem-first framework for durable agents. You write capabilities under `agent/`, and Eve runs the model loop, persists every session, and serves the agent over HTTP and platform channels. You'll scaffold an app, add a tool, run it locally, then create, stream, and continue a session over HTTP.
+eve is a filesystem-first framework for durable agents. You write capabilities under `agent/`, and eve runs the model loop, persists every session, and serves the agent over HTTP and platform channels. You'll scaffold an app, add a tool, run it locally, then create, stream, and continue a session over HTTP.
 
 <Callout>
-  Eve is currently in beta and subject to the [Vercel beta
+  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>
@@ -28,7 +28,7 @@ If you skip this, the dev TUI flags the missing credential and its `/model` comm
 
 ## Quick start
 
-`npx` runs `eve init` without installing Eve first:
+`npx` runs `eve init` without installing eve first:
 
 ```bash
 npx eve@latest init my-agent
@@ -36,7 +36,7 @@ npx eve@latest init my-agent
 
 The command:
 
-- Creates an npm-managed child directory and uses Eve's default model
+- Creates an npm-managed child directory and uses eve's default model
 - Installs dependencies and initializes Git
 - Starts the development server and opens the interactive [terminal UI](./guides/dev-tui)
 
@@ -44,11 +44,11 @@ Type a message and watch the model loop run. Pass `--channel-web-nextjs` to add
 
 `eve init` holds the terminal, so stop it with Ctrl+C to get your shell back before editing the generated agent. The command does not create a Vercel project or deploy.
 
-To add Eve to an existing project, run `eve init .` from a directory that already has a `package.json` and no `agent/` files yet. Eve adds the missing `eve`, `ai`, and `zod` dependencies without touching anything else the project owns. The Eve dependency and the Node engine come from the same release. Eve pins `engines.node` to the lowest major that release supports (for example `24.x`). It keeps an existing range only when every version that range allows stays within that major; otherwise it replaces the range and prints a warning.
+To add eve to an existing project, run `eve init .` from a directory that already has a `package.json` and no `agent/` files yet. eve adds the missing `eve`, `ai`, and `zod` dependencies without touching anything else the project owns. The eve dependency and the Node engine come from the same release. eve pins `engines.node` to the lowest major that release supports (for example `24.x`). It keeps an existing range only when every version that range allows stays within that major; otherwise it replaces the range and prints a warning.
 
 ## Manual installation
 
-To wire Eve into an existing app by hand instead of using `eve init`, first declare a compatible Node runtime in `package.json`:
+To wire eve into an existing app by hand instead of using `eve init`, first declare a compatible Node runtime in `package.json`:
 
 ```json
 {
@@ -135,7 +135,7 @@ The same CLI can point at a deployment. `npx eve dev https://your-app.vercel.app
 
 ## Send a message
 
-Every Eve app exposes the same stable HTTP API. Start a durable session:
+Every eve app exposes the same stable HTTP API. Start a durable session:
 
 ```bash
 curl -X POST http://127.0.0.1:3000/eve/v1/session \
@@ -186,8 +186,8 @@ See [Sessions, runs and streaming](./concepts/sessions-runs-and-streaming) for t
 
 If a coding agent (Claude Code, Cursor, and the like) is doing the setup, hand it this prompt:
 
-<CopyPrompt text="Set up an Eve agent for the user. Eve is a filesystem-first TypeScript framework for durable agents, published as the npm package eve. Read its docs: once eve is installed they are bundled in the package at node_modules/eve/docs; before eve is installed, read the published Introduction and Getting Started pages. If the project has no Eve app, scaffold one with `npx eve@latest init <name>`; add `--channel-web-nextjs` only when the user wants Web Chat. The init command installs dependencies, initializes Git, and starts the dev server, so run it in a controllable process and stop it with Ctrl+C before editing. To add Eve to an existing app, run `eve init .`, or install the dependencies by hand with `npm install eve@latest ai zod` (init adds ai and zod; the by-hand path needs all three). Make sure agent/agent.ts and agent/instructions.md exist, then add a first typed tool at agent/tools/get_weather.ts using defineTool from eve/tools with a Zod inputSchema and an inline execute. Start the dev server again, then exercise the HTTP API: create a session with POST /eve/v1/session, attach to GET /eve/v1/session/:id/stream, and send a follow-up with the returned continuationToken. Verify with the project's typecheck, adapt model and provider choices to the project, and do not commit unless the user asks.">
-  Set up an Eve agent: read the Eve docs (bundled at node_modules/eve/docs once eve is
+<CopyPrompt text="Set up an eve agent for the user. eve is a filesystem-first TypeScript framework for durable agents, published as the npm package eve. Read its docs: once eve is installed they are bundled in the package at node_modules/eve/docs; before eve is installed, read the published Introduction and Getting Started pages. If the project has no eve app, scaffold one with `npx eve@latest init <name>`; add `--channel-web-nextjs` only when the user wants Web Chat. The init command installs dependencies, initializes Git, and starts the dev server, so run it in a controllable process and stop it with Ctrl+C before editing. To add eve to an existing app, run `eve init .`, or install the dependencies by hand with `npm install eve@latest ai zod` (init adds ai and zod; the by-hand path needs all three). Make sure agent/agent.ts and agent/instructions.md exist, then add a first typed tool at agent/tools/get_weather.ts using defineTool from eve/tools with a Zod inputSchema and an inline execute. Start the dev server again, then exercise the HTTP API: create a session with POST /eve/v1/session, attach to GET /eve/v1/session/:id/stream, and send a follow-up with the returned continuationToken. Verify with the project's typecheck, adapt model and provider choices to the project, and do not commit unless the user asks.">
+  Set up an eve agent: read the eve docs (bundled at node_modules/eve/docs once eve is
   installed), scaffold with `npx eve@latest init <name>` (or `npm install eve@latest ai zod` in an existing app), add
   a typed tool at agent/tools/get_weather.ts, run it with `npm run dev`, then create a session, stream
   it, and send a follow-up.

package/docs/guides/auth-and-route-protection.md

@@ -3,7 +3,7 @@ title: "Auth & Route Protection"
 description: "Secure your agent's HTTP routes with an ordered auth walk, verifier helpers, and connection OAuth via Vercel Connect."
 ---
 
-Eve has two independent auth systems:
+eve has two independent auth systems:
 
 - **Route auth** (inbound) decides who can reach your agent's HTTP routes. It runs at the channel layer, gating the request before any model work runs.
 - **Tool and connection auth** (outbound) is how your agent signs in to an external service it calls, like an OAuth MCP server. It happens later, when a tool or connection actually reaches out.
@@ -18,7 +18,7 @@ The route-auth policy lives on the HTTP channel factory (`agent/channels/eve.ts`
 - `POST /eve/v1/session/:sessionId`
 - `GET /eve/v1/session/:sessionId/stream`
 
-These routes are protected by the channel's auth policy. Eve fails closed by default: production browser traffic is rejected unless you configure an authenticator that accepts it, and anonymous access requires an explicit `none()`.
+These routes are protected by the channel's auth policy. eve fails closed by default: production browser traffic is rejected unless you configure an authenticator that accepts it, and anonymous access requires an explicit `none()`.
 
 `GET /eve/v1/health` is always public and skips the walk entirely, so load balancers and uptime monitors can probe it without credentials.
 
@@ -33,7 +33,7 @@ export default eveChannel({
 
 ## The ordered auth walk
 
-`auth` takes a single `AuthFn` or an array that Eve walks in order. Each entry has three possible outcomes:
+`auth` takes a single `AuthFn` or an array that eve walks in order. Each entry has three possible outcomes:
 
 - returns a `SessionAuthContext`: accept the request and stop the walk
 - returns `null` / `undefined`: skip to the next entry
@@ -92,7 +92,7 @@ Any other thrown error follows the normal channel failure path. When building a
 | `httpBasic(...)` | Operator or service access via a shared username/password.                |
 | `jwtHmac(...)`   | You control a shared-secret JWT signer.                                   |
 | `jwtEcdsa(...)`  | You verify asymmetric JWTs minted by another system.                      |
-| `oidc(...)`      | You want Eve to verify OIDC-issued tokens from an arbitrary issuer.       |
+| `oidc(...)`      | You want eve to verify OIDC-issued tokens from an arbitrary issuer.       |
 
 Exercise caution for agents that process non-public, sensitive, regulated, or production data unless you have implemented other access controls.
 
@@ -199,7 +199,7 @@ export default eveChannel({
 });
 ```
 
-In production, `placeholderAuth()` returns a structured `401` so a generated web chat app can say "auth isn't configured yet" instead of throwing an internal error. Replace it before a browser caller submits a production request: swap in your app's `AuthFn` or one of the shipped helpers. Delete the authored channel file entirely and Eve falls back to the framework default `[localDev(), vercelOidc()]`, which also rejects production browser traffic.
+In production, `placeholderAuth()` returns a structured `401` so a generated web chat app can say "auth isn't configured yet" instead of throwing an internal error. Replace it before a browser caller submits a production request: swap in your app's `AuthFn` or one of the shipped helpers. Delete the authored channel file entirely and eve falls back to the framework default `[localDev(), vercelOidc()]`, which also rejects production browser traffic.
 
 Keep secret values (`ROUTE_AUTH_BASIC_PASSWORD`, signing keys) in environment variables. Route-auth secrets never land in compiled artifacts. The runtime re-materializes them from the authored channel definition at boot.
 
@@ -218,7 +218,7 @@ Route auth does not enforce session ownership. If multiple users or tenants can
 
 ## Tool and connection auth
 
-Tool and connection auth is how your agent reaches an external service that wants an interactive sign-in, like an OAuth MCP server. Both a connection and an individual tool can declare an `auth` strategy; Eve drives the sign-in, caches the token per step, and re-runs the call once the caller authorizes.
+Tool and connection auth is how your agent reaches an external service that wants an interactive sign-in, like an OAuth MCP server. Both a connection and an individual tool can declare an `auth` strategy; eve drives the sign-in, caches the token per step, and re-runs the call once the caller authorizes.
 
 ### On a connection
 

package/docs/guides/client/continuations.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Continuations"
-description: "Persist and resume Eve client sessions with continuation tokens, session IDs, and stream cursors."
+description: "Persist and resume eve client sessions with continuation tokens, session IDs, and stream cursors."
 ---
 
-Every Eve client turn returns two handles, and mixing them up is a common mistake. The TypeScript client tracks both for you:
+Every eve client turn returns two handles, and mixing them up is a common mistake. The TypeScript client tracks both for you:
 
 - `continuationToken`: the resume handle. Use it to send the next user turn.
 - `sessionId`: the stream-and-inspect handle. Use it to attach to event history.
@@ -115,4 +115,4 @@ for await (const event of session.stream()) {
 
 - [Streaming](./streaming): stream events and reconnect by index
 - [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming): the raw HTTP contract
-- [Eve channel](../../channels/eve): where continuation tokens come from
+- [eve channel](../../channels/eve): where continuation tokens come from

package/docs/guides/client/output-schema.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Output Schema"
-description: "Request structured results from Eve client turns and read typed data from MessageResult."
+description: "Request structured results from eve client turns and read typed data from MessageResult."
 ---
 
 Pass `outputSchema` on a client turn when the caller needs structured data instead of only assistant text. The runtime makes the model satisfy the schema before the turn settles, then emits the final payload as `result.completed`.

package/docs/guides/client/overview.mdx

@@ -1,9 +1,9 @@
 ---
 title: "TypeScript SDK Overview"
-description: "Call an Eve agent from TypeScript with Client, sessions, auth, and health checks."
+description: "Call an eve agent from TypeScript with Client, sessions, auth, and health checks."
 ---
 
-The `eve/client` entrypoint is the typed client for Eve's default HTTP API. Use it from scripts, server-to-server integrations, tests, evals, backend jobs, or custom UIs that want the session protocol without hand-writing the POST and NDJSON (newline-delimited JSON) stream loop.
+The `eve/client` entrypoint is the typed client for eve's default HTTP API. Use it from scripts, server-to-server integrations, tests, evals, backend jobs, or custom UIs that want the session protocol without hand-writing the POST and NDJSON (newline-delimited JSON) stream loop.
 
 For browser chat UIs, start with [`useEveAgent`](../frontend/overview). For wire-level details, read [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming). The client sits between those two: lower level than the frontend hooks, higher level than raw HTTP.
 
@@ -19,7 +19,7 @@ const client = new Client({
 });
 ```
 
-`host` is the origin where the Eve routes are mounted. In a same-origin browser integration this is often `""`; scripts and backend services usually name the full URL.
+`host` is the origin where the eve routes are mounted. In a same-origin browser integration this is often `""`; scripts and backend services usually name the full URL.
 
 ## Check health
 
@@ -34,7 +34,7 @@ Non-2xx responses throw `ClientError`, which carries the HTTP `status` and respo
 
 ## Authentication
 
-Pass `auth` when the [Eve channel](../../channels/eve) route requires credentials:
+Pass `auth` when the [eve channel](../../channels/eve) route requires credentials:
 
 ```ts
 const client = new Client({
@@ -111,6 +111,6 @@ The next pages cover the session lifecycle:
 
 ## What to read next
 
-- [Eve channel](../../channels/eve): the HTTP API this client calls
+- [eve channel](../../channels/eve): the HTTP API this client calls
 - [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming): the raw HTTP contract
 - [Frontend](../frontend/overview): browser UI with `useEveAgent`

package/docs/guides/client/streaming.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Streaming"
-description: "Consume Eve client stream events live, reconnect by event index, and aggregate turn results."
+description: "Consume eve client stream events live, reconnect by event index, and aggregate turn results."
 ---
 
 Every `ClientSession.send()` call posts the turn, then reads the session's NDJSON (newline-delimited JSON) event stream. `MessageResponse` gives you two ways to consume that stream, aggregating it with `result()` or iterating it live.

package/docs/guides/deployment.md

@@ -1,9 +1,9 @@
 ---
 title: "Deployment"
-description: "A production checklist for shipping an Eve agent on Vercel, covering build output, env and secrets, sandbox backend, prewarm, auth, deploy, and verify."
+description: "A production checklist for shipping an eve agent on Vercel, covering build output, env and secrets, sandbox backend, prewarm, auth, deploy, and verify."
 ---
 
-Eve runs the same way locally and on Vercel, so taking an agent from `eve dev` to production is mostly mechanical. Work through this checklist in order.
+eve runs the same way locally and on Vercel, so taking an agent from `eve dev` to production is mostly mechanical. Work through this checklist in order.
 
 ## 1. Build
 
@@ -13,7 +13,7 @@ Eve runs the same way locally and on Vercel, so taking an agent from `eve dev` t
 eve build
 ```
 
-When `VERCEL` is set (every hosted Vercel build sets it), `eve build` writes the Vercel output bundle under `.vercel/output`. A plain local `eve build` skips that bundle. Either way you get Eve's compiled framework artifacts under `.eve/`, including the discovery manifest, compiled manifest, diagnostics, and module map. Open those to see which authored surface a deployment will load. For the artifact guide and what to do when `eve build` fails, see [Observability](./instrumentation).
+When `VERCEL` is set (every hosted Vercel build sets it), `eve build` writes the Vercel output bundle under `.vercel/output`. A plain local `eve build` skips that bundle. Either way you get eve's compiled framework artifacts under `.eve/`, including the discovery manifest, compiled manifest, diagnostics, and module map. Open those to see which authored surface a deployment will load. For the artifact guide and what to do when `eve build` fails, see [Observability](./instrumentation).
 
 ## 2. Environment variables and secrets
 
@@ -37,11 +37,11 @@ export default defineSandbox({
 });
 ```
 
-Leave `backend` off and Eve falls back to `defaultBackend()`, which picks the Vercel backend on hosted builds and the local backend everywhere else. One definition, both environments.
+Leave `backend` off and eve falls back to `defaultBackend()`, which picks the Vercel backend on hosted builds and the local backend everywhere else. One definition, both environments.
 
 ## 4. Build-time sandbox prewarm
 
-During hosted builds, Eve prewarms reusable Vercel sandbox templates so the first session doesn't pay the cold-start cost:
+During hosted builds, eve prewarms reusable Vercel sandbox templates so the first session doesn't pay the cold-start cost:
 
 - Prewarm runs only when both `VERCEL` and `VERCEL_DEPLOYMENT_ID` are present.
 - A sandbox with no `bootstrap()` and no workspace seed files gets skipped.
@@ -103,9 +103,9 @@ Once the agent is deployed, the platform auto-detects `eve` as the framework and
 
 Agent Runs is separate from the OpenTelemetry exporters configured in [Observability](./instrumentation). Those still work and are the recommended path if you want spans in Braintrust, Datadog, or another third-party backend.
 
-## How Eve sits behind a host framework
+## How eve sits behind a host framework
 
-You can deploy an Eve app on its own, or mount it inside a host web framework that owns the rest of the site (marketing pages, a dashboard, other API routes). The host keeps its own routing and serves Eve's routes through the framework integration. Either way, the agent surface and HTTP contract are identical. For mounting Eve in Next.js (`withEve`) and the other supported frameworks, see [Frontend](./frontend/nextjs).
+You can deploy an eve app on its own, or mount it inside a host web framework that owns the rest of the site (marketing pages, a dashboard, other API routes). The host keeps its own routing and serves eve's routes through the framework integration. Either way, the agent surface and HTTP contract are identical. For mounting eve in Next.js (`withEve`) and the other supported frameworks, see [Frontend](./frontend/nextjs).
 
 ## Checklist
 

package/docs/guides/dev-tui.md

@@ -1,6 +1,6 @@
 ---
 title: "Dev TUI"
-description: "Drive an Eve agent locally in an interactive terminal UI. Chat, stream, approve tools, answer questions, tune the display, and point it at a deployment."
+description: "Drive an eve agent locally in an interactive terminal UI. Chat, stream, approve tools, answer questions, tune the display, and point it at a deployment."
 ---
 
 `eve dev` boots the local runtime and drops you into an interactive terminal UI. You chat with the agent, watch it stream, approve its tool calls, and answer the questions it asks back.
@@ -46,7 +46,7 @@ Each command echoes as an invocation line, asks through a bordered panel that ta
 
 ### Configure the model and provider
 
-Bare `/model` opens the configure menu. "Change model" runs the same searchable model picker setup uses (the Vercel AI Gateway catalog, pre-selected on the model the runtime is serving). A model change is written into your agent's authored source, and the command reports success only after Eve confirms the new id. `/model <provider/model-id>` applies one directly, skipping the menu.
+Bare `/model` opens the configure menu. "Change model" runs the same searchable model picker setup uses (the Vercel AI Gateway catalog, pre-selected on the model the runtime is serving). A model change is written into your agent's authored source, and the command reports success only after eve confirms the new id. `/model <provider/model-id>` applies one directly, skipping the menu.
 
 The provider row opens the provider questions: which model provider to use, and how to connect. Picking something other than Vercel AI Gateway shows wiring instructions for your own provider and stops there, leaving any existing setup untouched. For Vercel AI Gateway, you either paste your own `AI_GATEWAY_API_KEY` (saved straight to `.env.local`) or connect via a project. Connecting via a project asks for a Vercel team, opens that team's existing-project list (picking again re-links), then pulls the project's environment so an AI Gateway credential lands in `.env.local`. The dev server reloads env files automatically, with no restart needed.