eve 0.83.2 → 0.84.0

package/docs/evals/assertions.mdx

@@ -12,22 +12,22 @@ Scoped assertions take no explicit value and gate by default. Assertions on `t`
 | Assertion                                             | Asserts                                                                       |
 | ----------------------------------------------------- | ----------------------------------------------------------------------------- |
 | `t.succeeded()`                                       | The run did not fail and did not park on unanswered HITL input                |
-| `t.parked()`                                          | The run cleanly parked on HITL input                                          |
+| `t.awaitingInput()`                                   | The run cleanly parked on HITL input                                          |
 | `t.messageIncludes(token)`                            | Joined assistant text contains `token` (string or RegExp)                     |
 | `turn.outputEquals(value)` / `.outputMatches(schema)` | Deep equality or Standard Schema validation of turn/session structured output |
 | `t.calledTool(name, opts?)`                           | A matching tool call completed (`input`, `output`, `status`, `count`)         |
-| `t.loadedSkill(skill, opts?)`                         | A load of `skill` completed (`output`, `status`, `count`)                     |
+| `t.calledSkill(skill, opts?)`                         | A load of `skill` completed (`output`, `status`, `count`)                     |
 | `t.notCalledTool(name)`                               | No request for `name` in any lifecycle state                                  |
 | `t.toolOrder([...names])`                             | Tool requests appear in order                                                 |
 | `t.usedNoTools()`                                     | No tool calls at all; skill loads don't count                                 |
 | `t.maxToolCalls(n)`                                   | At most `n` tool calls; skill loads don't count                               |
-| `t.noFailedActions()`                                 | No tool, subagent, or skill action reported a failure                         |
-| `t.calledSubagent(name, opts?)`                       | A subagent delegation happened (identity, remote, output, status, count)      |
+| `t.noFailedCalls()`                                   | No tool, subagent, or skill action reported a failure                         |
+| `t.calledAgent(name, opts?)`                          | A subagent delegation happened (identity, remote, output, status, count)      |
 | `t.event(type, opts?)` / `t.notEvent(type, opts?)`    | Typed event presence, data, and count matching                                |
 | `t.eventOrder([...matchers])`                         | Matching event groups occur in order                                          |
 | `t.eventsSatisfy(label, predicate)`                   | Escape hatch: any predicate over the typed event stream                       |
 
-`succeeded()` accepts both a closed session and a healthy session left open for the next user message; it rejects protocol failures and unanswered HITL. `parked()` requires a clean HITL park. Structured output assertions live on turns and independent sessions, where the output is unambiguous (see the [output schema guide](../guides/client/output-schema)).
+`succeeded()` accepts both a closed session and a healthy session left open for the next user message; it rejects protocol failures and unanswered HITL. `awaitingInput()` requires a clean HITL park. Structured output assertions live on turns and independent sessions, where the output is unambiguous (see the [output schema guide](../guides/client/output-schema)).
 
 ```ts
 await t.send("What is the weather in Brooklyn?");
@@ -41,7 +41,8 @@ The same vocabulary narrows naturally in multi-turn and externally-created sessi
 const first = await t.send("Call get_weather for Brooklyn");
 first.calledTool("get_weather", { count: 1 });
 
-const attached = await t.target.attachSession(sessionId);
+const attached = t.target.attach(sessionId);
+await attached.nextTurn();
 attached.succeeded();
 attached.messageIncludes("Sunny");
 ```
@@ -52,15 +53,15 @@ A call through [`eve__tool`](../concepts/built-in-tools#eve__search-eve__tool-an
 
 ## Value assertions with `t.check`
 
-`t.check(value, assertion)` grades an explicit value against a builder from `eve/evals/expect`. The value can be a turn’s `.message`, parsed JSON, or any local you computed:
+`t.check(value, assertion)` grades an explicit value against a builder from `eve/evals/expect`. The value can be a turn’s `.reply`, parsed JSON, or any local you computed:
 
 ```ts
 import { includes, equals, matches, satisfies, similarity } from "eve/evals/expect";
 
-t.check(turn.message, includes(/sunny/i)); // substring or RegExp (gate)
+t.check(turn.reply, includes(/sunny/i)); // substring or RegExp (gate)
 t.check(parsed, equals({ city: "Brooklyn" })); // deep structural equality (gate)
 t.check(parsed, matches(WeatherSchema)); // Standard Schema, e.g. Zod (gate)
-t.check(turn.message, similarity("Sunny, 72F")); // fuzzy 0–1 Levenshtein (soft)
+t.check(turn.reply, similarity("Sunny, 72F")); // fuzzy 0–1 Levenshtein (soft)
 t.check(
   latencyMs,
   satisfies((value) => value < 1_000, "latency under one second"),
@@ -88,7 +89,7 @@ Pick the cheapest builder that captures what "correct" means. When exact match i
 `t.score(evaluation)` records a score from 0 to 1. The evaluation is the number or `{ score, message?, metadata? }`, or a promise of either. Chain `.label(key)` to name it; reporters and artifacts expose the label as `key`. Without a label the score reports as `score`, and several unlabeled scores share that name.
 
 ```ts
-const reply = turn.message ?? "";
+const reply = turn.reply ?? "";
 t.score({
   score: Math.max(0, 1 - reply.length / 400),
   metadata: { length: reply.length },
@@ -132,11 +133,11 @@ The same entries land in the [run artifacts](./running#artifacts) under `.eve/ev
 
 ## The matcher mini-language
 
-`t.calledTool` and `t.calledSubagent` take matcher objects. Tools accept `{ input, output, status, count }`; subagents accept `{ callId, childSessionId, remoteUrl, output, status, count }`. Calls match `status: "completed"` by default. Tool lifecycle checks also accept `"pending"`, `"failed"`, and `"rejected"`. Subagent checks accept `"working"`, `"completed"`, `"failed"`, and `"cancelled"`. A numeric `count` requires an exact number of calls matching every supplied constraint. Use a predicate for ranges or other custom count requirements; it receives the observed number of matching calls.
+`t.calledTool` and `t.calledAgent` take matcher objects. Tools accept `{ input, output, status, count }`; subagents accept `{ callId, childSessionId, output, status, count }`. Calls match `status: "completed"` by default. Tool lifecycle checks also accept `"pending"`, `"failed"`, and `"rejected"`. Subagent checks accept `"pending"`, `"completed"`, `"failed"`, `"rejected"`, `"interrupted"`, and `"abandoned"`. A numeric `count` requires an exact number of calls matching every supplied constraint. Use a predicate for ranges or other custom count requirements; it receives the observed number of matching calls.
 
-A subagent call is a task call: it stays `working` until its `task.settled` event arrives, then takes that event's `status` (`completed`, `failed`, or `cancelled`) and, when completed, its `output`. A completed call leaves the child session available for later calls with the same `taskId`.
+A subagent call is a task call: it stays `pending` until its `call.settled` arrives, then takes that call's outcome and, when completed, its `output`. A completed call leaves the child session available for later calls with the same `taskId`.
 
-The runner counts each `task.started` with `kind: "agent"` as a subagent call and takes its status from `task.settled`. `childSessionId` and `remoteUrl` come from the task's `agent.started`, so they are absent for a call that failed before its session opened. A proxied input request alone does not change the subagent call's status; assert that request with `requireInputRequest`.
+The runner counts each call that reaches an agent task (`call.started` whose task has `kind: "agent"`) as a subagent call and takes its status from its `call.settled`. `childSessionId` comes from the `child.opened` for the call or its task, so it is absent for a call that failed before its session opened. A proxied input request alone does not change the subagent call's status; assert that request with `requireInteraction`.
 
 Matcher values accept a literal (objects partial-deep-match), a RegExp, or a predicate function that returns a boolean:
 
@@ -150,16 +151,15 @@ t.calledTool("echo", { output: (value) => String(value).includes(marker) });
 parked.calledTool("guarded", { status: "pending", count: 1 });
 t.calledTool("guarded", { output: /approved/, count: 1 });
 
-t.calledSubagent("weather", {
-  remoteUrl: (value) => value === process.env.WEATHER_AGENT_URL,
+t.calledAgent("weather", {
   output: /72F/,
 });
 ```
 
-`requireInputRequest` uses the same matcher language for `input`, `prompt`, and `display`. Its `optionIds` matcher receives option ids in request order; a literal array must match that complete ordered list exactly:
+`requireInteraction` uses the same matcher language for `input`, `prompt`, and `display`. Its `optionIds` matcher receives option ids in request order; a literal array must match that complete ordered list exactly:
 
 ```ts
-const request = session.requireInputRequest({
+const request = session.requireInteraction({
   toolName: "confirm_deploy",
   optionIds: ["approve", "cancel"],
 });
@@ -172,10 +172,10 @@ Beyond the raw `session.events` stream, the runner derives typed facts the asser
 Typed event matching covers presence, absence, numeric or predicate counts, partial event data, and ordering:
 
 ```ts
-turn.notEvent("result.completed");
+turn.notEvent("content.completed", { data: { kind: "result" } });
 turn.eventOrder([
   { type: "task.started", data: { name: "researcher" }, count: 2 },
-  { type: "task.settled", data: { status: "completed" }, count: 2 },
+  { type: "task.ended", data: { outcome: "completed" }, count: 2 },
 ]);
 ```
 
@@ -183,7 +183,13 @@ When a protocol invariant needs cross-event correlation, `eventsSatisfy` remains
 
 ```ts
 t.eventsSatisfy("assistant reply includes the marker", (events) =>
-  events.some((e) => e.type === "message.completed" && e.data.message?.includes(marker)),
+  events.some(
+    (e) =>
+      e.type === "content.completed" &&
+      e.data.phase === "reply" &&
+      typeof e.data.value === "string" &&
+      e.data.value.includes(marker),
+  ),
 );
 ```
 
@@ -217,14 +223,14 @@ await t.require(
   sessionIds,
   satisfies((ids) => ids.length > 0, "dispatch started a session"),
 );
-await t.target.attachSession(sessionIds[0]!);
+await t.target.attach(sessionIds[0]!).nextTurn();
 ```
 
 Use the matching `require*` lookups when dependent code needs protocol data:
 
 ```ts
 const call = turn.requireToolCall("search");
-const request = session.requireInputRequest({ toolName: "guarded" });
+const request = session.requireInteraction({ toolName: "guarded" });
 ```
 
 ## Severity
@@ -240,8 +246,8 @@ The defaults are chosen so you rarely set severity. Run-level methods and `inclu
 
 ```ts
 t.calledTool("get_weather").soft(); // record the tool call as a metric, don't gate
-t.check(turn.message, similarity("Sunny")).label("forecast wording").atLeast(0.8);
-t.check(turn.message, includes("error")).soft(); // track without failing the build
+t.check(turn.reply, similarity("Sunny")).label("forecast wording").atLeast(0.8);
+t.check(turn.reply, includes("error")).soft(); // track without failing the build
 ```
 
 ## What to read next

package/docs/evals/cases.mdx

@@ -15,7 +15,7 @@ export default defineEvalConfig({});
 
 ## Single-turn evals
 
-The common case sends one turn and asserts on the reply. `t.send(input)` resolves once the turn settles, and the returned turn’s `.message` is the assistant reply:
+The common case sends one turn and asserts on the reply. `t.send(input)` resolves once the turn settles, and the returned turn’s `.reply` is the assistant reply:
 
 ```ts title="evals/weather/brooklyn-forecast.eval.ts"
 import { defineEval } from "eve/evals";
@@ -25,7 +25,7 @@ export default defineEval({
   async test(t) {
     const turn = await t.send("What is the weather in Brooklyn?");
     t.succeeded();
-    t.check(turn.message, includes("Sunny"));
+    t.check(turn.reply, includes("Sunny"));
   },
 });
 ```
@@ -69,8 +69,8 @@ import { includes } from "eve/evals/expect";
 export default defineEval({
   async test(t) {
     const draft = await t.send("Draft the follow-up email.");
-    t.check(draft.message, includes("Best regards"));
-    t.judge("professional tone", { on: draft.message }).atLeast(0.6);
+    t.check(draft.reply, includes("Best regards"));
+    t.judge("professional tone", { on: draft.reply }).atLeast(0.6);
 
     await draft.session.send("Now send it.");
     t.calledTool("send_email");
@@ -105,22 +105,22 @@ export default defineEval({
 
 Every `t.session()` or `t.send()` creates a new independent conversation. Continue an existing conversation through its session handle. Events from all sessions feed the same run-level assertions.
 
-- `t.session(options?)` creates a session without starting a turn or consuming its stream. It resolves on `202 Accepted` with an `EveEvalSession` whose `.sessionId` and `.state` are available. Options accept per-request `headers` and `signal`; creation uses the eval timeout signal by default.
-- `t.send(message, options?)` creates a new session with its first message in one request and waits for the turn to settle. The returned turn carries `.session`, `.message`, and `.expectOk()`.
+- `t.session(options?)` creates a session without starting a turn or consuming its stream. It resolves on `202 Accepted` with an `EveEvalSession` whose `.id` and `.state` are available. Options accept per-request `headers` and `signal`; creation uses the eval timeout signal by default.
+- `t.send(message, options?)` creates a new session with its first message in one request and waits for the turn to settle. The returned turn carries `.session`, `.reply`, and `.expectOk()`.
 - `session.send(message, options?)` sends a follow-up on that session and waits for it to settle.
 - `session.start(message, options?)` starts a text turn and returns as soon as the server accepts it. The live turn exposes `.session`, `.sessionId`, `.waitForEvent(...)`, `.cancel()`, and `.result()`.
-- `session.cancel()` requests cooperative cancellation of that session's active turn. Both `accepted` and `no_active_turn` are successful outcomes.
-- `session.compact()` compacts that session's history between turns and waits for it to finish. It resolves to the captured events from `compaction.requested` through `session.waiting`, so assertions such as `.event("compaction.completed")` work on the result. It throws when the session is no longer active.
+- `session.cancel()` returns a delivery for cooperative cancellation. A live idle session also accepts a no-op cancellation; an inactive session throws `SessionNotActiveError`.
+- `session.compact()` compacts that session's history between turns and waits for it to finish. It resolves to the captured events of the compaction, a context change, so assertions such as `.event("context.settled", { data: { kind: "compaction", outcome: "completed" } })` work on the result. It throws when the session is no longer active.
 - `session.sendFile(text, path, mediaType?)` attaches a local file as a data URL.
-- `session.agent(started).stream(options?)` follows a delegated child's stream through the parent with the eval client's credentials. Pass an `agent.started` event from that session. It also reaches children on another deployment, which `t.target.watchTurn(...)` cannot address.
-- `session.requireInputRequest(filter?)` records a gate, requires exactly one pending request, and returns it. Filters match tool name, action input, prompt, display, and option ids.
+- `session.agent(opened).stream(options?)` follows a delegated child's stream through the parent with the eval client's credentials. Pass a `child.opened` event from that session. It also reaches children on another deployment, which `t.target.attach(...).watch()` cannot address.
+- `session.requireInteraction(filter?)` records a gate, requires exactly one pending request, and returns it. Filters match tool name, action input, prompt, display, and option ids.
 - `session.respond(responses, options?)` answers specific pending input requests and sends them as the next turn. `session.startRespond(...)` returns a live turn for the same operation.
 - `session.respondAll(optionId)` answers every pending input request with the same option and sends the responses as the next turn.
 - `session.events` contains the events captured for that session. `session.transcript` formats its observed user and assistant messages in turn order.
 
 The transcript uses `User:` and `Assistant:` labels separated by blank lines. It excludes reasoning, tool calls, tool results, and messages from other sessions. It updates after each turn settles, so read it after `await session.send(...)`, `await session.respond(...)`, or `await live.result()`.
 
-Each `send` (and `respond`/`respondAll`) resolves to a turn with `.message`, `.data`, `.events`, `.inputRequests`, `.toolCalls`, `.session`, `.sessionId`, `.status`, and `.expectOk()`. Turn results retain their captured output and events; `.session` references the live conversation handle. `expectOk()` throws only when the turn ended failed; a session left open for a next message is the normal end state of a successful turn.
+Each `send` (and `respond`/`respondAll`) resolves to a turn with `.reply`, `.data`, `.events`, `.interactions`, `.toolCalls`, `.session`, `.sessionId`, `.status`, and `.expectOk()`. Turn results retain their captured output and events; `.session` references the live conversation handle. `expectOk()` throws only when the turn ended failed; a session left open for a next message is the normal end state of a successful turn.
 
 ## Prewarming a session
 
@@ -134,7 +134,7 @@ export default defineEval({
   async test(t) {
     const session = await t.session();
     const turn = await session.send("Greet Alice briefly.");
-    await t.require(turn.sessionId, equals(session.sessionId));
+    await t.require(turn.sessionId, equals(session.id));
     turn.event("session.started", { count: 1 });
     turn.event("turn.started", { count: 1, data: { turnId: "turn_0" } });
     t.succeeded();
@@ -153,8 +153,8 @@ and participate in timeout cleanup even when no message was sent.
 Replace `t.newSession()` and `t.prewarm()` with `const session = await t.session()`.
 Replace consecutive `t.send()` calls with `session.send()` calls, or continue the first
 returned turn through `turn.session.send()`. Read identity, cursor, events, and transcript
-from `session`; read replies from `turn.message`. Session operations such as `respond()`,
-`requireInputRequest()`, and `cancel()` also move from `t` to `session`.
+from `session`; read replies from `turn.reply`. Session operations such as `respond()`,
+`requireInteraction()`, and `cancel()` also move from `t` to `session`.
 
 ## In-flight turns
 
@@ -168,18 +168,13 @@ export default defineEval({
     const session = await t.session();
     const live = await session.start("Run the long operation.");
 
-    await live.waitForEvent("actions.requested", {
-      data: {
-        actions: (actions) =>
-          actions.some(
-            (action) => action.kind === "tool-call" && action.toolName === "long_operation",
-          ),
-      },
+    await live.waitForEvent("call.requested", {
+      data: { capability: { kind: "tool", name: "long_operation" } },
     });
 
     await live.cancel();
     const turn = await live.result();
-    turn.eventOrder([{ type: "turn.cancelled" }, { type: "session.waiting" }]);
+    turn.event("turn.settled", { count: 1, data: { outcome: "cancelled" } });
   },
 });
 ```
@@ -190,7 +185,7 @@ Use `expectOk()` only when the next operation depends on that intermediate turn
 
 To intentionally omit an eval for the current target, call `t.skip(reason)` before creating sessions, sending messages, or recording assertions. Skipped evals are reported separately and do not affect the exit code.
 
-Events from every session are captured in the result and artifacts. `t.log(message)` records debug lines into the eval artifact; `--verbose` also streams them to stdout as evals run. `t.signal` is an `AbortSignal` that fires on timeout.
+Events from every session are captured in the result and artifacts. `t.log(message)` records debug lines into the eval artifact; `--verbose` also streams them to stdout as evals run. `t.abortSignal` is an `AbortSignal` that fires on timeout.
 
 For driving sessions created outside the eval, by a channel webhook or a schedule, see [Targets](./targets).
 
@@ -212,7 +207,7 @@ export default rows.map((row) =>
     async test(t) {
       const turn = await t.send(row.prompt);
       t.succeeded();
-      t.check(turn.message, equals(row.sql));
+      t.check(turn.reply, equals(row.sql));
     },
   }),
 );

package/docs/evals/judge.mdx

@@ -51,7 +51,7 @@ Pass `on` to replace the output. JSON values stay structured rather than being c
 
 ```ts
 const draft = await t.send("Draft the welcome email.");
-t.judge("The response has a professional tone.", { on: draft.message }).atLeast(0.6);
+t.judge("The response has a professional tone.", { on: draft.reply }).atLeast(0.6);
 ```
 
 For a multi-turn eval, pass `session.transcript`:
@@ -72,7 +72,7 @@ A batch makes one decision request against one shared state. Pass `state` to rep
 
 ```ts
 const judgments = t.judge({
-  state: { response: turn.message ?? "", reference },
+  state: { response: turn.reply ?? "", reference },
   questions: {
     accurate: {
       type: "boolean",

package/docs/evals/overview.mdx

@@ -37,7 +37,7 @@ export default defineEval({
     const turn = await t.send("What is the weather in Brooklyn?");
     t.succeeded();
     t.calledTool("get_weather");
-    t.check(turn.message, includes("Sunny"));
+    t.check(turn.reply, includes("Sunny"));
   },
 });
 ```
@@ -50,15 +50,15 @@ Every `evals/` directory needs exactly one `evals.config.ts` at its root. It dec
 
 ```ts title="evals/evals.config.ts"
 import { defineEvalConfig } from "eve/evals";
-import { Braintrust } from "eve/evals/reporters";
+import { braintrustReporter } from "eve/evals/reporters";
 
 export default defineEvalConfig({
   judge: { model: "typesafe-ai/jev" },
-  reporters: [Braintrust({ projectName: "my-agent" })],
+  reporters: [braintrustReporter({ projectName: "my-agent" })],
 });
 ```
 
-Everything is optional. `judge` sets the default model for [LLM-as-judge](./judge) assertions (`t.judge(...)`); omit it to use the default decider, `typesafe-ai/jev`. Deterministic evals make no judge requests. `reporters`, `maxConcurrency`, `timeoutMs`, and `repeat` round out the defaults. Config `reporters` observe every eval in the run, so set one `Braintrust()` here instead of adding it to each eval. `repeat` runs every eval several times to measure repeatability; see [Repeat evals](./running#repeat-evals). CLI flags (`--max-concurrency`, `--timeout`, `--repeat`) and per-eval values take precedence over the config defaults.
+Everything is optional. `judge` sets the default model for [LLM-as-judge](./judge) assertions (`t.judge(...)`); omit it to use the default decider, `typesafe-ai/jev`. Deterministic evals make no judge requests. `reporters`, `maxConcurrency`, `timeoutMs`, and `repeat` round out the defaults. Config `reporters` observe every eval in the run, so set one `braintrustReporter()` here instead of adding it to each eval. `repeat` runs every eval several times to measure repeatability; see [Repeat evals](./running#repeat-evals). CLI flags (`--max-concurrency`, `--timeout`, `--repeat`) and per-eval values take precedence over the config defaults.
 
 ### Run setup and teardown
 
@@ -145,7 +145,7 @@ model: mockModel({
 
 `t` is both the driver and the assertion surface. There are no separate `input`, `run`, `checks`, or `scores` fields. You write ordinary control flow, sending turns and asserting inline.
 
-- **Drive** the agent: `t.session()` creates an empty session; `t.send(...)` creates a session with its first message and returns a turn. Continue through `turn.session.send(...)`. Session handles also expose `start`, `cancel`, `respond`, `respondAll`, `sendFile`, and `requireInputRequest`. Read output from `turn.message`, and conversation state from `turn.session`. See [Cases](./cases).
+- **Drive** the agent: `t.session()` creates an empty session; `t.send(...)` creates a session with its first message and returns a turn. Continue through `turn.session.send(...)`. Session handles also expose `start`, `cancel`, `respond`, `respondAll`, `sendFile`, and `requireInteraction`. Read output from `turn.reply`, and conversation state from `turn.session`. See [Cases](./cases).
 - **Assert** with three surfaces, covered next.
 
 ## Three assertion surfaces
@@ -153,7 +153,7 @@ model: mockModel({
 Each surface matches a genuinely different kind of judgment:
 
 - **Scoped methods** read the final whole run on `t`, snapshot one independent session when invoked there, or inspect one immutable `EveEvalTurn`. See [Assertions](./assertions).
-- **`t.check(value, assertion)`** grades an explicit value with a deterministic builder from `eve/evals/expect`, such as `t.check(turn.message, includes("sunny"))`. Grade `turn.message`, an intermediate draft, parsed JSON, or anything else. See [Assertions](./assertions).
+- **`t.check(value, assertion)`** grades an explicit value with a deterministic builder from `eve/evals/expect`, such as `t.check(turn.reply, includes("sunny"))`. Grade `turn.reply`, an intermediate draft, parsed JSON, or anything else. See [Assertions](./assertions).
 - **`t.score(evaluation)`** records a score, such as a length ratio or an evaluator's result. Chain `.label(key)` to name it, and `.gate(threshold)` or `.atLeast(threshold)` to let it decide the eval. See [Assertions](./assertions#scores-with-tscore).
 - **`t.judge(...)`** is the LLM-as-judge surface, like `t.judge("cites a source")`. It grades the most recently settled turn’s assistant message by default; pass `{ on: turn.session.transcript }` to grade a multi-turn conversation. The judge uses the configured judge model, never the agent under test. See [Judge](./judge).
 
@@ -171,7 +171,7 @@ t.succeeded(); // gate
 t.calledTool("get_weather").soft(); // record as a metric, don't gate
 t.judge("cites a source"); // soft, tracked (no threshold)
 t.judge("The response is consistent with output.reference.", {
-  on: { response: turn.message ?? "", reference },
+  on: { response: turn.reply ?? "", reference },
 }).atLeast(0.7); // soft, gated under --strict at 0.7
 ```
 

package/docs/evals/reporters.mdx

@@ -11,15 +11,15 @@ Reporters attach in two places. Declare them in `evals.config.ts` to observe **e
 
 ## Braintrust
 
-`Braintrust(...)` uploads eval results to Braintrust experiments. Put one instance in the config so it covers the whole run:
+`braintrustReporter(...)` uploads eval results to Braintrust experiments. Put one instance in the config so it covers the whole run:
 
 ```ts title="evals/evals.config.ts"
 import { defineEvalConfig } from "eve/evals";
-import { Braintrust } from "eve/evals/reporters";
+import { braintrustReporter } from "eve/evals/reporters";
 
 export default defineEvalConfig({
   judge: { model: "typesafe-ai/jev" },
-  reporters: [Braintrust({ projectName: "weather-agent" })],
+  reporters: [braintrustReporter({ projectName: "weather-agent" })],
 });
 ```
 
@@ -27,10 +27,10 @@ Need a destination for only some evals? Attach it per eval instead:
 
 ```ts title="evals/brooklyn-forecast.eval.ts"
 import { defineEval } from "eve/evals";
-import { Braintrust } from "eve/evals/reporters";
+import { braintrustReporter } from "eve/evals/reporters";
 
 export default defineEval({
-  reporters: [Braintrust({ projectName: "weather-agent" })],
+  reporters: [braintrustReporter({ projectName: "weather-agent" })],
   async test(t) {
     await t.send("What is the weather in Brooklyn?");
     t.succeeded();
@@ -46,14 +46,14 @@ Braintrust needs its SDK installed in the app and credentials in the environment
 
 ## Datadog
 
-`Datadog(...)` uploads eval assertion scores to a Datadog LLM Observability Experiment. Put one instance in the config so it covers the whole run:
+`datadogReporter(...)` uploads eval assertion scores to a Datadog LLM Observability Experiment. Put one instance in the config so it covers the whole run:
 
 ```ts title="evals/evals.config.ts"
 import { defineEvalConfig } from "eve/evals";
-import { Datadog } from "eve/evals/reporters";
+import { datadogReporter } from "eve/evals/reporters";
 
 export default defineEvalConfig({
-  reporters: [Datadog({ projectName: "weather-agent" })],
+  reporters: [datadogReporter({ projectName: "weather-agent" })],
 });
 ```
 
@@ -69,7 +69,7 @@ Datadog needs `dd-trace` installed in the app and Datadog credentials in the env
 
 ## JUnit
 
-`JUnit({ filePath })` writes JUnit XML for CI annotations. The `--junit <path>` CLI flag does the same thing without touching the eval file, usually the better fit because CI owns the output path, not the eval:
+`junitReporter({ filePath })` writes JUnit XML for CI annotations. The `--junit <path>` CLI flag does the same thing without touching the eval file, usually the better fit because CI owns the output path, not the eval:
 
 ```bash
 eve eval --strict --junit .eve/junit.xml
@@ -101,9 +101,13 @@ Each entry in `result.assertions` is an `AssertionResult`. `name` is the display
 
 An eval can create several sessions, and a long session can produce several traces, so completion exposes a list instead of a single trace id. `onEvalStart` does not include a trace because the agent session has not started yet. If the target has no tracing configured, `onSessionStart` does not fire and the completed trace list is empty.
 
-`result.result.derived` holds the facts the runner derived from the eval's sessions, such as tool calls and `models`: the distinct ids of the models the steps started with, in session order. Each entry in `result.result.sessions` holds the same facts for one session, in first-use order, so a reporter can tell the primary session's models from those of the other sessions the eval created or attached. A delegated subagent runs in its own session, so its models appear only when the eval attaches that session with `t.target.attachSession`. Compaction and `auto` routing calls are not included.
+`result.result.derived` holds the facts the runner derived from the eval's sessions, such as tool calls and `models`: the distinct ids of the models the steps started with, in session order. Each entry in `result.result.sessions` holds the same facts for one session, in first-use order, so a reporter can tell the primary session's models from those of the other sessions the eval created or attached. A delegated subagent runs in its own session, so its models appear only when the eval attaches and reads that session with `t.target.attach(...).nextTurn()` or `watch()`. Compaction summaries are included; provider-internal routing without an eve model lifecycle is not.
 
-`derived.usage` is the token usage and cost from each session's latest `session.waiting`, `turn.waiting`, `session.failed`, or `session.completed`, including what its delegated agents spent; on a turn, it is the session's total so far. The eval's `usage` counts each captured session once, by its latest usage in time (an eval can capture a session again with an earlier snapshot), and leaves out sessions another captured session opened, because that session already counts their spend. It is absent when a counted session reported no usage, and its `costUsd` is absent when a counted session reported no cost, so a partial sum never reads as the eval's cost. Compaction summary calls are included. It leaves out the turns an eval sends directly to a child session it attached, and delegated spend counted after a session's last such event.
+`result.result.reply` is the last observed turn's text; `data` is its structured output, without a text fallback. Its `status` describes the request, while `sessionEnded` and the optional `view` describe that turn's session. The top-level `sessionId` still identifies the primary captured session; inspect `sessions` for each session's events and view. When selecting one value for a reporter, fall back to `reply` only when `data === undefined`, so structured `null` remains an output.
+
+Braintrust and Datadog metadata use `eveStatus`, `eveAwaitingInput`, and `eveSessionEnded`. Update saved filters that used `eveParked` to use `eveAwaitingInput`, and use `eveSessionEnded` to distinguish request completion from session retirement. Existing records are not rewritten.
+
+`derived.usage` is the token usage and cost a session recorded, summed from its `usage.recorded` facts, including what its delegated agents spent; on a turn, it is the session's total so far. The eval's `usage` counts each captured session once, using the snapshot with the latest recorded session activity rather than the last capture order, and leaves out sessions another captured session opened, because that session already counts their spend. It is absent when a counted session recorded no usage. It includes compaction summaries.
 
 Reporter callbacks for an eval stay ordered—eval start, traced session starts, then completion—even when several evals run concurrently. Reach for a custom reporter only when a destination isn't covered. The per-run artifacts under `.eve/evals/` retain the trace contexts alongside the result for ad-hoc inspection.
 

package/docs/evals/targets.mdx

@@ -15,7 +15,8 @@ import { defineEval } from "eve/evals";
 export default defineEval({
   async test(t) {
     const { sessionIds } = await t.target.dispatchSchedule("heartbeat");
-    await t.target.attachSession(sessionIds[0]!);
+    const session = t.target.attach(sessionIds[0]!);
+    await session.nextTurn();
     t.succeeded();
     t.calledTool("send_report");
   },
@@ -24,8 +25,9 @@ export default defineEval({
 
 - `t.target.fetch(path, init)` performs an authenticated fetch against the target, useful for channel and webhook ingress. See [Authentication](#authentication) for how the runner authenticates.
 - `t.target.dispatchSchedule(id)` triggers a [schedule](../schedules) through the dev-only schedule route and returns the session ids it created. It works only against a target with dev routes enabled (the local `eve eval` dev server, or a deployment running in development mode), and throws otherwise.
-- `t.target.attachSession(sessionId, { startIndex? })` consumes one turn from a session created outside the eval, by a channel or a schedule, so its events feed the run-level assertions. `startIndex` skips events before that position, so a session already partway through its stream resumes from where you left off rather than replaying from the start. The attached session stays bound to that exact ID, so `session.send(...)` and `session.respond(...)` continue it after the turn parks (`session.waiting`).
-- `t.target.watchTurn(sessionId, { startIndex? })` starts consuming an externally-created turn immediately and returns a live-turn handle. Use `waitForEvent(...)` to coordinate with mid-turn work, `cancel()` to request cancellation, and `result()` to consume through the boundary. The live turn's `.session` is the attached `EveEvalSession` for follow-up sends after settlement.
+- `t.target.attach(sessionId, { startIndex? })` returns a handle without I/O. Its `id` is the exact session ID, and `startIndex` sets the initial stream cursor. An unknown or inaccessible session fails when you read it, not when you attach it.
+- `session.nextTurn()` reads and records the next turn boundary. Its events feed both the session's assertions and the run-level assertions. Each read advances the same session cursor.
+- `session.watch()` starts consuming immediately and returns a live-turn handle. Use `waitForEvent(...)` to coordinate with mid-turn work, `cancel()` to request cancellation, and `result()` to read through the boundary. Pass `{ until }` to stop at the commit containing a matching event, such as `context.settled` for a context change between turns.
 
 Sessions attached this way are full `EveEvalSession`s: you can keep driving them and assert directly on that session (`session.succeeded()`, `session.calledTool(...)`). Aggregate assertions on `t` continue to read the whole run, including every attached session.
 

package/docs/evals/tool-stubs.mdx

@@ -189,7 +189,7 @@ The stub verification endpoint also requires `allowToolStubs`, checked before re
 
 Stubs replace execution of existing ordinary, dynamic, and workflow tools. They retain the real tool's input schema, approvals, and output processing. A stub does not register a new tool or make it visible to the model.
 
-Ordinary tools with configured stub rules can emit an extra `action.partial` containing the final response. This also applies when no rule matches and the real tool returns a non-streaming result. The final `action.result` remains correct, and real streaming still delivers progress. Use `action.result` for final-result assertions. Removing the extra event is tracked in [AX-5164](https://linear.app/vercel/issue/AX-5164).
+Ordinary tools with configured stub rules can emit an extra `call.progress` containing the final response. This also applies when no rule matches and the real tool returns a non-streaming result. The final `call.settled` remains correct, and real streaming still delivers progress. Use `call.settled` for final-result assertions. Removing the extra event is tracked in [AX-5164](https://linear.app/vercel/issue/AX-5164).
 
 ### Subagents
 
@@ -252,7 +252,7 @@ turn.expectOk();
 turn.calledTool("list_tasks", { status: "failed", count: 1 });
 ```
 
-The eval can pass when the agent handles the failure correctly. `noFailedActions()` still rejects the failed call, so use explicit assertions for expected failures. Stub infrastructure and response-processing failures still fail verification.
+The eval can pass when the agent handles the failure correctly. `noFailedCalls()` still rejects the failed call, so use explicit assertions for expected failures. Stub infrastructure and response-processing failures still fail verification.
 
 This works for ordinary tools, workflow tools, whole-agent replacements, and qualified connection operations. An exception in a persistent workflow tool ends that task; retry with a new call, rather than its failed task ID. Normal approvals apply before an outcome is consumed.
 

package/docs/extensions.md

@@ -347,12 +347,13 @@ To retain an extension tool's result type in a consumer hook, import its definit
 ```ts title="agent/hooks/narrow-crm.ts"
 import { defineHook } from "eve/hooks";
 import { toolResultFrom } from "eve/tools";
+import { call } from "eve/events";
 import { search } from "@acme/crm/tools";
 
 export default defineHook({
   events: {
-    "action.result"(event) {
-      const match = toolResultFrom(event.data.result, search);
+    "call.settled"(event, ctx) {
+      const match = toolResultFrom(call(ctx.view, event.data.callId), search);
       if (match) console.log(match.output);
     },
   },
@@ -367,7 +368,9 @@ Local `eve dev` also mounts bundled development extensions without creating a pr
 
 ### Compatibility
 
-At build time, eve checks the extension's generated capability metadata. If the extension needs an unsupported capability contract, upgrade eve or install a compatible extension release.
+`eve extension build` records the eve version used to build the extension. When you mount a package, eve checks its distribution before loading extension code. A distribution built with a newer eve release needs that release or later; build with the oldest eve release you want to support and test the same distribution with newer consumers. An unsupported distribution generation needs a rebuilt extension or a compatible release. npm peer ranges do not replace this check.
+
+**Extensions built with the old epoch-based manifest need a rebuild** when you upgrade to the first eve release that uses the new format. Upgrade to a compatible extension release, or rebuild a source-backed workspace extension with that eve release. An installed, source-free extension cannot be rebuilt by the consuming app.
 
 ## What to read next
 

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

@@ -105,6 +105,10 @@ Exercise caution for agents that process non-public, sensitive, regulated, or pr
 
 Authenticates a synthetic `local-dev` principal, but only while the process is a local development server: `eve dev` (which sets `EVE_DEV=1`) or `vercel dev` (detected by `VERCEL=1` and `VERCEL_ENV=development` together). This is a property of the deployment, not the request, so no request header can flip it. A production deployment (`eve start`, a Vercel deployment, or any container host) sets neither flag, so `localDev()` authenticates nothing there and every request falls through to the next entry.
 
+On a development server, `localDev()` also refuses requests that a browser sends for another website: the request host or its `Origin` is neither a loopback host nor one of this machine's own addresses. A web page that the developer opens cannot call the local agent, even through DNS rebinding. A frontend served from any loopback host and port, such as `http://localhost:3000` calling `http://127.0.0.1:2000`, still authenticates.
+
+On `eve dev`, `localDev()` also refuses callers whose connection comes from another machine. A server started with `eve dev --host 0.0.0.0` accepts LAN connections, but those callers do not get the `local-dev` principal. A tunnel or reverse proxy on the same machine, such as ngrok or a local nginx, connects from this machine, so the callers it forwards still get `local-dev`.
+
 Because it never opens a production deployment, `localDev()` is safe to leave in the walk. Still put a real authenticator ahead of it so production traffic has something to match.
 
 ### `vercelOidc()`

package/docs/guides/client/continuations.mdx

@@ -10,14 +10,14 @@ replay events already consumed by that handle.
 ## Read and persist state
 
 Create the session with its first turn, then persist `session.state` after
-consuming the response:
+consuming the delivery:
 
 ```ts
-const { session, response } = await client.sessions.create({
+const { session, delivery } = await client.sessions.create({
   message: "Create a launch checklist.",
 });
 
-await response.result();
+await delivery.result();
 await saveSessionState(session.state);
 ```
 
@@ -65,13 +65,13 @@ result.
 
 ## Waiting, completed, and reset sessions
 
-A session that emits `session.waiting` accepts another message through the same
-handle. A terminal or reset session does not. Start a fresh conversation
+A session that hasn't ended (`session.ended`) accepts another message through the
+same handle. A terminal or reset session does not. Start a fresh conversation
 explicitly with another `client.sessions.create(firstTurn)` call.
 
 ```ts
 const reset = await session.reset({ reason: "Start over" });
-const { session: fresh, response } = await client.sessions.create({ message: "Begin again." });
+const { session: fresh, delivery } = await client.sessions.create({ message: "Begin again." });
 ```
 
 The old `session` remains pinned to its retired ID; `fresh` owns a different ID.
@@ -81,19 +81,19 @@ The old `session` remains pinned to its retired ID; `fresh` owns a different ID.
 Create one handle per conversation:
 
 ```ts
-const { session: research, response: researchResponse } = await client.sessions.create({
+const { session: research, delivery: researchDelivery } = await client.sessions.create({
   message: "Research competitors.",
 });
-const { session: support, response: supportResponse } = await client.sessions.create({
+const { session: support, delivery: supportDelivery } = await client.sessions.create({
   message: "Draft a support reply.",
 });
 
-await Promise.all([researchResponse.result(), supportResponse.result()]);
+await Promise.all([researchDelivery.result(), supportDelivery.result()]);
 await save("research", research.state);
 await save("support", support.state);
 ```
 
-The shared `Client` owns host, auth, headers, and redirect policy. Each
+The shared `Client` owns the base URL, auth, headers, and redirect policy. Each
 `ClientSession` owns its fixed ID and stream cursor.
 
 ## Reconnect an existing stream