eve 0.7.0 → 0.7.2

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # eve
 
+## 0.7.2
+
+### Patch Changes
+
+- 7504d7f: Sandbox template keys now derive their Eve version segment from the compile metadata bundled with the app instead of resolving the installed package version at runtime. Deployed runtimes previously could resolve a different version string than the build-time prewarm (when the bundled fallback version was unstamped), compute a different template key, and fail every sandbox turn with "Sandbox template … is not provisioned"; build and runtime now always agree on the key.
+- 7504d7f: Vercel stable sandbox template scopes no longer depend on `VERCEL_TEAM_ID`. Vercel exposes `VERCEL_PROJECT_ID` at both build and runtime but has no team system variable at runtime, so a build that set `VERCEL_TEAM_ID` would prewarm a template the deployed function could never resolve — surfacing as `Sandbox template … is not provisioned`. Stable templates are now keyed on the project id alone, so build-time prewarm and the deployed runtime always agree.
+
+## 0.7.1
+
+### Patch Changes
+
+- a4d23ba: Bump the Workflow packages to the latest betas (`@workflow/core@5.0.0-beta.15`, `@workflow/world@5.0.0-beta.9`, `@workflow/world-local@5.0.0-beta.16`).
+- 1728183: Declare `oxc-parser` as a runtime dependency, pinned to an exact version. Installed releases crashed `eve dev` with a silent non-zero exit when `/model` ran, because the model flow's source editor imports `oxc-parser` but releases since 0.6.x only declared it as a devDependency. The exact pin means every `eve` release ships the native parser version it was tested against, instead of floating to the newest patch at install time.
+- 3168daa: `pnpm create eve` is back: the create-eve package returns as a launcher whose only job is to run the bundled eve's `init`, forwarding every argument. The scaffolded project belongs to the package manager that invoked the create command — `npm create eve` produces an npm project, `pnpm create eve` a pnpm one, `yarn create eve` a yarn one.
+
 ## 0.7.0
 
 ### Minor Changes

package/dist/docs/public/README.md

@@ -10,7 +10,12 @@ Important naming note:
 - The current published package name is `eve`.
 - The CLI binary is `eve`.
 
-## Read This First
+Casing convention:
+
+- Use Title Case for page `title` frontmatter and `meta.json` section titles (Fumadocs renders the page `title` as both the sidebar entry and the `<h1>`, so one casing covers both) — e.g. `Execution Model & Durability`, `Dynamic Capabilities`, `Build an Agent`.
+- Use sentence case for in-page headings (`##` and below). Capitalize only the first word plus proper nouns/acronyms — e.g. `Next.js`, `SvelteKit`, `Slack`, `GitHub`, `CLI`, `TypeScript API`, `agent.ts`.
+
+## Read this first
 
 Read in this order:
 
@@ -19,23 +24,23 @@ Read in this order:
 3. [Project Layout](./reference/project-layout.md)
 4. [`agent.ts`](./agent-config.md)
 5. [TypeScript API](./reference/typescript-api.md)
-6. [Context Control](./advanced/context-control.md)
+6. [Context Control](./concepts/context-control.md)
 7. [Skills](./skills.mdx)
 8. [Tools](./tools.mdx)
 9. [Connections](./connections.mdx)
 10. [Sandboxes](./sandbox.mdx)
 11. [Channels](./channels/overview.mdx)
-12. [Session Context](./advanced/session-context.md)
-13. [Sessions And Streaming](./advanced/sessions-runs-and-streaming.md)
-14. [TypeScript Client](./client/overview.mdx)
+12. [Session Context](./guides/session-context.md)
+13. [Sessions And Streaming](./concepts/sessions-runs-and-streaming.md)
+14. [TypeScript SDK](./guides/client/overview.mdx)
 15. [Subagents](./subagents.mdx)
 16. [Schedules](./schedules.mdx)
 17. [Evals](./evals/overview.mdx)
-18. [Auth And Route Protection](./advanced/auth-and-route-protection.md)
-19. [Vercel Deployment](./advanced/deployment.md)
+18. [Auth And Route Protection](./guides/auth-and-route-protection.md)
+19. [Vercel Deployment](./guides/deployment.md)
 20. [CLI, Build, And Debugging](./reference/cli.md)
 
-## The Public Mental Model
+## The public mental model
 
 Eve is a filesystem-first framework for durable backend agents.
 
@@ -61,7 +66,7 @@ Eve then gives you:
 - a per-agent sandbox with a shared runtime workspace
 - typed runtime helpers accessed through `ctx` (`ctx.session`, `ctx.getSandbox()`, `ctx.getSkill()`)
 
-## The Runtime Shape
+## The runtime shape
 
 The public surface stays filesystem-first, but the implementation model underneath is still useful to
 know:
@@ -75,7 +80,7 @@ That is why Eve exposes two identifiers:
 - `continuationToken` for the next user message
 - `sessionId` for streaming and inspection
 
-## How To Use These Docs
+## How to use these docs
 
 - Start with the authored filesystem shape and `agent.ts`.
 - Then add runtime surfaces in this order: skills, tools, workspace, sandbox, channels.
@@ -83,7 +88,7 @@ That is why Eve exposes two identifiers:
   continuation-token follow-ups.
 - Then add advanced features: subagents, schedules, route protection, deployment.
 
-## Good Companions In This Repo
+## Good companions in this repo
 
 - Weather-focused smoke/dev fixture: [`../../apps/fixtures/weather-fixture`](../../apps/fixtures/weather-fixture)
 - Public API source of truth: [`../../packages/eve/src/public/index.ts`](../../packages/eve/src/public/index.ts)

package/dist/docs/public/agent-config.md

@@ -44,7 +44,7 @@ export default defineAgent({
 });
 ```
 
-See [Default harness](./advanced/default-harness#compaction) for how the loop applies it.
+See [Default harness](./concepts/default-harness#compaction) for how the loop applies it.
 
 ## Other fields
 
@@ -68,16 +68,16 @@ Build packaging controls. `externalDependencies` keeps listed packages external
 
 ## Where adjacent settings live
 
-| Concern                       | Lives in                                                                           |
-| ----------------------------- | ---------------------------------------------------------------------------------- |
-| Instructions prompt           | `agent/instructions.md`, [Instructions](./instructions)                            |
-| Per-tool approval (HITL)      | `agent/tools/*.ts`, [Tools](./tools)                                               |
-| Inbound auth & network policy | the channel layer, [Auth & route protection](./advanced/auth-and-route-protection) |
-| Sandbox / workspace           | `agent/sandbox/`, [Sandbox](./sandbox)                                             |
-| Telemetry & debugging         | `agent/instrumentation.ts`, [Instrumentation](./advanced/instrumentation)          |
+| Concern                       | Lives in                                                                         |
+| ----------------------------- | -------------------------------------------------------------------------------- |
+| Instructions prompt           | `agent/instructions.md`, [Instructions](./instructions)                          |
+| Per-tool approval (HITL)      | `agent/tools/*.ts`, [Tools](./tools)                                             |
+| Inbound auth & network policy | the channel layer, [Auth & route protection](./guides/auth-and-route-protection) |
+| Sandbox / workspace           | `agent/sandbox/`, [Sandbox](./sandbox)                                           |
+| Telemetry & debugging         | `agent/instrumentation.ts`, [Instrumentation](./guides/instrumentation)          |
 
 ## What to read next
 
-- [Default harness](./advanced/default-harness) for the loop and built-in tools this config drives
+- [Default harness](./concepts/default-harness) for the loop and built-in tools this config drives
 - [TypeScript API](./reference/typescript-api) for every `defineAgent` field and type
 - [Subagents](./subagents) for the `description` requirement and child-agent config

package/dist/docs/public/channels/custom.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Custom channels"
+title: "Custom Channels"
 description: "Author custom HTTP and WebSocket channels with routes, events, metadata, continuation tokens, and file uploads."
 ---
 
@@ -174,7 +174,7 @@ export default defineChannel({
 });
 ```
 
-The projection is re-evaluated whenever adapter state changes after channel event handlers run. Dynamic tool resolvers read it via `ctx.channel.metadata` and narrow it with `isChannel`. See [Dynamic capabilities](../advanced/dynamic-capabilities) for the full consumption pattern.
+The projection is re-evaluated whenever adapter state changes after channel event handlers run. Dynamic tool resolvers read it via `ctx.channel.metadata` and narrow it with `isChannel`. See [Dynamic capabilities](../guides/dynamic-capabilities) for the full consumption pattern.
 
 When a parent agent dispatches a subagent, the framework forwards the parent's channel metadata projection to the child. The same `metadata(state)` projector also serves instrumentation metadata resolvers.
 
@@ -271,5 +271,5 @@ The framework handles staging bytes to the sandbox, enforcing upload policy, hyd
 ## What to read next
 
 - [Channels overview](./overview)
-- [Dynamic capabilities](../advanced/dynamic-capabilities)
-- [Auth & route protection](../advanced/auth-and-route-protection)
+- [Dynamic capabilities](../guides/dynamic-capabilities)
+- [Auth & route protection](../guides/auth-and-route-protection)

package/dist/docs/public/channels/discord.mdx

@@ -71,4 +71,4 @@ export default discordChannel({
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/channels/eve.mdx

@@ -3,7 +3,7 @@ title: "Eve"
 description: "The default HTTP API for an agent: session routes, auth, and customization."
 ---
 
-The Eve channel is the framework's default HTTP API. It's what the terminal UI, [`useEveAgent`](../frontend/overview), `curl`, and any SDK client talk to when they start sessions, send messages, and stream events. `eveChannel()` mounts the canonical session routes under `/eve/v1/session*`, and they are enabled by default even when `agent/channels/eve.ts` does not exist.
+The Eve channel is the framework's default HTTP API. It's what the terminal UI, [`useEveAgent`](../guides/frontend/overview), `curl`, and any SDK client talk to when they start sessions, send messages, and stream events. `eveChannel()` mounts the canonical session routes under `/eve/v1/session*`, and they are enabled by default even when `agent/channels/eve.ts` does not exist.
 
 Reach for it when something needs HTTP access to your agent: local tooling, a browser frontend, the terminal UI, or another API client. Most apps never write this file. Add `agent/channels/eve.ts` only to override the defaults, usually the route auth policy:
 
@@ -25,7 +25,7 @@ The channel exposes the routes that create sessions, send follow-ups, and stream
 - `POST /eve/v1/session/:sessionId` (send a follow-up)
 - `GET /eve/v1/session/:sessionId/stream` (stream events, NDJSON)
 
-See [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming) for the request and stream flow.
+See [Sessions, runs & streaming](../concepts/sessions-runs-and-streaming) for the request and stream flow.
 
 ## Authentication
 
@@ -38,7 +38,7 @@ Neither admits browser users or external clients in production. For a public app
 
 `eve init` scaffolds an `agent/channels/eve.ts` with a production placeholder so you replace it before going live. The generated channel allows Vercel OIDC and localhost, and includes `placeholderAuth()`, which returns a setup-focused 401 in production until you swap it for real auth. Delete the file and Eve falls back to `[localDev(), vercelOidc()]`, which still does not admit browser users in production.
 
-For the full auth model and helper list, see [Auth & route protection](../advanced/auth-and-route-protection).
+For the full auth model and helper list, see [Auth & route protection](../guides/auth-and-route-protection).
 
 ## Customization
 
@@ -70,13 +70,13 @@ export default eveChannel({
 
 ## Clients
 
-The browser side of this API lives in the [Frontend](../frontend/overview) docs, where `useEveAgent` drives the Eve channel from React UI.
+The browser side of this API lives in the [Frontend](../guides/frontend/overview) docs, where `useEveAgent` drives the Eve channel from React UI.
 
-For scripts, server-to-server calls, evals, tests, and custom clients, use the [TypeScript Client](../client/overview). It wraps the session routes, continuation token, stream cursor, and reconnect loop.
+For scripts, server-to-server calls, evals, tests, and custom clients, use the [TypeScript SDK](../guides/client/overview). It wraps the session routes, continuation token, stream cursor, and reconnect loop.
 
 ## What to read next
 
-- [Frontend](../frontend/overview): drive the Eve channel from browser UI with `useEveAgent`
-- [TypeScript Client](../client/overview): call the Eve channel from TypeScript
-- [Auth & route protection](../advanced/auth-and-route-protection): the route auth policy
-- [Sessions, runs & streaming](../advanced/sessions-runs-and-streaming): the routes this channel exposes
+- [Frontend](../guides/frontend/overview): drive the Eve channel from browser UI with `useEveAgent`
+- [TypeScript SDK](../guides/client/overview): call the Eve channel from TypeScript
+- [Auth & route protection](../guides/auth-and-route-protection): the route auth policy
+- [Sessions, runs & streaming](../concepts/sessions-runs-and-streaming): the routes this channel exposes

package/dist/docs/public/channels/github.mdx

@@ -53,4 +53,4 @@ export default githubChannel({
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/channels/overview.mdx

@@ -5,7 +5,7 @@ description: "How users reach your agent: the channel contract, the base Eve HTT
 
 A channel is the edge adapter between a platform and your agent, and its job is deliberately small. It does exactly three things: normalizes platform input into a user message, owns the `continuationToken` (the resume handle for a conversation on that surface), and decides delivery (how, where, and whether a response goes back).
 
-Eve ships a base HTTP channel plus first-class platform channels (Slack, Discord, Teams, Telegram, Twilio, GitHub, Linear), and you can author your own.
+Eve ships a base HTTP channel plus first-class platform channels, and you can author your own. Browse the full set in the [Integrations](/integrations) gallery.
 
 ## Where channels live
 
@@ -24,30 +24,36 @@ Scaffold a channel file with `eve channels add` (interactive), or pass a kind: `
 
 ## The Eve HTTP channel (default)
 
-Eve's canonical HTTP session API: the routes the terminal UI, [`useEveAgent`](../frontend/overview), and `curl` all talk to. It is enabled by default, even with no `agent/channels/eve.ts` file. Add that file only to override the defaults, most often the route auth policy. See [Eve channel](./eve) for the routes, auth, and customization.
+Eve's canonical HTTP session API: the routes the terminal UI, [`useEveAgent`](../guides/frontend/overview), and `curl` all talk to. It is enabled by default, even with no `agent/channels/eve.ts` file. Add that file only to override the defaults, most often the route auth policy. See [Eve channel](./eve) for the routes, auth, and customization.
 
 ## Custom channels
 
 When Eve doesn't ship a channel for your surface, build one with `defineChannel` from `eve/channels`: route handlers (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `WS`), an `events` map, and a `send` call inside a handler to start or resume a session. See [Custom channels](./custom) for the full walkthrough, including WebSocket routes, cross-channel hand-off, channel metadata, continuation tokens, and file uploads.
 
+## Relationship to the Chat SDK
+
+Eve uses the Chat SDK's **card-builder components** (Cards, Buttons, Actions, etc.) for composing rich Slack messages. When you build a card with the [Slack channel](./slack), the underlying primitives come from the Chat SDK and get converted to Slack Block Kit at post time.
+
+Eve does **not** use the Chat SDK's runtime. The `Chat`, `Adapter`, and `Thread` primitives are never imported or reachable through Eve's public API. Eve's channel layer (webhook handling, signature verification, event parsing, and thread management) is implemented inside Eve itself. In short: building Slack messages feels just like Chat SDK cards, but wiring a channel means authoring against Eve's `defineChannel(...)` API, not a Chat SDK adapter.
+
 ## Which channel?
 
-| You want…                                   | Use                                                 |
-| ------------------------------------------- | --------------------------------------------------- |
-| A web app / browser chat UI                 | Eve channel + [`useEveAgent`](../frontend/overview) |
-| Local tooling, SDK clients, `curl`          | Eve channel (default)                               |
-| Slack mentions, DMs, buttons                | [Slack](./slack)                                    |
-| Discord slash commands, components          | [Discord](./discord)                                |
-| Microsoft Teams messages + Adaptive Cards   | [Teams](./teams)                                    |
-| Telegram bot messages                       | [Telegram](./telegram)                              |
-| SMS or speech-transcribed phone calls       | [Twilio](./twilio)                                  |
-| GitHub @mentions, PR review with checkout   | [GitHub](./github)                                  |
-| Linear issue delegation and Agent Sessions  | [Linear](./linear)                                  |
-| Anything else (internal webhook, WebSocket) | Custom channel (`defineChannel`, above)             |
+| You want…                                   | Use                                                        |
+| ------------------------------------------- | ---------------------------------------------------------- |
+| A web app / browser chat UI                 | Eve channel + [`useEveAgent`](../guides/frontend/overview) |
+| Local tooling, SDK clients, `curl`          | Eve channel (default)                                      |
+| Slack mentions, DMs, buttons                | [Slack](./slack)                                           |
+| Discord slash commands, components          | [Discord](./discord)                                       |
+| Microsoft Teams messages + Adaptive Cards   | [Teams](./teams)                                           |
+| Telegram bot messages                       | [Telegram](./telegram)                                     |
+| SMS or speech-transcribed phone calls       | [Twilio](./twilio)                                         |
+| GitHub @mentions, PR review with checkout   | [GitHub](./github)                                         |
+| Linear issue delegation and Agent Sessions  | [Linear](./linear)                                         |
+| Anything else (internal webhook, WebSocket) | Custom channel (`defineChannel`, above)                    |
 
 ## What to read next
 
 - [Slack](./slack): the most common platform channel, end to end
 - [Custom channels](./custom): build a channel for any surface with `defineChannel`
-- [Frontend](../frontend/overview): browser chat on the Eve channel with `useEveAgent`
+- [Frontend](../guides/frontend/overview): browser chat on the Eve channel with `useEveAgent`
 - [Integrations](/integrations): browse every built-in channel and connection in one gallery

package/dist/docs/public/channels/slack.mdx

@@ -4,7 +4,7 @@ description: "Reach your agent from Slack app mentions and DMs, with thread anch
 type: integration
 ---
 
-The Slack channel puts your agent inside a workspace: it answers `@mentions` and DMs, replies in threads, shows typing indicators, and turns HITL prompts into buttons. Use it when the conversation should happen where your team already works. Credentials run through [Vercel Connect](../advanced/auth-and-route-protection), which handles both the outbound bot token and inbound webhook verification, so there's no `SLACK_BOT_TOKEN` or `SLACK_SIGNING_SECRET` for you to manage. See [Channels](./overview) for the contract this builds on.
+The Slack channel puts your agent inside a workspace: it answers `@mentions` and DMs, replies in threads, shows typing indicators, and turns HITL prompts into buttons. Use it when the conversation should happen where your team already works. Credentials run through [Vercel Connect](../guides/auth-and-route-protection), which handles both the outbound bot token and inbound webhook verification, so there's no `SLACK_BOT_TOKEN` or `SLACK_SIGNING_SECRET` for you to manage. See [Channels](./overview) for the contract this builds on.
 
 ## Set up Connect
 
@@ -101,4 +101,4 @@ Event handlers receive `(eventData, ctx)` with platform handles on `ctx.thread`
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/channels/teams.mdx

@@ -52,4 +52,4 @@ export default teamsChannel({
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/channels/telegram.mdx

@@ -53,4 +53,4 @@ export default telegramChannel({
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/channels/twilio.mdx

@@ -59,4 +59,4 @@ export default twilioChannel({
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel
-- [Auth & route protection](../advanced/auth-and-route-protection): authenticating inbound traffic
+- [Auth & route protection](../guides/auth-and-route-protection): authenticating inbound traffic

package/dist/docs/public/{advanced → concepts}/context-control.md

@@ -1,5 +1,5 @@
 ---
-title: "Context control"
+title: "Context Control"
 description: "Control what the model sees and when: instructions, skills, the workspace, and subagents."
 ---
 
@@ -80,7 +80,7 @@ See [Subagents](../subagents).
 
 ## Dynamic context with `defineDynamic`
 
-The levers above are static: authored once, the same on every session. When the right context depends on who is calling (their team, tenant, plan, or feature flags), resolve it at runtime instead. `defineDynamic` in `agent/instructions/` returns the per-session system prompt, and `defineDynamic` in `agent/skills/` returns the set of skills a caller can load. Both read `ctx.session.auth` or channel metadata, so a caller on the billing team gets the billing instructions and playbook while nobody else sees them. See [Dynamic capabilities](./dynamic-capabilities) for the resolver API and when each event fires.
+The levers above are static: authored once, the same on every session. When the right context depends on who is calling (their team, tenant, plan, or feature flags), resolve it at runtime instead. `defineDynamic` in `agent/instructions/` returns the per-session system prompt, and `defineDynamic` in `agent/skills/` returns the set of skills a caller can load. Both read `ctx.session.auth` or channel metadata, so a caller on the billing team gets the billing instructions and playbook while nobody else sees them. See [Dynamic capabilities](../guides/dynamic-capabilities) for the resolver API and when each event fires.
 
 ## Choosing the right lever
 
@@ -106,4 +106,4 @@ For most agents:
 - [Tools](../tools)
 - [Skills](../skills)
 - [Subagents](../subagents)
-- [Hooks](./hooks)
+- [Hooks](../guides/hooks)

package/dist/docs/public/{advanced → concepts}/default-harness.md

@@ -41,7 +41,7 @@ These ship with every agent, no imports. Discovery never runs them: the harness
 
 Notes:
 
-- **`agent`** runs a copy of the current agent on a focused task. It inherits the same tools, connections, and instructions, but starts with fresh conversation history and fresh [state](./state). The child shares the parent's sandbox filesystem, so anything it writes is visible to the parent. See [Subagents](../subagents).
+- **`agent`** runs a copy of the current agent on a focused task. It inherits the same tools, connections, and instructions, but starts with fresh conversation history and fresh [state](../guides/state). The child shares the parent's sandbox filesystem, so anything it writes is visible to the parent. See [Subagents](../subagents).
 - **`load_skill`** only pulls instructions into context. It adds no new execution surface, because behavior still comes from the tools the agent already has.
 - **`connection_search`** is the model-facing `connection__search` tool. A search surfaces a connection's tools by their qualified name (e.g. `connection__linear__list_issues`), and the model can then call them directly. It's registered only when the agent has connections.
 - **`web_search`** has no local executor; the provider runs it. To supply your own implementation, override it with `defineTool()`.
@@ -85,10 +85,10 @@ There's also an experimental `Workflow` tool, shipped but off by default. To tur
 export { ExperimentalWorkflow as default } from "eve/tools";
 ```
 
-With it on, the model can orchestrate the agent's own subagents from model-authored JavaScript, all as one durable step. See [Dynamic workflows](./dynamic-workflows).
+With it on, the model can orchestrate the agent's own subagents from model-authored JavaScript, all as one durable step. See [Dynamic workflows](../guides/dynamic-workflows).
 
 ## What to read next
 
 - [Tools](../tools): define your own tools, gate them on approval, and shape their output with `toModelOutput`
-- [Dynamic capabilities](./dynamic-capabilities): generate the tool set per session with `defineDynamic`
+- [Dynamic capabilities](../guides/dynamic-capabilities): generate the tool set per session with `defineDynamic`
 - [Sandbox](../sandbox): the sandbox the shell and file tools run in

package/dist/docs/public/{advanced → concepts}/execution-model-and-durability.md

@@ -21,6 +21,8 @@ Crash the process, hit a timeout, or redeploy mid-turn, and the run picks up fro
 
 There's nothing to configure here. 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. When you do need session data from your own code, there are two supported surfaces: tools read the current session's metadata (id, turn, auth, parent lineage) via `ctx.session`, and [`defineState`](../guides/session-context) reads or writes session-scoped durable state. See [State](../guides/state) for the read/write model.
+
 ## Parked work
 
 Some work has to wait: a human approving a [tool](../tools), an interactive OAuth sign-in for a [connection](../connections), or a long-running [subagent](../subagents). At those points the turn parks durably. The workflow suspends and holds no compute until the input it's waiting on shows up (a click, a callback, a child completing), even if that's much later. When it does, the conversation picks up exactly where it left off.
@@ -45,4 +47,4 @@ Conversation history within a session is append-only. Turns land in order, and t
 
 - [Sessions, runs & streaming](./sessions-runs-and-streaming): the handles you hold and the event stream you watch.
 - [Security model](./security-model): the trust boundaries the runtime enforces.
-- [State](../advanced/state): durable per-session memory that persists across step boundaries.
+- [State](../guides/state): durable per-session memory that persists across step boundaries.

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

@@ -0,0 +1,10 @@
+{
+  "title": "Concepts",
+  "pages": [
+    "execution-model-and-durability",
+    "sessions-runs-and-streaming",
+    "default-harness",
+    "context-control",
+    "security-model"
+  ]
+}

package/dist/docs/public/{advanced → concepts}/security-model.md

@@ -50,7 +50,7 @@ A custom channel that accepts dashboard-style webhooks should follow the same sh
 
 ## Auth fails closed
 
-Routes reject unauthenticated traffic by default: if no `AuthFn` in the walk accepts the request, it gets a `401`, and admitting anonymous callers takes an explicit `none()`. The scaffold's `placeholderAuth()` keeps a half-configured app closed in production until you replace it. See [Auth & route protection](../advanced/auth-and-route-protection) for the full walk and verifiers.
+Routes reject unauthenticated traffic by default: if no `AuthFn` in the walk accepts the request, it gets a `401`, and admitting anonymous callers takes an explicit `none()`. The scaffold's `placeholderAuth()` keeps a half-configured app closed in production until you replace it. See [Auth & route protection](../guides/auth-and-route-protection) for the full walk and verifiers.
 
 ## Pre-production checklist
 
@@ -73,7 +73,7 @@ Before exposing an agent to real traffic:
 
 ## What to read next
 
-- [Auth & route protection](./auth-and-route-protection): the full auth walk and verifier helpers
+- [Auth & route protection](../guides/auth-and-route-protection): the full auth walk and verifier helpers
 - [Sandbox](../sandbox): backends, network policy, and brokering config
 - [Execution model & durability](./execution-model-and-durability): how durable sessions run
 - [Connections](../connections): static-token and OAuth connections

package/dist/docs/public/{advanced → concepts}/sessions-runs-and-streaming.md

@@ -14,7 +14,7 @@ Two handles do two jobs here, and mixing them up is the most common mistake. One
 
 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()`](../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
 
@@ -96,7 +96,7 @@ curl "http://127.0.0.1:3000/eve/v1/session/<sessionId>/stream?startIndex=<count>
 
 For scripts, server-to-server calls, tests, evals, and custom UIs, `eve/client` wraps these routes in a typed client so you don't hand-roll the POST and NDJSON stream loop.
 
-Start with the [TypeScript Client](../client/overview) guide. It covers basic usage, sending messages, continuations, streaming, and per-turn `outputSchema` results.
+Start with the [TypeScript SDK](../guides/client/overview) guide. It covers basic usage, sending messages, continuations, streaming, and per-turn `outputSchema` results.
 
 ## Inspect the agent over HTTP
 
@@ -106,7 +106,7 @@ Start with the [TypeScript Client](../client/overview) guide. It covers basic us
 curl http://127.0.0.1:3000/eve/v1/info
 ```
 
-The route uses the same default auth chain as the eve channel (`[localDev(), vercelOidc()]`). Locally it answers anonymously; a deployed Vercel target requires a valid OIDC bearer, with a same-project bypass for in-deployment callers. See [auth & route protection](../advanced/auth-and-route-protection).
+The route uses the same default auth chain as the eve channel (`[localDev(), vercelOidc()]`). Locally it answers anonymously; a deployed Vercel target requires a valid OIDC bearer, with a same-project bypass for in-deployment callers. See [auth & route protection](../guides/auth-and-route-protection).
 
 ## Dispatch order
 
@@ -114,8 +114,8 @@ Every stream event runs four steps, in this order:
 
 1. **Channel handler**: the channel's event handler runs and can mutate adapter state.
 2. **Metadata projection**: the framework re-evaluates the channel's `metadata(state)` and stores the result.
-3. **Hooks**: authored [hooks](../advanced/hooks) subscribed to the event fire.
-4. **Dynamic resolvers**: [dynamic](../advanced/dynamic-capabilities) tool, skill, and instruction resolvers fire, and `ctx.channel.metadata` already holds the freshly projected metadata from step 2.
+3. **Hooks**: authored [hooks](../guides/hooks) subscribed to the event fire.
+4. **Dynamic resolvers**: [dynamic](../guides/dynamic-capabilities) tool, skill, and instruction resolvers fire, and `ctx.channel.metadata` already holds the freshly projected metadata from step 2.
 
 The order isn't incidental, it's structural. By the time a resolver or hook reads channel metadata, the channel has already updated its state and the projection is current.
 
@@ -123,5 +123,5 @@ The order isn't incidental, it's structural. By the time a resolver or hook read
 
 - [Execution model & durability](./execution-model-and-durability): what makes a session durable and how parked work resumes.
 - [Channels](../channels/overview): what owns the continuation token and delivery.
-- [TypeScript Client](../client/overview): call these routes from scripts and server-side code.
-- [Frontend](../frontend/overview): `useEveAgent` instead of raw routes.
+- [TypeScript SDK](../guides/client/overview): call these routes from scripts and server-side code.
+- [Frontend](../guides/frontend/overview): `useEveAgent` instead of raw routes.

package/dist/docs/public/connections.mdx

@@ -124,7 +124,7 @@ export default defineMcpClientConnection({
 });
 ```
 
-`"linear"` is the UID you chose when registering the Connect client. Connect-managed OAuth is user-scoped by default, so the runtime resolves the per-user token before each tool call. The full setup (Connect client provisioning, project linking, the runtime consent flow) lives in [Auth & route protection](./advanced/auth-and-route-protection).
+`"linear"` is the UID you chose when registering the Connect client. Connect-managed OAuth is user-scoped by default, so the runtime resolves the per-user token before each tool call. The full setup (Connect client provisioning, project linking, the runtime consent flow) lives in [Auth & route protection](./guides/auth-and-route-protection).
 
 ## Self-hosted interactive OAuth
 
@@ -215,5 +215,5 @@ A tool can require both sign-in (`auth`) and a human approval. Today the model's
 
 - [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](./advanced/auth-and-route-protection): the full interactive-OAuth flow with Vercel Connect.
-- [Security model](./advanced/security-model): how connection credentials stay out of the model's reach.
+- [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/dist/docs/public/evals/cases.mdx

@@ -140,4 +140,4 @@ The loaders are meant for fixtures, not runtime agent code.
 
 - [Assertions](./assertions): assert on what the eval did
 - [Judge](./judge): grade quality with an LLM judge
-- [TypeScript client](../client/messages): the send/turn protocol eval sessions build on
+- [TypeScript client](../guides/client/messages): the send/turn protocol eval sessions build on

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

@@ -1,11 +1,11 @@
 ---
-title: "Evals"
+title: "Overview"
 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. Use it to catch regressions when you change a prompt or a tool: drive the agent through one or more turns, then 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.
 
-Evals exercise the same HTTP surface your users hit. The runner boots (or targets) a real agent server, drives sessions through the [TypeScript client](../client/overview) protocol, and grades what comes back — so a passing eval means the agent actually booted, accepted a request, and produced the result you asserted.
+Evals exercise the same HTTP surface your users hit. The runner boots (or targets) a real agent server, drives sessions through the [TypeScript client](../guides/client/overview) protocol, and grades what comes back — so a passing eval means the agent actually booted, accepted a request, and produced the result you asserted.
 
 ## `defineEval`
 

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

@@ -1,5 +1,5 @@
 ---
-title: "Running evals"
+title: "Running Evals"
 description: "The eve eval CLI: flags, filters, exit codes, artifacts, and how to wire evals into CI."
 ---
 

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

@@ -1,5 +1,5 @@
 ---
-title: "Targets and requirements"
+title: "Targets and Requirements"
 description: "Point evals at a local dev server or a deployment, and gate evals on target capabilities with requires."
 ---