eve 0.6.0-beta.9 → 0.7.2

package/dist/docs/public/{client → guides/client}/overview.mdx

@@ -1,11 +1,11 @@
 ---
-title: "TypeScript Client"
+title: "Overview"
 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 stream loop.
 
-For browser chat UIs, start with [`useEveAgent`](../frontend/overview). For wire-level details, read [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming). The client sits between those two: lower level than the frontend hooks, higher level than raw HTTP.
+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.
 
 ## Create a client
 
@@ -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
-- [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming): the raw HTTP contract
+- [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/dist/docs/public/{client → guides/client}/streaming.mdx

@@ -74,7 +74,7 @@ The most common UI events are:
 | `session.completed`  | Mark the conversation terminal.                                  |
 | `session.failed`     | Mark the conversation failed.                                    |
 
-For the complete event table, see [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming).
+For the complete event table, see [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming).
 
 ## Reconnection
 

package/dist/docs/public/{advanced → guides}/deployment.md

@@ -66,7 +66,7 @@ The deployed app serves the same stable health, session, and stream routes you'v
 
 ## 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. For mounting Eve in Next.js (`withEve`) and the other supported frameworks, see [Frontend](../frontend/nextjs). Either way, the agent surface and HTTP contract are identical.
+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. For mounting Eve in Next.js (`withEve`) and the other supported frameworks, see [Frontend](./frontend/nextjs). Either way, the agent surface and HTTP contract are identical.
 
 ## 7. Verify the deployment
 
@@ -98,6 +98,14 @@ eve dev https://<your-app>
 
 (Set `VERCEL_AUTOMATION_BYPASS_SECRET` locally first if the deployment uses preview protection.)
 
+## View runs in the dashboard
+
+Once the agent is deployed, the platform auto-detects `eve` as the framework and surfaces an **Agent Runs** tab under your project's **Observability** view in the Vercel dashboard. From there you can browse sessions and drill into each conversation's trace.
+
+> The Agent Runs tab is currently gated: your Vercel team needs the feature enabled before it appears. If you don't see it, reach out to your Vercel contact to get your team enabled.
+
+Agent Runs is separate from the OpenTelemetry exporters configured in [`instrumentation.ts`](./instrumentation). Those still work and are the recommended path if you want spans in Braintrust, Datadog, or another third-party backend.
+
 ## Checklist
 
 - [ ] `eve build` succeeds and writes `.vercel/output`.

package/dist/docs/public/guides/dev-tui.md

@@ -0,0 +1,50 @@
+---
+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."
+---
+
+`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:
+
+```bash
+eve dev
+```
+
+On startup the TUI prints a brand line with your agent's name, plus a rotating tip (local sessions only):
+
+```text
+ ▲ eve weather-agent
+ Use /channels to add more ways to reach your agent.
+```
+
+If agent discovery reported problems, an error/warning count renders between the two lines. Instructions, tools, skills, and subagents are one `eve info` away, and `/help` lists every command.
+
+From there the conversation streams straight into your terminal's normal scrollback — your prompts, the agent's replies, reasoning, tool calls, nested subagents, connection-authorization prompts, and any captured `stdout`/`stderr` — so you keep native scrolling, copy/paste, and a transcript that persists after you exit. Each turn is rendered without boxes: a colored gutter glyph marks who's speaking, tool calls collapse to a one-line summary (`✓ get_weather  city="SF" → 73°F`), and a subagent's work is indented beneath its `◆` header. A sticky footer keeps you oriented. The input prompt shows a dim `Type to chat · / for commands` placeholder while empty, and beneath it a persistent status line shows the model, the session's token flow (`⁕ ↑ 394.4K ↓ 4.3K`), the linked Vercel project and team (`▲ my-agent (acme)`), and a yellow `deploy pending` marker once a channel added this session still needs `/deploy`. The Vercel segment stays hidden until the directory is linked. Press `Enter` to send; `Ctrl+C` interrupts a running turn or quits at the prompt. Slash commands: `/new` starts a fresh session and `/exit` quits.
+
+When `eve dev` runs the server locally, three more slash commands manage the project without leaving the session. Bare `/model` opens a two-row configure menu that loops until Esc. "Change model" runs the same searchable model picker setup uses (the 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 (picking something other than AI Gateway shows wiring instructions for your own provider and stops there, leaving any existing setup untouched) and how to connect to AI Gateway — paste your own `AI_GATEWAY_API_KEY`, saved straight to `.env.local`, or connect via a project, which walks the same Vercel team/project pickers as setup (picking again re-links) and pulls the project's environment so an AI Gateway credential lands in `.env.local`; the dev server reloads env files automatically, no restart needed. The row demands attention (a bold yellow "Configure provider" with "Required to enable the agent") until a link or gateway credential is detected, then names the connection (e.g. "AI Gateway (Linked to my-project in my-team)") after, and each action's latest outcome stays visible beneath the menu (e.g. "✓ Model changed to openai/gpt-5.5"). `/channels` shows the agent's channel list — already-registered channels render as locked rows — and adds the one you pick, including the Slack Connect provisioning, then installs the dependencies the scaffold added so the dev server can load the new channels right away; after each addition the list repaints with the new channel locked, until Done (or Esc) leaves the flow. `/deploy` ships the agent to Vercel production, linking first when the directory is unlinked. Each command echoes as an invocation line, asks through a bordered panel that takes the input area's place — one question at a time, clearly separate from the chat transcript — and finishes with a one-line `⎿` result; loading states stay on the ephemeral status line instead of piling into the transcript. These commands are not available when connected to a remote server with `--url`, and when a turn fails because AI Gateway authentication is missing or stale, the error points you at `/model` directly. The TUI also checks at startup: a missing model-provider setup surfaces as an attention line — `⚠ 1 setup issue: model provider not linked · /model` — so the fix is visible before the first message fails, and each command's outcome hangs under it with the `⎿` connector.
+
+The prompt input behaves like a shell line editor: `↑`/`↓` cycle through the messages you've sent this session, `←`/`→`, Home/End, and `Ctrl+A`/`Ctrl+E` move the caret, and `Ctrl+U`/`Ctrl+K`/`Ctrl+W` kill the line, the rest of the line, or the previous word. If a turn fails terminally — the server session dies or the connection drops — the TUI starts a fresh session and notes it inline so you can keep going (server-side context resets with the old session). Errors render compactly, with docs links highlighted, and a code bug escaping your agent's own code shows its stack trace dim beneath the error headline. Captured server `stdout`/`stderr` renders as dim, indented log runs behind a `│` rule — consecutive lines from the same source share one label. Dev-server rebuilds condense further, into one status row that updates in place: `tui/setup-panel.ts changed · rebuilding…`, then `· rebuilt`. Only the latest rebuild shows, and paths shrink to their last two components. The TUI hides logs by default. `/loglevel <all|stderr|none>` switches what the transcript shows, and because logs stay buffered either way, the switch is retroactive: `/loglevel all` brings back everything captured so far, in its original order. Bare `/loglevel` reports the current mode; the `--logs` flag sets the starting one.
+
+The agent will sometimes need something from you, and the TUI asks inline. Tool approvals are a `y`/`n`. Option questions let you pick with `↑`/`↓` and `Enter`, or you can type a freeform answer. If a tool needs an authorized [connection](../connections), the URL shows up right in the transcript, and the turn picks back up once you've finished the flow.
+
+Density flags accept `full` / `collapsed` / `auto-collapsed` / `hidden`:
+
+```bash
+eve dev --tools full --assistant-response-stats tokens --context-size 200000
+```
+
+Other useful flags: `--subagents`, `--reasoning`, `--logs <all|stderr|none>`, `--host`/`--port`, and `--no-ui` (headless, also the automatic fallback when stdout isn't a TTY).
+
+## Remote: `eve dev <url>`
+
+Pass a URL and the TUI talks to a running deployment instead of spinning up a local server. That's handy for a Vercel preview or your production app:
+
+```bash
+eve dev https://<your-app>
+```
+
+The bare URL is shorthand for `--url`. `--host`, `--port`, and `--no-ui` are ignored against a remote target. If the deployment sits behind Vercel preview protection, set `VERCEL_AUTOMATION_BYPASS_SECRET` locally first. See [Deployment](./deployment) for the smoke-test flow.
+
+## What to read next
+
+- [instrumentation.ts](./instrumentation): OpenTelemetry, hooks, and the error catalog.
+- [CLI](../reference/cli): every command and flag.

package/dist/docs/public/{advanced → guides}/dynamic-capabilities.md

@@ -124,6 +124,6 @@ Both resolve before the prompt is assembled, so the model sees the right instruc
 ## What to read next
 
 - The static tool basics this builds on → [Tools](../tools)
-- The built-in tools and how to override them → [Default harness](./default-harness)
+- The built-in tools and how to override them → [Default harness](../concepts/default-harness)
 - Authenticate a tool or connection to an external service → [Auth & route protection](./auth-and-route-protection)
 - Durable per-session memory for resolvers to read → [State](./state)

package/dist/docs/public/{advanced → guides}/dynamic-workflows.md

@@ -52,4 +52,4 @@ Code mode is the broader version: the model drives _all_ of an agent's tools (fi
 
 - Declare the subagents a workflow orchestrates → [Subagents](../subagents)
 - Call another deployment as one of those agents → [Remote agents](./remote-agents)
-- The `agent/tools/` opt-in mechanism → [Default harness](./default-harness)
+- The `agent/tools/` opt-in mechanism → [Default harness](../concepts/default-harness)

package/dist/docs/public/{frontend → guides/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
 
@@ -47,33 +56,33 @@ const agent = useEveAgent({
 });
 ```
 
-Before deploying a user-facing app, add `agent/channels/eve.ts` so production requests run your app's auth policy. See [Channels](../channels/overview) and [Auth & route protection](../advanced/auth-and-route-protection).
+Before deploying a user-facing app, add `agent/channels/eve.ts` so production requests run your app's auth policy. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
 
 ## 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
 
 - [Frontend overview](./overview): the `useEveAgent` API
-- [Auth & route protection](../advanced/auth-and-route-protection)
-- [Deployment](../advanced/deployment)
+- [Auth & route protection](../auth-and-route-protection)
+- [Deployment](../deployment)

package/dist/docs/public/{frontend → guides/frontend}/nuxt.mdx

@@ -52,18 +52,18 @@ async function handleSubmit() {
 </template>
 ```
 
-Out of the box the module gives Eve a framework default channel. When you want to pick the route auth policy yourself, add `agent/channels/eve.ts` and swap `none()` for a helper like `vercelOidc()` on protected apps. See [Channels](../channels/overview) and [Auth & route protection](../advanced/auth-and-route-protection).
+Out of the box the module gives Eve a framework default channel. When you want to pick the route auth policy yourself, add `agent/channels/eve.ts` and swap `none()` for a helper like `vercelOidc()` on protected apps. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
 
 ## 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,12 +71,12 @@ 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
 
 - [`useEveAgent` (Vue)](./use-eve-agent-vue): the composable API
-- [Auth & route protection](../advanced/auth-and-route-protection)
-- [Deployment](../advanced/deployment)
+- [Auth & route protection](../auth-and-route-protection)
+- [Deployment](../deployment)

package/dist/docs/public/{frontend → guides/frontend}/overview.mdx

@@ -7,14 +7,14 @@ The frontend helpers put a browser chat or agent UI on top of an Eve agent. `use
 
 ## The integration model
 
-A browser UI is just a client of the agent's HTTP routes (the [Eve channel](../channels/overview)). Two layers wire it up:
+A browser UI is just a client of the agent's HTTP routes (the [Eve channel](../../channels/overview)). Two layers wire it up:
 
 - **The framework integration** mounts the Eve routes on your app's origin, so the browser never crosses a CORS boundary or reads an env var to find the agent. Pick yours: [Next.js](./nextjs) (`withEve`), [Nuxt](./nuxt) (the `eve/nuxt` module), or [SvelteKit](./sveltekit) (the `eveSvelteKit` Vite plugin). On any other stack the hook talks to same-origin `/eve/v1/*` routes directly, or you pass an explicit `host`.
 - **The hook** (`useEveAgent`) holds the session state, streaming, errors, and composer status. It defaults to same-origin Eve routes such as `/eve/v1/session`.
 
 For a guided setup, the [Guides](/docs/skills/eve-add-next) walk through the wiring step by step: [add a Next.js frontend to an existing Eve agent](/docs/skills/eve-add-next), or [add Eve to an existing Next.js app](/docs/skills/eve-add-agent).
 
-For scripts, server-to-server calls, evals, tests, or custom clients that do not need framework UI state, use the [TypeScript Client](../client/overview) directly.
+For scripts, server-to-server calls, evals, tests, or custom clients that do not need framework UI state, use the [TypeScript SDK](../client/overview) directly.
 
 ## Basic chat (React)
 
@@ -100,7 +100,7 @@ Assistant text, reasoning, tool calls, and tool results stream into `data` as th
 
 ## Human-in-the-loop prompts
 
-Tools opt into approval with `needsApproval` on the [server side](../tools), and the model can also ask a question with `ask_question`. Either way the stream emits an `input.requested` event, and the pending request rides on a `dynamic-tool` part of the latest message at `part.toolMetadata?.eve?.inputRequest`. Read it, then answer through the same session with `send()`:
+Tools opt into approval with `needsApproval` on the [server side](../../tools), and the model can also ask a question with `ask_question`. Either way the stream emits an `input.requested` event, and the pending request rides on a `dynamic-tool` part of the latest message at `part.toolMetadata?.eve?.inputRequest`. Read it, then answer through the same session with `send()`:
 
 ```tsx
 const request = agent.data.messages
@@ -228,7 +228,7 @@ const agent = useEveAgent({
 
 ## What to read next
 
-- [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming): the event stream and session cursor
-- [Channels](../channels/overview): the HTTP routes the hook talks to
-- [TypeScript Client](../client/overview): the lower-level client underneath the frontend hooks
+- [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming): the event stream and session cursor
+- [Channels](../../channels/overview): the HTTP routes the hook talks to
+- [TypeScript SDK](../client/overview): the lower-level client underneath the frontend hooks
 - [Guides](/docs/skills/eve-add-next): step-by-step guides for wiring Eve into Next.js

package/dist/docs/public/{frontend → guides/frontend}/sveltekit.mdx

@@ -61,18 +61,18 @@ With the plugin in `vite.config.ts`, components call [`useEveAgent`](./use-eve-a
 </form>
 ```
 
-Out of the box the plugin uses a framework default channel. To set the route auth policy yourself, add `agent/channels/eve.ts` and swap `none()` for a helper like `vercelOidc()` on protected apps. See [Channels](../channels/overview) and [Auth & route protection](../advanced/auth-and-route-protection).
+Out of the box the plugin uses a framework default channel. To set the route auth policy yourself, add `agent/channels/eve.ts` and swap `none()` for a helper like `vercelOidc()` on protected apps. See [Channels](../../channels/overview) and [Auth & route protection](../auth-and-route-protection).
 
 ## 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(),
     ],
@@ -90,5 +90,5 @@ Out of the box the plugin uses a framework default channel. To set the route aut
 ## What to read next
 
 - [`useEveAgent` (Svelte)](./use-eve-agent-svelte): the binding API
-- [Auth & route protection](../advanced/auth-and-route-protection)
-- [Deployment](../advanced/deployment)
+- [Auth & route protection](../auth-and-route-protection)
+- [Deployment](../deployment)

package/dist/docs/public/{frontend → guides/frontend}/use-eve-agent-svelte.mdx

@@ -75,7 +75,7 @@ await agent.send({
 
 ## Human-in-the-loop prompts
 
-A tool opts into approval with `needsApproval` ([Tools](../tools)). When one fires, the pending request rides along on a `dynamic-tool` part of the latest message. Read it, then answer with `agent.send({ inputResponses })`. This find-and-answer flow is identical across frameworks, so the full example lives in the [Frontend overview](./overview#human-in-the-loop-prompts).
+A tool opts into approval with `needsApproval` ([Tools](../../tools)). When one fires, the pending request rides along on a `dynamic-tool` part of the latest message. Read it, then answer with `agent.send({ inputResponses })`. This find-and-answer flow is identical across frameworks, so the full example lives in the [Frontend overview](./overview#human-in-the-loop-prompts).
 
 ## Stop, reset, and resume
 
@@ -108,4 +108,4 @@ const agent = useEveAgent({
 
 - [SvelteKit](./sveltekit): Vite plugin setup
 - [Frontend overview](./overview): the shared integration model
-- [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming)
+- [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming)

package/dist/docs/public/{frontend → guides/frontend}/use-eve-agent-vue.mdx

@@ -87,7 +87,7 @@ async function onFileChange(event: Event) {
 
 ## Human-in-the-loop prompts
 
-A tool opts into approval with `needsApproval` ([Tools](../tools)). When it triggers, the pending request shows up as a `dynamic-tool` part on the latest message. Read it and answer with `send({ inputResponses })`. That find-and-answer flow is the same across every framework, so the full example lives in the [Frontend overview](./overview#human-in-the-loop-prompts).
+A tool opts into approval with `needsApproval` ([Tools](../../tools)). When it triggers, the pending request shows up as a `dynamic-tool` part on the latest message. Read it and answer with `send({ inputResponses })`. That find-and-answer flow is the same across every framework, so the full example lives in the [Frontend overview](./overview#human-in-the-loop-prompts).
 
 ## Stop, reset, and resume
 
@@ -120,4 +120,4 @@ const agent = useEveAgent({
 
 - [Nuxt](./nuxt): module setup
 - [Frontend overview](./overview): the shared integration model
-- [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming)
+- [Sessions, runs & streaming](../../concepts/sessions-runs-and-streaming)

package/dist/docs/public/{advanced → guides}/hooks.md

@@ -149,6 +149,6 @@ Stream-event hooks and channel adapter event handlers are structurally identical
 ## What to read next
 
 - [Tools](../tools)
-- [Context control](./context-control)
+- [Context control](../concepts/context-control)
 - [Session context](./session-context)
-- [Sessions, runs & streaming](./sessions-runs-and-streaming)
+- [Sessions, runs & streaming](../concepts/sessions-runs-and-streaming)

package/dist/docs/public/{advanced → guides}/instrumentation.md

@@ -134,6 +134,8 @@ Per-turn usage tags are written on each step of a turn, accumulating cumulative
 
 Tag writes are best-effort: a failure is logged once per process and then swallowed, so a broken tag emit never breaks the agent.
 
+These tags power the **Agent Runs** tab in the Vercel dashboard. When you deploy on Vercel, the platform auto-detects `eve` as the framework and surfaces an Agent Runs view under your project's **Observability** tab, where you can browse sessions and drill into each conversation's trace — no `instrumentation.ts` required. The tab is currently gated per team; see [Deployment](./deployment#view-runs-in-the-dashboard) for enablement. Agent Runs is separate from the OpenTelemetry export above: use OTel when you want spans in Braintrust, Datadog, or another third-party backend.
+
 ## Debugging
 
 `eve info` is the fastest way to see what Eve actually picked up: the active tools, skills, subagents, schedules, routes, and discovery diagnostics. Eve also writes inspectable artifacts under `.eve/`, kept even when discovery hits errors:
@@ -162,4 +164,4 @@ When `eve build` fails on discovery errors, the CLI prints the full diagnostics
 - [`agent.ts`](../agent-config)
 - [Hooks](./hooks): observe the runtime event stream
 - [Dev TUI](./dev-tui): drive the agent locally
-- [Evals](./evals): repeatable scored checks
+- [Evals](../evals/overview): repeatable scored checks

package/dist/docs/public/{advanced → guides}/meta.json

@@ -1,21 +1,17 @@
 {
-  "title": "Advanced",
+  "title": "Guides",
   "pages": [
-    "default-harness",
-    "context-control",
-    "dynamic-capabilities",
-    "dynamic-workflows",
+    "deployment",
+    "auth-and-route-protection",
+    "instrumentation",
     "hooks",
     "session-context",
     "state",
+    "dynamic-capabilities",
+    "dynamic-workflows",
     "remote-agents",
-    "auth-and-route-protection",
-    "security-model",
-    "deployment",
-    "instrumentation",
     "dev-tui",
-    "evals",
-    "execution-model-and-durability",
-    "sessions-runs-and-streaming"
+    "frontend",
+    "client"
   ]
 }

package/dist/docs/public/{advanced → guides}/session-context.md

@@ -1,5 +1,5 @@
 ---
-title: "Session context"
+title: "Session Context"
 description: "Runtime helpers: ctx.session, ctx.getSandbox, ctx.getSkill, and defineState."
 ---
 
@@ -60,7 +60,7 @@ Important behavior:
 
 ```ts
 const sandbox = await ctx.getSandbox();
-const result = await sandbox.run({ command: "pnpm test" });
+const result = await sandbox.run({ command: "npm test" });
 ```
 
 Important behavior:
@@ -144,6 +144,6 @@ This lifecycle is fully managed by the framework. Authored code only needs to us
 ## What to read next
 
 - [State](./state)
-- [Sessions, runs & streaming](./sessions-runs-and-streaming)
+- [Sessions, runs & streaming](../concepts/sessions-runs-and-streaming)
 - [Subagents](../subagents)
 - [Skills](../skills)

package/dist/docs/public/{advanced → guides}/state.md

@@ -58,5 +58,5 @@ Every [subagent](../subagents) starts with its own fresh state, whether it's a b
 ## What to read next
 
 - Read state inside dynamic resolvers → [Dynamic capabilities](./dynamic-capabilities)
-- How step durability works → [Execution model & durability](../advanced/execution-model-and-durability)
+- How step durability works → [Execution model & durability](../concepts/execution-model-and-durability)
 - The `ctx` accessors available alongside state → [Tools](../tools)

package/dist/docs/public/instructions.mdx

@@ -49,10 +49,10 @@ Instructions never run code. When you need typed executable behavior, reach for
 
 ## Dynamic instructions
 
-Need the prompt resolved at runtime from session context (auth, tenant, channel)? Wrap `defineInstructions` in a `defineDynamic` resolver. See [Dynamic capabilities](./advanced/dynamic-capabilities).
+Need the prompt resolved at runtime from session context (auth, tenant, channel)? Wrap `defineInstructions` in a `defineDynamic` resolver. See [Dynamic capabilities](./guides/dynamic-capabilities).
 
 ## What to read next
 
 - [Tools](./tools): typed actions, the next capability to add
-- [Context control](./advanced/context-control): all the levers for what the model sees
+- [Context control](./concepts/context-control): all the levers for what the model sees
 - [Skills](./skills): on-demand procedures, the counterpart to always-on instructions

package/dist/docs/public/introduction.md

@@ -1,6 +1,6 @@
 ---
 title: "Introduction"
-description: "Meet Eve and the small set of ideas behind an Eve agent."
+description: "How an Eve agent is laid out as files, what runs when a message arrives, and the building blocks you add as it grows."
 ---
 
 Eve is a framework for building durable agents as ordinary files in a TypeScript project.
@@ -87,7 +87,7 @@ As the agent grows, each concern still has a predictable home:
 | Path                            | Add it when you need...                          |
 | ------------------------------- | ------------------------------------------------ |
 | [`connections/`](./connections) | Tools from external MCP servers                  |
-| [`hooks/`](./advanced/hooks)    | Code that reacts to lifecycle and stream events  |
+| [`hooks/`](./guides/hooks)      | Code that reacts to lifecycle and stream events  |
 | [`sandbox/`](./sandbox)         | A controlled workspace for files and commands    |
 | [`subagents/`](./subagents)     | Specialist agents the root agent can delegate to |
 | [`schedules/`](./schedules)     | Recurring or scheduled work                      |
@@ -99,4 +99,7 @@ The result stays readable before it runs: the directory tells you what the agent
 
 - [Getting started](./getting-started): scaffold and run your first agent
 - [Tools](./tools): the typed actions your agent calls
+- [Instructions](./instructions): the always-on system prompt that shapes behavior
+- [Channels](./channels/overview): reach the agent from Slack, Discord, or a web UI
+- [Connections](./connections): pull in tools from external MCP servers
 - [Project layout](./reference/project-layout): every authored slot under `agent/`

package/dist/docs/public/meta.json

@@ -12,9 +12,10 @@
     "sandbox",
     "subagents",
     "schedules",
-    "advanced",
-    "frontend",
-    "client",
+    "evals",
+    "---",
+    "guides",
+    "concepts",
     "---",
     "reference",
     "tutorial"

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`                |
@@ -90,27 +91,42 @@ Pass a bare URL as the only argument and the UI connects to that server instead
 
 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 [suiteId...] [--url <url>] [options]
+eve eval [evalId...] [--url <url>] [options]
 ```
 
-Runs all discovered suites when no suite ids are given. Exits `0` when every case passed its checks, `1` when any case failed (a failed check, an execution error, or a `--strict` threshold miss), `2` on configuration errors.
+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                                                 |
-| ----------------------- | ------------------------------------------------------ |
-| `--url <url>`           | Remote agent URL (skip local host startup)             |
-| `--tag <tag...>`        | Run only cases (or suites) carrying a tag              |
-| `--case <id...>`        | Run only specific case ids                             |
-| `--strict`              | Below-threshold scores also fail the exit code         |
-| `--list`                | Print discovered suites and cases without running them |
-| `--timeout <ms>`        | Per-case timeout in milliseconds                       |
-| `--max-concurrency <n>` | Max concurrent case executions per suite               |
-| `--json`                | Output results as JSON                                 |
-| `--skip-report`         | Skip suite-defined reporters (e.g. Braintrust)         |
+| Flag                    | Effect                                         |
+| ----------------------- | ---------------------------------------------- |
+| `--url <url>`           | Remote agent URL (skip local host startup)     |
+| `--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 eval-defined reporters (e.g. Braintrust)  |
 
-See [Evals](../advanced/evals) for authoring suites.
+See [Evals](../evals/overview) for authoring evals.
 
 ## Recommended loop
 
@@ -120,10 +136,10 @@ See [Evals](../advanced/evals) for authoring suites.
 4. `eve build` before shipping.
 5. `eve start` to smoke-test the built output locally.
 
-Related: [Project layout](./project-layout) · [instrumentation.ts](../advanced/instrumentation).
+Related: [Project layout](./project-layout) · [instrumentation.ts](../guides/instrumentation).
 
 ## What to read next
 
 - [Project layout](./project-layout): what `eve info` discovers
-- [instrumentation.ts](../advanced/instrumentation): tracing and the error catalog
-- [Deployment](../advanced/deployment): `eve build` and `eve start` in production
+- [instrumentation.ts](../guides/instrumentation): tracing and the error catalog
+- [Deployment](../guides/deployment): `eve build` and `eve start` in production

package/dist/docs/public/reference/meta.json

@@ -1,4 +1,4 @@
 {
   "title": "Reference",
-  "pages": ["typescript-api", "cli", "project-layout", "faqs"]
+  "pages": ["typescript-api", "cli", "project-layout"]
 }

package/dist/docs/public/reference/project-layout.md

@@ -1,5 +1,5 @@
 ---
-title: "Project layout"
+title: "Project Layout"
 description: "Authored slots under agent/ and the path-derived naming rule."
 ---
 
@@ -104,6 +104,10 @@ my-agent/
 
 Prefer the nested layout. It keeps the app root separate from the authored surface.
 
+## Why didn't Eve discover my file?
+
+Run `eve info`. It lists the discovered surface and prints discovery diagnostics. From there, check that the file sits in the right authored slot (per the slot table above) and that the root-vs-subagent boundary is valid. Eve also writes inspectable artifacts under `.eve/` — see the debugging artifacts in [instrumentation.ts](../guides/instrumentation) and the [CLI](./cli) reference.
+
 ## What to read next
 
 - [`agent.ts`](../agent-config): the runtime config at the root