eve 0.66.3 → 0.67.0

package/docs/guides/instrumentation/instrumentation.mdx

@@ -51,6 +51,11 @@ export default defineInstrumentation({
 `ctx.state` is JSON storage scoped to this file and operation. It survives
 durable suspension and is released after the terminal event.
 
+Use `setup` for asynchronous initialization. In `eve dev` and built servers,
+eve awaits every provider's setup before loading the server entry. A setup
+failure stops startup. Modules imported by an instrumentation file load before
+setup, so keep dependencies that need initialization out of those imports.
+
 ## Control inputs and outputs
 
 Each lifecycle file created with `defineInstrumentation(...)` has an
@@ -78,8 +83,8 @@ export default defineInstrumentation({
 });
 ```
 
-The function receives `agentName`, `channel`, `audience`, `mode`,
-`environment`, and `principalType`. `audience` is `"public"`, `"private"`, or
+The function receives `agentName`, `channel`, `audience`, `environment`, and
+`principalType`. `audience` is `"public"`, `"private"`, or
 `"unknown"`; `environment` is `"development"`, `"preview"`, or
 `"production"`.
 
@@ -146,9 +151,21 @@ Prefer `recordInputs: false` or `recordOutputs: false` when the destination does
 
 ## Lifecycle events
 
-Instrumentation can handle session, channel delivery, turn, model attempt,
-model call, action, input request, and tool call events. Start and terminal
-events share an `idempotencyKey`, which can serve as a destination row ID.
+`defineInstrumentation({ events })` supports the following event names. A
+start and its terminal event share an `idempotencyKey`; use it as a stable
+operation key when upserting records across replays.
+
+| Lifecycle        | Events                                                                                                            | Meaning                                                                                                                                                                          |
+| ---------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Session          | `session.started`, `session.waiting`, `session.completed`, `session.failed`                                       | Track a session from creation through suspension or termination. `session.waiting` is resumable; `session.completed` and `session.failed` are terminal.                          |
+| Turn             | `turn.started`, `turn.completed`, `turn.cancelled`, `turn.failed`                                                 | Track one turn. Cancellation is not a failure and commonly leaves the session waiting for another turn.                                                                          |
+| Channel delivery | `channel.delivery.started`, `channel.delivery.completed`, `channel.delivery.cancelled`, `channel.delivery.failed` | Track an inbound channel delivery while eve processes its turn. These events are emitted when the channel provides delivery metadata.                                            |
+| Step attempt     | `step.attempt.started`, `step.attempt.completed`, `step.attempt.failed`, `step.attempt.metadata`                  | Track each model-step attempt; retries have separate attempts. `step.attempt.metadata` is emitted after a step only when the AI SDK supplies provider metadata.                  |
+| Model call       | `model.call.started`, `model.call.completed`, `model.call.failed`                                                 | Track an individual call to the model provider. Completion includes usage and finish reason; content fields follow the trace policy.                                             |
+| Action           | `action.started`, `action.completed`, `action.failed`                                                             | Track eve's durable dispatch of a tool, skill load, local subagent, or remote agent. A failed event's `outcome` distinguishes failure, rejection, cancellation, and abandonment. |
+| Tool call        | `tool.call.started`, `tool.call.completed`, `tool.call.failed`                                                    | Track the AI SDK's in-process tool execution boundary, including its input and result when allowed by the trace policy.                                                          |
+| User input       | `input.requested`, `input.resolved`                                                                               | Track a question, tool approval, or session-limit request and its resolution. The resolution includes an outcome such as `answered`, `approved`, `denied`, or `cancelled`.       |
+| Memory operation | `memory.operation.started`, `memory.operation.completed`, `memory.operation.failed`                               | Track a memory-store search or write. Events include the operation name, phase, and memory slot; completion may include a record count and records.                              |
 
 An ordinary tool emits both `action.*` and `tool.call.*` events. Use `action.*` for eve's durable dispatch lifecycle, including tools, skills, subagents, and remote agents. Use `tool.call.*` only when you need the AI SDK's in-process tool execution boundary.
 

package/docs/guides/instrumentation/otel.mdx

@@ -38,6 +38,36 @@ does not affect lifecycle instrumentation created with `defineInstrumentation()`
 See [Audience](../channels/overview#audience) for how channels classify the
 conversation passed to this policy.
 
+## Instrument Node.js dependencies
+
+Pass OpenTelemetry instrumentation instances to `otel({ instrumentations })`.
+For example, install the PostgreSQL instrumentation alongside `pg`:
+
+```bash
+pnpm add pg @opentelemetry/instrumentation-pg
+```
+
+```ts title="agent/instrumentation/otel.ts"
+import { PgInstrumentation } from "@opentelemetry/instrumentation-pg";
+import { otel } from "eve/instrumentation/otel";
+
+export default otel({
+  instrumentations: [new PgInstrumentation()],
+});
+```
+
+Keep the instrumented package external so Node.js module hooks can intercept
+it. Add `pg` to your agent's [build configuration](/docs/agent-config#other-defineagent-fields):
+
+```ts title="agent/agent.ts"
+import { defineAgent } from "eve";
+
+export default defineAgent({
+  model: "openai/gpt-5.4-mini",
+  build: { externalDependencies: ["pg"] },
+});
+```
+
 ## Add an OpenTelemetry destination
 
 Use this section when sending traces to a third-party destination. Install

package/docs/guides/remote-agents.md

@@ -28,7 +28,6 @@ export default defineRemoteAgent({
 | `forwardPrincipal` | `boolean`                                     | No       | `false`           | Forward the dispatching turn's session principal to the remote deployment (see [Forwarding the caller identity](#forwarding-the-caller-identity)).       |
 | `headers`          | `HeadersValue`                                | No       | none              | Static or lazily resolved request headers.                                                                                                               |
 | `path`             | `string`                                      | No       | `/eve/v1/session` | Route appended to `url` for the create-session request.                                                                                                  |
-| `outputSchema`     | `StandardSchema \| JSON Schema`               | No       | none              | Structured return type for the first turn of each fresh remote session. A continuation may provide its own per-call schema.                              |
 | `tool`             | `boolean`                                     | No       | `true`            | Expose the remote agent as a tool to the parent model. Set `false` to allow only `ctx.agent()` calls from authored workflow tools.                       |
 
 ## Dynamic remote agents
@@ -81,9 +80,9 @@ The function may be async and must return a non-empty string. `auth` and `header
 
 ## Calling a remote agent
 
-By default, a remote agent is another subagent tool to the model. The model calls it the same way it calls a local subagent, with a `message` and an optional `outputSchema`. Set `tool: false` when an authored workflow tool should be the only model-facing routing surface; the workflow can still call the remote agent by its path-derived name through `ctx.agent()`. The message must carry the full task, including any context the remote agent needs, because it never receives the parent's conversation history.
+By default, a remote agent is another subagent tool to the model. The model calls it the same way it calls a local subagent, with a `message` and an optional `agentId`. Set `tool: false` when an authored workflow tool should be the only model-facing routing surface; the workflow can still call the remote agent by its path-derived name through `ctx.agent()`. The message must carry the full task, including any context the remote agent needs, because it never receives the parent's conversation history.
 
-To require structured output, set an `outputSchema` on the agent definition for fresh delegations or on an individual call for that turn. The structured value arrives in the task's completion notification, and the remote child remains available for follow-up messages. See [Subagents](../subagents) for continuation behavior.
+To require structured output, call the remote agent from an authored workflow tool with `ctx.agent(name, { message, outputSchema })`. The schema applies to that turn, the structured value is the call's result, and the remote child remains available for follow-up messages. See [Subagents](../subagents) for continuation behavior.
 
 ## Outbound auth
 
@@ -200,7 +199,7 @@ You can also steer a running remote background child by calling its subagent too
 
 When the parent session ends, eve sends an authenticated `POST /eve/v1/session/:childSessionId/reset` for each remote child. Reset retires the parked remote session and recursively cleans up its descendants. The request uses freshly resolved `headers` and `auth`; failures are logged so an unreachable remote cannot block parent finalization.
 
-A failed _start_ rejects admission before a task receipt is returned. After a remote starts, a terminal failure callback fails the task and notifies the parent with the remote's error (or `REMOTE_AGENT_FAILED` when none is supplied). Terminal callback delivery runs as a durable step on the underlying workflow engine (see [Execution model & durability](../concepts/execution-model-and-durability)). A failed callback POST is rethrown rather than marking the task complete, so the engine retries it.
+A failed _start_ rejects admission before a task receipt is returned. After a remote starts, a terminal failure callback fails the task and notifies the parent with the remote's error. Terminal callback delivery runs as a durable step on the underlying workflow engine (see [Execution model & durability](../concepts/execution-model-and-durability)). A failed callback POST is rethrown rather than marking the task complete, so the engine retries it.
 
 ## What to read next
 

package/docs/guides/self-modification.md

@@ -3,7 +3,7 @@ title: "Self-Modification"
 description: "Ask your agent to update its own instructions, tools, skills, and other authored files during local development."
 ---
 
-When `eve dev` starts a local server, it mounts the bundled self-modification extension by default. Ask your agent to change its instructions, tools, skills, or other files under `agent/`; eve delegates the source work to the `self-modification__agent` subagent. Connecting to an existing server with `eve dev <url>` does not add the bundled extension to that server.
+When `eve dev` starts a local server, it mounts the bundled self-modification extension by default. Ask your agent to change its instructions, tools, skills, or other files under `agent/`; eve delegates the source work to the `self-modification__agent` subagent. Connecting to an existing server with `eve remote connect --url <url>` does not add the bundled extension to that server.
 
 The bundled extension is for local development and is not included in production builds.
 

package/docs/memory/custom-provider.md

@@ -95,7 +95,7 @@ Every handler receives a `MemoryOperationContext`:
 | `memory.scope.value`     | The resolved scope string or tuple                                                                         |
 | `memory.slot`            | The path-derived slot name                                                                                 |
 | `messages`               | Projected conversation history for this phase                                                              |
-| `operationId`            | Stable per session, sequence, phase, and slot. Use it as an idempotency key.                               |
+| `operationId`            | Stable per session, turn, step, phase, and slot. Use it as an idempotency key.                             |
 | `abortSignal`            | Cancellation for the operation                                                                             |
 | `session`                | Session ID, authentication, and other `SessionContext` fields                                              |
 

package/docs/protocols/acp.md

@@ -12,7 +12,7 @@ eve acp
 Without a URL, the client starts one process from the eve application root. It supervises a local development server, and closing the ACP connection stops that owned server. To bridge ACP to a deployed eve agent, pass its URL:
 
 ```sh
-eve acp https://agent.example.com
+eve acp --url https://agent.example.com
 ```
 
 For a recognized Vercel deployment, eve verifies the exact origin and resolves a short-lived project-scoped OIDC token from the local Vercel session. Remote access requires an existing authorized Vercel session; account login runs during local deployment. Configure required Trusted Sources access in the target project before launching ACP. `VERCEL_AUTOMATION_BYPASS_SECRET` remains available for deployments configured with a Protection Bypass for Automation token.

package/docs/reference/cli.md

@@ -1,37 +1,30 @@
 ---
 title: "CLI"
-description: "Reference for every eve CLI command: init, set, info, build, start, dev, logs, traces, link, deploy, eval, channels, extension, and telemetry."
+description: "Reference for every eve CLI command."
 ---
 
 Relevant `eve` commands can run from the application root or any directory beneath it. Running `eve` with no command runs `eve init` when the current directory is not an eve project, or `eve dev` when it is.
 
 ## Commands
 
-| Command                        | Description                                                                                                                        |
-| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `eve`                          | Initialize the current directory, or start development when it is already an eve project                                           |
-| `eve init [target]`            | Create a new agent, or add an agent to an existing project                                                                         |
-| `eve info`                     | Print the resolved application, including static instructions and discovered capabilities, routes, artifact paths, and diagnostics |
-| `eve build`                    | Compile `.eve/` artifacts and build the host output; prints the output directory                                                   |
-| `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 acp [url]`                | Serve the local application or an existing eve server URL as a stable ACP v1 agent over stdio                                      |
-| `eve logs [logid]`             | Print an `eve dev` diagnostic log (the most recent when `logid` is omitted)                                                        |
-| `eve logs ls`                  | List `eve dev` diagnostic logs, most recent first                                                                                  |
-| `eve traces ls`                | List locally captured agent traces, most recent first                                                                              |
-| `eve traces [trace]`           | Show a local span tree (the most recent when omitted)                                                                              |
-| `eve telemetry <command>`      | Show, enable, or disable CLI telemetry collection                                                                                  |
-| `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 list`            | List user-authored channels                                                                                                        |
-| `eve extension init [target]`  | Create a new extension package                                                                                                     |
-| `eve extension build`          | Build the current package as an extension                                                                                          |
-| `eve set`                      | Change the root agent's model and reasoning effort                                                                                 |
-| `eve add <item>`               | Install an item from the official or a configured shadcn registry                                                                  |
-| `eve integration setup <kind>` | Run a built-in setup flow directly after its registry files are installed                                                          |
-| `eve registry <command>`       | Add sources and list, search, or view registry catalog items                                                                       |
+| Command                                        | Description                                            |
+| ---------------------------------------------- | ------------------------------------------------------ |
+| `eve init [target]`                            | Create a new agent, or add one to an existing project  |
+| `eve dev`                                      | Start the local development server and terminal UI     |
+| `eve remote connect --url <url>`               | Open the terminal UI for an existing agent             |
+| `eve remote invoke --url <url> [prompt]`       | Invoke an existing agent without a terminal UI         |
+| `eve remote info --url <url>`                  | Inspect an existing agent                              |
+| `eve acp [url]`                                | Serve a local or existing agent through ACP over stdio |
+| `eve info`                                     | Inspect the local application                          |
+| `eve set model [model] [--reasoning <effort>]` | Change model and reasoning settings                    |
+| `eve build` / `eve start`                      | Build or serve the application                         |
+| `eve logs show [logid]` / `eve logs list`      | Inspect local diagnostic logs                          |
+| `eve traces show [trace]` / `eve traces list`  | Inspect local traces                                   |
+| `eve link` / `eve deploy`                      | Link or deploy a Vercel project                        |
+| `eve eval`                                     | Run evals against a local or remote target             |
+| `eve add [item]` / `eve registry <command>`    | Install and browse registry items                      |
+| `eve extension <command>`                      | Create and build extension packages                    |
+| `eve telemetry <command>`                      | Manage CLI telemetry collection                        |
 
 When `eve build` fails on discovery errors, it prints the full diagnostics report (severity, message, source path) and the diagnostics artifact path.
 
@@ -101,19 +94,19 @@ Builds the complete agent-shaped extension tree into its configured dist root, e
 Change the root agent's AI Gateway model and reasoning effort without opening the dev TUI:
 
 ```bash
-eve set \
-  --model openai/gpt-6-sol \
-  --reasoning high
+eve set model openai/gpt-6-sol --reasoning high
+eve set model --reasoning medium
 ```
 
-Pass either flag by itself to change one setting. When you pass both, eve writes
-them to `agent/agent.ts` in one source edit. `--reasoning` accepts
+Use `eve set model` to change the model, its reasoning effort, or both. Omit
+the optional model argument to keep the current model. When you set both, eve
+writes them to `agent/agent.ts` in one source edit. `--reasoning` accepts
 `provider-default`, `none`, `minimal`, `low`, `medium`, `high`, or `xhigh`;
 `provider-default` removes the authored `reasoning` field.
 
 The command uses the same model ID validation and source editor as `/model` in
-the local dev TUI. It does not configure model credentials. The `--model` flag
-cannot rewrite models defined with `defineDynamic`, an environment expression,
+the local dev TUI. It does not configure model credentials. The `model`
+argument cannot rewrite models defined with `defineDynamic`, an environment expression,
 or a provider-authored SDK model; change those models in `agent.ts`.
 `--reasoning` can still update an editable root config when its model comes from
 an SDK call.
@@ -211,88 +204,99 @@ For self-hosted deployments, copy the app source, `.output/`, and installed depe
 
 ```bash
 eve dev [options]
-eve dev https://your-app.vercel.app
 ```
 
-Pass a bare URL and the UI connects to that server instead of booting a local one (same as `--url`), which lets you smoke-test a preview or production deployment. The interactive UI turns off in a non-TTY terminal.
-
-| Flag                                | Type   | Default            | Description                                                                               |
-| ----------------------------------- | ------ | ------------------ | ----------------------------------------------------------------------------------------- |
-| `--host <host>`                     | string | all interfaces     | Host interface to bind                                                                    |
-| `--port <port>`                     | number | `$PORT`, then 2000 | Port to listen on                                                                         |
-| `-u, --url <url>`                   | string | none               | Connect to an existing server URL instead of starting one                                 |
-| `-H, --header <header>`             | string | none               | Request header for a URL target, in `Name: value` form; repeat for multiple headers       |
-| `--no-ui`                           | flag   | UI on              | Start the server without an interactive UI                                                |
-| `--no-default-extensions`           | flag   | extensions on      | Do not mount bundled development extensions                                               |
-| `--name <name>`                     | string | app folder name    | Title shown in the terminal UI                                                            |
-| `--input <text>`                    | string | none               | Pre-fill the prompt input                                                                 |
-| `--tools <mode>`                    | enum   | `auto-collapsed`   | Tool-call rendering: `full` \| `collapsed` \| `auto-collapsed` \| `hidden`                |
-| `--reasoning <mode>`                | enum   | `full`             | Reasoning rendering: `full` \| `collapsed` \| `auto-collapsed` \| `hidden`                |
-| `--subagents <mode>`                | enum   | `auto-collapsed`   | Subagent-section rendering: `full` \| `collapsed` \| `auto-collapsed` \| `hidden`         |
-| `--connection-auth <mode>`          | enum   | `full`             | Connection-authorization rendering: `full` \| `collapsed` \| `auto-collapsed` \| `hidden` |
-| `--assistant-response-stats <mode>` | enum   | `tokensPerSecond`  | Assistant header statistic: `tokens` \| `tokensPerSecond`                                 |
-| `--context-size <tokens>`           | number | none               | Model context window size, shown as a usage percentage                                    |
-| `--logs <mode>`                     | enum   | `stderr`           | Server/agent logs to show: `all` \| `stderr` \| `sandbox` \| `none`                       |
+Starts a local development server and terminal UI. To connect the UI to an existing agent, use `eve remote connect --url <url>`.
+
+| Flag                                | Type   | Default            | Description                                 |
+| ----------------------------------- | ------ | ------------------ | ------------------------------------------- |
+| `--host <host>`                     | string | all interfaces     | Host interface to bind                      |
+| `--port <port>`                     | number | `$PORT`, then 2000 | Port to listen on                           |
+| `--no-ui`                           | flag   | UI on              | Start the server without an interactive UI  |
+| `--no-default-extensions`           | flag   | extensions on      | Do not mount bundled development extensions |
+| `--name <name>`                     | string | app folder name    | Title shown in the terminal UI              |
+| `--input <text>`                    | string | none               | Pre-fill the prompt input                   |
+| `--tools <mode>`                    | enum   | `auto-collapsed`   | Tool-call rendering                         |
+| `--reasoning <mode>`                | enum   | `full`             | Reasoning rendering                         |
+| `--subagents <mode>`                | enum   | `auto-collapsed`   | Subagent-section rendering                  |
+| `--connection-auth <mode>`          | enum   | `full`             | Connection-authorization rendering          |
+| `--assistant-response-stats <mode>` | enum   | `tokensPerSecond`  | Assistant header statistic                  |
+| `--context-size <tokens>`           | number | none               | Model context window size                   |
+| `--logs <mode>`                     | enum   | `stderr`           | Server and agent logs to show               |
 
 Local development mounts bundled development extensions without adding files to your project. Pass `--no-default-extensions` to disable them. See [Self-Modification](../guides/self-modification) for details.
 
-`eve acp` reserves stdin and stdout for newline-delimited JSON-RPC and sends diagnostics to stderr. Without a URL, it supervises an isolated local development server. With a URL, it bridges ACP to that server's existing eve HTTP API and accepts the same URL credentials and request headers as `eve dev <url>`. Pass `--scope <team>` when the active Vercel scope does not own the deployment; `EVE_VERCEL_SCOPE` provides the same value for managed harnesses. See [Agent Client Protocol (ACP)](../protocols/acp) for client configuration and capability limits.
-
 A fresh `eve init` opens the TUI and reuses an available model connection or opens `/login`. No Vercel project, channels, integrations, or review step is required before chat. Use `/model` to change models and settings, and `/add` to install an addition. Other `--input` text stays editable in the prompt. See [Terminal UI](../guides/dev-tui) for credential precedence and login options.
 
-For a URL target protected by HTTP Basic auth, put the credentials in the URL. eve sends them as a Basic `Authorization` header and strips them from the server URL before connecting:
+Local dev records the last ready URL per resolved app root in `.eve/dev-server-state.v1.json`. A second interactive `eve dev` reconnects only when that URL is loopback and healthy; each terminal UI creates a fresh client session while sharing the server process. A stale or malformed record is replaced when eve starts a new server. Passing `--host`, `--port`, or a `PORT` environment value skips reconnection and reports a healthy recorded server instead.
+
+Local dev keeps immutable runtime generations under `.eve/dev-runtime/snapshots/` so in-flight turns hold a consistent code revision while new turns pick up rebuilds. Each generation contains the compiled authored module graph and runtime resources rather than a recursive copy of the app or workspace. The terminal REPL keeps its logical session across successful rebuilds, so the next turn continues the conversation on the latest generation; `/new` terminally retires that session before clearing the transcript, and the next prompt starts a fresh session with a new session-scoped sandbox on first sandbox use. After a generation is superseded, `eve dev` retains it for at least 30 minutes and also retains the five most recently superseded generations, regardless of the configured Workflow World. The active generation is never pruned. Old runtime snapshots and local sandbox templates are pruned in the background. For manual cleanup, stop `eve dev` before deleting `.eve/dev-runtime/snapshots/` or `.eve/sandbox-cache/local/templates/`. A turn that remains unfinished beyond the automatic retention window can no longer resume after its generation is pruned.
+
+Local development records traces under `.eve/traces/` by default and bounds that store by age, size, and a keep-newest floor. Configure it with `EVE_TRACES*` in `.env.local`, or disable the destination with `agent/instrumentation/local.ts`; see [`eve traces`](#retention) for the rules and defaults.
+
+`eve acp` reserves stdin and stdout for newline-delimited JSON-RPC and sends diagnostics to stderr. Without a URL, it supervises an isolated local development server. With a URL, it bridges ACP to that server's existing eve HTTP API. See [Agent Client Protocol (ACP)](../protocols/acp) for client configuration and capability limits.
+
+## `eve remote`
+
+Use `eve remote` only with an explicit existing agent URL:
 
 ```bash
-eve dev https://user:pass@your-app.example.com
+eve remote connect --url https://agent.example.com
+eve remote invoke --url https://agent.example.com "Summarize station telemetry"
+eve remote info --url https://agent.example.com
 ```
 
-For bearer tokens or custom schemes, pass explicit headers with `-H`.
+`connect` opens the terminal UI. `info` verifies the target and prints its inspection response. Remote commands never start a local application.
+
+### `eve remote connect`
 
-### `eve invoke`
+```bash
+eve remote connect --url <url> [-H "Name: value"]
+```
 
-| Option                  | Type   | Default | Description                                     |
-| ----------------------- | ------ | ------- | ----------------------------------------------- |
-| `[prompt]`              | string | none    | Prompt, follow-up, or answer to a pending input |
-| `-u, --url <url>`       | string | local   | Invoke an existing server                       |
-| `-H, --header <header>` | string | none    | Request header for a URL target; repeatable     |
-| `--resume`              | flag   | off     | Read a previous resumable result from stdin     |
-| `--scope <team>`        | string | current | Vercel team that owns the URL target            |
-| `--json-schema`         | flag   | off     | Print the result JSON Schema and exit           |
+Use `-H, --header <header>` for a bearer token or another custom request header; repeat it for multiple headers. For HTTP Basic authentication, put credentials in the URL. eve sends them as a Basic `Authorization` header and removes them from the target URL.
 
-Use `eve invoke` to submit a turn without opening the TUI. It emits JSON after the invocation completes or reaches a blocking input or authorization event.
+### `eve remote invoke`
 
 ```bash
-eve invoke "Summarize station telemetry"
-result=$(eve invoke "Deploy the application")
-printf '%s' "$result" | eve invoke --resume "approve"
-eve invoke --json-schema
+eve remote invoke --url <url> [prompt] [--resume] [-H "Name: value"] [--scope <team>]
 ```
 
-`--resume` reads a complete previous result from stdin. Supply text for a `ready` follow-up or pending input; the agent harness resolves input text against all pending requests. A `ready` result includes the previous turn's completed or failed `outcome`. An `authorization-required` result lists every unresolved challenge in `authorizations`; complete them, then resume without text. Pass explicit headers again for protected remote servers. If the URL belongs to another Vercel team, pass its slug with `--scope`; this does not relink the current directory. Pass the scope again when resuming. Paused invocations exit `3`; failures exit `1`.
+Invokes an existing agent without opening the terminal UI. It emits JSON after the invocation completes or reaches a blocking input or authorization event.
 
-Local callback-based connection authorization requires a persistent server. Run `eve dev`, then use `eve invoke --url <dev-url>` instead. If a waiting invocation receives `SIGINT` or `SIGTERM` after acceptance, it emits a final resumable `running` result before exiting.
+| Option                  | Type   | Default  | Description                                     |
+| ----------------------- | ------ | -------- | ----------------------------------------------- |
+| `<url>`                 | string | required | Existing eve agent URL                          |
+| `[prompt]`              | string | none     | Prompt, follow-up, or answer to a pending input |
+| `-H, --header <header>` | string | none     | Request header for the URL target; repeatable   |
+| `--resume`              | flag   | off      | Read a previous resumable result from stdin     |
+| `--scope <team>`        | string | current  | Vercel team that owns the URL target            |
 
-Local dev records the last ready URL per resolved app root in `.eve/dev-server-state.v1.json`. A second interactive `eve dev` reconnects only when that URL is loopback and healthy; each terminal UI creates a fresh client session while sharing the server process. A stale or malformed record is replaced when eve starts a new server. Passing `--host`, `--port`, or a `PORT` environment value skips reconnection and reports a healthy recorded server instead.
+`--resume` reads a complete previous result from stdin. Supply text for a `ready` follow-up or pending input. An `authorization-required` result lists every unresolved challenge; complete them, then resume without text. Pass headers and scope again when resuming. Paused invocations exit `3`; failures exit `1`. If a waiting invocation receives `SIGINT` or `SIGTERM` after acceptance, it emits a final resumable `running` result before exiting.
 
-Local dev keeps immutable runtime generations under `.eve/dev-runtime/snapshots/` so in-flight turns hold a consistent code revision while new turns pick up rebuilds. Each generation contains the compiled authored module graph and runtime resources rather than a recursive copy of the app or workspace. The terminal REPL keeps its logical session across successful rebuilds, so the next turn continues the conversation on the latest generation; `/new` terminally retires that session before clearing the transcript, and the next prompt starts a fresh session with a new session-scoped sandbox on first sandbox use. After a generation is superseded, `eve dev` retains it for at least 30 minutes and also retains the five most recently superseded generations, regardless of the configured Workflow World. The active generation is never pruned. Old runtime snapshots and local sandbox templates are pruned in the background. For manual cleanup, stop `eve dev` before deleting `.eve/dev-runtime/snapshots/` or `.eve/sandbox-cache/local/templates/`. A turn that remains unfinished beyond the automatic retention window can no longer resume after its generation is pruned.
+### `eve remote info`
 
-Local development records traces under `.eve/traces/` by default and bounds that store by age, size, and a keep-newest floor. Configure it with `EVE_TRACES*` in `.env.local`, or disable the destination with `agent/instrumentation/local.ts`; see [`eve traces`](#retention) for the rules and defaults.
+```bash
+eve remote info --url <url> [-H "Name: value"] [--json]
+```
+
+Verifies the existing agent and prints its inspection response. Use `-H, --header <header>` for protected targets; repeat it for multiple headers.
 
 ## `eve logs`
 
 ```bash
 eve logs            # print the most recent diagnostic log
-eve logs ls         # list logs, most recent first
-eve logs <logid>    # print a specific log
+eve logs list          # list logs, most recent first
+eve logs show <logid>  # print a specific log
 eve logs --dump     # prepend the log's environment dump
 eve logs --events   # interleave session events from the local workflow store
 ```
 
 Each interactive `eve dev` process writes a private diagnostic log under `.eve/logs/` capturing stderr, stdout (including sandbox and rebuild lines), tool failures, workflow errors, and eve framework log records — regardless of what the transcript shows. The file is JSON Lines — every line is one JSON record with `at` and `source` fields. `eve logs` reads those files back.
 
-A log id is the file name without `.log` (for example `dev-2026-07-15T12-00-00.000Z-123`). `eve logs <logid>` also accepts the file name, the `.eve/logs/...` path printed in the dev transcript, or any unambiguous prefix of the id with or without the `dev-` lead — so `eve logs 2026-07-15` works when a single log matches. An ambiguous prefix fails and lists the candidates.
+A log id is the file name without `.log` (for example `dev-2026-07-15T12-00-00.000Z-123`). `eve logs show <logid>` also accepts the file name, the `.eve/logs/...` path printed in the dev transcript, or any unambiguous prefix of the id with or without the `dev-` lead — so `eve logs 2026-07-15` works when a single log matches. An ambiguous prefix fails and lists the candidates.
 
-`eve logs` prints nothing but records — no path banner on either stream — so `eve logs 2>&1 | jq -c .` always parses. Discover ids and file paths with `eve logs ls`; `eve logs ls --json` emits a machine-readable array with `id`, `path`, `startedAt`, and `sizeBytes`.
+`eve logs` prints nothing but records — no path banner on either stream — so `eve logs 2>&1 | jq -c .` always parses. Discover ids and file paths with `eve logs list`; `eve logs list --json` emits a machine-readable array with `id`, `path`, `startedAt`, and `sizeBytes`.
 
 `eve logs --events` resolves session events (`session.started`, `turn.failed`, message deltas, …) from the local workflow store (`.eve/.workflow-data`) at query time and interleaves them into the output by timestamp as `source: "event"` records — the log file itself never stores them, so nothing is duplicated at capture time. Selection is by the log's time window (its start through the next log's start), so events from concurrently running `eve dev` processes may appear.
 
@@ -301,10 +305,10 @@ Each log has a same-named `.dump` sibling holding environment diagnostics and se
 ## `eve traces`
 
 ```bash
-eve traces ls              # list traces, most recent first
-eve traces ls --json       # emit machine-readable trace summaries
-eve traces                 # show the most recent span tree
-eve traces <trace>         # show one span tree
+eve traces list              # list traces, most recent first
+eve traces list --json       # emit machine-readable trace summaries
+eve traces show         # show the most recent span tree
+eve traces show <trace> # show one span tree
 eve traces --verbose       # expand every span with all attributes and events
 eve traces --json          # dump the full trace as JSON
 ```
@@ -317,6 +321,8 @@ Every subagent activation starts its own trace. The first child's `invoke_agent`
 
 Each `agent()` call inside an authored workflow has its own `agent.action` caller span, including sequential, parallel, and background calls. A workflow tool that coordinates one of those calls has an enclosing `invoke_workflow <tool>` span; a workflow tool without agent calls remains `agent.action`. The tool also keeps its `execute_tool <tool>` span. Only agent execution uses `invoke_agent`.
 
+Outbound MCP `tools/call` requests add MCP semantic attributes to the matching `execute_tool` span. When eve has no tool span to enrich, it creates a `CLIENT` `tools/call <tool>` span. Each `tools/list` discovery also has a `CLIENT` span. Configured OpenTelemetry propagation fields are injected into MCP `params._meta` for JSON-RPC bodies up to 1 MiB and propagation metadata up to 8 KiB; larger requests are sent unchanged. eve removes its audience and session-lineage baggage before forwarding, and keeps the input/output content-capture policy local.
+
 A durable conversation produces one bounded trace per turn. Worker replacements reuse the prepared context for the same turn, while a later turn or an independently replayed attempt starts a fresh trace. Passing the conversation ID shows every trace it produced, oldest first.
 
 Every span carries a real duration. A turn's root `invoke_agent` span is written when the turn settles, so a running turn shows only its steps.
@@ -383,18 +389,6 @@ Runs all discovered evals when no eval ids are given; ids match exactly or by di
 
 See [Evals](../evals/overview) for authoring evals.
 
-## `eve channels list`
-
-```bash
-eve channels list [--json]
-```
-
-Lists the user-authored channels in the current project.
-
-| Flag     | Type | Default | Description    |
-| -------- | ---- | ------- | -------------- |
-| `--json` | flag | off     | Output as JSON |
-
 ## Recommended loop
 
 1. Edit files under `agent/`.

package/docs/schedules.mdx

@@ -14,7 +14,7 @@ Every schedule provides a `cron` and exactly one of `markdown` or `run`:
 ```ts
 interface ScheduleDefinition {
   cron: string;
-  markdown?: string; // fire-and-forget prompt (task mode)
+  markdown?: string; // fire-and-forget prompt
   run?: (args: ScheduleHandlerArgs) => Promise<void> | void; // handler
 }
 
@@ -33,7 +33,7 @@ A TypeScript schedule with `markdown` is compile-only because eve stores the pro
 
 ## Markdown form (fire-and-forget)
 
-This is the minimal schedule. eve runs the agent on the prompt and throws away the output, though the agent can still call tools, write to backends, and log along the way. We call this task mode. A task-mode session runs to completion or fails, and cannot park to wait for a person or an OAuth sign-in.
+This is the minimal schedule. eve runs the agent on the prompt and throws away the output, though the agent can still call tools, write to backends, and log along the way. The session has no channel, so it cannot ask a person for input, and nothing can send it a follow-up message. If the agent calls a tool that needs approval, the session fails instead of waiting for an answer. After its turn settles, the session parks like any other session until its [session timeout](./agent-config#runtime-limits) ends it.
 
 ```ts title="agent/schedules/heartbeat.ts"
 import { defineSchedule } from "eve/schedules";
@@ -86,7 +86,7 @@ The agent does not have to deliver a message on every run. When a prompt makes d
 
 The `auth` option controls which principal the session runs as. A handler may instead supply a user principal when scheduled work needs that user's grants; a session created by that dispatch still retains schedule provenance and conditional delivery behavior.
 
-A handler-form session runs on the same durable runtime engine as any other session, so it can park (durably suspend), for instance when the channel handoff is waiting for a Slack reply. Only markdown task mode is barred from waiting.
+A handler-form session runs on the same durable runtime engine as any other session, so it can park (durably suspend), for instance when the channel handoff is waiting for a Slack reply. Markdown-form sessions park too, but no channel is attached, so they cannot receive follow-up messages.
 
 ## Background task results
 
@@ -118,8 +118,7 @@ its policy unless the send supplies an explicit value.
 
 Under `"auto"`, a model call may finish silently while related work is pending.
 Available results remain in the next reporting context so the parent can combine
-previously withheld outputs later. A scheduled task-mode session stays alive while
-it owns pending background tasks. See
+previously withheld outputs later. See
 [Background task results](./channels/overview#background-task-results).
 
 ## Session continuity

package/docs/subagents/index.mdx

@@ -51,9 +51,8 @@ The root session receives `agent` by default. The model calls it to delegate a t
 
 ```ts
 {
-  message: string;       // everything the child needs; it does not see the parent's history
-  agentId?: string;      // continue or steer an existing child
-  outputSchema?: object; // require structured output for this turn
+  message: string;  // everything the child needs; it does not see the parent's history
+  agentId?: string; // continue or steer an existing child
 }
 ```
 
@@ -239,7 +238,7 @@ The root built-in `agent` tool is the exception. Its children reuse the root's s
 
 ## What the parent sees
 
-eve lowers every tool-enabled subagent visible to the current agent (the root built-in copy, declared, or [remote](./guides/remote-agents)) into a model-visible tool with the same `{ message, agentId?, outputSchema? }` shape. The parent packs `message` with everything the child needs, since the child never sees the parent's history. Set `outputSchema` to require structured output for that turn; the child remains available for follow-up messages afterward.
+eve lowers every tool-enabled subagent visible to the current agent (the root built-in copy, declared, or [remote](./guides/remote-agents)) into a model-visible tool with the same `{ message, agentId? }` shape. The parent packs `message` with everything the child needs, since the child never sees the parent's history. To require structured output from a child, call it from an authored workflow tool with [`ctx.agent(name, { message, outputSchema })`](./tools/workflows); the schema applies to that turn, and the child remains available for follow-up messages afterward.
 
 Declared subagents can call nested subagents defined under their own directories. eve does not apply a separate depth limit; nesting ends where the authored directory tree ends. The built-in `agent` follows the stricter root-only rule above, so `limits.maxSubagentDepth` no longer exists.
 
@@ -249,9 +248,8 @@ A directly declared subagent's tool name is the bare path-derived name, with no
 
 ```ts
 {
-  message: string;       // all context the child needs; it never sees the parent's history
-  agentId?: string;      // continue or steer an existing child
-  outputSchema?: object; // require structured output for this turn
+  message: string;  // all context the child needs; it never sees the parent's history
+  agentId?: string; // continue or steer an existing child
 }
 ```
 

package/docs/tools/human-in-the-loop.md

@@ -121,6 +121,8 @@ The `response` policy receives:
 
 Return `{ status: "allowed" }` to accept the approval. Return `{ status: "rejected", reason }` to leave the shared request pending so another eligible responder can approve it.
 
+When a response is refused without starting a turn, the session returns to `session.waiting`. The client finishes the submission and keeps the approval prompt answerable. Submitting an answer does not confirm approval: `approval.settled` or `input.resolved` records the server's decision. You can inspect `approval.candidate` events for the response policy's refusal reason.
+
 ### Skipping approval for schedule-dispatched turns
 
 `session.auth.current` identifies the caller of this turn. Markdown schedules use the app principal (`authenticator: "app"`, `principalId: "eve:app"`, `principalType: "runtime"`) automatically. A `run` schedule must pass its `appAuth` to `send(...)` for the child session to use that principal. Match all three fields to skip approval for automated turns while still prompting when a person calls the same tool:
@@ -197,6 +199,8 @@ Channels turn requests into native UI: the Slack adapter renders approvals as bu
 
 From your own frontend, scan all messages for pending requests and answer through the same session — see [Building a frontend](/docs/guides/frontend/overview#human-in-the-loop-prompts) for the client-side reducer and `inputResponses` shape.
 
+The default message reducer waits for server confirmation before marking any input request answered. Use the store's `submitted` or `streaming` status to show that a response is being processed; submitting a response alone does not resolve an approval, question, or session-limit prompt. The `client.input.responded` event remains a submission notification for custom reducers, not confirmation that the server accepted the answer.
+
 ## What to read next
 
 - [Tools](/docs/tools): define the typed actions an approval gates

package/docs/tools/overview.mdx

@@ -39,6 +39,8 @@ eve validates the model's input against `inputSchema` before `execute` runs:
 - eve treats `format` as an annotation and does not reject input for it.
 - When eve cannot evaluate a JSON Schema locally, for example because of an unknown `type` name or a `$ref` it cannot resolve, the model still receives the schema and eve passes the input to `execute` unvalidated.
 
+Optional input fields remain optional for authored tools and connection tools. eve explicitly disables provider strict mode for function tools so providers such as OpenAI Responses do not implicitly require every property. Local input validation still follows the tool's schema.
+
 ### Hide a tool from delegated agents
 
 Set `availableInSubagents: false` when a tool should be callable only in a top-level root session:

package/docs/tools/workflows.mdx

@@ -441,7 +441,7 @@ import { agentRouter } from "eve/tools/agent-router";
 export default agentRouter();
 ```
 
-Its input is `{ message: string, outputSchema?: object }`. `agentRouter()` ignores entries without a non-empty description. With two or more described targets, it sends the message and effective descriptions to Jev, then invokes the selected name through `ctx.agent()`. It invokes a sole target without evaluation and forwards an optional `outputSchema` unchanged. In a top-level root session, the candidates include the root-copy `agent`; delegated root copies and declared subagent contexts include only their declared targets.
+Its input is `{ message: string }`. `agentRouter()` ignores entries without a non-empty description. With two or more described targets, it sends the message and effective descriptions to Jev, then invokes the selected name through `ctx.agent()`. It invokes a sole target without evaluation. In a top-level root session, the candidates include the root-copy `agent`; delegated root copies and declared subagent contexts include only their declared targets.
 
 When an authored tool accepts a JSON Schema supplied by the model, represent that input with a permissive object such as `z.looseObject({})`. Avoid `z.record(z.string(), z.json())`: its generated JSON Schema uses `propertyNames`, which OpenAI does not support. Validate the supplied value at the point where your tool consumes it.
 

package/docs/tutorial/remember-definitions.mdx

@@ -65,7 +65,7 @@ export default defineTool({
 
 The sample data has two high-value customers: Acme ($57) and Globex ($99). This definition works with the same fixed dataset whenever you run the tutorial. The second turn is a separate turn in the same session, yet the definition is still there. State checkpoints at step boundaries, so it's the same durability from [Step 2](./how-it-runs), now applied to your own data.
 
-State is scoped to a session and isolated per agent, so a subagent starts with fresh state and never sees the parent's. Need to reset something each turn? Call `update(() => fresh)` in a lifecycle hook. More in [State](../concepts/state).
+State is scoped to a session and isolated per agent, so a subagent starts with fresh state and never sees the parent's. Need to clear the glossary each turn? Call `glossary.update(() => ({ terms: {} }))` in a lifecycle hook. More in [State](../concepts/state).
 
 → Next: [Team playbooks](./team-playbooks)
 

package/docs/tutorial/ship-it.mdx

@@ -116,7 +116,7 @@ Open the HTTPS preview URL and enter the configured username and password. Creat
 The authenticated web app and eve runtime share the same origin, and the sandbox runs on Vercel Sandbox. You can also smoke-test the deployment through the authenticated CLI:
 
 ```bash
-npx eve dev https://your-analytics-app.vercel.app
+npx eve remote connect --url https://your-analytics-app.vercel.app
 ```
 
 For a production deployment, add the username, password, and model credential to the Production environment too, then run `npx vercel@latest deploy --prod`. Missing Basic credentials keep browser access closed.