eve 0.6.0-beta.8 → 0.7.0

package/dist/docs/public/evals/targets.mdx

@@ -0,0 +1,54 @@
+---
+title: "Targets and requirements"
+description: "Point evals at a local dev server or a deployment, and gate evals on target capabilities with requires."
+---
+
+An eval target is always an HTTP URL. `eve eval` starts a local dev server, while `eve eval --url <url>` runs against an existing server or deployment — the same eval files work for both, which is what makes evals usable as end-to-end tests in CI.
+
+The runner polls `/eve/v1/health`, verifies `/eve/v1/info`, and exposes the live target as `t.target` inside the `test` function.
+
+## Target helpers
+
+```ts title="evals/heartbeat.eval.ts"
+import { defineEval } from "eve/evals";
+
+export default defineEval({
+  requires: ["mockModels", "devRoutes"],
+  async test(t) {
+    const { sessionIds } = await t.target.dispatchSchedule("heartbeat");
+    await t.target.attachSession(sessionIds[0]!);
+    t.completed();
+    t.calledTool("send_report");
+  },
+});
+```
+
+- `t.target.fetch(path, init)` performs an authenticated fetch against the target — useful for channel and webhook ingress.
+- `t.target.dispatchSchedule(id)` triggers a [schedule](../schedules) through the dev-only schedule route and returns the session ids it created. It requires the `devRoutes` capability.
+- `t.target.attachSession(sessionId, { startIndex? })` consumes one turn from a session created outside the eval — by a channel or a schedule — so its events feed the run-level assertions.
+
+Sessions attached this way are full `EveEvalSession`s: you can keep driving them with `send` and read their event streams. The run-level assertions on `t` (`t.completed()`, `t.calledTool(...)`) read the whole run, attached sessions included.
+
+## Requirements
+
+Use `requires` to declare assumptions the runner verifies before executing an eval:
+
+| Requirement    | Means                                                                 |
+| -------------- | --------------------------------------------------------------------- |
+| `"mockModels"` | `/eve/v1/info` reports the deterministic mock model adapter is active |
+| `"devRoutes"`  | `/eve/v1/info` reports dev-only routes are mounted                    |
+| `"env:NAME"`   | The eval process has environment variable `NAME` set                  |
+
+Unmet requirements produce a visible `skipped` verdict and do not affect the exit code. Pass `--no-skips` when a CI leg must prove full coverage.
+
+## Mock models
+
+Deterministic evals — the kind you want in CI — should not depend on a live model. `eve eval --mock-models` starts the local dev server with deterministic authored models, and `requires: ["mockModels"]` makes the dependency explicit so the eval skips instead of flaking anywhere else.
+
+`--mock-models` is invalid with `--url` because remote target capabilities are discovered, not set by the runner. For evals that genuinely need a real model — judging nuanced behavior, exercising provider-side tools — gate them on credentials instead (`requires: ["env:AI_GATEWAY_API_KEY"]`) and keep them in their own eval files so a tag filter can select or exclude them.
+
+## What to read next
+
+- [Running evals](./running): `--url`, `--mock-models`, and `--no-skips` in practice
+- [Schedules](../schedules): the surface `dispatchSchedule` drives
+- [Channels](../channels/overview): ingress you can exercise with `target.fetch`

package/dist/docs/public/frontend/nextjs.mdx

@@ -34,6 +34,15 @@ All fields are optional.
 | `eveBuildCommand`       | `string`  | `"eve build"`          | Build command for the generated Eve Vercel service. Use it when the Eve service needs project-specific prework, without changing the Next.js build.     |
 | `configureVercelOutput` | `boolean` | `true`                 | Set to `false` to skip creating or updating `.vercel/output/config.json`. By default `withEve` writes the `experimentalServices` entries for both apps. |
 | `servicePrefix`         | `string`  | `"/_eve_internal/eve"` | Private Vercel route namespace for the Eve service. Must match the Eve service's mount in your Vercel Build Output config when you set it manually.     |
+| `devServerTimeoutMs`    | `number`  | `180000`               | Maximum time to wait for the Eve development server to become available.                                                                                |
+
+For unusually slow cold starts, increase the development timeout:
+
+```ts
+export default withEve(nextConfig, {
+  devServerTimeoutMs: 300_000,
+});
+```
 
 ## Call the hook
 
@@ -51,25 +60,25 @@ Before deploying a user-facing app, add `agent/channels/eve.ts` so production re
 
 ## Dev vs deploy topology
 
-- **Local dev.** `pnpm dev` boots the Eve dev server next to `next dev` and rewrites the Eve routes over to it. The browser only ever talks to the Next.js origin.
+- **Local dev.** `npm run dev` boots the Eve dev server next to `next dev` and rewrites the Eve routes over to it. The browser only ever talks to the Next.js origin.
 - **Vercel.** The web app and the Eve runtime deploy as a single project. The web app stays public; the Eve runtime sits behind it on the same site origin. When the agent needs its own build step, set `eveBuildCommand`:
 
   ```ts
   export default withEve(nextConfig, {
-    eveBuildCommand: "pnpm build:eve",
+    eveBuildCommand: "npm run build:eve",
   });
   ```
 
 - **Local production build.** `next build && next start` proxies Eve routes to `http://127.0.0.1:4274`. Change the port with `EVE_NEXT_PRODUCTION_PORT`:
 
   ```bash
-  EVE_NEXT_PRODUCTION_PORT=5000 pnpm build && pnpm start
+  EVE_NEXT_PRODUCTION_PORT=5000 npm run build && npm start
   ```
 
 - **Non-Vercel hosts.** If the Eve service lives on a separate origin, tell Next.js where to find it with `EVE_NEXT_PRODUCTION_ORIGIN`:
 
   ```bash
-  EVE_NEXT_PRODUCTION_ORIGIN=https://agent.example.com pnpm build
+  EVE_NEXT_PRODUCTION_ORIGIN=https://agent.example.com npm run build
   ```
 
 ## What to read next

package/dist/docs/public/frontend/nuxt.mdx

@@ -56,14 +56,14 @@ Out of the box the module gives Eve a framework default channel. When you want t
 
 ## Dev vs deploy topology
 
-- **Local dev.** `pnpm dev` starts the Eve dev server next to `nuxt dev` and proxies the Eve routes through it. As far as the browser knows, everything is the Nuxt origin.
+- **Local dev.** `npm run dev` starts the Eve dev server next to `nuxt dev` and proxies the Eve routes through it. As far as the browser knows, everything is the Nuxt origin.
 - **Vercel.** A single Vercel project carries both the Nuxt app and the Eve runtime. The web app stays public; the runtime sits behind it on the same origin. Set `eveBuildCommand` when the agent needs its own build step:
 
   ```ts
   export default defineNuxtConfig({
     modules: ["eve/nuxt"],
     eve: {
-      eveBuildCommand: "pnpm build:eve",
+      eveBuildCommand: "npm run build:eve",
     },
   });
   ```
@@ -71,8 +71,8 @@ Out of the box the module gives Eve a framework default channel. When you want t
 - **Non-Vercel hosts.** Point Nuxt at a separate Eve origin with `EVE_NUXT_PRODUCTION_ORIGIN`. To override the local port (it defaults to `4274`), use `EVE_NUXT_PRODUCTION_PORT`:
 
   ```bash
-  EVE_NUXT_PRODUCTION_ORIGIN=https://agent.example.com pnpm build
-  EVE_NUXT_PRODUCTION_PORT=5000 pnpm build && pnpm preview
+  EVE_NUXT_PRODUCTION_ORIGIN=https://agent.example.com npm run build
+  EVE_NUXT_PRODUCTION_PORT=5000 npm run build && npm run preview
   ```
 
 ## What to read next

package/dist/docs/public/frontend/sveltekit.mdx

@@ -65,14 +65,14 @@ Out of the box the plugin uses a framework default channel. To set the route aut
 
 ## Dev vs deploy topology
 
-- **Local dev.** `pnpm dev` boots the Eve dev server next to SvelteKit and proxies the Eve routes to it, so the browser only ever hits the SvelteKit origin. `pnpm build && pnpm preview` behaves the same: the preview server gets its own Eve route proxy and either reuses the shared Eve server or starts one.
+- **Local dev.** `npm run dev` boots the Eve dev server next to SvelteKit and proxies the Eve routes to it, so the browser only ever hits the SvelteKit origin. `npm run build && npm run preview` behaves the same: the preview server gets its own Eve route proxy and either reuses the shared Eve server or starts one.
 - **Vercel.** The SvelteKit app and the Eve runtime deploy as a single project. The web app is public; the Eve runtime sits behind it on the same origin. Use `eveBuildCommand` for a project-specific agent build:
 
   ```ts
   export default defineConfig({
     plugins: [
       eveSvelteKit({
-        eveBuildCommand: "pnpm build:eve",
+        eveBuildCommand: "npm run build:eve",
       }),
       sveltekit(),
     ],

package/dist/docs/public/getting-started.mdx

@@ -8,24 +8,35 @@ Eve is a filesystem-first framework for durable agents: you write capabilities u
 ## Prerequisites
 
 - Node `24.x`
-- `pnpm`
+- npm (bundled with Node)
 
 You also need a model credential. Set the provider or gateway key your model string requires (gateway ids like `anthropic/claude-opus-4.8` route through the Vercel AI Gateway), or link a Vercel project that supplies one.
 
 ## Create Your Agent
 
-The fastest path is the `create` CLI. It scaffolds the project, prompts for a model, and wires up an optional channel:
+Run `eve init` with `npx` before Eve is installed locally:
 
 ```bash
-pnpm create eve@beta
+npx eve@latest init my-agent
 ```
 
-The wizard asks for a model and which channel you want (Web Chat or Slack). You can skip both: every app ships the built-in HTTP channel (`agent/channels/eve.ts`) regardless. For a local chat it installs dependencies and starts the dev server for you.
+The command creates an npm-managed child directory, uses Eve's default model,
+installs dependencies, initializes Git, and starts the development server. Pass
+`--channel-web-nextjs` to add the Web Chat application. Stop the server before
+editing the generated agent. The command does not create a Vercel project or
+deploy.
 
-To add Eve to an existing app instead:
+The target can also be an existing project directory (`eve init .`): the
+project must have a `package.json`, the `agent/` files must not exist yet, and
+the missing `eve`, `ai`, and `zod` dependencies are added without touching
+anything else the project owns. Either way the final handoff runs the `eve dev`
+binary through the project's package manager, never the project's own `dev`
+script.
+
+To add only the dependency to an existing app instead:
 
 ```bash
-pnpm add eve@beta
+npm install eve@latest
 ```
 
 ## What's In Your Project
@@ -38,13 +49,13 @@ The scaffold writes two files; you add tools as you need them.
 You are a concise assistant. Use tools when they are available.
 ```
 
-`agent/agent.ts` (generated; model comes from the wizard) holds runtime config:
+`agent/agent.ts` holds runtime config:
 
 ```ts
 import { defineAgent } from "eve";
 
 export default defineAgent({
-  model: "anthropic/claude-opus-4.8",
+  model: "anthropic/claude-sonnet-4.6",
 });
 ```
 
@@ -76,7 +87,7 @@ Tools run in your app runtime with full `process.env`, not inside the [sandbox](
 From the app root:
 
 ```bash
-pnpm dev
+npm run dev
 ```
 
 Useful commands:
@@ -153,10 +164,10 @@ See [Sessions, runs & streaming](./advanced/sessions-runs-and-streaming) for the
 
 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/dist/docs/public; before eve is installed, read the published Introduction and Getting Started pages. If the project has no Eve app, scaffold one with `pnpm create eve@beta`; to add Eve to an existing app, run `pnpm add eve@beta`. Make sure agent/agent.ts (which sets the model) 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. Run it locally with `pnpm dev` (or `eve dev`), 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.">
+<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/dist/docs/public; 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 before editing. To add Eve to an existing app, run `npm install eve@latest`. 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/dist/docs/public once eve is
-  installed), scaffold with `pnpm create eve@beta` (or `pnpm add eve@beta` in an existing app), add
-  a typed tool at agent/tools/get_weather.ts, run it with `pnpm dev`, then create a session, stream
+  installed), scaffold with `npx eve@latest init <name>` (or `npm install eve@latest` 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.
 </CopyPrompt>
 
@@ -164,7 +175,8 @@ Once `eve` is a dependency, the full docs are bundled in the package, so the age
 
 - Docs: `node_modules/eve/dist/docs/public/`
 
-To scaffold a project end to end, `pnpm create eve@beta` collects the decisions (name, model, channels), runs setup, adds Slack interactively with `eve channels add slack`, and verifies the result with `eve info --json`.
+`eve init <name>` creates the base agent; `eve init .` adds one to an existing project. Add `--channel-web-nextjs` for Web Chat, or run
+`eve channels add slack` later from an interactive terminal.
 
 ## What to read next
 

package/dist/docs/public/meta.json

@@ -12,6 +12,7 @@
     "sandbox",
     "subagents",
     "schedules",
+    "evals",
     "advanced",
     "frontend",
     "client",

package/dist/docs/public/reference/cli.md

@@ -14,7 +14,9 @@ The `eve` binary (`bin: eve`) runs from your app root, and every command loads `
 | `eve start`               | Serve the built `.output/` app; prints the listening URL                                                                                    |
 | `eve dev`                 | Start the local dev server and open the terminal UI                                                                                         |
 | `eve dev <url>`           | Connect the UI to an existing server URL (e.g. a remote deployment) instead of booting a local server                                       |
-| `eve eval`                | Run eval suites against the local app or a remote target                                                                                    |
+| `eve link`                | Link the directory to a Vercel project and pull AI Gateway credentials                                                                      |
+| `eve deploy`              | Deploy the agent to Vercel production (links first if needed)                                                                               |
+| `eve eval`                | Run evals against the local app or a remote target                                                                                          |
 | `eve channels add [kind]` | Scaffold a channel interactively, or by kind (`slack` \| `web`)                                                                             |
 | `eve channels list`       | List user-authored channels                                                                                                                 |
 
@@ -77,7 +79,6 @@ Pass a bare URL as the only argument and the UI connects to that server instead
 | `--host <host>`                     | Host interface to bind                                                                    |
 | `--port <port>`                     | Port to listen on (defaults to `$PORT`, then `3000`)                                      |
 | `-u, --url <url>`                   | Connect to an existing server URL instead of starting one                                 |
-| `--repl`                            | Use the classic line-based REPL instead of the terminal UI                                |
 | `--no-ui`                           | Start the server without an interactive UI                                                |
 | `--name <name>`                     | Title shown in the terminal UI (defaults to the app folder name)                          |
 | `--tools <mode>`                    | Tool-call rendering: `full` \| `collapsed` \| `auto-collapsed` \| `hidden`                |
@@ -88,23 +89,44 @@ Pass a bare URL as the only argument and the UI connects to that server instead
 | `--context-size <tokens>`           | Model context window size, shown as a usage percentage                                    |
 | `--logs <mode>`                     | Server/agent logs to show: `all` \| `stderr` \| `none`                                    |
 
+Local dev keeps immutable runtime source snapshots under `.eve/dev-runtime/snapshots/` so in-flight sessions keep a consistent code revision while new prompts pick up rebuilds. `eve dev` prunes stale runtime snapshots and old local sandbox templates in the background on startup; stopping `eve dev` and deleting `.eve/dev-runtime/snapshots/` or `.eve/sandbox-cache/local/templates/` is safe when you want a manual cleanup.
+
+## `eve link`
+
+```bash
+eve link
+```
+
+Links the current directory to a Vercel project through interactive team/project pickers, then pulls the project's environment so an AI Gateway credential (`VERCEL_OIDC_TOKEN` or `AI_GATEWAY_API_KEY`) lands in `.env.local`, and verifies one actually did. Running it again re-links: the pickers always run, and the new choice wins. Interactive only — in CI, use `vercel link --project <name> --yes` instead. A running `eve dev` reloads env files automatically, so no restart is needed after the pull.
+
+## `eve deploy`
+
+```bash
+eve deploy
+```
+
+Deploys the agent to Vercel production (`vercel deploy --prod`), installing dependencies first and pulling environment variables after. An already-linked project deploys with or without a TTY (non-interactive runs pass the non-interactive `vercel` flags); an unlinked directory walks the `eve link` pickers when a terminal is present, and exits with guidance otherwise.
+
 ## `eve eval`
 
 ```bash
-eve eval [--suite <id...>] [--all] [--url <url>] [options]
+eve eval [evalId...] [--url <url>] [options]
 ```
 
+Runs all discovered evals when no eval ids are given; ids match exactly or by directory prefix (`eve eval weather` runs everything under `evals/weather/`). Exits `0` when every eval passed its checks, `1` when any eval failed (a failed check, an execution error, or a `--strict` threshold miss), `2` on configuration errors.
+
 | Flag                    | Effect                                         |
 | ----------------------- | ---------------------------------------------- |
-| `--suite <id...>`       | Suite IDs to run (repeatable)                  |
-| `--all`                 | Run all discovered suites                      |
 | `--url <url>`           | Remote agent URL (skip local host startup)     |
-| `--timeout <ms>`        | Per-case timeout in milliseconds               |
-| `--max-concurrency <n>` | Max concurrent case executions per suite       |
+| `--tag <tag...>`        | Run only evals carrying a tag                  |
+| `--strict`              | Below-threshold scores also fail the exit code |
+| `--list`                | Print discovered evals without running them    |
+| `--timeout <ms>`        | Per-eval timeout in milliseconds               |
+| `--max-concurrency <n>` | Max concurrent eval executions (default 8)     |
 | `--json`                | Output results as JSON                         |
-| `--skip-report`         | Skip suite-defined reporters (e.g. Braintrust) |
+| `--skip-report`         | Skip eval-defined reporters (e.g. Braintrust)  |
 
-See [Evals](../advanced/evals) for authoring suites.
+See [Evals](../evals/overview) for authoring evals.
 
 ## Recommended loop
 

package/dist/docs/public/reference/typescript-api.md

@@ -46,7 +46,8 @@ export default defineTool({
 | `defineSandbox`                                        | `eve/sandbox`                                 | `agent/sandbox.ts`                   | [Sandbox](../sandbox)                                    |
 | `defineInstrumentation`                                | `eve/instrumentation`                         | `agent/instrumentation.ts`           | [instrumentation.ts](../advanced/instrumentation)        |
 | `defineRemoteAgent`                                    | `eve`                                         | `agent/subagents/<id>/agent.ts`      | [Remote agents](../advanced/remote-agents)               |
-| `defineEvalSuite`                                      | `eve/evals`                                   | `agent/evals/*.eval.ts`              | [Evals](../advanced/evals)                               |
+| `defineEval`                                           | `eve/evals`                                   | `evals/*.eval.ts`                    | [Evals](../evals/overview)                               |
+| `defineEvalConfig`                                     | `eve/evals`                                   | `evals/evals.config.ts`              | [Evals](../evals/overview)                               |
 | `useEveAgent`                                          | `eve/react`, `eve/vue`, `eve/svelte`          | frontend                             | [Frontend](../frontend/overview)                         |
 
 A few non-`define*` helpers round out the set: `disableTool` and `ExperimentalWorkflow` from `eve/tools` (see [Default harness](../advanced/default-harness)), the route verbs `GET`/`POST`/`PUT`/`PATCH`/`DELETE`/`WS` from `eve/channels`, the approval predicates `always`/`once`/`never` from `eve/tools/approval`, and the channel auth helpers `localDev`/`vercelOidc`/`placeholderAuth` from `eve/channels/auth`. To wrap a built-in tool, import its default value from `eve/tools/defaults` (`bash`, `readFile`, `writeFile`, `glob`, `grep`, `webFetch`, `webSearch`, `todo`, `loadSkill`).
@@ -83,7 +84,10 @@ A few non-`define*` helpers round out the set: `disableTool` and `ExperimentalWo
 | `eve/context`                                               | `defineState`, session and state types                               |
 | `eve/sandbox`                                               | `defineSandbox`, backends                                            |
 | `eve/instrumentation`                                       | `defineInstrumentation`, `isChannel`                                 |
-| `eve/evals`                                                 | `defineEvalSuite`, loaders, scorers, reporters                       |
+| `eve/evals`                                                 | `defineEval`, `defineEvalConfig`, eval types                         |
+| `eve/evals/expect`                                          | `includes`, `equals`, `matches`, `similarity`                        |
+| `eve/evals/reporters`                                       | `Braintrust`, `JUnit`, `EvalReporter`                                |
+| `eve/evals/loaders`                                         | `loadJson`, `loadYaml`                                               |
 | `eve/react`, `eve/vue`, `eve/svelte`                        | `useEveAgent`                                                        |
 | `eve/next`, `eve/nuxt`, `eve/sveltekit`                     | framework bundler plugins                                            |
 | [`eve/client`](../client/overview)                          | `Client`, `ClientSession`                                            |

package/dist/docs/public/sandbox.mdx

@@ -130,13 +130,15 @@ export default defineSandbox({
 });
 ```
 
+In local development, `localBackend()` stores template and session files as normal directories under `.eve/sandbox-cache/local/`. Template directories are reused across sessions when the sandbox source, seed files, and `revalidationKey` still match; `eve dev` prunes stale local templates in the background. Session directories persist `/workspace` changes across turns for the same durable session.
+
 You can write your own backend too: a `SandboxBackend` is just an object with a `name`, a `create`, and an optional `prewarm`. See the `SandboxBackend*` types on `eve/sandbox`.
 
 ## Lifecycle
 
 There are two hooks, scoped differently:
 
-- **`bootstrap({ use })`** is template-scoped and runs once when the template is built. Put reusable setup here, the kind every later session inherits: clone a baseline repo, install dependencies, seed files. Call `use()` to get a `SandboxSession`. Only filesystem state survives snapshotting; config like network policy does not. If external inputs affect what bootstrap produces, set `revalidationKey: () => string` so Eve knows when to rebuild the template (authored sandbox source and seed contents are already tracked for you).
+- **`bootstrap({ use })`** is template-scoped and runs once when the template is built. Put reusable setup here, the kind every later session inherits: clone a baseline repo, install dependencies, seed files. Call `use()` to get a `SandboxSession`. Only template filesystem state and supported backend metadata carry into later sessions; config like network policy does not. If external inputs affect what bootstrap produces, set `revalidationKey: () => string` so Eve knows when to rebuild the template (authored sandbox source and seed contents are already tracked for you).
 - **`onSession({ use, ctx })`** is durable-session-scoped and runs once per session. This is where per-session setup goes: network policy, resources, timeout, per-user credentials, one-time markers. Because it runs inside the active runtime context, it can read `ctx.session` and derive the current principal without baking credentials into the template. Call `use(opts?)` to get a `SandboxSession`; `opts` flow to the backend's update path after create.
 
 ```ts

package/dist/docs/public/tools.mdx

@@ -99,10 +99,6 @@ toModelOutput(output) {
 
 It receives the full, typed `execute` return and only affects the model. Channel event handlers and hooks still get the full output on `action.result`, so a channel can render rich platform output (Slack Block Kit, say) the model never sees. Return `{ type: "text", value }` for a summary, or `{ type: "json", value }` for a smaller object.
 
-## Survive compaction with `onCompact`
-
-When the harness [compacts history](./advanced/default-harness#compaction), it calls each tool's `onCompact(input, ctx)` in registration order and applies the merged result to the compacted session. Return nothing to leave things alone, `messages` to append to the compacted history, or a `sessionPatch` to shallow-merge into session state. It works on the projected output (what the model sees), and a throw fails the compaction step, so don't swallow errors.
-
 ## What to read next
 
 - [Skills](./skills): on-demand procedures the model loads when relevant

package/dist/docs/public/tutorial/connect-a-warehouse.mdx

@@ -24,7 +24,7 @@ export default defineMcpClientConnection({
 
 `"warehouse"` is the UID you chose when registering the Connect client. By default this OAuth is user-scoped. Each end-user authorizes in their own browser, and Eve resolves that user's token before every tool call.
 
-Connect is in private beta. Once enabled: `pnpm add @vercel/connect`, create the Connect client (`vercel connect create <type> --name warehouse`), link it to your project, then `vercel link` and `vercel env pull` so `VERCEL_OIDC_TOKEN` is available locally. Full setup: [Connections](../connections).
+Connect is in private beta. Once enabled: `npm install @vercel/connect`, create the Connect client (`vercel connect create <type> --name warehouse`), link it to your project, then `vercel link` and `vercel env pull` so `VERCEL_OIDC_TOKEN` is available locally. Full setup: [Connections](../connections).
 
 ## What the user sees
 

package/dist/docs/public/tutorial/first-agent.mdx

@@ -10,10 +10,13 @@ Step 1 gets it talking. The scaffold bundles a small sample dataset, so your fir
 ## Scaffold
 
 ```bash
-pnpm create eve@beta
+npx eve@latest init analytics-assistant
 ```
 
-The wizard prompts for a model and which channels to add (Web Chat or Slack). Skip both for this tutorial: every app ships the built-in HTTP API channel (`agent/channels/eve.ts`). The wizard then installs dependencies and writes a starter `agent/`.
+The command writes the starter agent with Eve's default model and built-in HTTP API
+channel (`agent/channels/eve.ts`), installs dependencies, initializes Git, and
+starts the development server. Stop the server before continuing with the edits
+below. It does not create a Vercel project or deploy.
 
 ## Set the model