@sema-agent/sdk 9.6.0 → 9.7.1

package/dist/types.d.ts

@@ -57,7 +57,7 @@
  *    null" may be correct — check for a normalizer at the boundary before widening it to `| null`.
  */
 import type { SemaSettings } from "./settings.js";
-import type { AskOrigin, ClassifierUnavailable, DenialLimitFallback, RuleOffer } from "./resources/tool-approvals.js";
+import type { AskOrigin, ClassifierUnavailable, DenialLimitFallback, RuleOffer, ToolApprovalFrame } from "./resources/tool-approvals.js";
 /** Authenticated end-user identity. Opaque to the service (used as memory scope + session owner). The SDK
  *  normalizes; the service does NOT validate the format. Convention: `user:` / `org:` / `ai:` / `anon:`. */
 export type Principal = string;
@@ -180,11 +180,20 @@ export interface TaskStats {
          *  gate **恰好 4 键** `{kind, decision, toolName, waitMs}`,逐键命中、零未声明字段。**`tool_input`/`toolInput` 不在
          *  1.6.1 gate ledger 上**(此前推测 core 1.148 会经开集带被拒入参 —— 本部署证伪;留开集 `[k]` 待更新部署再验,不加为
          *  typed 字段)。`toolName` 实采为被拒工具名(Q6/core 1.161 起 = CC 名,如 "Bash")。 */
+        /** 🔴 **`toolCallId` 自 core 7.23.0 #897(server ≥7.87.0)到货,逐字透传**:
+         *   · **缺席 = 不可 join**,**不是**「没有调用」—— 四个铸点里有三个(继承授权复用 / 耐久 resume 腿 /
+         *     park 自检合成行)本就可能没有调用身份可给;
+         *   · **按键 join,不按条数、不按位置**:多腿聚合(verify / cascade / repair-loop)把各腿的 gates **整块
+         *     push**,次序是「腿完成序的拼接」;而消费端自己的权限账本与这一本**条数天生不等**。
+         *   · 右表有键了**不等于**该在别处再铸一本并行账本:引擎这一本是权威,拿自己的账本按本键对上去。
+         *  ⚠️ `toolArg` 与 `segment` 两片模型自由文本自 server 7.84.0(S-394)起与 `result` 走**同一只脱敏器**
+         *  ⇒ 含凭据形的**字节会变**(不含的逐字节不变);拿它们做哈希/身份比对的消费端要改。 */
         gates: Array<{
             kind: string;
             waitMs: number;
             decision?: string;
             toolName?: string;
+            toolCallId?: string;
             [k: string]: unknown;
         }>;
     };
@@ -400,6 +409,29 @@ export interface TaskRequest {
      *  与持久 body 一起骑到 resume 腿上(与 `memoryWrite` 同姿势)。
      *  中途才想关?用 {@link RunsResource.memoryCaptureOptOut}(同一条记录的另一个 ingress)。 */
     memoryCapture?: "off";
+    /** 🔴 **请求级「记忆整面关」声明**(server ≥7.84.0 / S-405 / core #863 W3;server 铸点
+     *  `src/http/wire-types.ts:309`)—— `"off"` = **这一次运行不挂记忆面**(没有 `# Memory` 段 / 索引 /
+     *  三只记忆工具 / 写准入)。**单成员闭集,没有 `"on"`**:缺席就是「记忆照常挂」的唯一写法。
+     *
+     *  🔴 与 {@link memoryCapture} / {@link memoryWrite} **三轴正交,别混用**:
+     *   · 本键 —— 「这一次运行整个记忆面都不挂」(读写整面,逐请求);
+     *   · `memoryCapture:"off"` —— 「记忆照常挂,但**这个会话**的内容永远不进长期记忆」(采集面,一次性会话记录);
+     *   · `memoryWrite:false` —— 「这一次 run 照常挂、照常读,harvest 不提交」(per-run 只读平面)。
+     *
+     *  🔴 **两键同发不等于买到两件事**(server 亲核 core `prepare-memory.js:48/:55` 后写进契约 §12.7):
+     *  core 把 capture 腿与引擎挂载**合取**,所以 `memory:"off"` 这一 turn 上 `memoryCapture:"off"` 的
+     *  **单向会话记录不落** ⇒ 下一 turn 不带本键时采集照常。要「这个会话永久别记」,那一 turn 就**别**同时发本键。
+     *  ⚠️ 语义如实:这是「不挂记忆面」,**不是**文件系统级禁读禁写 —— 记忆根若落在本次授权的工作区内,
+     *  普通 Read/Write 照走普通围栏(没有记忆面 = 没有记忆写门,不是多了一道禁令)。
+     *  ⚠️ 事实**保留而不是整键缺席**:server 透传为 `TaskSpec.memory.enabled:false`(不是删 spec)⇒ 终局观测面
+     *  把它读作 `disabled` 而不是 `no-spec`,审计上两者不是一件事。
+     *  ⚠️ 与 `GET /v1/capabilities` 的 legacy 能力位 {@link Capabilities.memory}(恒假)**同名不同物**——
+     *  那一位说的是退役的 MemoryStore HTTP 动词族,别按它判断本键可不可用。
+     *  🔴 **无能力位**:7.78.1–7.83.x 可 trial-by-400(拼写门拒),更老的 worker 探不出来(静默忽略)。
+     *  🔴 拼写门**两腿同判、响亮拒**:`"OFF"` / 布尔 / 任何别的值 ⇒ 400 `request.field_invalid`
+     *  (fresh 提交腿与 resume 重放腿共用 server 的 `singleMemberOffFieldIssue` 一只判据;resume 腿折成
+     *  409 `resume_blocked_by_policy`)。与持久 body 一起骑到 resume 腿上。 */
+    memory?: "off";
     /** 🔴 TOB-fleet 透传(core/search AI 2026-06-27,research/toc-settings-adapter/01-design.md §5②)—— fleet/远端模式
      *  把用户 `settings.json`(CC-parity {@link SemaSettings})带给 service;**service** 把它 wire 进引擎同款 seam
      *  (SessionPolicyStore / NodeExecutionEnv / RunnerDeps.hooks),同它做 MF-* 数据契约那层。TOC-local 模式**不走这**
@@ -1945,6 +1977,29 @@ export interface TraceTurn {
  * 走不到的分支,同时把消费端本可以拿到的**编译期穷尽性**弄丢。
  * {@link Settlement} 的 `kind` 与 {@link GateOutcome.origin} 走同一只筛子,同样是这条纪律。
  */
+/**
+ * 🔴 **core 的 `DecisionReason`(含 7.11.0 #619 新加的 `read_only`)**为什么**不在**本 SDK 的型面上
+ * —— cli L-178 / client-core 的镜像票在本版的答复,连同取证坐标一起写在这里,免得下一个人再查一遍。
+ *
+ * core 的 `DECISION_REASONS`(`dist/core/tool-policy.d.ts`:`rule` / `mode` / `hook` / `safety` /
+ * `classifier` / `persisted_rule` / `sandbox` / `org_rule` / `org_unavailable` / **`read_only`**)是
+ * **`PermissionResult` 上的一个键**,而 `PermissionResult` **从不离开引擎**:
+ *  · server 侧成文(`src/governance-ask-marks.ts` 顶注,亲读):`decisionReason` 连同整个 `PermissionResult`
+ *    留在 core 内部,**`AskRequest` 的类型面上也没有这个键**;
+ *  · 对着 server **7.87.0 的发布字节**全树 grep `read_only`,命中只有三处,**没有一处上 JSON wire**:
+ *    两处注释、`trace/core-keyset-guard.d.ts` 的 `permission.read_only_allowed`(那是 **TraceEvent 的 kind**,
+ *    本仓唯一消费点是 `/metrics` 计量)、以及 `observability/permission-rule-events` 的
+ *    `permission_rule_events_total{event="read_only_allowed"}` 标签与它的 HELP 文本(Prometheus 文本面)。
+ * ⇒ 「消费端要镜像的那张表」在这条 wire 上**只有两张**:{@link DeniedBy}(谁拒的,闭集)与
+ * {@link import("./resources/tool-approvals.js").AskOrigin}(谁问的,开集),而 core 7.11.0 **哪一张都没有加员**。
+ * 本 SDK 因此**不铸**一个 `DecisionReason` 型面:那会是一个任何 server 版本都不发的幻影表(本仓幻影键族
+ * 的教训逐字同源),而幻影表比缺席更坏 —— 它让消费端以为有一条读得到的归因通道。
+ *
+ * 🔴 **哪天它真上了 wire,本判据会自己红**:机器钉在
+ * `test/server-787-catchup-wire.test.ts` 的「件⑦b」——它对**已装的 server 发布字节**扫「`read_only` 有没有出现
+ * 在任何 JSON 体铸点上」,并带判别力自证(同一只扫描器必须扫得到真在 wire 上的词)。
+ * ⇒ 上游哪天把它抬上响应体,那一格当天变红,SDK 当批补声明。
+ */
 export type DeniedBy = "policy" | "hook" | "org" | "persisted_rule" | "classifier" | "plan_mode" | "compliance" | "write_protection" | "ask_resolution";
 /**
  * 这一次分类的**模型归属**(core 7.18.0 #742 `AutoModeClassifierRound`,server ≥7.78.0)——「这次 auto 模式
@@ -2216,6 +2271,64 @@ export type WiringManifestLspSeam = {
      *  **缺席 = 两条道都不活**,不是「未知」。 */
     lane?: "tool" | "diagnostics" | "tool_and_diagnostics" | (string & {});
 };
+/**
+ * `wiring_manifest.writeProtection` 段(core 7.20.1 #853 / clay C-R55 丙,**server ≥7.80.1**(S-361 提货批,
+ * 亲核 server CHANGELOG 的版本段;C-R24 去幻觉轮把首版写的 7.81.0 改真);**租户可见**)——
+ * 这条腿的**写保护判官拿到了哪一种目标读法**。
+ *
+ * · `"target"` —— 判官握着执行环境:拼法没命中时会在**解析后的真目标**上再判一次(别名 / 软链够到受保护
+ *   行的写会被清掉);
+ * · `"spelling-only"` —— 没有环境,**拼法就是全部判决**。
+ *
+ * 🔴 **缺席 = 第三态,禁折成 `"spelling-only"`**:core 的段是 **present-iff 编译出了判官**,一台
+ * `writeProtectedPaths: []` 的部署整段缺席 —— 那是「根本没有判官」,与「判官在、只认拼法」是两件事。
+ * ⚠️ 与 `GET /v1/capabilities.writeProtection`({@link WriteProtectionCapability})/ operator 面
+ * `GET /v1/diagnostics/wiring` 的 `writeProtection`({@link WriteProtectionPosture})**同名不同物**:
+ * 那两处是**本 server 装配的名表**(boot 产物,计数 / 逐行);本段是 **core 判官的 per-leg 自述读法**。
+ * ⚠️ `type` 而不是 `interface`:同 {@link WiringManifestMcpEntry} 顶注那条裁定(隐式索引签名)。
+ */
+export type WiringManifestWriteProtection = {
+    /** core 的两词闭集,**开集读**(词表属主在引擎)。 */
+    targetView: "spelling-only" | "target" | (string & {});
+};
+/**
+ * `wiring_manifest.readDeny` 段(core 7.22.0 #889 / C-R60,server ≥7.85.0)——
+ * **这台部署选了哪几档内置敏感路径 deny 表**,而且是**实质激活了行**的那几档。
+ *
+ * 🔴 **operator 受众**:server 只在 **operator 身份**的 `wiring_manifest` 帧上投它(租户面整段剥,
+ * `GET /v1/diagnostics/wiring` 也**不**带它)。所以在租户流上缺席**不构成**「这台部署没开档」的证据。
+ * 🔴 **present-iff 实质激活至少一行**:缺席 = 没有内置行在判这条腿(正面事实),**不是**「没有读被 deny 判」
+ * —— 部署自己的 `READ_DENY_PATTERNS` 刻意不上报(模式文本是部署材料,不是枚举)。
+ * 🔴 **空数组永不发出**(「关」与「开到什么都不判」是同一个事实)⇒ 收到 `[]` 按**坏 producer** 处置。
+ * ⚠️ 档名**不是本层的闭集**:词表属主在 core 的 `READ_DENY_BUILTIN_TIERS`(今天五档
+ * `credentials` / `shell-history` / `browser` / `wallet` / `agent-config`),server 只判「非空串」逐字透传,
+ * 抄一份会把 core 的第六档静默吞成缺席。
+ * ⚠️ **部署面语义自 core 7.22.0 翻面**:`READ_DENY_BUILTIN_TIERS` **未设置 = OFF**(此前缺席走 core 缺省四档)。
+ * ⚠️ `type` 而不是 `interface`:同 {@link WiringManifestMcpEntry} 顶注那条裁定。
+ */
+export type WiringManifestReadDeny = {
+    /** 实质激活了行的档名,按 core 的词表序。**非空**(空数组是坏 producer 的形)。 */
+    builtinTiers: string[];
+};
+/**
+ * `wiring_manifest.autoConsolidation` 段(core 7.21.0 #761,**server ≥7.82.0**(S-362 提货批;同上,首版写的
+ * 7.81.0 是从相邻版本推出来的,已改真))——
+ * **记忆自动整理武装了没有**。
+ *
+ * 🔴 **operator 受众**(与 `governance` / `configFingerprint` 同表同裁):它是**出口事实** —— 武装 =
+ * 每个建议任务之后整库记忆自动外流到整理模型,而且它对调用方**本就不可观测**(整理跑在终局 harvest
+ * 之后、fire-and-forget、宿主侧)。租户流上整段剥。
+ * 🔴 **present-iff 武装**,而且在场形**只有** `{ onRecommendation: true }`(core 的构造期门已拒掉
+ * 「武装但跑不起来」)。**缺席 = 未武装**(正面事实),**禁**读成 `false`、更不是「未知」。
+ * ⚠️ 同一个事实在**会话面**有一格租户可读的孪生:`GET /v1/sessions/:id/memory-status` 的
+ * {@link SessionMemoryStatusResponse.autoConsolidationArmed}(恒在场的真布尔)。一个事实两张脸、
+ * 同源唯一读点 —— 在租户流上读不到本段**不是**「没武装」,那句话去读那一格。
+ * ⚠️ `type` 而不是 `interface`:同 {@link WiringManifestMcpEntry} 顶注那条裁定。
+ */
+export type WiringManifestAutoConsolidation = {
+    /** 字面 `true` —— core 的在场形只有这一个(所以它是**形而不是值**:写得出 `false` 的代码当场编译红)。 */
+    onRecommendation: true;
+};
 /**
  * `context_usage.sections[]` 的**一行**(core 7.18.0 #790,server ≥7.78.0)—— 这条腿的**系统提示词**由哪些
  * 段组成、哪一段大。一条渲染出来的 pack 段一行。
@@ -3308,6 +3421,67 @@ export interface Capabilities {
      *  `null` = 这个进程说不出来(非 composition root 装配的夹具形)。**老 worker 上整键缺席,而「没有这个键」
      *  不是「没有表」** —— 引擎侧座位缺席恰恰是**缺省表在岗**(按键名 grep 推断「没装」会推错,B-023 F2 真案)。 */
     writeProtection?: WriteProtectionCapability | null;
+    /** **本部署默认的 WebSearch 后端**(server ≥7.82.1 / S-382;`routes/capabilities.ts:236` =
+     *  `projectWebSearchCapability(deps.webSearchProvider)`,折词属主 `plugins/web-search.ts:114`)。
+     *  闭集取型自 server 的 `WEB_SEARCH_PROVIDERS`(`plugins/web-search.ts:70`,全仓唯一一张 provider 词表)
+     *  ∪ `"none"`;谓词 = boot 期**真正拿去造后端**的那份 `webSearchConfigFromEnv()` 产物的 provider
+     *  (`boot/stage-07-capability-layer.ts` 一次求值,装配与本位共读)⇒「位说 brave、装的是 tavily」结构上不可能。
+     *  🔴 **`backend:"none"` 与整键缺席处置相反,禁互折**(server 发车帖逐字):`"none"` = **这台机器没有搜索
+     *  后端**(渲「不可用」);**缺席** = 老 server(<7.82.1)⇒ 渲「判不了」。把缺席读成 `"none"` 会让一台
+     *  配好了 searxng 的 7.8x 之前的部署被渲成「没有搜索」。
+     *  🔴 **不出内情**:端点(SearXNG 实例 URL)/ API key / 配额一个字都不在这一位上;每请求
+     *  `settings.webSearch`(单用户车道压过部署座)**刻意不回显** —— 本位广告的是**部署默认**,不随调用方漂。
+     *  ⚠️ 本位**不是**任何端点的开关:搜索缺席时工具整个不装配(模型只说「我没有这个工具」),而那句话在 UX 上
+     *  与「后端配错了」不可区分 —— 本位就是为了让消费端不必跑一次真任务去猜。 */
+    webSearch?: {
+        backend: "brave" | "tavily" | "searxng" | "none" | (string & {});
+        [k: string]: unknown;
+    };
+    /** 会话内 **MCP re-dial** 端点 `POST /v1/sessions/:id/mcp/reconnect` 的在场位(server ≥7.85.0 /
+     *  S-381 / core 7.22.0 #857;`routes/capabilities.ts:264` = `Boolean(deps.runStore) &&
+     *  Boolean(deps.sessionStorage?.ownerOf)`)。谓词类 = **设施依赖**两项合取:持久 run 账面(动词要经 run 行
+     *  找本副本活流)∧ 会话属主面(入站 owner 门 fail-closed,缺它整口 501)—— 两个 501 与本位从**同一批 deps**
+     *  推导 ⇒「说 yes 但 501」结构上不可能。
+     *  🔴 位为真**只**保证端点在场:不保证这一次有活 run(非 live ⇒ 409 `steering.not_running`),更不保证这条 run
+     *  声明过 MCP(未声明 ⇒ **200** `outcome:"unsupported"`,不是错误)。
+     *  ⚠️ 缺席 = 老 worker ⇒ 按 404/405 探,**别渲假入口**。消费面见 {@link import("./resources/sessions.js").SessionsResource.mcpReconnect}。 */
+    mcpReconnect?: boolean;
+    /** 本部署的**执行车道自述**(server ≥7.86.0 / S-426;`routes/capabilities.ts:602` =
+     *  `projectExecutionLaneCapability(deps.config)`,属主 `capabilities/execution-lane.ts:77`)——
+     *  「这台引擎的工具跑不跑在**本机**」第一次由引擎自己回答,消费端不必再用「本壳 spawn ∧ 无远端 URL ∧
+     *  `REMOTE_EXEC`∈{空,host}」这条会漂的旁证三合取(连远端引擎时壳读的 `REMOTE_EXEC` 说的是自己那台的事)。
+     *  · `provider` —— 车道词,闭集取型自 server 的 `RemoteExecProvider`(`execution-lane-caps.ts:50`,
+     *    派生自 `ServiceConfigFlat["remoteExec"]` 判别联合)。**`REMOTE_EXEC` 未设 ⇒ `"host"` 是契约不是兜底**
+     *    (与 `toolsRunOnThisHost` 的缺席读法同源)。⚠️ 代价如实:server 内部另有一个更细的词 `"in-process"`
+     *    (那条 lane **根本没挂手**),本位把它折进 `"host"` ⇒ 消费端分辨不出「本机有手」与「压根没手」;
+     *    要分辨得开是另一条轴,不是把车道词偷偷换义。
+     *  · `toolsOnThisHost` —— 工具跑的那台机器是不是本进程这台(= server 盘上的绝对路径对模型的工具有没有意义),
+     *    属主 = `task-cwd.ts` 的 `toolsRunOnThisHost`,与 `skills[].baseDir` 的铸点**同一只函数**。
+     *  🔴 **蕴含是单向的,别写成等价**(server 侧对抗复审逮到过的那句):`toolsOnThisHost === false` ⇒
+     *  `skills[].baseDir` 恒不发(这一向是承诺);反向**不成立** —— `true` 只是必要条件(扁平形技能
+     *  `skills/<name>.md` 结构上没有自己的目录;插件来源技能走的加载器根本不传那个开关)⇒ `true` 时
+     *  `baseDir` 按 **present-iff** 读,缺席是合法态。
+     *  🔴 **只出词,不出内情**:k8s apiUrl / ssh host / adb serial / 镜像 / 凭据 / `mountPath` 一个字都不上这条 wire。
+     *  ⚠️ 缺席(老 server)**不许读作任一侧** —— 那正是本位来之前消费端只能猜的那个状态。 */
+    executionLane?: {
+        provider: "host" | "e2b" | "k8s" | "ssh" | "adb" | "local-docker" | "device" | (string & {});
+        toolsOnThisHost: boolean;
+        [k: string]: unknown;
+    };
+    /** 本部署的 **审批推送面带不带 live 事件族**(server ≥7.87.1 / S-455,S-454 的消费半场;
+     *  `routes/capabilities.ts:667` = `projectApprovalsStreamLiveCapability(deps)`,判据唯一属主
+     *  `capabilities/approvals-push.ts`)。true ⟺ `GET /v1/approvals/stream` 除 durable park 行外
+     *  还推 `live_pending` / `live_resolved` 两词(与 `GET /v1/approvals` 的 `livePending` 同一只读函数)。
+     *  谓词 = **两项合取**,逐项对着那条腿自己的在场判据:①审批底座(= `approvals` 那一位;`checkpointStore`,
+     *  缺 ⇒ `/v1/approvals/*` 整域 404,连流都没有)∧ ②live 协调器(= `toolApproval` 那一位;
+     *  `TOOL_APPROVAL_ENABLED`,缺 ⇒ 流在、但那条源整个缺席,字节与 S-454 之前逐字相同)。
+     *  🔴 **刻意不合并进 `approvals` 或 `toolApproval`**:`approvals` 为真而本位为假是**常态**(没开工具审批的
+     *  部署);`toolApproval` 为真而无 checkpoint 底座时**根本没有这条流** —— 单读任一位都对一半部署说谎。
+     *  ⚠️ 位为真**只**保证这条源在场:不保证这一次有悬挂 ask,也不保证跨副本可见(live 半场是**进程内投影**,
+     *  与 `livePending` 逐字同限;durable park 行那一半才是跨副本的)。
+     *  ⚠️ 缺席 = 老 server(<7.87.1)⇒ 判不出推面带不带 live 族,**别把「等不到 `live_pending`」读成「这台不推」**
+     *  ——两者在老 server 上不可分,按 `GET /v1/approvals` 的 `livePending` 拉面兜底。 */
+    approvalsStreamLive?: boolean;
     [k: string]: unknown;
 }
 /** 写保护名表的**租户面**窄投影(`GET /v1/capabilities.writeProtection`)。**不含行内容**。 */
@@ -3429,9 +3603,15 @@ export interface ScenarioDetail {
  *      boundCallId+boundInputHash 两件套 —— `ApprovalDecision` 上那个可选 checkpointToken 字段已于 SDK 1.0.0 删除）。
  *  这是 boundCallId/boundInputHash decide 绑定的唯一 surface 处。契约说"可选字段缺则 OMIT 不是 null"。 */
 /** #315(server ≥7.43)—— `GET /v1/approvals` 信封第二顶层键 `livePending` 的行:streamApproval 窗内的
- *  **流内 ask**(此前对轮询消费端结构性不可见)。刻意窄:tool input/args 不列(不开第二道脱敏面,详情
- *  骑 SSE `tool_approval` 帧)。🔴 决议口=`POST /v1/tool-approvals/{approvalId}/respond`,**不是** /decide
- *  (那是 durable 行的门)——数组名即路由判据,两数组不混编。可选旗标 only-if-true(缺席绝不编码成 false)。 */
+ *  **流内 ask**(此前对轮询消费端结构性不可见)。🔴 决议口=`POST /v1/tool-approvals/{approvalId}/respond`,
+ *  **不是** /decide(那是 durable 行的门)——数组名即路由判据,两数组不混编。可选旗标 only-if-true
+ *  (缺席绝不编码成 false)。
+ *
+ *  🔴 **「tool input/args 不列」那条窄化自 server 7.87.0 起作废**(S-454 P1;本行与 spec 的旧描述都是
+ *  当时写下的真话,现在是假话,一并改真):旧理由的原文是「详情走流帧」—— 而**悬挂 ask 永远没有流帧**
+ *  (铸造时刻零投递目标 ⇒ 转悬挂,窗 1h)。对它那条理由结构上不成立,消费方要出卡就必须在这一行上拿到
+ *  卡体,否则「列得到但渲不出」。⇒ 新增 {@link frame},**一视同仁给全部 live 行**(规则集不因 `suspended`
+ *  分叉:有活流的 ask 多带一份它自己那张卡的副本无害)。 */
 export interface LivePendingRow {
     /** 与 respond 端点收的同一个 id(wire uuidv7)。 */
     approvalId: string;
@@ -3448,6 +3628,25 @@ export interface LivePendingRow {
     /** S-52 C2(server ≥7.52,A-075.87)—— 子代 taskId(= core runSourceTaskId,uuid):把这行 ask 关联到
      *  发起它的子代 run 行。与 `fromSubagent` 恒同生同缺(server `listLivePending` 单条件 spread 铸两键)。 */
     originTaskId?: string;
+    /** S-62(server ≥7.6x;铸点 `tool-approval.ts` 的 `listLivePending` 条件 spread,词属主
+     *  `approval-content-kind.ts`)—— **内容问句分型**:被门的工具是 AskUserQuestion 时为 `"content_ask"`。
+     *  与 durable 两读面 / core summarize 面**同一个词**。缺席 = 普通工具 ask。
+     *  ⚠️ 展示/分诊分型用,**永不参与决议路由**(决议口仍是 respond)。 */
+    contentKind?: "content_ask" | (string & {});
+    /**
+     * 🔴 **这只 ask 本来会 emit 的那只活卡帧**(server ≥7.87.0 / S-454 P1;cli L-397)。
+     *
+     * 值 = server `PendingApproval.frame` 的**同一个对象**(`askBroadcast` 里那一处唯一构造,已过脱敏 /
+     * 字节帽 / 窗三键补写)—— 悬挂与可达两条路共用它。⇒ 这一格**不是**为列表另算的第二份卡投影:
+     * 一处脱敏属主不变、零第二脱敏面。
+     * 🔴 **`frame.approvalId === row.approvalId` 恒成立**(server 7.87.0 合并复审验真后的不变式):同一只 ask
+     * 被重复悬挂登记且首登记被取消时,帧上的 id 曾指向已死的首登记(照它 respond ⇒ 404)。现在不等时 server
+     * 交一份把 id 对齐到本行的浅拷贝 ⇒ **永远照 `row.approvalId`(或等价地 `row.frame.approvalId`)决断**。
+     * 🔴 **缺席 = 老 server(≤7.86.0)**;7.87.0 起**恒在场**(条目上是必填格),恒不铸 `null`。
+     * ⚠️ 帧里带 **tool input/args**(这正是本键存在的理由);它与 SSE 上那一帧**同源同字节**,消费端拿它出卡
+     * 即可,别再去重算一份摘要。
+     */
+    frame?: ToolApprovalFrame;
 }
 /** S-02(server ≥7.52)—— decide 409 `approval_stale` 拒体的 additive 指路键 `currentPending`:本会话
  *  **当前** pending 的三件 D-1 坐标(与 §7b 队列行同名同形),壳一跳重定位免整队重拉。🔴 恒不含
@@ -3734,6 +3933,92 @@ export interface McpStatusPanel {
     };
     [k: string]: unknown;
 }
+/**
+ * `POST /v1/sessions/:id/mcp/reconnect` 的 `status` 段(server ≥7.85.0 / S-381;铸点
+ * `src/http/routes/mcp-reconnect.ts` 的 `projectStatus`)—— core `McpServerStatus` 的**本面投影**。
+ *
+ * ⚠️ **与 {@link McpServerStatus}(`/mcp` 面板那一份)是同一个 core 型的两次投影,键集不同,刻意不合并**:
+ * 面板只投 `{name, status, serverInfo?, toolNames?, error?}`,本面多投 `errorCode` / `httpStatus` /
+ * `delivered` / `transportClosed` 四位。把它们并成一个类型 = 让面板的消费端去等四个永远不来的键。
+ *
+ * 🔴 **下一步动作按本段的机器面,不解析 {@link reason}**:`errorCode`(core 的 `McpFailureKind` 词表,
+ * **属主在引擎,不在此枚举收窄** ⇒ switch 必须带 default 臂)与 `httpStatus`(401 = 一扇重新授权的门)
+ * 才是可分支的东西。
+ */
+export interface McpReconnectServerStatus {
+    name: string;
+    status: "connected" | "failed" | (string & {});
+    /** core 的 `McpFailureKind` 词(`spawn_failed` / `http_status` / …)。开集 —— 词表属主在引擎。 */
+    errorCode?: McpFailureKind;
+    /** 只与 `errorCode === "http_status"` 同行(401/403 去重新授权,5xx 是那头挂了)。缺席而不是 0。 */
+    httpStatus?: number;
+    /** 请求到没到那台服务器 —— 与 {@link errorCode} **合读**。 */
+    delivered?: McpDelivered;
+    serverInfo?: {
+        name: string;
+        version: string;
+    };
+    /** 远端作者文本:server 已 `redactSecrets` + 截 200 字符。**人读,不解析**。 */
+    error?: string;
+    /** 这条传输是不是已经关了(重拨之前的旧连接恒先关 —— 见 {@link SessionMcpReconnectResult} 的「一次交易」)。 */
+    transportClosed?: boolean;
+    [k: string]: unknown;
+}
+/**
+ * `POST /v1/sessions/:id/mcp/reconnect` 的 200 体(server ≥7.85.0 / S-381 / core 7.22.0 #857;
+ * 铸点 `src/http/routes/mcp-reconnect.ts` 的 `projectResult`)。
+ *
+ * 🔴 **一次交易,不是一个「刷新」按钮**(core 原话,必须进 UI 文案):旧连接在拨新号**之前**就被关掉
+ * (对拥有设备/端口的 stdio server 没有别的顺序可用)⇒ **一次失败的重拨花掉一条能用的连接**:server
+ * 留在断线、**它的工具从模型名册撤走**、在飞调用随之失败。在一台**健康**的 server 上点「重连」= 做一次交易。
+ *
+ * 🔴 **`outcome` 是唯一判别键,三态全部走 200**:HTTP 状态只回答「动词有没有到达引擎」(与 steer 回执
+ * 「branch on `delivery`, not the status」同一条律)。
+ *  · `accepted` —— core 的 `reconnected`;
+ *  · `refused` —— core 的 `refused` **或** `not_declared`(未知 server 名是**名册事实**,不是引擎能力事实);
+ *  · `unsupported` —— **server 自己的词**(core 无此词):这条 run **没有声明任何 MCP**(core 抛
+ *    `mcp.reconnect_unavailable`)。这一臂是**恒五键体** `{taskId, sessionId, server, outcome, reason}` ——
+ *    没有 core 结果 ⇒ `prefix` / `toolCount` / `added` / `removed` / `toolNames` **一个都不铸**。
+ *    ⇒ 消费端**必须**按 `outcome` 分支,**不许**无条件读 `body.added`。
+ *
+ * 🔴 `toolNames` 按 **`tools` 的在场性** present-iff(不按 `outcome`):`[]`(拨号失败)与**缺席**(没碰过
+ * 连接的臂)是两句不同的话。⚠️ 它是「这次重拨对自己 `prefix` 域断言的那份名册」,**不是**「模型最终看得见
+ * 的那份」—— core 在挂载前还按部署的排除表滤一道,axis-fold 被拒时一只都没挂 ⇒ 本键在两种形下都是**超集**。
+ * 要「真挂上了什么」读名册面(`wiring_manifest.tools` / `GET /v1/sessions/:id/mcp`)。
+ */
+export interface SessionMcpReconnectResult {
+    /** 承载这次重拨的那条活 run(= 本会话的 active run;拿它去 `GET /v1/runs/:id/events` 跟)。 */
+    taskId: string;
+    /** 路径段的回显(已 percent-decode)。 */
+    sessionId: string;
+    /** 被重拨的那台具名 server(请求体里送的那个字符串)。 */
+    server: string;
+    /** 三态判别键(见顶注)。开集读:server 将来加词 ⇒ 落 default 臂,别当成失败。 */
+    outcome: "accepted" | "refused" | "unsupported" | (string & {});
+    /** 该 server 的工具名前缀域。`unsupported` 臂**恒缺席**。 */
+    prefix?: string;
+    /** 重拨后该域的工具数。`unsupported` 臂恒缺席;**缺席而不是 0**。 */
+    toolCount?: number;
+    /** 这次重拨新挂上的工具名。 */
+    added?: string[];
+    /** 这次重拨撤下的工具名。 */
+    removed?: string[];
+    /** 本次对该 `prefix` 域断言的整份名册(present-iff core 给了 `tools`;见顶注的超集警告)。 */
+    toolNames?: string[];
+    /** 人读的一句话(server 已脱敏 + 截 200 字符)。**不许解析** —— 可分支的东西在 {@link status}。 */
+    reason?: string;
+    /** 这台 server 重拨后的状态段({@link McpReconnectServerStatus})。 */
+    status?: McpReconnectServerStatus;
+    /** 「这次走名册没走完」—— 在场即**别把 {@link toolNames} 当全集**。`reason` 是 core 的词,`pages` 是走过的页数。 */
+    listingIncomplete?: {
+        reason: string;
+        pages: number;
+        budgetMs?: number;
+        error?: string;
+        [k: string]: unknown;
+    };
+    [k: string]: unknown;
+}
 /** S-53(server ≥7.53;core 7.0.2 #511 件1 / design/383 §S-7)—— core 导出 `SessionMemoryStatus` 的**同名同形**
  *  镜像(`dist/core/memory-engine/engine.d.ts:804`,五键全可选,闭集)。🔴 缺席是诚实答案不是默认值,但**缺席的
  *  含义逐键不同**(codex R1 验真后订正,依据=亲读 `engine.js sessionMemoryStatus`,不是 d.ts 顶注的一揽子句):
@@ -3764,6 +4049,20 @@ export interface SessionMemoryStatus {
 export interface SessionMemoryStatusResponse extends SessionMemoryStatus {
     /** 状态所属会话(路径段的回显,已 percent-decode)。 */
     sessionId: string;
+    /**
+     * **这台部署的记忆自动整理武装了没有**(server ≥7.85.0 / S-403 / core 7.22.0 #863 W1;铸点
+     * `src/http/routes/sessions.ts:744` = `deps.memoryAutoConsolidationArmed`,boot 期由 core 的**唯一读法**
+     * `autoRunOnRecommendationEffective` 算一次)。
+     *
+     * 🔴 **它不是本面那五键的同族**:那五键是 core `sessionMemoryStatus` 的**会话级**推导(缺席各有含义),
+     * 本键是**部署级事实**,在 ≥7.85.0 上**恒在场**的真布尔。缺席 ⇒ 老 worker(<7.85.0),读「不知道」,
+     * **禁折成 `false`** —— 那会把一台正在把整库记忆自动外流给整理模型的部署渲染成没在外流。
+     * 🔴 语义如实:`true` = 一次越过阈值的终局 harvest 会**自动跑**一次宿主整理(记忆内容自动外流到所配模型),
+     * 与「这个会话采不采集」({@link SessionMemoryStatus.captureOptedOut})是**两件事**,别合读。
+     * ⚠️ 同一个事实在 operator 的 `wiring_manifest.autoConsolidation` 段上也读得到(present-iff 武装);
+     * 两处**同源唯一读点**,租户面只有本键。
+     */
+    autoConsolidationArmed?: boolean;
 }
 /** ONE session-tree entry as it crosses the sync wire — the SDK treats it as an OPAQUE payload (verbatim,
  *  cross-backend stable ids/parents). It is core's `SessionTreeEntry`; the SDK only ever reads `.id` (for the
@@ -3917,6 +4216,86 @@ export interface LeaderReceipt {
     leaderRunId: string;
     status: "running" | "completed" | "failed";
 }
+/**
+ * `GET /v1/leader/:id` 的 `result` —— leader run 的**终局载荷**(server `leader/leader.ts` 的 `LeaderResult`)。
+ *
+ * 🔴 本型**只镜像消费端真要渲染的那几段**,其余按开集透传(索引签名):leader 是 gated 的 v2 车道,
+ * 整只结果里还有 `reports` / `merge` / `repairTerminal` 等 server 内部形,把它们一次抄进来只会造出一份
+ * 会各自漂的镜像。**声明了的段就是承诺,没声明的段照读不误**。
+ *
+ * 🔴 **S-113 / clay C-R63 ④(server ≥7.83.0):合不上 = 交给用户**(对齐 CC 形)。merge 的 apply 冲突不再
+ * 起 collapse 模型:`ok:false` + {@link conflict} 段,run 状态走既有的第三终局 `needs_human`
+ * ({@link LeaderRecord.status},**不加新状态词**)。用户拿 `workers[].branch` + `files` 自己 merge /
+ * cherry-pick。**同批两键整删、零别名**:`merge.conflictsResolved` / `conflictResolverCostUsd` 没了,
+ * `replan.trigger` 闭集删掉 `"merge-conflict"` —— 读它们的消费端当天 tsc 红,那就是通知。
+ */
+export interface LeaderRunResult {
+    /** 这一趟整体成不成(冲突终局恒 `false`)。 */
+    ok?: boolean;
+    /**
+     * **合不上**的那一趟(server ≥7.83.0;铸点 `leader/leader.ts` 的 `conflictSegment` —— 主路与 collapse 路
+     * **共用这一只**,所以「同一情形两种终局」结构上不再可能)。
+     * 🔴 **缺席 = 这一趟没有冲突,或对面是老 server**(两者同形,别按缺席反推版本)。
+     */
+    conflict?: {
+        /** 用户侧的合并基点 = leader 这一趟的 durable base(拿它 `git checkout` / `git merge`)。 */
+        baseSha: string;
+        /** 有冲突标记 / `.rej` 的路径清单(**不含内容**)。 */
+        files: string[];
+        /**
+         * 清单**被上限截断**时才在场。
+         * 🔴 **缺席 ≠「这就是全部」**(9.7.0 改真;codex 对抗复审 [medium] 验真后亲读 server `leader/merge.ts`
+         * 的探测臂):本位只反映**上限**这一种不完整。清单是两条 shell 探测腿拼出来的(`grep -rIl` 找冲突标记 +
+         * `find -name '*.rej'`),**任一腿失败时 server 如实给出一份可能为空/残缺的 `files`,只在自己的日志里
+         * 留一行 `merge_conflict_files_probe_failed`** —— wire 上**没有**这一形的判别位。
+         * ⇒ 消费端读法:`conflict` 段在场而 `files` 为空(或看起来不合常理地短)**不许**渲成「零冲突文件 / 就这几个」;
+         * 渲「清单不可得或可能不全」,让用户按 {@link rejHead} 与 `workers[].branch` 自查。
+         * (要一个能分辨「探测失败」与「真的没有更多」的位,属主是 server —— 本包不自造第二个判官。)
+         */
+        filesTruncated?: true;
+        /** **全部 completed worker** 的分支;`applied:false` = 这只 worker 的补丁没进树(冲突者本人,或排在它
+         *  后面还没轮到 apply 的 —— 顺序 apply,首次失败即停)。分支取自登记表,**恒有值**(用户要拿它 checkout)。 */
+        workers: Array<{
+            workerId: string;
+            branch: string;
+            applied: boolean;
+        }>;
+        /** `.rej` 头(经 server 既有工件脱敏面,≤2 KiB)—— 给人看冲突长什么样,**不是**给机器 parse 的。 */
+        rejHead?: string;
+        [k: string]: unknown;
+    };
+    /**
+     * 没能并进树的那些 worker 的补丁(best-effort、**非空才在场**)。
+     * 🔴 **7.83.0 起冲突终局下含「全部」worker 的补丁**(此前只含未完成者):集成沙箱在 `finally` 里销毁,
+     * 分支**不一定**还在远端 —— 所以补丁本身就是交付物,消费端该给用户一个落盘的口子。
+     * ⚠️ `patch` 是 **worker 写的代码**(不可信文本):渲染/落盘可以,**别回喂模型**。
+     */
+    salvaged?: Array<{
+        workerId: string;
+        sessionId: string;
+        patch: string;
+        [k: string]: unknown;
+    }>;
+    /** 被挂起 worker 的 resume 句柄(C4;checkpoint 与暂停环境完好)。 */
+    suspended?: Array<{
+        workerId: string;
+        sessionId: string;
+        [k: string]: unknown;
+    }>;
+    /** 路由选择:`single` = 单子任务计划,`fanout` = N 个。 */
+    route?: "single" | "fanout" | (string & {});
+    /** fan-out 之前的规划/备机失败。 */
+    error?: string;
+    /** Replan-lite:哪个触发赢了仲裁 + 做了什么。
+     *  🔴 **闭集自 7.83.0 起删 `"merge-conflict"`**(S-113 硬 breaking,零别名):合不上从此不重规划,交用户。 */
+    replan?: {
+        trigger?: "suspended" | "budget" | "verify-fail" | "worker-failed" | (string & {});
+        redispatched?: string[];
+        collapsed?: string;
+        [k: string]: unknown;
+    };
+    [k: string]: unknown;
+}
 export interface LeaderRecord {
     id: string;
     /** 🔴 facade 审计(2026-07-24,批次②-7):server leader/endpoint.ts:21-27(权威 `LeaderRun` 类型 + wire
@@ -3924,6 +4303,10 @@ export interface LeaderRecord {
      *  loop/merge push 卡点主动弃权(候选被判 candidate_only/needs_human_oracle/conflict 之一,held 住
      *  push、留证据给人看),语义上不是「跑失败了」而是「需要人来看」——与 failed 混同会误导重试/告警逻辑。 */
     status: "running" | "completed" | "failed" | "needs_human";
+    /** leader run 的终局载荷。**形是 {@link LeaderRunResult}**(server ≥7.83.0 起含 `conflict` / `salvaged`
+     *  两段),这里**刻意仍是 `unknown`**:把它就地收窄是 RELEASE.md 第 14 行意义上的收窄(= major),而
+     *  本键的消费端今天全部走 `as`;下一个 major 再把它指过去(已登记为 9.7.0 的未闭环项)。
+     *  读法:`const r = record.result as LeaderRunResult`,然后按 `r.conflict` / `r.salvaged` 分支。 */
     result?: unknown;
     error?: string;
 }
@@ -4098,12 +4481,33 @@ export interface AssistantTask {
     createdAt: string;
     updatedAt: string;
 }
-/** §4c plan_review 请求体（3-state）。editedPlan 仅 decision==="edit" 时必带, 其余禁带（→ 400, BFF 也会守）。 */
+/** §4c plan_review 请求体（3-state）。editedPlan 仅 decision==="edit" 时必带, 其余禁带（→ 400, BFF 也会守）。
+ *  🔴 **体键是闭集**(server ≥7.86.0 / S-438):受理集之外的顶层键 ⇒ 400 `request.body_shape` + `unknownKeys` /
+ *  `unsupportedKeys` 两张机读表(拼错的 `permissionModeAfter` 从此响亮拒,而不是静默丢掉一条安全轴的表态)。 */
 export interface PlanReviewRequest {
     decision: "approve" | "edit" | "reject";
     /** operator 改写后的 plan; REQUIRED iff decision==="edit", 否则禁带。 */
     editedPlan?: string;
     reason?: string;
+    /**
+     * 🔴 **批准计划之后这条 task 继续跑在哪一档权限模式**(server ≥7.86.0 / S-433 P1;铸点
+     * `routes/approvals-assistant.ts:1021/1024/1148`)—— 在这一位之前,plan 模式的「批准」是一张**空头支票**:
+     * 计划批了,可写工具仍然逐次征询,只读钳没有解除。
+     *
+     * · `"acceptEdits"` —— 批准后按「接受编辑」跑(写不再逐次征询);
+     * · `"default"` —— 批准后仍每次写都征询(**= 缺席时的折叠值**,所以老壳一行不改也能执行计划)。
+     * 🔴 **闭集只有这两个词**:`"plan"` / `"bypassPermissions"` 之类一律 400 `request.field_invalid`
+     * (零宽臂 —— 这一位选的是批准之后模型有没有手,把拼错的词折成任一档都是安全轴上的静默降级)。
+     * 🔴 **只配 `approve`**:`edit` / `reject` 带它 ⇒ 400 `request.field_conflict`(core 定:那两态送回去重做
+     * 计划,只读保留;在那里静默丢掉它,调用方会以为自己已经把模式说定了)。
+     * 🔴 **只对以 `permissionMode:"plan"` 提交的 task 成立**:该 task 当初不是 plan 模式 ⇒ 400
+     * `request.field_conflict`(「批准计划解除不了任何只读限制」)。
+     * ⚠️ 它**不是**一个能顺带关掉征询面的旋钮 —— 两个词之外没有第三档。
+     * ⚠️ **直连门部署**:本键进 HMAC 信封的**尾位扩展对象**(server 7.87.0 起 `{answer?, permissionModeAfter?}`,
+     * 在场键按字典序;7.86.0 的裸尾位形已删、零双读)⇒ 签名器必须按新形签,混版两向皆 401。
+     * ⚠️ 键名定谳 `permissionModeAfter`(任务书曾写 `nextPermissionMode`,从未上过发布版,**零别名**)。
+     */
+    permissionModeAfter?: "default" | "acceptEdits";
 }
 /** §4b/§4c/§4d 决策端点的返回。status 形如 "completed"|"failed"|"suspended"|"needs_review"|"preempting"|…
  *  —— 开放串, 不窄化。🔴 facade 审计(2026-07-24,SDK 全量核查批次②-9):此前只声明 `{status}` 一个字段,
@@ -4144,6 +4548,17 @@ export interface AssistantTaskStatus {
  * (core 的契约:no projection ⇒ do not disclose),两处待遇不同不是 drift,是同一条规则的两侧。
  *
  * 开集读法:每一段都可能随 core 增键;按已知键分支,忽略其余。
+ *
+ * 🔴 **一条规则管所有「effective 半场 only」的键**(9.7.0 立,codex 对抗复审 [high] 验真后收成这一句,
+ * 而不是给新加的三段各写一条特例):本型**今天唯一的消费点**是 `GET /v1/diagnostics/wiring` 的 `static`
+ * 半场,而标了「只在 effective 半场铸」的键(`leg` / `ask.effective` / `configFingerprint` / `tools` /
+ * `hooks` / `lsp` / `modelGate` / `autoMode` / `writeProtection` / `readDeny` / `autoConsolidation`)
+ * 在这条 wire 上**恒缺席** ⇒ **它们在本面上的缺席不携带任何信息**。
+ * 每一段顶注里写的那些「缺席 = 未武装 / 缺席 = 第三态」的读法**只对 live 帧成立**(`AgentEvent` 的
+ * `wiring_manifest` 臂),**不许**搬到这条端点的响应上来读 —— 在这里把缺席读成「未武装」,恰恰会把一台
+ * 正在自动外流记忆的部署渲成没在外流。要读那几件事:租户面读
+ * `GET /v1/sessions/:id/memory-status` 的 {@link SessionMemoryStatusResponse.autoConsolidationArmed};
+ * operator 面订阅那条腿的 live 流(治理段与这三段只在**知道调用方身份**的 live 投影上才有)。
  */
 export interface WiringManifest {
     schemaVersion?: number;
@@ -4251,6 +4666,20 @@ export interface WiringManifest {
         armed: boolean;
         reason: string;
     };
+    /** core 7.20.1 #853(clay C-R55 丙),server ≥7.80.1 —— **租户可见**:这条腿的写保护判官拿到了哪种目标读法。
+     *  段形单源见 {@link WiringManifestWriteProtection}(那里的三态读法是 **live 帧**的读法)。
+     *  🔴 **effective 半场 only ⇒ 本面恒缺席**,这里的缺席**不携带任何信息**(见本型顶注那条统一规则)。 */
+    writeProtection?: WiringManifestWriteProtection;
+    /** core 7.22.0 #889 / C-R60,server ≥7.85.0 —— **operator 受众**:这台部署实质激活了哪几档内置读 deny 表。
+     *  段形单源见 {@link WiringManifestReadDeny}(present-iff / 空数组的读法是 **live operator 投影**的读法)。
+     *  🔴 **effective 半场 only,且 server 显式裁定本诊断端点不带它** ⇒ 本面恒缺席、缺席不携带任何信息。 */
+    readDeny?: WiringManifestReadDeny;
+    /** core 7.21.0 #761,server ≥7.82.0 —— **operator 受众**:记忆自动整理武装了没有。
+     *  段形单源见 {@link WiringManifestAutoConsolidation}(present-iff 武装的读法是 **live operator 投影**的读法)。
+     *  🔴 **effective 半场 only ⇒ 本面恒缺席**:在这条端点上**禁**把缺席读成「未武装」(那会把一台正在自动
+     *  外流记忆的部署渲成没在外流)。这台部署武装没武装,租户面读
+     *  {@link SessionMemoryStatusResponse.autoConsolidationArmed}(恒在场的真布尔)。 */
+    autoConsolidation?: WiringManifestAutoConsolidation;
 }
 /** core `ToolRoster`(design/388 B-4)—— 一条腿的工具名册。**顶层四键逐键镜像**;`entries[]` 的行只镜像身份 /
  *  出身 / 轴 / 面几组消费端会读的键,其余按开集读(core 给行加键不该把消费端编译炸掉;属主是 core 的 typebox