eve 0.69.0 → 0.70.1

package/docs/guides/frontend/overview.mdx

@@ -53,7 +53,7 @@ export function Chat() {
         <article key={message.id}>
           <header>{message.role}</header>
           {message.parts.map((part, index) =>
-            part.type === "text" ? <p key={index}>{part.text}</p> : null,
+            part.type === "text" ? <p key={part.id ?? index}>{part.text}</p> : null,
           )}
         </article>
       ))}
@@ -70,21 +70,22 @@ export function Chat() {
 
 `useEveAgent()` returns the current UI state plus commands:
 
-| Field     | What it is                                                                                |
-| --------- | ----------------------------------------------------------------------------------------- |
-| `data`    | Projected UI state from the reducer. Defaults to `{ messages }`.                          |
-| `status`  | `"ready"`, `"resuming"`, `"submitted"`, `"streaming"`, or `"error"`. Drives the composer. |
-| `error`   | The latest session creation, stream, resume, or turn failure.                             |
-| `events`  | Raw eve stream events for this session.                                                   |
-| `session` | Serializable fixed session cursor (`sessionId`, `streamIndex`).                           |
-| `prewarm` | Create the durable session without starting a turn.                                       |
-| `send`    | Send text or a multi-part message, with per-turn options.                                 |
-| `respond` | Answer pending HITL input requests, with per-turn options.                                |
-| `resume`  | Replay an attached session and follow its in-flight turn.                                 |
-| `cancel`  | Request durable cancellation of the active turn.                                          |
-| `reset`   | Clear local events, data, errors, and the local session cursor.                           |
-
-Most chat UIs only need `data.messages` and `status`. Drop down to `events` when you need the authoritative wire events directly, for example to persist an audit log or build a custom projection.
+| Field          | What it is                                                                                |
+| -------------- | ----------------------------------------------------------------------------------------- |
+| `data`         | The selected projection: `ConversationState` by default, or your custom reducer's state.  |
+| `conversation` | Canonical conversation state, including messages, root turns and inputs, and child state. |
+| `status`       | `"ready"`, `"resuming"`, `"submitted"`, `"streaming"`, or `"error"`. Drives the composer. |
+| `error`        | The latest session creation, stream, resume, or turn failure.                             |
+| `events`       | Raw eve stream events for this session.                                                   |
+| `session`      | Serializable fixed session cursor (`sessionId`, `streamIndex`).                           |
+| `prewarm`      | Create the durable session without starting a turn.                                       |
+| `send`         | Send text or a multi-part message, with per-turn options.                                 |
+| `respond`      | Answer pending HITL input requests, with per-turn options.                                |
+| `resume`       | Replay an attached session and follow its in-flight turn.                                 |
+| `cancel`       | Request durable cancellation of the active turn.                                          |
+| `reset`        | Clear local events, data, errors, and the local session cursor.                           |
+
+Most chat UIs only need `data.messages` and `status` with the default reducer. Use `conversation` for session state when a custom reducer shapes `data`. Drop down to `events` when you need the authoritative wire events directly, for example to persist an audit log or build a custom projection.
 
 Pass `prewarm: true` to start a workflow when the chat mounts and after each reset:
 
@@ -157,9 +158,10 @@ change the option from `false` to `true` again, reset, or send a message to reco
 
 The hook keeps consuming one session stream across turns and idle periods. Replies,
 authorization updates, and turns started elsewhere all update the same projection. Separately
-delivered participant messages remain separate bubbles even when they steer the same active turn;
-a single event that coalesces multiple deliveries remains one bubble. A turn settling does not
-close the connection. The transport reconnects from its cursor after a disconnect or the
+delivered participant messages remain separate bubbles before that turn's assistant response, even
+when they arrive after the response begins. A single event that coalesces multiple deliveries
+remains one bubble. A turn settling does not close the connection. The transport reconnects from
+its cursor after a disconnect or the
 server's renewable 60-second lease; lease renewal does not start a turn or clear UI state.
 Unmounting or resetting closes the local stream without cancelling the old durable session.
 
@@ -168,9 +170,15 @@ the reset, it prepares the next owned session; otherwise, the next send creates
 supplied `session` remains externally owned and is never replaced by prewarming or reset. Use
 `initialSession` with `resume: true` to restore a saved chat.
 
-`data.messages` are eve-owned `EveMessage[]`. Common text, reasoning, file, and dynamic-tool parts follow the [AI SDK `UIMessage`](https://ai-sdk.dev/docs/reference/ai-sdk-core/ui-message) rendering convention, but the types are not interchangeable. eve also exposes authorization and HITL metadata, and a file part's URL can be absent. Adapt those parts before passing messages to an API typed as `UIMessage[]`.
+`data.messages` are eve-owned `EveMessage[]`. Assistant text and reasoning parts have a stable `id` from the event that created the part. Appends and completion retain that ID. Use `part.id` to key streamed assistant content, including successive text parts within one step. Older events without an ID get a best-effort fallback. User text parts may not have an ID.
 
-When the root agent delegates, its stream emits `agent.started` with the child's `sessionId`, and the subagent tool call's `task.settled` carries the child's reply. The child session can remain available for reuse. Detailed child progress lives on the child session's stream instead of being flattened into the root `data.messages`. When your UI needs live subagent activity, attach a [client session](../client/overview#sessions) to the parent and pass the `agent.started` event from `events` to [`session.agent()`](../client/streaming#follow-a-subagent) and follow the child with `stream()`. It follows local and remote children through the parent, so the browser never calls a remote deployment directly. See [What the parent sees](../../subagents#what-the-parent-sees) for the complete contract.
+Common text, reasoning, file, and dynamic-tool parts follow the [AI SDK `UIMessage`](https://ai-sdk.dev/docs/reference/ai-sdk-core/ui-message) rendering convention, but the types are not interchangeable. eve also exposes authorization and HITL metadata, and a file part's URL can be absent. Adapt those parts before passing messages to an API typed as `UIMessage[]`.
+
+When the root agent delegates, its stream emits `task.started` for the call, `agent.started` with the child's `sessionId`, and `task.settled` with the call's result, failure, or cancellation. The default reducer settles the subagent's tool part from `task.settled`, so the part shows the call's outcome rather than its start receipt. `data.tasks[taskId].calls[callId]` records each call's `status`, `output`, and `error`, and `data.agents[sessionId]` records each session a call opened, with its `taskId` and opening `callId`. These records come from the root stream alone.
+
+Detailed child progress lives on the child session's stream, not in the root `data.messages`. Pass `followSubagents: true` to follow the session each subagent call reaches while the component is mounted; following is off by default. Narrow `data.agents[sessionId].observation.status` before reading its `conversation`: `"not-followed"` has no child detail, `"following"` has live detail, and `"idle"` has everything the calls so far produced and resumes when another call reaches the task. `"unavailable"` means the stream failed, not that the child failed. Calls that continue a task with its `taskId` reach the same session, so one session's `conversation.messages`, `inputs`, and `turns` span all of them. Sessions that a custom task opens with `ctx.agent` are recorded but not followed.
+
+If you manage your own session rather than using the hook, pass an `agent.started` event from `events` to [`session.agent()`](../client/streaming#follow-a-subagent) and follow the child with `stream()`. It follows local and remote children through the parent, so the browser never calls a remote deployment directly. See [What the parent sees](../../subagents#what-the-parent-sees) for the complete contract.
 
 ## Sending and streaming
 
@@ -192,13 +200,15 @@ await agent.send([
 
 Assistant text, reasoning, tool calls, and tool results stream into `data` as they arrive, and a new turn moves `status` from `ready` to `submitted` to `streaming` and back. Resuming an attached session uses `resuming` while eve performs bounded catch-up. Disable message and HITL submission in that state. A settled tail moves directly to `ready`; an in-flight tail moves to `streaming` before eve follows it.
 
+A turn stays open while tasks it started are working. `status` stays `streaming` until the turn ends, and `data.turns[turnId].waiting` is `true` while the turn is parked, until its next step starts. When a call the turn runs asks a question, `send()` resolves at that point, as `session.send().result()` does; answer with `respond()` while the turn stays open.
+
 To steer an active turn with a follow-up, send the message with `turnPolicy: "steer"`. Before answer output or local tool execution begins, eve interrupts pending model generation and continues the same turn with the correction. Executing tools finish and checkpoint their results first; after answer output starts, steering waits for the next committed workflow boundary. Reasoning and search progress do not count as answer output. The hook stays attached through completion:
 
 ```tsx
 await agent.send(message, { turnPolicy: "steer" });
 ```
 
-Other message sends and HITL responses reject while the hook is processing a turn. Call `cancel()` to stop the durable server-side turn without replacing it, and `reset()` to clear local state so the next send starts a fresh durable session.
+Other message sends reject while the hook is processing a turn. Answers to open input requests are accepted at any time; see [Human-in-the-loop prompts](#human-in-the-loop-prompts). The default `data.inputs` ledger keeps each request's originating `turnId` and `stepIndex`, response and settlement status, including requests left open after their originating turn ends; `data.activeTurnId` tracks the current root turn when known. A request from a task's run also carries that task's `taskId`. Each followed session keeps its own ledger in `data.agents[sessionId].observation.conversation`. Call `cancel()` to stop the durable server-side turn without replacing it, and `reset()` to clear local state so the next send starts a fresh durable session.
 
 `cancel()` can be called as soon as `status` is `"submitted"`; the hook waits for the active response to identify its turn when necessary, sends one guarded cancellation request, and keeps the event stream attached. The promise resolves when eve accepts the request or reports that no turn is active, and rejects if the cancellation request fails. The turn then settles on the same stream as `turn.cancelled` followed by `session.waiting`, so the session is safe to continue.
 
@@ -216,18 +226,14 @@ received attachment as a `file` part on the user message. The part includes `med
 
 ## Human-in-the-loop prompts
 
-Tools opt into approval with `approval`, and workflow tools such as the opt-in `ask_question` tool ask the user a question with `ctx.ask()` — see [Human-in-the-loop](/docs/human-in-the-loop) for the server-side model. Either way the stream emits an `input.requested` event, and the pending request rides on a `dynamic-tool` part at `part.toolMetadata?.eve?.inputRequest`. Scan every message because an unrelated turn can add newer messages while an approval stays open, then answer through the same session with `respond()`:
+Tools opt into approval with `approval`, and workflow tools such as the opt-in `ask_question` tool ask the user a question with `ctx.ask()` — see [Human-in-the-loop](/docs/human-in-the-loop) for the server-side model. Either way the stream emits an `input.requested` event. The default projection keeps open requests in `data.inputs`, including a request that sits on an earlier message than the latest one. Render from that ledger and answer through the same session with `respond()`. The request also appears on its originating `dynamic-tool` part at `part.toolMetadata?.eve?.inputRequest` for inline display:
 
 ```tsx
-const pendingRequests = agent.data.messages
-  .flatMap((message) => message.parts)
-  .flatMap((part) => {
-    if (part.type !== "dynamic-tool" || part.state !== "approval-requested") return [];
-    const request = part.toolMetadata?.eve?.inputRequest;
-    return request ? [request] : [];
-  });
+import { openConversationInputs } from "eve/react";
+
+const pendingRequests = openConversationInputs(agent.data).map((input) => input.request);
 
-const inputDisabled = ["submitted", "streaming", "resuming"].includes(agent.status);
+const inputDisabled = agent.status === "resuming";
 
 return pendingRequests.map((request) => (
   <fieldset disabled={inputDisabled} key={request.requestId}>
@@ -252,11 +258,11 @@ return pendingRequests.map((request) => (
 ));
 ```
 
-For a question with `allowFreeform`, render a text input and send `{ requestId, text }`. The default reducer keeps each request pending until the server confirms its resolution through `input.resolved` or `approval.settled`. Disable input controls while the response is being processed; a refused approval attempt leaves the request answerable. Approved tools update again when eve streams their result.
+For a question with `allowFreeform`, render a text input and send `{ requestId, text }`. You can answer while other work runs. For example, when one model step asks to approve two tools, the first approval settles on its own and the second stays answerable while the batch waits for it. `respond()` marks each answered request `responded` in `data.inputs` until the server settles it through `approval.settled` or `input.resolved`, so `openConversationInputs()` no longer returns it. Answering a request that is no longer open rejects without contacting the server. A refused approval attempt, or a response that never reaches the server, reopens the request. Approved tools update again when eve streams their result.
 
 ## Authorization prompts
 
-Connections and tools that need OAuth or another grant emit `authorization.required`. The default reducer projects that into an `authorization` message part with the display name, instructions, device code, and user-facing sign-in URL. Render that part as a normal chat message, then keep the session cursor; eve resumes the parked turn when the callback completes and updates the part after `authorization.completed`:
+Connections and tools that need OAuth or another grant emit `authorization.required`. The default reducer projects that into an `authorization` message part with the display name, instructions, device code, and user-facing sign-in URL. When multiple people authorize the same connection in one session, the client matches completion to the corresponding `attemptId`, not merely the connection name. The part stays `required` until eve reports the outcome, then becomes `completed`. `awaitsCallback` is `true` when the sign-in's callback settles the attempt and resumes the parked turn. Render the part as a normal chat message and keep the session cursor so eve can resume the parked turn:
 
 ```tsx
 import type { EveMessagePart } from "eve/react";
@@ -284,7 +290,7 @@ function AuthorizationPrompt({ part }: { part: EveMessagePart }) {
 }
 ```
 
-For fully custom state machines, `authorization.required` and `authorization.completed` are still available on `events` and `onEvent`.
+With a custom reducer, authorization attempts remain available in `conversation.messages`; `authorization.required` and `authorization.completed` are also available on `events` and `onEvent`.
 
 ## Attach page context per turn
 
@@ -324,11 +330,11 @@ const agent = useEveAgent({
 });
 ```
 
-The `optimistic` option (default `true`) projects submitted user messages into `data` before eve confirms them with a `message.received` event. These are reducer-facing projection events only. `events` stays the authoritative eve stream. For an existing session, the hook reconciles each placeholder with the server's delivery ID, so an unrelated or identical message cannot consume it.
+The `optimistic` option (default `true`) projects submitted user messages into `data` before eve confirms them with a `message.received` event. Steered follow-ups appear before the active turn's assistant response once the turn is known; if the send fails, the failed placeholder stays in place. These are reducer-facing projection events only. `events` stays the authoritative eve stream. For an existing session, the hook reconciles each placeholder with the server's delivery ID, so an unrelated or identical message cannot consume it.
 
 ## Custom reducer
 
-The default reducer projects events into `{ messages }` (`EveMessageData`). When you want `data` shaped differently, pass a `reducer` implementing `EveAgentReducer<TData>`:
+The default hook uses `conversationReducer`, which includes the `EveMessageData` message fields plus turn and input state (`ConversationState`). When you want `data` shaped differently, pass a `reducer` implementing `EveAgentReducer<TData>`:
 
 ```tsx
 import { useEveAgent } from "eve/react";
@@ -345,10 +351,10 @@ const toolCounter: EveAgentReducer<ToolLog> = {
 };
 
 const agent = useEveAgent({ reducer: toolCounter });
-// agent.data is ToolLog
+// agent.data is ToolLog; agent.conversation remains ConversationState.
 ```
 
-`reduce(data, event)` receives both authoritative eve stream events and client projection events (`client.message.submitted`, `client.message.failed`, `client.input.responded`). `client.input.responded` notifies custom reducers that an answer was submitted, not that it was accepted. The default reducer waits for server settlement; the durable `input.resolved` event records the server-accepted outcome and lets replayed history rebuild the same HITL state. Return `data` unchanged for events your reducer does not handle.
+`reduce(data, event)` receives authoritative eve stream events and client projection events (`client.message.submitted`, `client.message.failed`, `client.input.responded`). The custom reducer only shapes `data`: the client maintains `conversation` separately for authorization, input requests, turns, and child following. Agent-session observations update `conversation.agents`, not the custom reducer. The built-in reducer makes `data` and `conversation` the same state. `client.input.responded` tells a custom reducer an answer was submitted, not that the server accepted it; the durable `input.resolved` event confirms settlement. Return `data` unchanged for events your reducer does not handle.
 
 ## Resumable sessions
 

package/docs/guides/frontend/use-eve-agent-svelte.mdx

@@ -62,21 +62,15 @@ Call `agent.send(text)` for text or pass content parts for attachments. The API
 
 ## Human-in-the-loop prompts
 
-Pending requests appear in `agent.data.messages`. Use the Svelte exports when narrowing message parts, then answer through `agent.respond()`:
+Open requests appear in the `agent.data.inputs` ledger. Read them with `openConversationInputs()`, then answer through `agent.respond()`. An answered request leaves the list right away, so its buttons can't be pressed twice:
 
 ```svelte
 <script lang="ts">
-  import { useEveAgent } from "eve/svelte";
+  import { openConversationInputs, useEveAgent } from "eve/svelte";
 
   const agent = useEveAgent();
   const pendingRequests = $derived(
-    agent.data.messages.flatMap((message) =>
-      message.parts.flatMap((part) => {
-        if (part.type !== "dynamic-tool" || part.state !== "approval-requested") return [];
-        const request = part.toolMetadata?.eve?.inputRequest;
-        return request ? [request] : [];
-      }),
-    ),
+    openConversationInputs(agent.data).map((input) => input.request),
   );
 </script>
 
@@ -128,7 +122,7 @@ Pass `onEvent`, `onError`, `onFinish`, or `onSessionChange` when the application
 
 ## Custom reducer
 
-Import `EveAgentReducer` from `eve/svelte` when projecting events into application-specific state. The resulting `agent.data` uses the reducer's `TData` type. See [Custom reducer](./overview#custom-reducer) for the reducer contract and client projection events.
+Import `EveAgentReducer` from `eve/svelte` when projecting events into application-specific state. The resulting `agent.data` uses the reducer's `TData` type; `agent.conversation` remains `ConversationState`. See [Custom reducer](./overview#custom-reducer) for the reducer contract and client projection events.
 
 ## What to read next
 

package/docs/guides/frontend/use-eve-agent-vue.mdx

@@ -61,23 +61,17 @@ Call `send(text)` for text or pass content parts for attachments. The API and tr
 
 ## Human-in-the-loop prompts
 
-Pending requests appear in `data.value.messages`. Use the Vue exports when narrowing message parts, then answer through `respond()`:
+Open requests appear in the `data.value.inputs` ledger. Read them with `openConversationInputs()`, then answer through `respond()`. An answered request leaves the list right away, so its buttons can't be pressed twice:
 
 ```vue
 <script setup lang="ts">
 import { computed } from "vue";
-import { useEveAgent } from "eve/vue";
+import { openConversationInputs, useEveAgent } from "eve/vue";
 
 const { data, respond } = useEveAgent();
 
 const pendingRequests = computed(() =>
-  data.value.messages.flatMap((message) =>
-    message.parts.flatMap((part) => {
-      if (part.type !== "dynamic-tool" || part.state !== "approval-requested") return [];
-      const request = part.toolMetadata?.eve?.inputRequest;
-      return request ? [request] : [];
-    }),
-  ),
+  openConversationInputs(data.value).map((input) => input.request),
 );
 </script>
 
@@ -130,7 +124,7 @@ Pass `onEvent`, `onError`, `onFinish`, or `onSessionChange` when the application
 
 ## Custom reducer
 
-Import `EveAgentReducer` from `eve/vue` when projecting events into application-specific state. The resulting `data` remains a `ComputedRef<TData>`. See [Custom reducer](./overview#custom-reducer) for the reducer contract and client projection events.
+Import `EveAgentReducer` from `eve/vue` when projecting events into application-specific state. The resulting `data` remains a `ComputedRef<TData>`; `conversation` remains a `ComputedRef<ConversationState>` regardless of your reducer. See [Custom reducer](./overview#custom-reducer) for the reducer contract and client projection events.
 
 ## What to read next
 

package/docs/guides/instrumentation/otel.mdx

@@ -139,12 +139,30 @@ invoke_agent <agent>
               └── execute_tool <tool>
 ```
 
-Each turn starts a new trace. The first subagent trace links to its caller with
-`eve.link.type=agent.dispatch`; the link is not an authorization grant. For a
-remote agent, `trustedForwarders` lets the receiver accept the sender's session
-lineage and trace-content policy. See [Remote agents](../guides/remote-agents#preserving-trace-content).
-Use `gen_ai.conversation.id` to find the traces for one conversation in your
-destination's span-search surface.
+Each root agent turn starts a new trace. If eve receives a local caller's trace
+context, the first local subagent turn uses that trace. Its span is a
+child of the dispatch span and has a different span ID. Without caller trace
+context, the first subagent turn starts a new trace. Later turns in the child
+session start new traces. They do not use the original dispatch span as their
+parent.
+
+A remote child starts a separate trace with a root `invoke_agent` span. Its first
+turn links to the caller with `eve.link.type=agent.dispatch`. The receiving
+deployment applies its sampler. Queries for local dispatches must use
+`parentSpanId` or `agent.parent_run.id` and `agent.parent_call.id` instead of a
+dispatch link.
+
+Use `gen_ai.conversation.id` to find the root session and its child sessions
+across traces. eve adds this ID to spans created during model, tool, and memory
+execution. This includes spans from third-party instrumentation. `agent.run.id`
+identifies one agent session, not the full conversation.
+
+The shared conversation ID does not give access to message history, agent state,
+or credentials. It does not give authorization or require the same worker for
+each turn. Remote requests carry the conversation ID in W3C Baggage.
+`trustedForwarders` controls whether the receiver accepts parent session data
+and the trace-content policy. See
+[Remote agents](../guides/remote-agents#preserving-trace-content).
 
 ## Local traces
 

package/docs/guides/remote-agents.md

@@ -59,9 +59,16 @@ remain lazy and resolve before each outbound request without entering durable
 workflow state.
 
 Author `auth` and `headers` directly in the `defineRemoteAgent({ ... })` object
-and keep their functions self-contained with module imports or environment
-variables. They are rehydrated outside the event handler, so they cannot close
-over `_event`, `ctx`, or handler-local values.
+and keep their functions self-contained with module imports, module-level
+constants, or environment variables. They are rehydrated outside the event
+handler, so they cannot close over `_event`, `ctx`, or handler-local values. The
+build fails with an error that names the handler-local value when they do.
+
+eve compiles only `auth` and `headers` written directly in the
+`defineRemoteAgent({ ... })` object in the subagent file. When they arrive
+through a spread, a variable passed as the argument, or a definition built in
+another module, eve rejects the definition at runtime, logs the error, and runs
+the agent without that subagent.
 
 ## Runtime URLs
 
@@ -141,16 +148,27 @@ Forwarding identity is explicit on both sides. The receiver names which deployme
 
 ## Trace propagation
 
-Each remote turn starts a new trace. eve links the child trace to the
-dispatching turn and carries `gen_ai.conversation.id` so you can find the
-traces for one conversation. Trace context is observability metadata, not an
-authorization grant. See [OpenTelemetry](../observability/otel#trace-topology)
-for the trace topology.
+A remote child starts its own trace with a root `invoke_agent` span. When caller
+trace context is available, the first turn links to the dispatch span with
+`eve.link.type=agent.dispatch`. The receiving deployment applies its sampler.
+Later turns start new traces without the original dispatch link. The first turn
+of a local child can use the remote agent's trace as a nested span.
+
+Use `gen_ai.conversation.id` to find all turns and child sessions for one
+conversation. The child has its own session ID, message history, and agent
+state. Trace context identifies related work. It does not give authorization.
+See [OpenTelemetry](../observability/otel#trace-topology) for the trace structure.
 
 eve carries parent session lineage separately. The receiver accepts it only
 when `trustedForwarders` approves the authenticated caller; otherwise, trace
 correlation continues without it.
 
+On Vercel, a remote agent's spans and its local subagents' spans carry the
+remote session's ID as `vercel.session_id`, so the receiving project groups
+them as their own session. `gen_ai.conversation.id` still names the sender's
+conversation, and the remote agent's `agent.parent_run.id` names the calling
+session.
+
 ## Preserving trace content
 
 With `forwardPrincipal: true`, a sampled remote dispatch forwards its original

package/docs/reference/cli.md

@@ -276,7 +276,7 @@ Starts a local development server and terminal UI. To connect the UI to an exist
 | `--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                                   |
+| `--logs <mode>`                     | enum   | `error`            | Display `none`, `error`, `warn`, `debug`, or `all` logs         |
 
 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.
 
@@ -391,13 +391,13 @@ Reads the immutable OTLP/JSON segments under `.eve/traces/v1`, so `eve dev` need
 
 Span rows carry inline metrics when the span recorded them — `↑input`/`↓output` token counts, gateway cost, and the tool name for `execute_tool` spans. The header lists models across the trace, sums token usage and cost from step spans, and counts all error-bearing spans. `--verbose` expands each span under its tree row: status (with the error message on failures), timing, ids, every attribute (prompts, responses, and tool payloads as transcripts or pretty-printed JSON), and every span event with its offset from span start. `--json` prints the same records as JSON, one object per selected trace.
 
-Every subagent activation starts its own trace. The first child's `invoke_agent` root links to the dispatching caller with `eve.link.type=agent.dispatch`; remote agents preserve that caller in W3C `tracestate` even when HTTP `traceparent` advances through platform ingress. Later turns also start fresh traces without repeating the initial caller link. All related sessions retain the same `gen_ai.conversation.id`, and `agent.subagent.name` labels the child invocation.
+With local caller trace context, the first local subagent turn uses the caller's trace. Its span is a child of the dispatch span. A remote child starts a separate root trace and links its first turn to the dispatch with `eve.link.type=agent.dispatch`. Remote requests use W3C `tracestate` to identify that dispatch span if platform HTTP handling changes `traceparent`. Later child turns start new traces. All related sessions have the same `gen_ai.conversation.id`. `agent.subagent.name` identifies the subagent.
 
-Each workflow tool call has one `agent.action` span and keeps its `execute_tool <tool>` span. Sessions the tool opens with `ctx.agent` link to that call's `agent.action` span as their dispatching caller; individual `ctx.agent` calls get no span of their own. Only agent execution uses `invoke_agent`.
+Each workflow tool call has an `agent.action` span and an `execute_tool <tool>` span. The first turn of each local session it opens with `ctx.agent` is a child of the call's `agent.action` span. A remote session links to that action from its own trace. An individual `ctx.agent` call does not create a separate dispatch 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.
+Each root agent turn starts a new trace. With local caller trace context, that trace includes the first turn of each local subagent it starts. Remote child turns and later local child turns start separate traces. If a worker is replaced, the new worker uses the prepared trace context for the same turn. Supply the conversation ID to show all related traces, 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.
 

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

@@ -9,7 +9,7 @@ Human-in-the-loop (HITL) is any point where the agent durably pauses and waits f
 - **Approvals** — a tool policy allows, denies, or pauses a call for a person to review. The agent decides to call the tool; the policy decides whether it runs automatically or needs a human decision.
 - **Questions** — the agent itself asks the user a clarifying question or a choice mid-turn, and parks until they answer.
 
-An approval ends the turn and the session parks at `session.waiting`. A question keeps the turn open, and the stream reports `turn.waiting`. Either way the run waits durably, for as long as it takes — seconds or days — and picks back up exactly where it left off once the answer arrives. Channels render the request for you.
+Both keep the turn open, and the stream reports `turn.waiting`. The run waits durably, for as long as it takes — seconds or days — and picks back up exactly where it left off once the answer arrives. Channels render the request for you.
 
 ## Approvals
 
@@ -212,7 +212,7 @@ Approvals and questions share one protocol:
 
 1. A tool call needs approval, or a workflow tool such as `ask_question` calls `ctx.ask()`.
 2. eve emits an `input.requested` stream event carrying the pending requests.
-3. The run parks durably, for as long as it takes. An approval ends the turn with `turn.completed`, then `session.waiting`. A question keeps the turn open: the stream emits `turn.waiting`, and after the answer the turn resumes under the same `turnId`.
+3. The run parks durably, for as long as it takes. The turn stays open: the stream emits `turn.waiting`, and after the answer the turn resumes under the same `turnId`. That `turn.waiting` carries `on: "input"`, since a person must act.
 4. The client answers with `inputResponses` (structured, keyed by `requestId`) or a normal follow-up `message`. A follow-up whose text matches an option ID, option label, or numeric option index resolves automatically, including approval options such as `approve` and `cancel`.
 
 For `ctx.ask()` questions from tools, a follow-up message answers the question only when exactly one question is pending. The message must match an option, or the question must allow free text. Otherwise the message follows the session's `turnPolicy`. A steering message, the default, aborts the `ctx.abortSignal` of each `execute` workflow tool call the turn waits on, so a question such a call asked, such as `ask_question`'s, is withdrawn and resolves as `cancelled`. The model reads the message once those calls settle. Questions from subagents need a structured response.
@@ -226,7 +226,7 @@ The run picks back up exactly where it parked. Because the pause is durable, not
 
 When a subagent requests input, eve emits the same `input.requested` event on its parent session. Answering through that parent session routes the response directly to the blocked child without invoking the parent model.
 
-For approval requests, unrelated follow-up text does not deny the tool call. eve keeps the approval pending and records that pending state in model-visible session history. Follow-up turns run normally and may call other tools while the approval remains unresolved. Once it is answered, eve settles the original tool call exactly once.
+For approval requests, a follow-up message that doesn't match an option steers the turn instead of answering it. eve cancels the turn's pending approval, so the call doesn't run and `input.resolved` reports `outcome: "ignored"`, and the model reads the message next. This happens even when the message is sent with `turnPolicy: "queue"`, because a turn held on a person can't end until they act. Calls the person already approved in the same batch still run. A message from someone other than the person the turn serves waits until the turn ends. Cancelling the turn withdraws its approval: the call doesn't run, `input.resolved` reports `outcome: "cancelled"`, and a later answer to it approves nothing.
 
 See [Sessions, runs & streaming](/docs/concepts/sessions-runs-and-streaming) for the full event and resume contract that this builds on.
 
@@ -236,7 +236,7 @@ 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.
+You can answer while a turn is running, such as the second approval of a batch while the first answer is still settling. The default message reducer waits for server confirmation before marking any input request answered. A submitted answer marks its request `responded` in `data.inputs` until `approval.settled` or `input.resolved` arrives; submitting a response alone does not resolve an approval, question, or session-limit prompt. Answering a request that is no longer open rejects without a server request. The `client.input.responded` event remains a submission notification for custom reducers, not confirmation that the server accepted the answer.
 
 ## What to read next
 

package/docs/tools/overview.mdx

@@ -126,7 +126,7 @@ export default defineTool({
 });
 ```
 
-The label is presentation only. It does not replace the path-derived tool name, enter model input, or change execution. eve records the bounded label on the corresponding public action event so activity renderers and other authorized stream consumers can use it without interpreting raw tool data. Built-in channel activity can show `Deploy storefront to production` instead of `deploy`; if the callback throws or returns an empty label, activity falls back to the tool name.
+The label is presentation only. It does not replace the path-derived tool name, enter model input, or change execution. eve records the bounded label on the corresponding public action event so activity renderers and other authorized stream consumers can use it without interpreting raw tool data. Built-in channel activity can show `Deploy storefront to production` instead of `Deploy`; if the callback throws or returns an empty label, activity falls back to a readable form of the tool name, such as `Sync accounts` for `sync_accounts`.
 
 Provided tools define labels for `bash`, `glob`, `grep`, `load_skill`, `read_file`, `web_fetch`, `web_search`, and `write_file`.
 

package/docs/tools/tasks.md

@@ -233,8 +233,8 @@ continues once the person answers or signs in.
 In every session, `turn.completed` comes only when the turn really ends. The TypeScript client's
 `send(...).result()` and the MCP channel's `agent_get` read past `turn.waiting` and report the
 final reply rather than the text written before the wait. `result()` stops at `turn.waiting` only
-while a question is pending, and returns `status: "waiting"` with it; `respond()` then reads the
-same turn to its end. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
+while a question is pending or the turn waits on a sign-in or approval, and returns
+`status: "waiting"`; `respond()` then reads the same turn to its end. See [Aggregate a turn](/docs/guides/client/streaming#aggregate-a-turn).
 Channels such as [Slack](/docs/channels/slack) post a root session's text before the wait as an
 ordinary reply, then post the reply after the results as another message. Slack also shows each
 turn's tasks in a live [task card](/docs/channels/slack#task-card).
@@ -263,12 +263,12 @@ same `taskId` continues where it left off. A `serve` body that doesn't return to
 
 ## Stream events
 
-| Event           | When                                                                     | Data                                                                                       |
-| --------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
-| `task.started`  | A call starts a task, or reaches a resumable task by its `taskId`        | `taskId`, `callId`, `turnId`, the tool `name`, and `kind`                                  |
-| `task.settled`  | A reply, return, failure, or cancel settles one call                     | `taskId`, `callId`, `turnId`, `name`, `kind`, `status`, and `output`, `error`, or `cancel` |
-| `agent.started` | A workflow run, including an agent tool's, opens a session with an agent | `callId`, `turnId`, `taskId`, `name`, `sessionId`, `streamPath`                            |
-| `turn.waiting`  | An open turn parks on its tasks, a `task_wait`, a question, or a sign-in | `turnId` and `sequence`                                                                    |
+| Event           | When                                                                                  | Data                                                                                       |
+| --------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
+| `task.started`  | A call starts a task, or reaches a resumable task by its `taskId`                     | `taskId`, `callId`, `turnId`, the tool `name`, and `kind`                                  |
+| `task.settled`  | A reply, return, failure, or cancel settles one call                                  | `taskId`, `callId`, `turnId`, `name`, `kind`, `status`, and `output`, `error`, or `cancel` |
+| `agent.started` | A workflow run, including an agent tool's, opens a session with an agent              | `callId`, `turnId`, `taskId`, `name`, `sessionId`, `streamPath`                            |
+| `turn.waiting`  | An open turn parks on its tasks, a `task_wait`, a question, a sign-in, or an approval | `turnId`, `sequence`, and `on`: `"input"` when a person must act, otherwise `"tasks"`      |
 
 `task.started` and `task.settled` come once each per call, and `(taskId, callId)` identifies the
 call. Both carry that call's `turnId`, which for a resumable task's later call can be a later turn

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eve",
-  "version": "0.69.0",
+  "version": "0.70.1",
   "private": false,
   "description": "Filesystem-first framework for durable backend AI agents that run anywhere.",
   "keywords": [
@@ -561,8 +561,8 @@
     "emulate": "0.6.0",
     "env-runner": "0.1.16",
     "eventsource-parser": "3.1.0",
-    "gray-matter": "4.0.3",
     "jose": "6.2.3",
+    "js-yaml": "4.3.2",
     "jsonc-parser": "3.3.1",
     "just-bash": "3.1.0",
     "just-secrets": "0.0.2",

package/dist/src/cli/dev/tui/steering-stream.d.ts

@@ -1,15 +0,0 @@
-import { type MessageStreamEvent } from "#protocol/message.js";
-/**
- * Follows accepted messages through their boundary, including a send racing
- * settlement. Delivery responses may overlap; stream event IDs deduplicate them.
- */
-export declare class SteeringStream implements AsyncIterable<MessageStreamEvent> {
-    private readonly session;
-    private readonly streams;
-    private closed;
-    private readonly controller;
-    constructor(initial: AsyncIterable<MessageStreamEvent>, session: SteeringStream["session"]);
-    send(message: string): Promise<void>;
-    abort(): void;
-    [Symbol.asyncIterator](): AsyncGenerator<MessageStreamEvent>;
-}

package/dist/src/cli/dev/tui/steering-stream.js

@@ -1 +0,0 @@
-import{createEventDeduper}from"#protocol/event-dedupe.js";import{isCurrentTurnBoundaryEvent}from"#protocol/message.js";var SteeringStream=class{session;streams;closed=!1;controller=new AbortController;constructor(e,t){this.session=t,this.streams=[Promise.resolve(e)]}async send(e){if(this.closed)throw Error(`The active stream ended before steering was sent.`);let t=this.session.send(e,{turnPolicy:`steer`,signal:this.controller.signal});this.streams.push(t.then(e=>e,()=>void 0)),await t}abort(){this.closed=!0,this.controller.abort()}async*[Symbol.asyncIterator](){let e=createEventDeduper(),t;try{for(;this.streams.length>0;){let n=await this.streams.shift();if(n!==void 0){for await(let r of n)if(e.admit(r)){if(isCurrentTurnBoundaryEvent(r)){t=r;break}yield r}}}t!==void 0&&(yield t)}finally{this.abort()}}};export{SteeringStream};