@sema-agent/client-core 0.40.0 → 0.42.0

package/dist/hitl/hitlBridge.d.ts

@@ -213,6 +213,14 @@ export type FindPendingOutcome = {
  * whose toolName the predicate doesn't recognize, but which still belongs to this run). Never `pending[0]`
  * — a typed failure when nothing for this taskId is queued.
  *
+ * F4947-1(2026-08-22,0.41.0):`callId` 是**更强的身份腿**,在场时先于上面两条跑。它来自
+ * `HitlBridge.decideTool`/`answerQuestion` 的 `toolUseID`(CC 的 tool_use id)—— 那两处此前走的是
+ * 本类里一个**同名私有** `findPending`,REF-CC-029 的收编没覆盖到它、P-30 的门种闸也没加到它,
+ * 于是真实生产入口(`makeHitlCanUseTool` → `decideTool`,从不传 `preResolvedPending`)一直在一条
+ * **没有闸**的复刻上跑(test 线 P0-KPI 复现)。收口方式是把私有件删掉改调本函数,而不是给它补第二
+ * 份过滤 —— 复刻正是这条缺陷的成因。身份腿同样只在**过完门种闸的行**里找:一个 `plan_review` 行
+ * 哪怕 callId 逐字命中也不该被工具审批 decide 掉(server 那边照样 409 `gate_not_tool_approval`)。
+ *
  * P-30(2026-08-14):both legs only consider rows whose `gateKind` belongs to the ask/approval family
  * ({@link askParkForeignGateKind} — the same single-source guard `classifyAskParkRows` uses). Without it
  * the ANY-row fallback would hand a `plan_review`/`resource_limit` row to the tool-approval wire — an
@@ -222,7 +230,34 @@ export type FindPendingOutcome = {
  */
 export declare function findPendingForTask(client: HitlClientLike, taskId: string, matches: (toolName: string | undefined) => boolean, opts?: {
     signal?: AbortSignal;
-}): Promise<FindPendingOutcome>;
+}, 
+/**
+ * F4947-1:调用方手上的**更强身份** —— CC 的 `toolUseID`(`HitlBridge`),或这张 park 的
+ * wire 身份(server ≥7.41.0,两条决断腿)。在场 ⇒ 先在**本 taskId** 的行里按
+ * `boundCallId`/`toolCallId` 逐字命中(仍在门种闸之内);不命中再走下面两条 taskId 腿。
+ *
+ * 🔴 **刻意不 fail-closed**(异源复审二审 finding① 的部分驳回,理由成文):身份在场而队列里
+ * 没有那一行时**照旧回落**,不铸「身份不匹配」的硬拒。两条理由:
+ *   · 回落的失效面 = 与本参数出现之前**逐字节相同**(那时压根没有身份腿);fail-closed 的失效面
+ *     = **每一次审批都决断不了**(用户点了 Yes 也过不去)。代价严重不对称;
+ *   · 这个 join(checkpoint 的 `pendingAction.toolCallId` ↔ `/v1/approvals` 富行的
+ *     `toolCallId`/`boundCallId`)本仓**没有对真 server 的实证**,只有上游帖面的口径。拿一个
+ *     没实证的键去关整条 HITL 的门,是把「可能对不上」赌成「一定对得上」。
+ * 跨 run 那一半的风险由上面的 taskId 约束关掉;「决断落在同 task 的另一行」这一格与本参数出现
+ * 之前同形,且下游 `dropHeldForDecidedPark` 对这一格自带保守判(身份对不上 ⇒ 一帧都不摘)。
+ */
+callId?: string, 
+/**
+ * 身份腿的**族闸**(整行可读)。缺省 = 退回 `matches(toolName)`。
+ *
+ * 🔴 为什么必须能读**整行**而不是只读 toolName(五审 finding①):工具审批族有**两条腿** ——
+ * 一等 `kind === 'tool_approval'`(放行**任意** toolName)与 fs 写 / shell 名字腿。而 wire 模块
+ * 传下来的 `matches` 只有名字腿那半(它服务的是「同族第一行」那条 leg 2)。拿它当身份闸,一个
+ * **合法的 kind-only 行**即使 taskId+callId 逐字命中也会被判出局 ⇒ 回落挑了同 task 的另一行,
+ * 卡面与决断全落在别的审批上、真 gate 继续 suspended。⇒ 调用方按自己那条腿的**完整**族判据
+ * 供给本闸(fs 腿 = `isToolApprovalGate({kind: row.gateKind, toolName})`,ask 腿 = `isAskTool`)。
+ */
+identityAccepts?: (row: PendingCheckpoint) => boolean): Promise<FindPendingOutcome>;
 /**
  * The bridge state. One per run/session. The shell feeds it `suspended` events (observe) and the human's
  * outcome (decide / answer / planReview); it owns the `approvals.list()` join + the verbatim binding echo.
@@ -240,17 +275,24 @@ export declare class HitlBridge {
     /** The gate currently awaiting a human, if any. The shell branches on `gate.kind` to pick the chrome. */
     currentGate(): CheckpointGate | null;
     /**
-     * Find the `PendingCheckpoint` the human is about to decide on. Joins by `toolCallId` when CC hands a
-     * `toolUseID`; otherwise falls back to the single pending row for this run's `taskId`. Returns null when
-     * the queue is empty (e.g. resolved/expired under the human → the caller must refetch + re-present).
+     * Fetch the `PendingCheckpoint` this decide/answer is about to resolve, for the callers that do NOT
+     * already have one in hand (see `decideTool`/`answerQuestion`'s `preResolvedPending` param — the wire
+     * modules that surface a card/overlay BEFORE deciding fetch the row themselves and pass it straight
+     * through, closing the TOCTOU window between "the row the human saw" and "the row decide resolves",
+     * REF-CC-029/hitl2-08).
      *
-     * Used only as the fallback when a caller does NOT already have the pending row in hand (see
-     * `decideTool`/`answerQuestion`'s `preResolvedPending` param) — the wire modules that surface a card/
-     * overlay BEFORE calling decide/answer fetch the row themselves via `findPendingForTask` (below) and
-     * pass it straight through, closing the TOCTOU window between "the row the human saw" and "the row
-     * decide resolves" (REF-CC-029/hitl2-08).
+     * 🔴 F4947-1(2026-08-22,0.41.0):本方法**没有自己的查找逻辑** —— 它是 {@link findPendingForTask}
+     * 的一层出参映射,一个字节的行过滤都不在这里。上一版是一个与那个单源导出**撞名**的私有复刻
+     * (`findPending`),REF-CC-029 的三合一没覆盖到它、P-30 的门种闸也只加在导出那一份上,于是
+     * `makeHitlCanUseTool` → `decideTool`(真实用户点 Yes/No 那条路,从不传 `preResolvedPending`)
+     * 一直在没有闸的老复刻上跑:同 task 停着 `plan_review` 行时,它被当成「这个 run 的 pending」
+     * 交给工具审批 decide(空 toolName 卡 / 409 `gate_not_tool_approval`)。
+     * 名字也一并换掉:撞名正是「看起来只有一份实现」的成因。
+     *
+     * 谓词传 {@link ANY_TOOL_FAMILY}:桥这一层对工具族**没有意见**(人刚刚决断的是哪张门就是哪张),
+     * 与旧私有件的 taskId 兜底逐字同语义;身份腿(`toolUseID`)由单源函数的 `callId` 参数承接。
      */
-    private findPending;
+    private pendingForDecide;
     /**
      * Build the D-1 binding off the pending row the human SAW. Echo VERBATIM — NEVER recompute the hash
      * (contract/04 §2.2). `checkpointToken` is DELIBERATELY never set (deprecated legacy path;
@@ -266,9 +308,23 @@ export declare class HitlBridge {
      *
      *  - `approve` → `{decision:"approve", boundCallId, boundInputHash}`; `updatedInput` rides along for
      *    approve-with-edit (applied AFTER the binding check — the hash still binds the ORIGINAL input).
-     *  - `deny`    → `{decision:"deny", reason}`. CANCEL a suspended run by DENYING, never by `runs.cancel`
-     *    (which 409s on a suspended run — contract/04 §2.4); the deny-and-abort `interrupt:true` EFFECT is
-     *    "the run ends after the deny", carried by the backend, not a wire flag.
+     *  - `deny`    → `{decision:"deny", reason}`.
+     *
+     * 🔴 **§2.4「DENY-abort」撤稿(0.42.0;server [4833] 明请,契约成文 `4631a0f` 随 7.39 出)**。
+     *    本段原文写的是:「CANCEL a suspended run by DENYING, never by `runs.cancel` (**which 409s on a
+     *    suspended run** — contract/04 §2.4); the deny-and-abort `interrupt:true` EFFECT is *the run ends
+     *    after the deny*」。**三句话里有两句已被上游证伪,逐条**:
+     *      · **「deny 用来 cancel 一条 run」** —— `ASSISTANT-WIRE-CONTRACT.md` §4a 逐字反过来说:
+     *        **DENY is a TOOL-level answer, NEVER a run kill**;客户端不得把用户的拒绝译成 cancel。
+     *        两个动词的 wire 判别式是 `cancelled`(真取消)vs `gate.batch_halted`(裸拒的兄弟结算)。
+     *      · **「`runs.cancel` 对 suspended run 回 409」** —— 自 server [868] 起**就地取消**:
+     *        `runs.js` 的 cancel 腿对 SUSPENDED/needs_review 先结算 pending checkpoint(CAS expire)再
+     *        终态化,`cancelSuspended` 有实体,409 只剩 `conflict.approval_settled` 一条
+     *        (本仓 `docs/fresh-scan-client-core-2026-08-08.md` B型-5 已按真字节证伪,当时未跟修注释)。
+     *      · **仍然成立的那一句**:deny 之后 run 是否结束由**后端编排**决定,不是 wire 上的旗标
+     *        (裸拒 ⇒ `gate.batch_halted` + `haltedOnUserRejection`;带留言拒 ⇒ run 续跑)。
+     *    ⇒ 本方法的**行为一字未改**(它本来走的就是 §4a 说的那条 TOOL 级 decide 通路);改的是这段
+     *      引用错权威、并把一条早已失效的 409 断言当理由的散文。
      *
      * The resumed run continues its SAME durable stream. A binding mismatch (409) is re-raised as a
      * `HitlSafetyError('binding_mismatch')` — the caller re-presents, NEVER auto-retries.
@@ -288,7 +344,7 @@ export declare class HitlBridge {
      *  its own `approvals.list()` — closing the TOCTOU window between "the row the human saw" and "the
      *  row decide resolves" (two independent fetches could otherwise land on different rows if the
      *  first one got resolved/expired in between, hitl2-01/hitl2-08). Omit only when the caller has no
-     *  such row in hand (falls back to `findPending`). */
+     *  such row in hand(缺省回落 `pendingForDecide` — 见其头注,那是单源 `findPendingForTask` 的一层出参映射). */
     preResolvedPending?: PendingCheckpoint): Promise<unknown>;
     /**
      * Answer an `AskUserQuestion` gate (contract/04 §4; 08 CS-16). Same suspended → decide loop as a

package/dist/hitl/hitlBridge.js

@@ -213,6 +213,12 @@ export class DecideTransportRetryExhaustedError extends Error {
         this.name = 'DecideTransportRetryExhaustedError';
     }
 }
+/**
+ * 「本层对工具族没有意见」的谓词(`HitlBridge.pendingForDecide` 用)。桥不是 wire 模块:它决断的
+ * 就是人刚刚看过的那张门,族属由那两条 wire 在**取件时**说了算。写成具名常量而不是就地 `() => true`
+ * —— 一个匿名恒真谓词读起来像「忘了填」,而这里的恒真是**有理由**的(理由即本注)。
+ */
+const ANY_TOOL_FAMILY = () => true;
 /**
  * The single source for "which `PendingCheckpoint` row is the human about to decide on", used by the two
  * decision wires (`toolApprovalWire.surfaceFsApprovalAndDecide` / `askGateWire.surfaceGateAndDecide`)
@@ -233,6 +239,14 @@ export class DecideTransportRetryExhaustedError extends Error {
  * whose toolName the predicate doesn't recognize, but which still belongs to this run). Never `pending[0]`
  * — a typed failure when nothing for this taskId is queued.
  *
+ * F4947-1(2026-08-22,0.41.0):`callId` 是**更强的身份腿**,在场时先于上面两条跑。它来自
+ * `HitlBridge.decideTool`/`answerQuestion` 的 `toolUseID`(CC 的 tool_use id)—— 那两处此前走的是
+ * 本类里一个**同名私有** `findPending`,REF-CC-029 的收编没覆盖到它、P-30 的门种闸也没加到它,
+ * 于是真实生产入口(`makeHitlCanUseTool` → `decideTool`,从不传 `preResolvedPending`)一直在一条
+ * **没有闸**的复刻上跑(test 线 P0-KPI 复现)。收口方式是把私有件删掉改调本函数,而不是给它补第二
+ * 份过滤 —— 复刻正是这条缺陷的成因。身份腿同样只在**过完门种闸的行**里找:一个 `plan_review` 行
+ * 哪怕 callId 逐字命中也不该被工具审批 decide 掉(server 那边照样 409 `gate_not_tool_approval`)。
+ *
  * P-30(2026-08-14):both legs only consider rows whose `gateKind` belongs to the ask/approval family
  * ({@link askParkForeignGateKind} — the same single-source guard `classifyAskParkRows` uses). Without it
  * the ANY-row fallback would hand a `plan_review`/`resource_limit` row to the tool-approval wire — an
@@ -240,7 +254,34 @@ export class DecideTransportRetryExhaustedError extends Error {
  * out, not a rejection of the whole queue: a genuine approval row for the same task still resolves.
  * Rows with no `gateKind` (pre-`gate_kind` history) keep the old behaviour — no stronger signal exists.
  */
-export async function findPendingForTask(client, taskId, matches, opts) {
+export async function findPendingForTask(client, taskId, matches, opts, 
+/**
+ * F4947-1:调用方手上的**更强身份** —— CC 的 `toolUseID`(`HitlBridge`),或这张 park 的
+ * wire 身份(server ≥7.41.0,两条决断腿)。在场 ⇒ 先在**本 taskId** 的行里按
+ * `boundCallId`/`toolCallId` 逐字命中(仍在门种闸之内);不命中再走下面两条 taskId 腿。
+ *
+ * 🔴 **刻意不 fail-closed**(异源复审二审 finding① 的部分驳回,理由成文):身份在场而队列里
+ * 没有那一行时**照旧回落**,不铸「身份不匹配」的硬拒。两条理由:
+ *   · 回落的失效面 = 与本参数出现之前**逐字节相同**(那时压根没有身份腿);fail-closed 的失效面
+ *     = **每一次审批都决断不了**(用户点了 Yes 也过不去)。代价严重不对称;
+ *   · 这个 join(checkpoint 的 `pendingAction.toolCallId` ↔ `/v1/approvals` 富行的
+ *     `toolCallId`/`boundCallId`)本仓**没有对真 server 的实证**,只有上游帖面的口径。拿一个
+ *     没实证的键去关整条 HITL 的门,是把「可能对不上」赌成「一定对得上」。
+ * 跨 run 那一半的风险由上面的 taskId 约束关掉;「决断落在同 task 的另一行」这一格与本参数出现
+ * 之前同形,且下游 `dropHeldForDecidedPark` 对这一格自带保守判(身份对不上 ⇒ 一帧都不摘)。
+ */
+callId, 
+/**
+ * 身份腿的**族闸**(整行可读)。缺省 = 退回 `matches(toolName)`。
+ *
+ * 🔴 为什么必须能读**整行**而不是只读 toolName(五审 finding①):工具审批族有**两条腿** ——
+ * 一等 `kind === 'tool_approval'`(放行**任意** toolName)与 fs 写 / shell 名字腿。而 wire 模块
+ * 传下来的 `matches` 只有名字腿那半(它服务的是「同族第一行」那条 leg 2)。拿它当身份闸,一个
+ * **合法的 kind-only 行**即使 taskId+callId 逐字命中也会被判出局 ⇒ 回落挑了同 task 的另一行,
+ * 卡面与决断全落在别的审批上、真 gate 继续 suspended。⇒ 调用方按自己那条腿的**完整**族判据
+ * 供给本闸(fs 腿 = `isToolApprovalGate({kind: row.gateKind, toolName})`,ask 腿 = `isAskTool`)。
+ */
+identityAccepts = (r) => matches(typeof r.toolName === 'string' ? r.toolName : undefined)) {
     let rows;
     try {
         rows = (await client.approvals.list(opts)).pending;
@@ -249,8 +290,33 @@ export async function findPendingForTask(client, taskId, matches, opts) {
         return { ok: false, reason: `approvals.list failed: ${String(e)}` };
     }
     const decidable = rows.filter((r) => askParkForeignGateKind(r) === null);
-    const pending = decidable.find((r) => r.taskId === taskId && matches(typeof r.toolName === 'string' ? r.toolName : undefined)) ??
-        decidable.find((r) => r.taskId === taskId);
+    // 🔴 身份腿**约束在本 taskId 之内**(异源复审二审 finding①):`/v1/approvals` 是 scope 级单队列,
+    // 别的 run / 后台子代 lane 的行同在表里 —— 一个撞名或被复用的 callId 就能把**别人会话**的 pending
+    // 行交给这次 decide。REF-CC-022 拆掉 `?? pending[0]` 防的正是这件事;身份腿是「更强的身份」,
+    // 不是「可以跨 run 的身份」,不能自带一个新的绕行口。
+    const identityRow = callId !== undefined
+        ? decidable.find((r) => r.taskId === taskId && (r.boundCallId === callId || r.toolCallId === callId))
+        : undefined;
+    // 🔴 身份命中还要过**族闸**(四审 finding② / 五审 finding①,闸读整行见 `identityAccepts`):
+    // 门种闸只挡 plan_review/resource_limit 这类外族,AskUserQuestion 与工具审批**同在** `decidable` 里。
+    // 一个陈旧/错配/被复用的 park 身份否则就能让 fs 腿选中一行 ask(反之亦然),而那一行随后原样当
+    // `preResolvedPending` 去呈卡 + decide —— 卡面全错、决断打在另一个 checkpoint 上。
+    const identityConflicts = identityRow !== undefined && !identityAccepts(identityRow);
+    // 🔴 身份证据与本腿族属**冲突**时,这一轮的候选池整体收紧到族闸放行的行(六审 finding① +
+    // 七审 finding①)。两步演进的理由要写清楚:
+    //   · 只拦身份腿是自相矛盾的 —— 最后那条「同 taskId 任意行」兜底会把**同一行**重新捞出来
+    //     (队列里只剩它时必然发生),刚判定「这一行不是本腿的」,转头又拿它去呈卡 + 决断;
+    //   · 只剔除命中的**那一个对象**也不够 —— 同 task 排着两条反族行时,删掉第一条,兜底照样捡起
+    //     第二条(七审实撞)。
+    // 冲突 = wire 数据自相矛盾(park 说 gate 是 A 族、身份却指着 B 族的行),这一轮**整体**保守:
+    // 只在族闸放行的行里选;一条都不剩 ⇒ 诚实 `no_pending`(调用方走既有 fail-soft / 重呈路)。
+    // 🔴 收紧**只发生在冲突路径上**:身份缺席(绝大多数路径)时候选池一个字节不动 —— 那条
+    // 「任意行」兜底本来就是给 kind-only / 名字腿认不得的合法行留的(见上方 leg 说明),不能被
+    // 一条与它无关的规则顺手削掉。
+    const pool = identityConflicts ? decidable.filter((r) => identityAccepts(r)) : decidable;
+    const pending = (identityConflicts ? undefined : identityRow) ??
+        pool.find((r) => r.taskId === taskId && matches(typeof r.toolName === 'string' ? r.toolName : undefined)) ??
+        pool.find((r) => r.taskId === taskId);
     if (!pending)
         return { ok: false, reason: 'no pending checkpoint for this run (resolved/expired?)', code: 'no_pending' };
     return { ok: true, pending, gatedCallId: pending.toolCallId ?? pending.boundCallId ?? undefined };
@@ -298,32 +364,33 @@ export class HitlBridge {
         return this.active?.gate ?? null;
     }
     /**
-     * Find the `PendingCheckpoint` the human is about to decide on. Joins by `toolCallId` when CC hands a
-     * `toolUseID`; otherwise falls back to the single pending row for this run's `taskId`. Returns null when
-     * the queue is empty (e.g. resolved/expired under the human → the caller must refetch + re-present).
+     * Fetch the `PendingCheckpoint` this decide/answer is about to resolve, for the callers that do NOT
+     * already have one in hand (see `decideTool`/`answerQuestion`'s `preResolvedPending` param — the wire
+     * modules that surface a card/overlay BEFORE deciding fetch the row themselves and pass it straight
+     * through, closing the TOCTOU window between "the row the human saw" and "the row decide resolves",
+     * REF-CC-029/hitl2-08).
      *
-     * Used only as the fallback when a caller does NOT already have the pending row in hand (see
-     * `decideTool`/`answerQuestion`'s `preResolvedPending` param) — the wire modules that surface a card/
-     * overlay BEFORE calling decide/answer fetch the row themselves via `findPendingForTask` (below) and
-     * pass it straight through, closing the TOCTOU window between "the row the human saw" and "the row
-     * decide resolves" (REF-CC-029/hitl2-08).
+     * 🔴 F4947-1(2026-08-22,0.41.0):本方法**没有自己的查找逻辑** —— 它是 {@link findPendingForTask}
+     * 的一层出参映射,一个字节的行过滤都不在这里。上一版是一个与那个单源导出**撞名**的私有复刻
+     * (`findPending`),REF-CC-029 的三合一没覆盖到它、P-30 的门种闸也只加在导出那一份上,于是
+     * `makeHitlCanUseTool` → `decideTool`(真实用户点 Yes/No 那条路,从不传 `preResolvedPending`)
+     * 一直在没有闸的老复刻上跑:同 task 停着 `plan_review` 行时,它被当成「这个 run 的 pending」
+     * 交给工具审批 decide(空 toolName 卡 / 409 `gate_not_tool_approval`)。
+     * 名字也一并换掉:撞名正是「看起来只有一份实现」的成因。
+     *
+     * 谓词传 {@link ANY_TOOL_FAMILY}:桥这一层对工具族**没有意见**(人刚刚决断的是哪张门就是哪张),
+     * 与旧私有件的 taskId 兜底逐字同语义;身份腿(`toolUseID`)由单源函数的 `callId` 参数承接。
      */
-    async findPending(toolUseID, opts) {
-        const { pending } = await this.client.approvals.list(opts);
-        if (pending.length === 0)
+    async pendingForDecide(toolUseID, opts) {
+        const found = await findPendingForTask(this.client, this.taskId, ANY_TOOL_FAMILY, opts, toolUseID);
+        if (found.ok)
+            return found.pending;
+        // 🔴 `no_pending`(良性缺席)才是「没有行可决」;`approvals.list` 自身失败必须照旧**抛**出去。
+        //    旧私有件让 list 的错原样逃逸,而下游 `parkResolver` 对 `no_pending` 的处置是「这张 gate
+        //    早就被解决了 ⇒ 继续读流」—— 把一次网络失败降级成那个码 = 谎报已解决(#110 烧会话的路径)。
+        if (found.code === 'no_pending')
             return null;
-        if (toolUseID) {
-            const byCall = pending.find((p) => p.boundCallId === toolUseID || p.toolCallId === toolUseID);
-            if (byCall)
-                return byCall;
-        }
-        // Fall back to this run's pending row (the suspended run holding the session claim).
-        // REF-CC-022(2026-08-02): NEVER `?? pending[0]` — once this taskId's own rows are exhausted, the
-        // first queue row can belong to a DIFFERENT session or a background subagent lane (they share the
-        // same `/v1/approvals` queue); deciding on it would resolve someone else's gate. A miss here is a
-        // real `no_pending` — the caller's existing typed-fail path (and exactly the signal #110's
-        // cancel-by-deny-recovery arm expects), not "decide on whatever happens to be first".
-        return pending.find((p) => p.taskId === this.taskId) ?? null;
+        throw new Error(found.reason);
     }
     /**
      * Build the D-1 binding off the pending row the human SAW. Echo VERBATIM — NEVER recompute the hash
@@ -348,9 +415,23 @@ export class HitlBridge {
      *
      *  - `approve` → `{decision:"approve", boundCallId, boundInputHash}`; `updatedInput` rides along for
      *    approve-with-edit (applied AFTER the binding check — the hash still binds the ORIGINAL input).
-     *  - `deny`    → `{decision:"deny", reason}`. CANCEL a suspended run by DENYING, never by `runs.cancel`
-     *    (which 409s on a suspended run — contract/04 §2.4); the deny-and-abort `interrupt:true` EFFECT is
-     *    "the run ends after the deny", carried by the backend, not a wire flag.
+     *  - `deny`    → `{decision:"deny", reason}`.
+     *
+     * 🔴 **§2.4「DENY-abort」撤稿(0.42.0;server [4833] 明请,契约成文 `4631a0f` 随 7.39 出)**。
+     *    本段原文写的是:「CANCEL a suspended run by DENYING, never by `runs.cancel` (**which 409s on a
+     *    suspended run** — contract/04 §2.4); the deny-and-abort `interrupt:true` EFFECT is *the run ends
+     *    after the deny*」。**三句话里有两句已被上游证伪,逐条**:
+     *      · **「deny 用来 cancel 一条 run」** —— `ASSISTANT-WIRE-CONTRACT.md` §4a 逐字反过来说:
+     *        **DENY is a TOOL-level answer, NEVER a run kill**;客户端不得把用户的拒绝译成 cancel。
+     *        两个动词的 wire 判别式是 `cancelled`(真取消)vs `gate.batch_halted`(裸拒的兄弟结算)。
+     *      · **「`runs.cancel` 对 suspended run 回 409」** —— 自 server [868] 起**就地取消**:
+     *        `runs.js` 的 cancel 腿对 SUSPENDED/needs_review 先结算 pending checkpoint(CAS expire)再
+     *        终态化,`cancelSuspended` 有实体,409 只剩 `conflict.approval_settled` 一条
+     *        (本仓 `docs/fresh-scan-client-core-2026-08-08.md` B型-5 已按真字节证伪,当时未跟修注释)。
+     *      · **仍然成立的那一句**:deny 之后 run 是否结束由**后端编排**决定,不是 wire 上的旗标
+     *        (裸拒 ⇒ `gate.batch_halted` + `haltedOnUserRejection`;带留言拒 ⇒ run 续跑)。
+     *    ⇒ 本方法的**行为一字未改**(它本来走的就是 §4a 说的那条 TOOL 级 decide 通路);改的是这段
+     *      引用错权威、并把一条早已失效的 409 断言当理由的散文。
      *
      * The resumed run continues its SAME durable stream. A binding mismatch (409) is re-raised as a
      * `HitlSafetyError('binding_mismatch')` — the caller re-presents, NEVER auto-retries.
@@ -361,9 +442,9 @@ export class HitlBridge {
      *  its own `approvals.list()` — closing the TOCTOU window between "the row the human saw" and "the
      *  row decide resolves" (two independent fetches could otherwise land on different rows if the
      *  first one got resolved/expired in between, hitl2-01/hitl2-08). Omit only when the caller has no
-     *  such row in hand (falls back to `findPending`). */
+     *  such row in hand(缺省回落 `pendingForDecide` — 见其头注,那是单源 `findPendingForTask` 的一层出参映射). */
     preResolvedPending) {
-        const pending = preResolvedPending ?? (await this.findPending(toolUseID, opts));
+        const pending = preResolvedPending ?? (await this.pendingForDecide(toolUseID, opts));
         if (!pending) {
             throw new HitlSafetyError('no pending checkpoint to decide (resolved/expired under the human) — refetch + re-present', 'no_pending');
         }
@@ -408,10 +489,10 @@ export class HitlBridge {
     /** REF-CC-029(2026-08-02):see `decideTool`'s same-named param — the pending row the caller already
      *  fetched via `findPendingForTask`. */
     preResolvedPending) {
-        // 🔴 校验在 findPending **之前**:入参坏了跟 pending 行在不在场无关,而先 list 再拒会把
+        // 🔴 校验在取件**之前**:入参坏了跟 pending 行在不在场无关,而先 list 再拒会把
         //    「你的作答是空的」这条真判词换成「no_pending」那条假判词(行恰好过期时)。
         assertAnswersSendable(answers);
-        const pending = preResolvedPending ?? (await this.findPending(toolUseID, opts));
+        const pending = preResolvedPending ?? (await this.pendingForDecide(toolUseID, opts));
         if (!pending) {
             throw new HitlSafetyError('no pending AskUserQuestion checkpoint to answer — refetch + re-present', 'no_pending');
         }
@@ -554,7 +635,9 @@ export function makeHitlCanUseTool(bridge, prompt) {
         const decision = forceDecision ??
             (await prompt({ toolName: tool.name, input, toolUseID, gate }));
         if (decision.behavior === 'deny') {
-            // Deny → cancel-by-deny (contract/04 §2.4). The deny message rides `reason`.
+            // Deny → 一次 **TOOL 级**的 deny 应答(server `ASSISTANT-WIRE-CONTRACT.md` §4a;0.42.0 撤稿:
+            // 原文写的是「cancel-by-deny (contract/04 §2.4)」,而 §4a 逐字反对把拒绝读成 run kill ——
+            // 详见 `decideTool` 头注的撤稿段)。The deny message rides `reason`.
             // 0.28.0 发版扫描 F1(P2):message 逐字嵌原始命令(壳侧 bashPermissions 无上限)——必须与
             // 卡腿同门经窄化器截到 4096,否则 server 413 丢的是整次 deny(run 留 suspended)。
             await bridge.decideTool({ decision: 'deny', reason: denyReasonForWire(decision.message, `canUseTool ${toolUseID}`) ?? DEFAULT_DENY_REASON }, toolUseID);

package/dist/hitl/hitlHostSurface.d.ts

@@ -31,9 +31,32 @@ export declare function _resetHitlHostSurfaceForTest(): void;
 /** 内部读点(计 miss)。`askGateWire.ts` 的 `surfaceClassifierDeny` 路径与本文件的
  *  `surfaceCancelDenyWarn` 共用它。 */
 export declare function surfaceForCurrentSession(): HitlHostSurface | null;
-/** cancel-by-deny 的后台 settle 预算。decide 是 SYNC 驱动的(引擎跑到下一 park/终态才返,实测
- *  4-5s+),但 DENY-abort 语义上引擎收到即终结 run;2s 内连收都没收到 ⇒ 按丢失警示(晚到成功
- *  只是多一行良性 warn,比锁死无线索诚实)。 */
+/**
+ * 中断-deny 的后台 settle 观察预算。
+ *
+ * ══ 🔴 §2.4「DENY-abort」撤稿 + 本常量的论证前提重审(0.42.0;server [4833] 明请)═══════════
+ *
+ * **本段 0.28.0 原文写的是**:「decide 是 SYNC 驱动的(引擎跑到下一 park/终态才返,实测 4-5s+),
+ * 但 **DENY-abort 语义上引擎收到即终结 run**;2s 内连收都没收到 ⇒ 按丢失警示」。
+ * 那句加粗的前提**已被上游撤稿**,来源是 server 自己的契约成文(`4631a0f`,随 7.39 出;
+ * `ASSISTANT-WIRE-CONTRACT.md` §4a):**DENY 是 TOOL 级的应答,永远不是 run kill**;客户端不得
+ * 把「拒绝」译成「取消」;两个动词的 wire 判别式是 `cancelled` vs `gate.batch_halted`。
+ * ⇒ 「引擎收到 deny 即终结 run」这条**不成立**:deny 只结算**这一只 ask**,run 按自己的编排继续
+ *   (裸拒 ⇒ `gate.batch_halted` 兄弟 coded 结算 + `haltedOnUserRejection`;带留言拒 ⇒ run 续跑)。
+ *
+ * **重审结论(本批只改论证,不改数值 —— 理由写全)**:
+ *   · 旧论证「2s 没结算 = deny 大概率丢了,因为收到就该终结」**作废**;
+ *   · 但本常量守的那件事**换一个理由仍然成立**:它是一个**观察上限**,给「decide 永不返回」这种
+ *     形态一条出声的路 —— 没有它,一次真的丢失就只剩静默;
+ *   · **数值不在本批动**:动它是行为面改动,而判据(多久算「没回来」)只有拿真实 decide 往返分布
+ *     说了算,那份实测在**消费端**(壳中断路径)而不在包里;且下游 `sema-cli` 的
+ *     `src/sema/hitlCancelDeny.test.ts` 按现值锁着行为,单边改会当场把消费端打红。
+ *   · **如实登记的残余**(接入档 §6e/§7 同批记):预算到点就发的那行 warn 措辞是
+ *     {@link CANCEL_DENY_WARN_TEXT}（「the session may stay locked」),而在新契约下「decide 慢」
+ *     与「deny 丢了」这两件事在 2s 这个刻度上**不可分** —— 晚到的成功不会撤回那行 warn(只有 10s
+ *     自清)。要根治得做成两档(软档只记 debug、硬档才上屏),那是**跨仓一批**:包侧改时序、壳侧
+ *     同批换判据与用例。本批不做单边改动。
+ */
 export declare const CANCEL_DENY_BUDGET_MS = 2000;
 /** warn 行文案(测试锁字面)。 */
 export declare const CANCEL_DENY_WARN_TEXT = "could not cancel the pending question \u2014 the session may stay locked; the run may need engine-side recovery";
@@ -66,6 +89,13 @@ export declare function surfaceRememberNotApplied(): void;
 export declare function surfaceEditNotForwarded(): void;
 /**
  * 中断 deny 的有界观察(壳侧单测 `hitlCancelDeny.test.ts` 的被测面;REF-CC-023 起两条决断腿共用)。
+ *
+ * 🔴 **命名撤稿(0.42.0)**:函数名与日志里的「cancel-by-deny」是**历史词**,保留只为不打断下游
+ * 按名锚的用例。它描述的动作在现行契约(server `ASSISTANT-WIRE-CONTRACT.md` §4a)下的准确说法是
+ * 「**中断时把这只挂着的 ask 用一个 TOOL 级 deny 结算掉**,好让 run 不停在 suspended 上」——
+ * **不是**「用 deny 去 cancel 一条 run」。方向也别读反:这里是把**用户的中断**结算成一次 deny,
+ * 而 §4a 禁的是反向的那件事(把**用户的拒绝**译成 cancel),两者不是同一件事。
+ *
  * 铁律:不 await 进 abort 返回路径(用户立即拿回控制);这里只管后台 settle 的«观察»:
  *   - 2s 内 settle 成功 ⇒ 零上屏(SEMA_DEBUG 记成功);
  *   - 失败/超时 ⇒ 上屏一行 warn + SEMA_DEBUG 记原因(deny 丢失 = run 卡 suspended,下一条消息

package/dist/hitl/hitlHostSurface.js

@@ -61,9 +61,32 @@ export function surfaceForCurrentSession() {
     return hostSurface;
 }
 // ── 件3(中断事故修复批 G,2026-07-15)—— 中断 deny 的有界观察 ─────────────────────────────────
-/** cancel-by-deny 的后台 settle 预算。decide 是 SYNC 驱动的(引擎跑到下一 park/终态才返,实测
- *  4-5s+),但 DENY-abort 语义上引擎收到即终结 run;2s 内连收都没收到 ⇒ 按丢失警示(晚到成功
- *  只是多一行良性 warn,比锁死无线索诚实)。 */
+/**
+ * 中断-deny 的后台 settle 观察预算。
+ *
+ * ══ 🔴 §2.4「DENY-abort」撤稿 + 本常量的论证前提重审(0.42.0;server [4833] 明请)═══════════
+ *
+ * **本段 0.28.0 原文写的是**:「decide 是 SYNC 驱动的(引擎跑到下一 park/终态才返,实测 4-5s+),
+ * 但 **DENY-abort 语义上引擎收到即终结 run**;2s 内连收都没收到 ⇒ 按丢失警示」。
+ * 那句加粗的前提**已被上游撤稿**,来源是 server 自己的契约成文(`4631a0f`,随 7.39 出;
+ * `ASSISTANT-WIRE-CONTRACT.md` §4a):**DENY 是 TOOL 级的应答,永远不是 run kill**;客户端不得
+ * 把「拒绝」译成「取消」;两个动词的 wire 判别式是 `cancelled` vs `gate.batch_halted`。
+ * ⇒ 「引擎收到 deny 即终结 run」这条**不成立**:deny 只结算**这一只 ask**,run 按自己的编排继续
+ *   (裸拒 ⇒ `gate.batch_halted` 兄弟 coded 结算 + `haltedOnUserRejection`;带留言拒 ⇒ run 续跑)。
+ *
+ * **重审结论(本批只改论证,不改数值 —— 理由写全)**:
+ *   · 旧论证「2s 没结算 = deny 大概率丢了,因为收到就该终结」**作废**;
+ *   · 但本常量守的那件事**换一个理由仍然成立**:它是一个**观察上限**,给「decide 永不返回」这种
+ *     形态一条出声的路 —— 没有它,一次真的丢失就只剩静默;
+ *   · **数值不在本批动**:动它是行为面改动,而判据(多久算「没回来」)只有拿真实 decide 往返分布
+ *     说了算,那份实测在**消费端**(壳中断路径)而不在包里;且下游 `sema-cli` 的
+ *     `src/sema/hitlCancelDeny.test.ts` 按现值锁着行为,单边改会当场把消费端打红。
+ *   · **如实登记的残余**(接入档 §6e/§7 同批记):预算到点就发的那行 warn 措辞是
+ *     {@link CANCEL_DENY_WARN_TEXT}（「the session may stay locked」),而在新契约下「decide 慢」
+ *     与「deny 丢了」这两件事在 2s 这个刻度上**不可分** —— 晚到的成功不会撤回那行 warn(只有 10s
+ *     自清)。要根治得做成两档(软档只记 debug、硬档才上屏),那是**跨仓一批**:包侧改时序、壳侧
+ *     同批换判据与用例。本批不做单边改动。
+ */
 export const CANCEL_DENY_BUDGET_MS = 2000;
 /** warn 行文案(测试锁字面)。 */
 export const CANCEL_DENY_WARN_TEXT = 'could not cancel the pending question — the session may stay locked; the run may need engine-side recovery';
@@ -161,6 +184,13 @@ function isNoPendingError(e) {
 }
 /**
  * 中断 deny 的有界观察(壳侧单测 `hitlCancelDeny.test.ts` 的被测面;REF-CC-023 起两条决断腿共用)。
+ *
+ * 🔴 **命名撤稿(0.42.0)**:函数名与日志里的「cancel-by-deny」是**历史词**,保留只为不打断下游
+ * 按名锚的用例。它描述的动作在现行契约(server `ASSISTANT-WIRE-CONTRACT.md` §4a)下的准确说法是
+ * 「**中断时把这只挂着的 ask 用一个 TOOL 级 deny 结算掉**,好让 run 不停在 suspended 上」——
+ * **不是**「用 deny 去 cancel 一条 run」。方向也别读反:这里是把**用户的中断**结算成一次 deny,
+ * 而 §4a 禁的是反向的那件事(把**用户的拒绝**译成 cancel),两者不是同一件事。
+ *
  * 铁律:不 await 进 abort 返回路径(用户立即拿回控制);这里只管后台 settle 的«观察»:
  *   - 2s 内 settle 成功 ⇒ 零上屏(SEMA_DEBUG 记成功);
  *   - 失败/超时 ⇒ 上屏一行 warn + SEMA_DEBUG 记原因(deny 丢失 = run 卡 suspended,下一条消息

package/dist/hitl/parkResolver.js

@@ -90,7 +90,10 @@ export function toAnsweredOutput(questions, answer) {
  * 弹既有 AskUserQuestion overlay → 等作答 → 经 HitlBridge decide(答案/拒答)。
  * decide 成功即引擎已把 run 驱到下一状态(sync);调用方随后 attach runs.events 续流。
  */
-async function surfaceGateAndDecide(deps, taskId, askArgsByCall, signal) {
+async function surfaceGateAndDecide(deps, taskId, askArgsByCall, signal, 
+/** 这张 park 的待批 call 身份(server ≥7.41.0;缺席是常态)。语义与不 fail-closed 的理由
+ *  与 fs 腿同一条,见 `toolApprovalWire.surfaceFsApprovalAndDecide` 的同名参数头注。 */
+parkGatedCallId) {
     if (!hasQuestionOverlay()) {
         return { kind: 'failed', reason: 'no question overlay mounted (print/non-REPL mode)' };
     }
@@ -98,7 +101,9 @@ async function surfaceGateAndDecide(deps, taskId, askArgsByCall, signal) {
     // REF-CC-029(单源取件)+ REF-CC-033(no_pending 判别码):findPendingForTask 是唯一取件口
     // (三份近似复刻已收敛),其失败形带 code 判别位,本处原样透传给 GateOutcome ——
     // 「没有待决 gate」(良性,park 重放常见)与「approvals.list 真失败」自此结构可分。
-    const found = await findPendingForTask(deps.client, taskId, isAskTool, signal ? { signal } : undefined);
+    const found = await findPendingForTask(deps.client, taskId, isAskTool, signal ? { signal } : undefined, parkGatedCallId, // 身份在场 ⇒ 逐字命中优先;缺席/不命中 ⇒ 原两腿(不 fail-closed,理由见参数头注)
+    // 本腿的族就是 ask 一族(整行可读闸的 ask 半场,与 fs 腿的 `isToolApprovalGate` 对称)。
+    (row) => isAskTool(typeof row.toolName === 'string' ? row.toolName : undefined));
     if (!found.ok)
         return { kind: 'failed', reason: found.reason, ...(found.code !== undefined ? { code: found.code } : {}) };
     const { pending, gatedCallId } = found;
@@ -149,12 +154,24 @@ async function surfaceGateAndDecide(deps, taskId, askArgsByCall, signal) {
     });
     const bridge = new HitlBridge(deps.client, taskId);
     if (answer === null) {
-        // turn 被中断(Esc/Ctrl+C):cancel-by-deny(contract/04 §2.4 —— suspended run 不 runs.cancel)。
+        // turn 被中断(Esc/Ctrl+C):把这只挂着的 ask 用一次 **TOOL 级 deny** 结算掉,好让 run 不停在
+        // suspended 上(server `ASSISTANT-WIRE-CONTRACT.md` §4a)。
+        // 🔴 **0.42.0 撤稿**:原文写的是「cancel-by-deny(contract/04 §2.4 —— suspended run 不
+        //    runs.cancel)」。那条引用的两个前提都已作废 —— §4a 逐字说 DENY 是 tool 级应答**永远不是**
+        //    run kill;而「suspended run 不能 runs.cancel」自 server [868] 起就不成立(就地取消已实装,
+        //    本仓 fresh-scan B型-5 按真字节证伪)。这里选 deny 不是因为 cancel 不可用,是因为**这一刻
+        //    要处理的就是一只挂着的 ask**:先把它结算掉,run 才走得下去。下方那句「引擎侧解锁腿到货前」
+        //    同批订正:那条腿早就到货了,本臂保留的理由变成「结算 ask 是这一步的正解」,不再是权宜。
         // 件3(中断事故修复批 G,2026-07-15,症状1 壳侧配套):此前 .catch(()=>{}) 全吞 = deny 丢失时
         // run 永卡 suspended,session 锁死,用户下一条消息撞 409「active run」还全无线索。改为有界观察
         // (observeCancelByDeny,2s 预算):abort 仍立即返回用户控制(不 await,交互时序不变),后台
-        // settle 失败/超时上屏一行 warn + SEMA_DEBUG 记失败原因。引擎侧解锁腿([866] server:cancel
-        // suspended 改语义 + reapSuspended TTL)到货前,这是壳能做的最诚实半场。
+        // settle 失败/超时上屏一行 warn + SEMA_DEBUG 记失败原因。
+        // 🔴 **0.42.0 订正**:本段原文以「引擎侧解锁腿([866] server:cancel suspended 改语义 +
+        //    reapSuspended TTL)**到货前**,这是壳能做的最诚实半场」收尾 —— 那条腿早已到货
+        //    (server [868] 起 suspended run 就地取消 + `reapSuspended` 实体在,fresh-scan B型-5 已按
+        //    真字节证伪)。本臂**不是**在等一条不存在的上游腿:它保留的理由是「这一刻要处理的就是一只
+        //    挂着的 ask,先结算它 run 才走得下去」。观察器的预算论证前提见 `CANCEL_DENY_BUDGET_MS` 头注
+        //    的重审段(同批 §2.4 撤稿件)。
         observeCancelByDeny(bridge.decideTool({ decision: 'deny', reason: 'Interrupted by user' }, gatedCallId, undefined, pending), taskId);
         return { kind: 'aborted', gatedCallId };
     }
@@ -208,7 +225,7 @@ export async function resolvePark(park, ctx) {
     else if (park.gate === 'fs') {
         candidateGatedCallId = led.lastFsOrShellGatedCallId();
         // [816] 放宽腿:fs 写权限 gate → CC 三选卡(vendored PermissionRequest)→ decide。
-        outcome = await surfaceFsApprovalAndDecide({ client: deps.client }, taskId, argsByCallOf(led), ctx.signal);
+        outcome = await surfaceFsApprovalAndDecide({ client: deps.client }, taskId, argsByCallOf(led), ctx.signal, park.gatedCallId);
         // #51: `outcome`'s declared type is the wider `GateOutcome |
         // FsApprovalOutcome`; both unions share a 'decided' kind with
         // different optional fields (`answered` vs `denied`), so a plain
@@ -221,7 +238,7 @@ export async function resolvePark(park, ctx) {
         }
     }
     else {
-        outcome = await surfaceGateAndDecide(deps, taskId, argsByCallOf(led), ctx.signal);
+        outcome = await surfaceGateAndDecide(deps, taskId, argsByCallOf(led), ctx.signal, park.gatedCallId);
     }
     // #110 缺陷② b/c —— **重放的、早已决断过的 park 不是失败**。
     // durable re-attach 必然会把 park 帧再送一遍(`lastEventId` 再准也只能精确到帧,park 就在
@@ -288,6 +305,15 @@ export async function resolvePark(park, ctx) {
     }
     // decide 成功:丢弃该 call 的毒化 HOLD(续流重放会带 isError:false 的解答帧收口卡片),
     // 并记下真实答案供该解答帧 stamp `structured`(否则卡片渲成结果不可用)。
+    //
+    // 🔴 件④([4933] 立案的存量,0.41.0 根修):摘扣留帧走 `dropHeldForDecidedPark` 而不是裸
+    //    `dropHeld(outcome.gatedCallId)` —— 后者的入参是 `findPendingForTask` 的**卡面渲染宽口**
+    //    (同 taskId + 谓词命中的第一行),同族多行排队时它可能是旁观者,于是摘掉的是**另一条**
+    //    call 的扣留帧、那一帧再也不吐(「一帧不丢」在这一格上不成立)。新动词的两条腿见其头注:
+    //    `park.gatedCallId`(server ≥7.41.0 的 wire 身份)在场就点名摘,缺席则只在同族唯一时摘。
+    //    这一行**刻意排在 `if (outcome.gatedCallId)` 之外**:身份在 wire 上时,摘不摘与 pending
+    //    行给没给出 callId 无关(park 有主角,decide 也成功了)。
+    led.dropHeldForDecidedPark(outcome.gatedCallId, park.gatedCallId);
     if (outcome.gatedCallId) {
         // 🔴 #324:**刻意不把 pending 行的 callId 当成连坐判别的主角身份**。durable `checkpointGate`
         //    不带 callId,`findPendingForTask` 取的是「同 taskId + 谓词命中的**第一行**」(谓词不命中
@@ -295,12 +321,12 @@ export async function resolvePark(park, ctx) {
         //    同族两行排队时它可能给出旁观者,于是真主角被挤成「非主角」而 stamp(异源复审实测)。
         //    连坐判别改由台账按「本批唯一的该族 call」自证(`gateLedger.flushHeld` 头注),
         //    分不出来就整批不标。下面两行是 gate 生命周期(#110 / REF-CC-034),与判别无关,照旧。
-        //    ⚠️ **记案(存量,非本批根因)**:`dropHeld` 用的也是这个不可信的 `gatedCallId` —— 同族
-        //    多行排队时它可能摘掉**另一条** call 的扣留帧,那一帧就再也不吐了(「一帧不丢」在这一格
-        //    上不成立)。这条早于本批(4c42c8a 逐字相同),根因在「decide 结果没有可核验的 park 身份」,
-        //    与本批修的判别面是两件事;改它要动 #110 的承重路径,单独立案。server 补
-        //    `checkpointGate.toolCallId` 后两处一并收口。
-        led.dropHeld(outcome.gatedCallId);
+        //    ✅ **记案已销**(0.41.0 件④):此处原先那句「`dropHeld` 用的也是这个不可信 callId」的
+        //    存量记案,已由上方 `dropHeldForDecidedPark` 收口(wire 身份点名 / 判不出就不摘)。
+        //    🔴 `markDecided` **刻意仍用** `outcome.gatedCallId`:它喂的是 #110 那条「重放的 park 不是
+        //    失败」的承重判据,而那条判据的候选取自 `lastFsOrShellGatedCallId()`(同一条 pending 宽口
+        //    时代的口径),两边必须同源才对得上;换成 wire 身份是**另一件**改动(要连着上方
+        //    `candidateGatedCallId` 一起换,且会改动烧会话那条路径的行为),不搭本批的车。
         led.markDecided(outcome.gatedCallId); // #110 缺陷② b / REF-CC-034:身份留痕,上方候选匹配消费
         if ('answered' in outcome && outcome.answered)
             led.rememberAnswer(outcome.gatedCallId, outcome.answered);