eve 0.83.3 → 0.84.0

package/docs/channels/linear.mdx

@@ -83,7 +83,7 @@ Turn start posts an ephemeral `thought`, tool calls post ephemeral `action` acti
 
 ### Human-in-the-loop (HITL)
 
-Human-in-the-loop (HITL) input requests render as Linear `elicitation` activities. When the user replies to the Agent Session, the channel resolves that prompt back to the pending eve input request and resumes with `inputResponses`.
+Human-in-the-loop (HITL) input requests render as Linear `elicitation` activities. When the user replies to the Agent Session, the channel resolves that prompt back to the pending eve input request and resumes with `answers`.
 
 ### Connection authorization
 
@@ -139,16 +139,16 @@ import { linearChannel } from "eve/channels/linear";
 
 export default linearChannel({
   events: {
-    async "message.completed"(eventData, channel) {
-      if (eventData.finishReason === "tool-calls" || !eventData.message) return;
-      await channel.linear.createActivity({
-        body: `Done.\n\n${eventData.message}`,
+    async "content.completed"(event, ctx) {
+      if (event.data.phase !== "reply" || typeof event.data.value !== "string") return;
+      await ctx.channel.linear.createActivity({
+        body: `Done.\n\n${event.data.value}`,
         type: "response",
       });
     },
-    async "input.requested"(eventData, channel) {
-      await channel.linear.createActivity({
-        body: eventData.requests.map((request) => request.prompt).join("\n\n"),
+    async "interaction.opened"(event, ctx) {
+      await ctx.channel.linear.createActivity({
+        body: event.data.request.prompt,
         type: "elicitation",
       });
     },

package/docs/channels/linq.mdx

@@ -82,7 +82,7 @@ export default linqChannel({
     if (!tapback.added) return null;
     const auth = defaultLinqAuth(tapback);
     if (tapback.tapback === "like") return { auth, answer: "approve" };
-    if (tapback.tapback === "dislike") return { auth, answer: "cancel" };
+    if (tapback.tapback === "dislike") return { auth, answer: "deny" };
     return { auth };
   },
 });

package/docs/channels/mcp.mdx

@@ -185,8 +185,8 @@ least `pollAfterMs` before polling again.
 The invocation response is discriminated by `status`:
 
 - `working`: work is active; continue polling according to `pollAfterMs`.
-- `input_required`: present `inputRequests`, then send the complete answer batch through `agent_update`. A successful update returns the current invocation state.
-- `authorization_required`: present the returned sign-in URL, user code, or instructions. The connection callback resumes the invocation automatically; continue polling.
+- `input_required`: present `interactions`, keyed by `interactionId`, then send the complete answer batch through `agent_update`, one `{ interactionId, optionId?, text? }` response per entry. A successful update returns the current invocation state.
+- `authorization_required`: present each sign-in in `interactions`: its `signIn` URL, user code, or instructions. The connection callback resumes the invocation automatically; continue polling.
 - `completed`: the agent's turn settled, after any [tasks](/docs/tools/workflows#run-calls-as-tasks-task) it started finished. Consume the optional `result`: the final assistant message.
 - `failed`: inspect the structured `error`.
 - `cancelled`: cancellation reached a terminal state.

package/docs/channels/overview.mdx

@@ -34,6 +34,16 @@ authorization. See the [default eve HTTP channel](./eve#audience) for its
 mapping, or [custom channels](./custom#conversation-audience) to classify your
 own.
 
+## Sign-ins
+
+When a tool needs a connection the person hasn't authorized, the built-in channels show a sign-in. Its link or code is a credential: whoever completes it connects their account. So it appears only where the person signing in alone reads it:
+
+- In a conversation that's theirs (a direct message, a private chat, an SMS thread), eve posts the sign-in there.
+- In a group, eve sends it privately where the platform can (Slack and Chat SDK adapters with ephemeral messages; Telegram once the requester presses **Authorize**) and posts a status without the link. Otherwise the status asks the person to continue in a direct message with the agent. Teams channels and Discord servers and group DMs work this way. On GitHub, where every comment is public, the status says the person who asked must sign in.
+- When the sign-in ends, eve edits the status where it can, or posts how it ended, and once the person connects, shows the turn resuming.
+
+Linear uses its native sign-in prompt. A sign-in an approval's responder needs appears with that approval's prompt instead.
+
 ## Overlapping messages
 
 Channels default to `turnPolicy: "steer"`. Before assistant answer output or local tool execution begins, a message can interrupt pending model generation and continue the same turn with the correction. Executing tools finish and checkpoint their results before steering reaches the next model call. After answer output starts, steering waits for the next committed workflow boundary. The turn ID stays the same.
@@ -53,7 +63,7 @@ export default defineChannel({
 
 Adjacent queued messages can combine into one turn only when their full auth contexts match, including identity, issuer, authenticator, and authorization attributes. Their attachments and context stay in payload order. A different auth context ends the batch; eve does not regroup messages across intervening senders. Anonymous deliveries stay separate. Turns still share the session's conversation history.
 
-`from(address).send(...)`, fixed `Session.send(...)`, cross-channel sends, and Chat SDK bridge sends also accept a per-send `turnPolicy` override. Pure `inputResponses` deliveries answer their pending request without steering. Explicit `cancel()` remains the stop-without-replacement operation.
+`from(address).send(...)`, fixed `Session.send(...)`, cross-channel sends, and Chat SDK bridge sends also accept a per-send `turnPolicy` override. Pure `answers` deliveries answer their pending request without steering. Explicit `cancel()` remains the stop-without-replacement operation.
 
 Events rejected before `send(...)`, such as invalid signatures or filtered mentions, never reach the active turn. A delivery already sent to the session can interrupt pending generation before the channel's `deliver` hook processes it. If that hook ignores the correction, eve resumes the original request with its original auth, delivery provenance, and channel state.
 

package/docs/channels/photon.mdx

@@ -113,7 +113,7 @@ export default photonIMessageChannel({
     if (!tapback.added) return null;
     const auth = defaultPhotonAuth(tapback);
     if (tapback.tapback === "like") return { auth, answer: "approve" };
-    if (tapback.tapback === "dislike") return { auth, answer: "cancel" };
+    if (tapback.tapback === "dislike") return { auth, answer: "deny" };
     return { auth };
   },
 });

package/docs/channels/slack.mdx

@@ -117,7 +117,7 @@ Only the first available handler runs. A message hook returning `null` drops the
 
 Message hooks only decide whether and how a message starts a turn. They don't render anything, so replacing one never changes what people see: eve still acknowledges the message, shows progress, and posts the reply. To change what the agent posts, add [renderers](#customize-rendering).
 
-`onInteraction(action, ctx)` separately handles user-owned `block_actions` callbacks. eve-owned HITL buttons and modal submissions go through `onInputResponse(ctx, submission)` instead. `action.triggerId` carries the click's `trigger_id`, so a button can open a modal with `ctx.slack.request("views.open", { trigger_id, view })`. Slack accepts the id for about 3 seconds. eve attaches the triggering Slack user id to the same model message as its text, preserving speaker attribution without profile lookups.
+`onInteraction(action, ctx)` separately handles user-owned `block_actions` callbacks. eve-owned HITL buttons and modal submissions go through `onAnswers(ctx, submission)` instead. `action.triggerId` carries the click's `trigger_id`, so a button can open a modal with `ctx.slack.request("views.open", { trigger_id, view })`. Slack accepts the id for about 3 seconds. eve attaches the triggering Slack user id to the same model message as its text, preserving speaker attribution without profile lookups.
 
 Use `onShortcut(shortcut, ctx)` for message shortcuts and global shortcuts configured under **Interactivity & Shortcuts** in your Slack app. The handler receives the shortcut callback ID, user, workspace, and trigger ID. Message shortcuts also include the selected message and channel. The context exposes workspace-scoped Slack API access because global shortcuts have no channel or message. eve acknowledges shortcut requests immediately and keeps their handlers alive in the background.
 
@@ -172,7 +172,7 @@ export default slackChannel({
     }
     return { auth: defaultSlackAuth(message, ctx) };
   },
-  onInputResponse(ctx, submission) {
+  onAnswers(ctx, submission) {
     if (!allowedUsers.has(submission.user.id) || !allowedConversations.has(ctx.slack.channelId)) {
       return null;
     }
@@ -181,17 +181,17 @@ export default slackChannel({
 });
 ```
 
-Override every enabled inbound handler; leaving `onDirectMessage` out would retain eve's default DM behavior. Apply the same policy in `onInputResponse` so someone who cannot start a turn cannot resume one through an eve-owned HITL control. Slack Connect can deliver events from external users, so authorize the explicit user and current conversation IDs your policy expects. If access depends on organization membership, resolve it from Slack's shared-channel and user data instead of inferring it from the request signature.
+Override every enabled inbound handler; leaving `onDirectMessage` out would retain eve's default DM behavior. Apply the same policy in `onAnswers` so someone who cannot start a turn cannot resume one through an eve-owned HITL control. Slack Connect can deliver events from external users, so authorize the explicit user and current conversation IDs your policy expects. If access depends on organization membership, resolve it from Slack's shared-channel and user data instead of inferring it from the request signature.
 
 Keep authorization checks inside sensitive tools too. The inbound allowlist controls who can start a turn; tool-level checks control what that authenticated Slack principal may read or change.
 
 `defaultSlackAuth` and `ctx.defaultAuth` identify a person as `slack:<team>:<user>`, where `<team>` is the app installation workspace when Slack reports one, otherwise the event's team. Messages and button clicks resolve the same team, so a Slack Connect user keeps one principal, and one connection sign-in, whether they post in the thread or click an approval.
 
-`onInputResponse` runs after eve decodes a built-in HITL answer but before the parked session resumes. Return `{ auth }` to accept the answer. Returning `null` or throwing rejects it, leaves the request pending, and keeps the Slack controls active. `ctx.defaultAuth` identifies the Slack user who submitted the signed interaction; it does not authorize that user by itself.
+`onAnswers` runs after eve decodes a built-in HITL answer but before the parked session resumes. Return `{ auth }` to accept the answer. Returning `null` or throwing rejects it, leaves the request pending, and keeps the Slack controls active. `ctx.defaultAuth` identifies the Slack user who submitted the signed interaction; it does not authorize that user by itself.
 
-A message typed in a thread or DM never passes through `onInputResponse`, so while it or `approvalChannel` is set, a typed message doesn't answer a pending request. Answers come only through the Slack controls. The typed message reaches the agent as a new message and follows the [turn policy](#control-overlapping-turns). With the default steering policy, it withdraws an open question.
+A message typed in a thread or DM never passes through `onAnswers`, so while it or `approvalChannel` is set, a typed message doesn't answer a pending request. Answers come only through the Slack controls. The typed message reaches the agent as a new message and follows the [turn policy](#control-overlapping-turns). With the default steering policy, it withdraws an open question.
 
-If you omit `onInputResponse`, Slack accepts HITL answers with the submitting user's auth, regardless of which message or event handlers you define. Define `onInputResponse` when those handlers enforce an invocation policy that must also apply to HITL answers. Put sensitive prompts in conversations limited to the intended approvers, and re-check `ctx.session.auth.current` inside a sensitive tool before performing its side effect.
+If you omit `onAnswers`, Slack accepts HITL answers with the submitting user's auth, regardless of which message or event handlers you define. Define `onAnswers` when those handlers enforce an invocation policy that must also apply to HITL answers. Put sensitive prompts in conversations limited to the intended approvers, and re-check `ctx.session.auth.current` inside a sensitive tool before performing its side effect.
 
 #### Continue conversations without repeated mentions
 
@@ -266,14 +266,14 @@ export default slackChannel({
 
 With `"queue"`, adjacent messages with matching full auth contexts can combine into one turn, keeping their attachments and context in order. Messages from different users, or from the same user with different authorization attributes, stay separate. Anonymous deliveries also stay separate. Batching follows session-inbox order, and turns still share the thread's session history.
 
-Message hooks (`onMessage`, `onAppMention`, and `onDirectMessage`) also receive thread-bound session operations directly on `ctx`. `ctx.cancel({ turnId? })` remains useful for a Stop button: it cancels without sending replacement input. `"accepted"` means the live thread session durably queued that request; a parked session consumes it as a no-op, and `"no_active_turn"` means the thread has no active session owner.
+Message hooks (`onMessage`, `onAppMention`, and `onDirectMessage`) also receive thread-bound session operations directly on `ctx`. `ctx.cancel({ turnId? })` remains useful for a Stop button: it cancels without sending replacement input. The returned `Delivery` identifies the queued command. An idle session accepts a no-op cancellation; an unowned thread throws `SessionNotActiveError`.
 
 Message and interaction hooks expose every current-owner operation directly on `ctx`:
 
 ```ts
 async onAppMention(ctx) {
   await ctx.send("Run a separate turn.");
-  await ctx.respond(inputResponses);
+  await ctx.respond(answers);
   await ctx.cancel();
   await ctx.compact();
   await ctx.clear();
@@ -302,11 +302,11 @@ export default slackChannel({
 });
 ```
 
-Reset returns `{ status: "reset", previousSessionId }` when the thread had a session, or `{ status: "no_active_session" }` when it was already free. Both outcomes are successful. Returning `null` after reset consumes the triggering message as a command; return `{ auth }` instead to deliver that message as the first turn of the fresh session. Custom `onInteraction` handlers receive the same flat operations, which is useful for a New conversation button.
+Reset returns a `Delivery` for the retiring session; `await delivery.result()` waits for retirement and address release. An already unowned thread throws `SessionNotActiveError`. Returning `null` after reset consumes the triggering message as a command; return `{ auth }` instead to deliver that message as the first turn of the fresh session. Custom `onInteraction` handlers receive the same flat operations, which is useful for a New conversation button.
 
 ### Other Events API callbacks
 
-Use `onEvent` for subscribed events such as `reaction_added`, `team_join`, or `channel_created`. It receives the raw, open-ended Slack event and owns control flow. Call `ctx.send(message, { target, auth, title, history })` zero, one, or many times to start turns. `title` sets the run title without changing the message sent to the model, and `history` adds prior conversation before the message (see [Start from prior history](./eve#start-from-prior-history)). Each call returns the resulting session.
+Use `onEvent` for subscribed events such as `reaction_added`, `team_join`, or `channel_created`. It receives the raw, open-ended Slack event and owns control flow. Call `ctx.send(message, { target, auth, title, history })` zero, one, or many times to start turns. `title` sets the run title without changing the message sent to the model, and `history` adds prior conversation before the message (see [Start from prior history](./eve#start-from-prior-history)). Each call returns a delivery receipt; use its `sessionId` to attach a session handle.
 
 ```ts title="agent/channels/slack.ts"
 import { connectSlackCredentials } from "@vercel/connect/eve";
@@ -342,7 +342,7 @@ Because a generic event is not necessarily tied to one thread, put the target in
 const target = { channelId, threadTs };
 
 await ctx.send("Follow up", { auth: null, target });
-await ctx.respond(inputResponses, { auth: null, target });
+await ctx.respond(answers, { auth: null, target });
 await ctx.cancel({ target, turnId });
 await ctx.compact({ target });
 await ctx.clear({ target });
@@ -356,7 +356,7 @@ const session = await ctx.resolveSession({ target });
 
 ### Slack API calls outside a handler
 
-Inside inbound webhook handlers such as `onAppMention`, `onEvent`, `onInteraction`, `onShortcut`, `onSlashCommand`, and `onInputResponse`, `ctx.slack.request(operation, body)` is the raw-API escape hatch. Inside a [renderer](#customize-rendering)'s event handler, use `channel.slack.request(...)` instead. Outside those contexts there is no handle — a schedule resolving reactions on old
+Inside inbound webhook handlers such as `onAppMention`, `onEvent`, `onInteraction`, `onShortcut`, `onSlashCommand`, and `onAnswers`, `ctx.slack.request(operation, body)` is the raw-API escape hatch. Inside a [renderer](#customize-rendering)'s event handler, use `ctx.channel.slack.request(...)` instead. Outside those contexts there is no handle — a schedule resolving reactions on old
 messages, for example, has no inbound Slack request. For that, call the
 same primitive the handle uses directly:
 
@@ -442,7 +442,7 @@ This applies to the turn's final reply only. A failed status update, tool-call n
 
 When the model replies while its tasks keep working, including text it writes before `eve__task_wait` in the same step, that reply posts like any other, and the reply after the results posts as another message. A schedule's session posts only the final reply.
 
-Outbound text preserves bare `@` tokens as literal text. To mention a user, embed Slack's `<@USER_ID>` syntax directly or use `channel.thread.mentionUser(userId)`.
+Outbound text preserves bare `@` tokens as literal text. To mention a user, embed Slack's `<@USER_ID>` syntax directly or use `ctx.channel.thread.mentionUser(userId)` in a renderer.
 
 ### Task card
 
@@ -465,10 +465,10 @@ eve writes the card from the session's own events as they happen, and only when
 Without `renderers`, eve renders everything above with its default renderer. Pass `renderers` to change what the agent posts without replacing that default. Each renderer wraps the ones after it, ending with eve's default renderer, and has three optional parts:
 
 - `received(message, channel, next)` acknowledges a mention or DM the moment it arrives, and another channel message once `onMessage` dispatches it. eve's default sets `Thinking...`.
-- `events` handles session events such as `message.completed` or `input.requested`. Each handler receives `(eventData, channel, ctx, next)`, with Slack platform handles on `channel.thread` and `channel.slack`; a `session.failed` handler receives `(eventData, channel, next)`.
+- `events` handles session facts such as `content.completed` or `interaction.opened`. Each handler receives `(event, ctx, next)`: the whole fact with its `type`, `data`, and `scope`, and a context whose `ctx.channel` holds Slack's platform handles, `ctx.channel.thread` and `ctx.channel.slack`, along with `ctx.position` and `ctx.view`.
 - `taskCard(view, next)` returns the task card's blocks and notification text, or `null` for no card.
 
-Call `next()` to run the rest of the chain, ending with eve's default. Call it after your own work, before it, or with changed data, as in `next({ ...event, message })`; the rest of the chain runs at most once. Skip `next` to replace the default for that event. This renderer adds feedback buttons below each final reply and a context row to the finished task card:
+Call `next()` to run the rest of the chain, ending with eve's default. Call it after your own work, before it, or with a changed fact, as in `next({ ...event, data: { ...event.data, value } })`; the rest of the chain runs at most once. Skip `next` to replace the default for that event. This renderer adds feedback buttons below each final reply and a context row to the finished task card:
 
 ```ts title="agent/channels/slack.ts"
 import { connectSlackCredentials } from "@vercel/connect/eve";
@@ -476,10 +476,10 @@ import { defineSlackRenderer, slackChannel } from "eve/channels/slack";
 
 const feedback = defineSlackRenderer({
   events: {
-    async "message.completed"(event, channel, _ctx, next) {
+    async "content.completed"(event, ctx, next) {
       await next(); // eve posts the reply, or uploads a long one as a snippet
-      if (event.finishReason === "tool-calls") return;
-      await channel.thread.post({
+      if (event.data.phase !== "reply" || event.data.kind !== "text") return;
+      await ctx.channel.thread.post({
         blocks: [
           {
             type: "context_actions",
@@ -517,7 +517,7 @@ export default slackChannel({
 });
 ```
 
-A `message.completed` handler that posts the final reply itself, instead of calling `next()`, owns that delivery. If it throws, eve logs the error, posts the content-free notice described in [Delivery](#delivery), and tells the model on the next message. eve doesn't retry or re-send your reply, because your renderer may post elsewhere, change the content, or attach data eve can't reproduce. If you post the reply and then a separate follow-up message, as the feedback example above does, catch the follow-up's errors in your handler. Otherwise eve posts the notice even though the reply arrived.
+A `content.completed` handler that posts the reply itself, instead of calling `next()`, owns that delivery. If it throws, eve logs the error, posts the content-free notice described in [Delivery](#delivery), and tells the model on the next message. eve doesn't retry or re-send your reply, because your renderer may post elsewhere, change the content, or attach data eve can't reproduce. If you post the reply and then a separate follow-up message, as the feedback example above does, catch the follow-up's errors in your handler. Otherwise eve posts the notice even though the reply arrived.
 
 To get eve's fallbacks for a reply you render, post it with `postCompletedSlackReply`. You choose the content; eve makes the Slack calls:
 
@@ -532,14 +532,15 @@ import { defineSlackRenderer, postCompletedSlackReply, slackChannel } from "eve/
 
 const sourcedReplies = defineSlackRenderer({
   events: {
-    async "message.completed"(event, channel, _ctx, next) {
-      if (event.finishReason === "tool-calls" || !event.message) return next();
-      await postCompletedSlackReply(channel, {
+    async "content.completed"(event, ctx, next) {
+      const { kind, phase, value } = event.data;
+      if (phase !== "reply" || kind !== "text" || typeof value !== "string") return next();
+      await postCompletedSlackReply(ctx.channel, {
         blocks: [
-          { type: "markdown", text: event.message },
+          { type: "markdown", text: value },
           { type: "context", elements: [{ type: "mrkdwn", text: "Sources: internal docs" }] },
         ],
-        markdown: event.message,
+        markdown: value,
       });
     },
   },
@@ -548,15 +549,18 @@ const sourcedReplies = defineSlackRenderer({
 export default slackChannel({ renderers: [sourcedReplies] });
 ```
 
-Pass a string, as in `postCompletedSlackReply(channel, reply)`, to deliver Markdown alone the way eve's default does.
+Pass a string, as in `postCompletedSlackReply(ctx.channel, reply)`, to deliver Markdown alone the way eve's default does.
 
-`taskCard` runs for every turn that calls a tool, and receives the same view eve's default renders from:
+`taskCard` runs for every turn that calls a tool, and receives the same card eve's default renders from:
 
-- `state`: `blocked` while any task waits on a person, `working` while the turn or any other task works, then `finished`.
-- `tasks`: the tasks the turn started, each with a `title`, `status`, `blockedOn`, and `summary`. A failed task's `summary` and a blocked task's `blockedOn.label` are present only in a DM or private channel.
-- `actions`: the turn's other tool calls, each with its tool `name`, `title`, `status`, and `input`. `input` is left out when its JSON is longer than 4,096 characters.
+- `calls`: the turn's tool calls on this card as immutable `CallObservation` values, in call order. A call that started a task has a `taskId`. eve's own task controls, and calls a tool makes on the model's behalf, are left out.
+- `view`: the opaque session snapshot, to read each call with the selectors from `eve/events`: `callState(view, callId)` for where it stands (`running`, `blocked`, `completed`, `cancelled`, ...), `callLabel(row)` for its title, and `openInteractions(view, { about: { callId } })` for open requests holding the call up.
+- `state`: `blocked` while any task waits on an interaction, `working` while the turn or any task works, then `finished`.
+- `audience`: who reads the card. eve's default shows a failed task's error and a request's prompt only when it is `private`, in a DM or private channel; do the same with what you show from `calls`.
 
-`taskCard` is synchronous and pure: eve posts the card and updates it as the view changes. eve's default returns `null` for a turn that started no tasks. Its block keeps the same `block_id` for the whole turn; keep that `block_id` on a block you build in its place. To change a row's title in every channel, give the tool a [label](/docs/tools#label-tool-activity) instead.
+A turn keeps one card unless it starts a task after every task on its card ended, as a turn its caller keeps talking to does. That card is finished, and the turn's next calls go on a new card, posted as a new message.
+
+`taskCard` is synchronous and pure: eve posts the card and updates it as the tables change. eve's default returns `null` for a card without tasks. Its block keeps the same `block_id` for the whole turn; keep that `block_id` on a block you build in its place. To change a row's title in every channel, give the tool a [label](/docs/tools#label-tool-activity) instead.
 
 Renderers run in the order you list them, and the first one is outermost. `onInteraction` receives clicks on buttons a renderer posts, such as the feedback buttons above.
 
@@ -601,13 +605,14 @@ const SLACK_STATUS = {
 } as const;
 
 const plan = defineSlackRenderer({
-  taskCard(view, next) {
-    const card = next(view);
-    const calls = view.actions.filter((action) => action.name === "plan");
-    const items = calls.at(-1)?.input?.items as PlanItem[] | undefined;
-    if (items === undefined) return card;
+  taskCard(card, next) {
+    const rendered = next(card);
+    const calls = card.calls.filter((call) => call.capability.name === "plan");
+    const input = calls.at(-1)?.input as { items?: PlanItem[] } | undefined;
+    const items = input?.items;
+    if (items === undefined) return rendered;
     // eve's card is one `plan` block, or one `task_card` block for a single task.
-    const [block] = card?.blocks ?? [];
+    const [block] = rendered?.blocks ?? [];
     const taskRows: BlockKitBlock[] =
       block === undefined ? [] : block.type === "plan" ? (block.tasks as BlockKitBlock[]) : [block];
     const planRows = items.map((item, index) => ({
@@ -630,7 +635,7 @@ A turn that only plans gets a card too, because `taskCard` runs for every turn t
 
 ### Human-in-the-loop (HITL)
 
-HITL renders as Slack buttons and selects. Fixed-choice actions and freeform modal submissions pass through `onInputResponse` before the parked session resumes. The initial **Type your answer** action only opens eve's modal; the hook runs when the user submits an answer.
+HITL renders as Slack buttons and selects. Fixed-choice actions and freeform modal submissions pass through `onAnswers` before the parked session resumes. The initial **Type your answer** action only opens eve's modal; the hook runs when the user submits an answer.
 
 Set `approvalChannel` to choose where each input request appears, including tool approvals and questions from `ctx.ask()`. Return `"direct-message"` when the request must be visible only to the Slack user who triggered the turn, or `"thread"` for the normal shared thread.
 
@@ -639,19 +644,19 @@ import { slackChannel } from "eve/channels/slack";
 
 export default slackChannel({
   approvalChannel: (request) =>
-    request.kind === "question" || request.action.toolName === "review_answer"
+    request.request.kind === "question" || request.call?.name === "review_answer"
       ? "direct-message"
       : "thread",
 });
 ```
 
-The callback receives the `InputRequest` and current `SessionContext`, so it can switch on `kind`, `action`, or presentation properties. Omit it to keep every request in the thread, or return `"direct-message"` unconditionally to make every request private. If eve cannot resolve the triggering Slack user for a direct message, it logs the undelivered request and posts no fallback, so private delivery fails closed. The existing `onInputResponse` or tool approval response policy still decides whether the person who clicks may respond.
+The callback receives the `Interaction` and current `SessionContext`, so it can switch on `request.kind`, `call`, or prompt presentation properties. Omit it to keep every request in the thread, or return `"direct-message"` unconditionally to make every request private. If eve cannot resolve the triggering Slack user for a direct message, it logs the undelivered request and posts no fallback, so private delivery fails closed. The existing `onAnswers` or tool approval response policy still decides whether the person who clicks may respond.
 
 When a tool approval resolves, eve retires the messages it posted for it. The card loses its buttons and shows the answer and who gave it, the separate tool-input post is deleted, and a direct-message request's `Waiting on approval` note in the thread changes to the outcome. This also happens when the approval ends without a click, for example when the person replies in the thread instead, in which case the card reads `No longer needed`.
 
 A click on any request whose session is no longer active, for example because its run was cancelled outside eve, can never be answered. eve removes the card's buttons, marks it `No longer active`, and tells the person who clicked, in an ephemeral message, to send a new message.
 
-A renderer's `input.requested` handler can extend delivery and then hand the requests on to eve with `next()`. For example, an application can add non-sensitive context to the Slack thread before eve renders the actionable controls. The configured `approvalChannel` still sends sensitive reviews to a DM and keeps ordinary requests in the thread:
+A renderer's `interaction.opened` handler can extend delivery and then hand the request on to eve with `next()`. For example, an application can add non-sensitive context to the Slack thread before eve renders the actionable controls. The configured `approvalChannel` still sends sensitive reviews to a DM and keeps ordinary requests in the thread:
 
 ```ts title="agent/channels/slack.ts"
 import { slackChannel } from "eve/channels/slack";
@@ -664,8 +669,9 @@ export default slackChannel({
   renderers: [
     {
       events: {
-        async "input.requested"(_event, channel, _ctx, next) {
-          await channel.thread.post({
+        async "interaction.opened"(event, ctx, next) {
+          if (event.data.request.kind === "sign-in" || !("thread" in ctx.channel)) return next();
+          await ctx.channel.thread.post({
             blocks: [
               {
                 type: "context",
@@ -689,38 +695,39 @@ export default slackChannel({
 
 #### Render and decode HITL controls yourself
 
-`eve/channels/slack` exports the helpers eve uses for its own HITL controls. `renderInputRequestBlocks(request, route?)` returns the Block Kit blocks for one `InputRequest`. `deriveHitlResponse(action)` decodes a click on those blocks into `{ response, kind?, route? }`, where `response` is the eve `InputResponse`, or returns `null` for any other action. Every eve-owned control's `action_id` starts with `HITL_ACTION_PREFIX` (`"eve_input:"`), so give your own buttons a different prefix to keep them routed to `onInteraction`.
+`eve/channels/slack` exports the helpers eve uses for its own HITL controls. `renderInteractionBlocks(request, route?)` returns the Block Kit blocks for one `Interaction`. `answerFromSlackAction(action)` decodes a click on those blocks into `{ response, kind?, route? }`, where `response` is the eve `Answer`, or returns `null` for any other action. Every eve-owned control's `action_id` starts with `ANSWER_ACTION_PREFIX` (`"eve_input:"`), so give your own buttons a different prefix to keep them routed to `onInteraction`.
 
 ```ts
-import { deriveHitlResponse, renderInputRequestBlocks } from "eve/channels/slack";
+import { answerFromSlackAction, renderInteractionBlocks } from "eve/channels/slack";
 
-const [card] = renderInputRequestBlocks(request) as [
+const [card] = renderInteractionBlocks(request) as [
   { actions: { action_id: string; value: string }[] },
 ];
 const button = card.actions[0]!;
 
 // For a request whose first option id is "approve":
-deriveHitlResponse({ actionId: button.action_id, value: button.value });
-// { response: { optionId: "approve", requestId: request.requestId } }
+answerFromSlackAction({ actionId: button.action_id, value: button.value });
+// { response: { optionId: "approve", interactionId: request.interactionId } }
 ```
 
-Use them to test a custom renderer against eve's wire format, or to post eve's controls from your own renderer. A click on these controls in the session's Slack thread resumes the session through `onInputResponse`, the same as eve's own controls. eve does not track controls you post yourself, so update or remove those messages from your renderer's `approval.settled` and `input.resolved` handlers. To pass `response` to `respond()` yourself, validate it first with `parseInputResponses` from `eve/client`.
+Use them to test a custom renderer against eve's wire format, or to post eve's controls from your own renderer. A click on these controls in the session's Slack thread resumes the session through `onAnswers`, the same as eve's own controls. eve does not track controls you post yourself, so update or remove those messages from your renderer's `interaction.settled` handler. To pass `response` to `respond()` yourself, validate it first with `parseAnswers` from `eve/client`.
 
-Authorization prompts split public status from private credentials. A sign-in challenge (OAuth URL, device code) is a credential. Anyone who completes it binds their identity to the session's connection. The default `authorization.required` handler posts a public, link-free status in the thread, delivers the actual challenge ephemerally to the Slack user behind the event's `principalId`, device code included, and then updates that public status when `authorization.completed` fires. A renderer's `authorization.required` handler receives a private-delivery context with `postEphemeral`, `postDirectMessage` (needs the `im:write` scope), and `state`. There is, intentionally, no public `post` and no raw API access. Its `next()` reaches eve's default, which posts the public status; skip `next` to deliver the challenge yourself, as this handler does by direct message. `state.slackUsersByPrincipal` maps each principal eve has seen in the thread, through a message or an input response, to its Slack user ID. If the principal has no entry, the challenge is not sent privately.
+Authorization prompts split public status from private credentials. A sign-in challenge (OAuth URL, device code) is a credential. Anyone who completes it binds their identity to the session's connection. A sign-in is an `interaction.opened` with `request.kind: "sign-in"`. The default handler posts a public, link-free status in the thread, delivers the actual challenge ephemerally to the Slack user behind the interaction's `audience.principalIds`, device code included, and then updates that public status when its `interaction.settled` fires. For a sign-in, a renderer's `interaction.opened` handler receives a private-delivery context as `ctx.channel`, with `postEphemeral`, `postDirectMessage` (needs the `im:write` scope), and `state`. There is, intentionally, no public `post` and no raw API access. Its `next()` reaches eve's default, which posts the public status; skip `next` to deliver the challenge yourself, as this handler does by direct message. `state.slackUsersByPrincipal` maps each principal eve has seen in the thread, through a message or an input response, to its Slack user ID. If the principal has no entry, the challenge is not sent privately.
 
-The default private prompt names the service, says the agent is paused, and pairs a **Connect** button with **Cancel**. Cancel ends the held turn and removes the prompt; the public status, "Paused: waiting for @user to connect Linear…", then reads "Linear sign-in cancelled". Approval cards say the agent is paused until someone approves or cancels.
+The default private prompt names the service, says the agent is paused, and pairs a **Connect** button with **Cancel**. Cancel ends the held turn, removes the prompt, and updates the public status to say the sign-in was cancelled. Approval cards pair **Deny** with a primary **Approve** button and say the agent is paused until someone approves or denies.
 
 ```ts
 renderers: [
   {
     events: {
-      "authorization.required"(eventData, channel) {
+      "interaction.opened"(event, ctx, next) {
+        const { audience, request } = event.data;
+        if (request.kind !== "sign-in") return next();
+        const principalId = audience?.principalIds[0];
         const userId =
-          eventData.principalId === undefined
-            ? undefined
-            : channel.state.slackUsersByPrincipal?.[eventData.principalId];
-        if (!userId || !eventData.authorization?.url) return;
-        return channel.postDirectMessage(userId, `Sign in to continue: ${eventData.authorization.url}`);
+          principalId === undefined ? undefined : ctx.channel.state.slackUsersByPrincipal?.[principalId];
+        if (!userId || !request.signIn?.url) return;
+        return ctx.channel.postDirectMessage(userId, `Sign in to continue: ${request.signIn.url}`);
       },
     },
   },
@@ -744,7 +751,7 @@ Pass `{ channelId }` as the target to start a new thread. The agent's first post
 
 The default mention handler lets teammates continue the session by mentioning the app in the thread. To accept replies without a mention, [configure an `onMessage` hook and the required Slack subscriptions and scopes](#continue-conversations-without-repeated-mentions).
 
-For a Slack post without an agent turn, use `ctx.thread.post(...)` in an inbound handler or `channel.thread.post(...)` in a renderer's event handler. Outside a handler, use [`callSlackApi(...)`](#slack-api-calls-outside-a-handler).
+For a Slack post without an agent turn, use `ctx.thread.post(...)` in an inbound handler or `ctx.channel.thread.post(...)` in a renderer's event handler. Outside a handler, use [`callSlackApi(...)`](#slack-api-calls-outside-a-handler).
 
 ### Attachments
 

package/docs/channels/teams.mdx

@@ -81,17 +81,17 @@ Replies post as Markdown (`textFormat: "markdown"`), with oversized text split a
 
 ### Human-in-the-loop (HITL)
 
-A human-in-the-loop (HITL) `input.requested` event renders as an Adaptive Card. Approval cards show the tool input in the card and fallback text. Buttons and options map to `Action.Submit`, selects to `Input.ChoiceSet`, and freeform to `Input.Text`. Teams may return a submission as a message or invoke; eve handles both before the normal message mention gate and resumes the thread recorded in the card.
+A human-in-the-loop (HITL) request, an `interaction.opened` fact, renders as an Adaptive Card. Approval cards show the tool input in the card and fallback text. Buttons and options map to `Action.Submit`, selects to `Input.ChoiceSet`, and freeform to `Input.Text`. Teams may return a submission as a message or invoke; eve handles both before the normal message mention gate and resumes the thread recorded in the card.
 
-By default, submissions use the Teams identity of the user who clicked the card. If you customize `onMessage` for an allowlist, configure the same policy in `onInputResponse`; eve otherwise rejects HITL submissions rather than bypassing the message gate.
+By default, submissions use the Teams identity of the user who clicked the card. If you customize `onMessage` for an allowlist, configure the same policy in `onAnswers`; eve otherwise rejects HITL submissions rather than bypassing the message gate.
 
 When a tool approval settles, eve replaces its Adaptive Card with the outcome and responder name. A response rejected by an approval policy leaves the shared card unchanged. A submission to a card whose session is no longer active, for example because its run was cancelled outside eve, replaces the card with its prompt and `No longer active`, and the invoke response tells the person who submitted to send a new message.
 
 ### Connection sign-ins
 
-When a connection needs the person to sign in, eve's `authorization.required` handler posts an Adaptive Card. In a personal chat, the card includes the sign-in link and any confirmation code. In group chats and channels, the shared card only says who has to sign in and has a **Sign in** button (`Action.Execute`). When someone presses it, eve resolves who they are the same way it does for HITL submissions (`onInputResponse`). If that's the person who needs to sign in, eve sends back a card with the link and code, and Teams shows that card only to them. Anyone else is told they can't open it. That way another member can't finish the sign-in with their own account and have it saved under the requester's identity.
+When a connection needs the person to sign in, eve's `interaction.opened` handler posts an Adaptive Card for the sign-in. In a personal chat, the card includes the sign-in link and any confirmation code. In group chats and channels, the shared card only says who has to sign in and has a **Sign in** button (`Action.Execute`). When someone presses it, eve resolves who they are the same way it does for HITL answers (`onAnswers`). If that's the person who needs to sign in, eve sends back a card with the link and code, and Teams shows that card only to them. Anyone else is told they can't open it. That way another member can't finish the sign-in with their own account and have it saved under the requester's identity.
 
-If you customize `onMessage` without also setting `onInputResponse`, nobody can open a sign-in from a group chat or channel, because eve rejects every press.
+If you customize `onMessage` without also setting `onAnswers`, nobody can open a sign-in from a group chat or channel, because eve rejects every press.
 
 For invokes that aren't HITL, handle them in `onInvoke(ctx, activity)`.
 

package/docs/channels/telegram.mdx

@@ -45,7 +45,7 @@ To customize auth or filtering, override `onMessage`. Return `title` alongside `
 
 ### Delivery
 
-The default `message.completed` handler sends plain text via `sendMessage`. It passes no `parse_mode`, so any Markdown shows up literally. Replies longer than Telegram's 4096-char limit are split across messages. Custom handlers use `channel.telegram`.
+The default `content.completed` handler sends each reply part as plain text via `sendMessage`. It passes no `parse_mode`, so any Markdown shows up literally. Replies longer than Telegram's 4096-char limit are split across messages. Custom handlers use `ctx.channel.telegram`.
 
 ### Human-in-the-loop (HITL)
 

package/docs/channels/twilio.mdx

@@ -58,11 +58,11 @@ export default twilioChannel({
 
 ### Delivery
 
-The default `message.completed` handler sends the reply as SMS through Twilio's Messages API. A reply to an inbound message can reuse the webhook's `To` as the sender, but a proactive send has nothing to reuse, so it needs `messaging.from` or `messaging.messagingServiceSid`. Behind a proxy, set `webhookUrl` so signature verification matches the exact configured URL, and `publicBaseUrl` so voice TwiML can build absolute callback URLs.
+The default `content.completed` handler sends each reply part as SMS through Twilio's Messages API. A reply to an inbound message can reuse the webhook's `To` as the sender, but a proactive send has nothing to reuse, so it needs `messaging.from` or `messaging.messagingServiceSid`. Behind a proxy, set `webhookUrl` so signature verification matches the exact configured URL, and `publicBaseUrl` so voice TwiML can build absolute callback URLs.
 
 ### Human-in-the-loop (HITL)
 
-SMS has no buttons or cards, so the default `input.requested` handler sends each question and tool approval as an SMS with its options numbered. A reply with an option's number or label answers the pending request, so `1` or `approve` runs an approval-gated tool and `2` or `cancel` stops it. If the question allows a custom answer, any other text is taken as that answer. Callers on a voice call get the question by SMS too. To render questions differently, declare your own `events["input.requested"]` handler.
+SMS has no buttons or cards, so the default `interaction.opened` handler sends each question and tool approval as an SMS with its options numbered. A reply with an option's number or label answers the pending request, so `1` or `approve` runs an approval-gated tool and `2` or `cancel` stops it. If the question allows a custom answer, any other text is taken as that answer. Callers on a voice call get the question by SMS too. To render questions differently, declare your own `events["interaction.opened"]` handler.
 
 ### Proactive sessions
 

package/docs/code-extension.mdx

@@ -104,7 +104,7 @@ Configure `github` to broker GitHub access through Connect instead. The extensio
 | `github.org`         | With `github` | Organization whose repositories the `gh` tool can access                                          |
 | `github.broker`      | With `github` | `broker(sandbox, rules)` callback that installs, then removes, the GitHub credential rules        |
 | `github.authorize`   | No            | `authorize({ auth, repository, token })` callback that allows or denies each `gh` tool invocation |
-| `github.attribution` | No            | `attribution(ctx)` callback that returns the `{ name, email }` co-author for this turn            |
+| `github.attribution` | No            | `attribution(ctx)` returns the current turn's `{ name, email }` co-author, or `null`              |
 
 The `gh` tool requests a token scoped to exactly one repository in `github.org` for each invocation. The sandbox process receives a placeholder `GH_TOKEN`, and the firewall exchanges it on matching GitHub requests. Your `github.broker` callback receives the header-transform rules for the command, then `null` to remove the lease. The callback must preserve your other network rules. GitHub authentication has no command-delivery option.
 
@@ -135,14 +135,26 @@ export default git({
 });
 ```
 
-Commits made by the `gh` tool are authored by the GitHub App. To credit the person a turn works for, return them from `github.attribution`. The callback receives the tool's context, so it can read the verified caller from `ctx.session.auth.current` or resolve their linked accounts with `ctx.getToken`. The `gh` tool then ends every `gh-signed-commit` message, and every `gh pr create` body passed with `--body` or `--body-file`, with `Co-authored-by: <name> <email>`. Return `null` to publish without a co-author. `Co-authored-by` lines the agent writes itself are kept, and the trailer joins their block so they still count. Pull requests created without a body flag, such as with `--fill` or `--template`, and other paths, such as `gh api`, are not attributed.
+### Credit the person behind a turn
 
-```ts
-git({
+Commits made by the `gh` tool are authored by the GitHub App. Return a verified user mapping from
+`github.attribution` to add that person's `Co-authored-by` trailer to `gh-signed-commit` messages
+and `gh pr create` bodies passed through `--body` or `--body-file`. The callback receives the tool
+context, including `ctx.session.auth.current` and `ctx.getToken`. Return `null` to omit attribution.
+Existing co-author trailers are preserved; commands without a body flag and direct `gh api` calls
+are not attributed.
+
+For example, resolve the author through your application's authenticated user mapping:
+
+```ts title="agent/extensions/git.ts"
+import git from "eve/extensions/git";
+import { brokerGitHubLease, coAuthorFor } from "../lib/github";
+
+export default git({
   github: {
-    connector: "github",
+    connector: "github/my-agent",
     org: "acme",
-    broker,
+    broker: brokerGitHubLease,
     attribution: (ctx) => coAuthorFor(ctx.session.auth.current),
   },
 });
@@ -150,7 +162,7 @@ git({
 
 ### Migrate from `code({ github })`
 
-`code({ github })` is deprecated. While it is set, the code extension still contributes `code__gh`, its GitHub instructions, and the signed-commit `code__pr` skill. Without it, the code extension contributes no GitHub tool, instructions, or pull request skill. Move the `github` option to `git({ github })`, and import `gh` and the GitHub sandbox helpers from `eve/extensions/git/tools` and `eve/extensions/git/sandbox`.
+`code({ github })` is rejected. Move the `github` option to `git({ github })`, and import `gh` and the GitHub sandbox helpers from `eve/extensions/git/tools` and `eve/extensions/git/sandbox`.
 
 ## Prepare the sandbox