@sema-agent/sdk 13.1.0 → 15.0.0

package/dist/types.d.ts

@@ -555,7 +555,22 @@ export interface TaskRequest {
      * 顶层键闭集)—— 两形都按 `fileHistoryCapture === "on-optional"` 判再发。
      */
     fileHistory?: "disabled";
-    /** 🔴 PERMISSION MODE INTENT — the TOB-fleet server's five accepted wire values: `default` | `plan` |
+    /** 🔴 **K-32 扩项 —— server ≥7.106.0(S-877 / core 7.34.0 design/1111「一只权限模式」)先读这一段;下面的长段描述的是 ≤7.105.0。**
+     *  · 生效模式**原样过境**给引擎(`TaskSpec.permissionMode`),本服务的「模式 → shellGate / writeFace 档」翻译表整表退役;引擎在**每一种**模式下
+     *    给全权 shell 装形状档、按模式 × 类仲裁表({@link AskClass})裁决每一只 ask。
+     *  · **ABSENT(两个载体都不带模式)= `default`**(不再是「无门」):非只读 shell 命令与每一次写先问;有审批席 / durable park 的腿上是卡,无人应答的
+     *    腿上 headless 拒(拒句点名 `permissionMode:"acceptEdits"` / 接审批席)。要旧的「不问」就显式发 `acceptEdits`(工作区内写不问)或
+     *    `bypassPermissions`(托管部署 422 `request.host_posture_refused`)。
+     *  · `bypassPermissions` **放行并披露**可放的九类 ask(写保护、根外读探针、MCP / A2A 工具标记、transcript 写、规则店读不出〔安全轴 fail-open,单列〕、
+     *    他人共享 artifact 读、模式自己的问、普通 / 形状层的问)—— 逐调用记在 `tool_end.gate.disposition.released`({@link ModeRelease}),每 (模式, 类)
+     *    每 run 一帧 `engine_notice` `permission.ask_released_by_mode`;免疫类(部署出身 `operator_forced`、ask / org 规则、hook、祖先、问答 …)照问。
+     *    判不出保护目标的写仍拒(`deniedBy:"mode"`)。
+     *  · `auto` 武装 ⟺ `permissionMode === "auto"` ∧ 部署挂了分类器席 ∧ `caps.autoMode !== false`(单极;答旧极性的那一位 server 7.107.0 起删,
+     *    读 `capabilities.permissionModeAuto.armed` / `reason`)。请求的模式没生效 ⇒ 流上一帧 `engine_notice` `config.permission_mode_unavailable`(`effective` 恒 `default`)。
+     *  · 词表:请求面**五词**(本型 = {@link PermissionMode} 去掉 `dontAsk`);`dontAsk` fresh 提交 400 `request.field_invalid`(S-902,票 7.107.0)。
+     *  ⚠️ 下文「omit ⇒ NO mode-derived gate」「`auto` 与请求词无关、按 principal 授权武装」「bypass adds NO mode-derived ask gate」三句只对 ≤7.105.0 成立。
+     *
+     *   🔴 PERMISSION MODE INTENT — the TOB-fleet server's five accepted wire values: `default` | `plan` |
      *  `acceptEdits` | `bypassPermissions` | `auto` (post-[816]/[820]/[822] current state; server task-settings.ts
      *  `SettingsPermissionMode` is the same closed set, same-batch aligned 2026-08-05 via server.ts submit-gate
      *  commits 0c39959/ff62de6). NOT a claim that these are CC's/sema-cli's complete mode vocabulary — that
@@ -587,7 +602,7 @@ export interface TaskRequest {
      *  gate at all" (the SAME posture as `bypassPermissions`) is true only when NEITHER carrier supplies a mode. A
      *  caller that wants the manual-ask posture must send `"default"` on at least one carrier — omitting both is
      *  NOT equivalent to sending an explicit `"default"` on either. */
-    permissionMode?: "default" | "plan" | "acceptEdits" | "bypassPermissions" | "auto";
+    permissionMode?: Exclude<PermissionMode, "dontAsk">;
     /** 🔴 **READ 容纳面(`readFace` / READ deny 表)不在这条请求面上** —— 2026-08-16 亲读 server 7.25.0
      *  实况定界(不是「SDK 还没跟上」,别照着 core 的 `TaskSpec.readFace` 在这里手拼一个键):
      *   · **接收面 = 部署席,单腿 env**:`READ_FACE`(`open`|`roots`,坏词启动期响亮拒)/ `READ_DENY_PATTERNS`
@@ -729,12 +744,28 @@ export interface TaskRequest {
      *  ⚠️ **辖域**:A2A 入站面(`message/send`)**不承载本键** —— 那条腿的提交体是服务端从协议消息重建的
      *  闭四字段,消息里放这个键**无效且不报错**,名册照旧。A2A peer 要零工具面就走 skill 路由。 */
     excludeAllTools?: true;
-    /** server ≥7.93.0(core 7.26.0 #1000;client-core CC-116 装配口):宿主对这个 run 的**审批姿态声明**——
-     *  「这些卡由我自己自动答」。一个词 `"bypass"`,闭集属主在引擎(`ApproverPosture`),本仓只镜像 wire 拼写。
-     *  🔴 **它不授权任何东西、不是一只门**:引擎只把它渲给模型,没有裁决腿读它;与 `permissionMode:"bypassPermissions"`
-     *  不是一回事、不能互相派生(后者选门的形状且只能收紧,前者只说谁来答卡)。server 零判据原样过境,不认识的词由
-     *  引擎响亮拒(`config.*` 族码)。老 server(≤7.92.2)把它当未知顶层键 400 `request.body_shape`(trial-by-400 探测路)。 */
-    approverPosture?: "bypass";
+    /** **host 车道的 shell 继承多少用户环境**(K-32 扩项;server ≥7.106.0 / S-895,core design/1159 C-R179 ②;契约 §18;真源发布字节
+     *  `dist/http/wire-types.d.ts` 提交体同名成员 + `dist/request-value-closure.js` 的 `INHERIT_ENV_WORDS` / `inheritEnvFieldIssue`)。
+     *  闭集两词(名单形 `string[]` **不上 wire** —— 那是嵌入方构造执行环境的选项):
+     *  · `"all"` —— 这条请求的模型驱动 host shell 继承这台机器的**整份**环境(`{ ...process.env }` 逐字,CC 交互形);
+     *  · `"scrub"` —— 缺省清洗(剥凭据形变量),**任何车道、任何部署都受理**(它就是缺省)。
+     *  **缺席 = 缺省清洗,并清掉本会话上一条请求留下的声明**(不粘:这一位是「本条请求要什么」,与 `cwd` 的「缺席留旧值」刻意不同)。
+     *  🔴 判决(fresh 提交三口 `POST /v1/tasks` · `/v1/tasks/stream` · `/v1/runs` 同判):
+     *   · 词表外 ⇒ 400 `request.field_invalid`(句点名两词);
+     *   · 非 host 车道(e2b / k8s / local-docker / ssh / adb / device / in-process)带 `"all"` ⇒ 400 `request.field_invalid`
+     *     「applies to the host lane only」(`"scrub"` 照受理);`"all"` 而部署不接 authorizer(无会话)⇒ 400 `request.field_invalid`;
+     *   · 托管部署(`REQUIRE_PRINCIPAL=true`)× `"all"` ⇒ **422 `request.host_posture_refused`**(与写容纳面那条腿同码同状态;
+     *     射程读同一只 `hostPostureDeclarationsHonored`,**不**读 `TASK_WRITE_FACE_ESCALATION`)⇒ {@link import("./errors.js").APIError}
+     *     按码分支,出路 = 删键或改发 `"scrub"`;
+     *   · 续跑腿(revive / `/decide` / 抢占 / 唤醒)重放盘上的体照判,折 `409 resume_blocked_by_policy`
+     *     ({@link import("./errors.js").ResumeBlockedByPolicyError},`blockedBy` 点名原码);
+     *   · **老 server(≤7.105.0)⇒ 400 `request.body_shape`**(未知顶层键,`unknownKeys:["inheritEnv"]`)—— 按版本不发。
+     *  🔴 **事先读数 = {@link Capabilities.projectContext}**(host 车道 ∧ 非托管,与本键的车道门 + 射程门逐组合相等);**别拿
+     *  {@link Capabilities.taskWriteFaceOpen} 当读数**(它另合了 `TASK_WRITE_FACE_ESCALATION` 与 `AUTONOMY` 两半,在「托管 + 旋钮 allow」
+     *  「单用户 + `AUTONOMY=read-only`」两形上与本键的兑现相反)。
+     *  ⚠️ 残余(server 如实登记,S-908):绑定按**会话**键控、在 run 认领之后写(被拒的请求零写);无 run 店的部署上同会话并发受理的
+     *  两条 run 之间「最后写者赢」—— 同会话别并发提交不同的 `inheritEnv`。委派子代的 shell 照缺省清洗。 */
+    inheritEnv?: "all" | "scrub";
     /** server ≥1.221 (core 1.314): DEFERRED DISCLOSURE list — the named MOUNTED tools (built-ins included)
      *  ride the wire as a placeholder (schema bytes out of the cache prefix) and materialize via ToolSearch
      *  on demand. The carrier for the shell's "Workflow on by default but not exposed" posture. Same
@@ -2133,7 +2164,12 @@ export interface TraceTurn {
  *    core 7.9.0 #625 持久规则三态起可达)。它是 `org` 的**个人店同胞**:与 `org` 同属「可以否掉一次人已经
  *    给过的批准」的复查层(改过的命令会被重判),所以既不是 `policy` 也不是 `ask_resolution`;
  *  · `classifier` —— auto 模式分类器**直接**拒(它的 ASK 侧角色是 `origin: "denial_limit_fallback"`);
- *  · `plan_mode` —— plan 模式对写工具的只读拦阻;
+ *  · ⚰️ `plan_mode` —— **退役词**(server ≤7.105.0 / core ≤7.33.x):plan 模式对写工具的只读拦阻。core 7.34.0 design/1111 把模式裁决收成
+ *    一只仲裁表,这一格并进 `mode`(server 7.106.0 起不再发出;`permission_denied_total{deniedBy}` 同换标签)。本包支持地板(3.0.0)之内的老
+ *    server 真会发它 ⇒ 留在闭集里(同 `fileHistoryCapture` 的 `on-always` 先例),登记 `test/_keyset-divergence.ts` `DENIED_BY_RETIRED_WORDS`,
+ *    删除条件 = 支持地板抬过 7.106.0;
+ *  · `mode` —— **权限模式自己的拒**(server ≥7.106.0 / core 7.34.0):`dontAsk` 把一只无人在场可答的问变成拒、`bypassPermissions` 拒一次
+ *    判不出保护目标的写(`write_protection_unresolved`)。同臂必带 `mode` / `askClass` / `classes`(core 不变量 I8,见 {@link GateDisposition});
  *  · `compliance` —— 合规的调用期锁;
  *  · `write_protection` —— 一次被批准的编辑被限制链改写到了**没有任何审批覆盖**的写保护路径上;
  *  · `ask_resolution` —— 这次 ask 的**结算本身**就是拒(有人说了不 / 窗到期 / 没人可问……),细节在
@@ -2168,10 +2204,50 @@ export interface TraceTurn {
  * 在任何 JSON 体铸点上」,并带判别力自证(同一只扫描器必须扫得到真在 wire 上的词)。
  * ⇒ 上游哪天把它抬上响应体,那一格当天变红,SDK 当批补声明。
  */
-export type DeniedBy = "policy" | "hook" | "org" | "persisted_rule" | "classifier" | "plan_mode" | "compliance" | "write_protection" | "ask_resolution"
+export type DeniedBy = "policy" | "hook" | "org" | "persisted_rule" | "classifier"
+/** ⚰️ 退役词(server ≤7.105.0):见上方注。 */
+ | "plan_mode" | "compliance" | "write_protection" | "ask_resolution"
 /** core 7.25.0(#945 读站)/ server ≥7.92.0:shell 读站拒的——拒表路径命中(D 路,审批之前)或已批改写重判到拒表行
  *  (V 路,与 `settlement.kind: "human_allowed"` 并排);可否决(`DENIED_BY_MAY_VETO`),不带 `cause`。 */
- | "read_boundary";
+ | "read_boundary"
+/** server ≥7.106.0(core 7.34.0 design/1111):模式自己的拒 —— 同臂 `mode`(`dontAsk` / `bypassPermissions`)+ `askClass` + `classes`。 */
+ | "mode";
+/**
+ * 权限模式词(core 7.34.0 `PERMISSION_MODES`,六词;K-32 扩项 / server ≥7.106.0 起上 wire 的门记录位 {@link ModeRelease.mode} 用它)。
+ * 🔴 **在门记录这一面是真闭集**:server `dist/trace/project.js` 的 `modeLedgerDefect` 按 core `isPermissionMode` 筛,出集 ⇒ 整条 `gate` 不上帧
+ * (与 {@link DeniedBy} 同一条纪律)。⚠️ 请求面不是六词:{@link TaskRequest.permissionMode} 在 server 7.106.0 上只收**五词**(`dontAsk` fresh
+ * 400 `request.field_invalid`,S-902 票 7.107.0)—— 它照样可能出现在门记录上(例:部署旋钮 `UNATTENDED_PERMISSION_MODE=dontAsk` 的无人值守腿)。
+ */
+export type PermissionMode = "default" | "acceptEdits" | "plan" | "auto" | "bypassPermissions" | "dontAsk";
+/**
+ * 一只问**属于哪一类**(core 7.34.0 `ASK_CLASSES`,二十词;模式 × 类仲裁表的列)。K-32 扩项 / server ≥7.106.0 起出现在
+ * {@link ModeRelease.askClass} / `.classes` 与 deny 臂的 `askClass` / `classes` 上,以及通告 `permission.ask_released_by_mode` 的 detail 里。
+ * 🔴 **门记录这一面是真闭集**(server 按 core `isAskClass` 筛,出集整条不上帧)。`bypassPermissions` 只放行其中**可放**的九类
+ * (core `RELEASABLE_ASK_CLASSES`:`transcript_write` / `rule_unreadable` / `probe` / `write_protection` / `tool_marks_mcp` / `tool_marks_a2a` /
+ * `artifact_shared_read` / `mode` / `ordinary`);其余(`operator_forced` 部署出身、`ask_rule` / `org_rule`、`hook`、`ancestor`、`content_question`、
+ * `unverifiable_delete`、`governance_unavailable`、`policy_rra` …)任何模式下都照问。
+ */
+export type AskClass = "content_question" | "hook" | "ancestor" | "unverifiable_delete" | "transcript_write" | "org_rule" | "governance_unavailable" | "rule_unreadable" | "ask_rule" | "denial_limit_fallback" | "operator_forced" | "write_protection_unresolved" | "probe" | "write_protection" | "tool_marks_mcp" | "tool_marks_a2a" | "policy_rra" | "artifact_shared_read" | "mode" | "ordinary";
+/**
+ * 一个权限**模式放行**了一只本该问人的 ask 的记录(K-32 扩项;server ≥7.106.0 / core 7.34.0 `ModeRelease`,键集逐键同 core
+ * `dist/core/gate-outcome.d.ts`)—— 只挂在 `allowed` 臂上({@link GateDisposition}):这一次**没有问任何人**,是模式放的。
+ * core 不变量 I7:`released` 在场 ⇒ `kind:"allowed"`、无 settlement、`mode` 是 `bypassPermissions`、`askClass` 是可放类。
+ * 每 (模式, 类) 每 run 另有一帧 `engine_notice` `permission.ask_released_by_mode`(首次)。server 修前(≤7.105.0)这四位被逐键重建面静默剥掉。
+ */
+export interface ModeRelease {
+    /** 放行它的模式(门记录面上今天恒 `bypassPermissions`)。 */
+    mode: PermissionMode;
+    /** 披露的类词 = 折叠集合按 core `ASK_CLASSES` 序的**第一位**(可放类之一)。 */
+    askClass: AskClass;
+    /** 这只 ask 折叠出的**整个**类集合。 */
+    classes: AskClass[];
+    /** 卡上本会显示的 origin(与 {@link GateOutcome.origin} 同一张表;本面 server 按 core 闭集筛)。 */
+    origin?: AskOrigin;
+    /** 卡上本会显示的强制词(六词闭集,见 {@link PersistedRuleMandate})。 */
+    mandate?: PersistedRuleMandate;
+    /** 🔴 `"rule_unreadable"` = 放行越过了一条**这次调用读不出**的规则(规则店读不出 —— 安全轴 fail-open 方向,server 单列披露)。单词闭集。 */
+    reason?: "rule_unreadable";
+}
 /**
  * 这一次分类的**模型归属**(core 7.18.0 #742 `AutoModeClassifierRound`,server ≥7.78.0)——「这次 auto 模式
  * 的门判是**问了谁**、**谁答的**,梯子有没有挪过」。
@@ -2217,6 +2293,9 @@ export type GateDisposition = {
     /** server ≥7.78.0(core 7.18.0 #742):这次分类的模型归属。语义、缺席读法与不变量**全部**写在
      *  {@link GateClassifierAttribution} 顶注(单源,两臂不各写一份会漂的散文)。 */
     classifier?: GateClassifierAttribution;
+    /** K-32 扩项(server ≥7.106.0 / core 7.34.0 design/1111):`bypassPermissions` **放行**了一只没人答的 ask —— 见 {@link ModeRelease}。
+     *  缺席 = 这次放行不是模式放的(普通 allow / 人批的 / 规则放的),或老 server(≤7.105.0 剥掉了它)。 */
+    released?: ModeRelease;
 } | {
     kind: "denied";
     deniedBy: DeniedBy;
@@ -2232,6 +2311,13 @@ export type GateDisposition = {
      *  ⚠️ 与同臂的 {@link cause} 是**两件事**:`cause` 说「这次 deny 是什么形」,本键说「是哪只模型判的」;
      *  一条继承来的链带得出 `cause` 却**没有**归属座,所以两者可以一个在场一个缺席。 */
     classifier?: GateClassifierAttribution;
+    /** K-32 扩项(server ≥7.106.0 / core 7.34.0 `ModeRefusal`):**present-iff `deniedBy === "mode"`**(core 不变量 I8)—— 拒它的模式,两词:
+     *  `dontAsk`(把一只无人可答的问变成拒)/ `bypassPermissions`(拒一次判不出保护目标的写)。`plan` 在这里什么都不拒(它的问照问)。 */
+    mode?: "bypassPermissions" | "dontAsk";
+    /** 与 `mode` 同在:被拒那只 ask 的披露类词(见 {@link AskClass})。 */
+    askClass?: AskClass;
+    /** 与 `mode` 同在:折叠出的整个类集合。 */
+    classes?: AskClass[];
 };
 /**
  * 一只 ask 在等的那次等待**怎么结束的** —— 按 `kind` 判别的联合(core 7.6.0 `SETTLEMENT_KINDS`,闭十二词)。
@@ -3064,9 +3150,12 @@ interface PermissionModeAutoBase {
 /**
  * `capabilities.permissionModeAuto` 的**两代形**(判别位 = `armed` 的**三态**)。
  *
- * 🔴 **武装三键(`intentArming` / `armed` / `reason`)是 server ≥7.57.0(S-80)才有的**,而本包声明的
+ * 🔴 **武装两键(`armed` / `reason`)是 server ≥7.57.0(S-80)才有的**,而本包声明的
  * 支持地板是 **3.0.0** ⇒ 每一台 7.x ≤7.56.0 的 server 都在承诺面内,它们**只发** {@link PermissionModeAutoBase}
  * 那三位(亲核 server tag `v7.50.0` / `v7.56.0` 的 `routes/capabilities.ts` 逐字确认)。
+ * 🔴 **K-35(server 7.107.0 / S-899,wire-changes R2,BREAKING)**:7.57.0–7.106.0 还随武装两键发一只极性位 `intentArming`(7.106.0 起单极恒真),
+ * 7.107.0 起**恒缺席**,本包**删声明**(零别名、零双读)。老 server 发来的那只旧键落进 {@link PermissionModeAutoBase} 的透传索引签名
+ * (型为 `unknown`),本包不读它、不译它;缺席**不是**「旧式极性」—— 要「此刻会不会武装」读 `armed`,不会时读 `reason`。
  * 所以 `armed` **不能**写成必填:写成必填会让
  * ```ts
  * if (!auto.armed) console.log(auto.reason.toUpperCase());   // 老 server 上 reason 根本不在场
@@ -3085,21 +3174,18 @@ interface PermissionModeAutoBase {
 export type PermissionModeAutoCapability = 
 /** **server ≤7.56.0**:只有三位,武装三键**整体缺席**(`armed` 缺席 = 武装态不可知)。 */
 (PermissionModeAutoBase & {
-    intentArming?: undefined;
     armed?: undefined;
     reason?: undefined;
     model?: undefined;
 })
 /** **server ≥7.57.0** · 会武装。`model` = 分类器**配置**的模型路由;解不出时 server 不写这个键。 */
  | (PermissionModeAutoBase & {
-    intentArming: boolean;
     armed: true;
     reason?: undefined;
     model?: string;
 })
 /** **server ≥7.57.0** · 不会武装 ⇒ `reason` 必在场(闭六词,按开集分支)。 */
  | (PermissionModeAutoBase & {
-    intentArming: boolean;
     armed: false;
     reason: AutoModeUnarmedReason;
     model?: string;
@@ -3124,6 +3210,10 @@ export interface Capabilities {
         resume?: "snapshot" | (string & {});
         bgNotifyFailClosed?: boolean;
         steerPriority?: "advisory" | (string & {});
+        /** server ≥7.48.0(#281;K-32 扩项补声明 —— server 7.106.0 的复合位成员闭集 `COMPOSITE_CAPABILITY_MEMBERS` 登记了它,本包此前漏了):
+         *  本二进制会在 `hook_notice` 帧上发**第二个** kind `hook_non_blocking_failure`(用户自配的 hook 自己坏了:exit ≠ 0 ∧ ≠ 2 / 超时 /
+         *  起不来 / 坏 JSON)。缺席 = 老 worker 只发得出 `hook_decision_unavailable` 一个 kind ⇒ 渲染面按 `kind` 分派、未知 kind 别崩。 */
+        hookFailureNotice?: boolean;
         [k: string]: unknown;
     };
     /** #3([1894];server 1.299–7.51)workspace 浏览面能力族——对象=面在场(E19 快照店读面+durable 会话店
@@ -3250,14 +3340,6 @@ export interface Capabilities {
      *  而 wire 上没有任何迹象。**缺席 ⇒ 键正被忽略**,自己那步等待/对账不能省。
      *  (⚠️ 这一位**在场**也不解除那步:该字段是给模型的指引,不是完成契约。) */
     oneShot?: boolean;
-    /** design/201 §3(server ≥7.12.0):这份二进制里**有没有** `permissionMode` → `spec.shellGate` 的翻译表
-     *  (bypassPermissions ⇒ off;auto/default/acceptEdits/plan ⇒ classify;表态缺席 ⇒ 不写键)。
-     *  **恒 true 且与翻译表同一个 commit** —— 这一位说的不是「配置在不在」而是「这份二进制里有没有那张表」,
-     *  所以「says yes ⟺ 翻译真在」是结构性的,没有任何 deps 缺席能让它变假。
-     *  🔴 **判据必须是「所连 server 广告本位」,绝不是壳自身版本**:壳据它撤掉对 `MANUAL_MODE_SHELL_GATE`
-     *  的无条件 env 注入,而按壳版本判会在三种真部署下开天窗(新壳连老 server / 副本回滚到旧二进制 / 混版
-     *  fleet)—— 那正是「翻译还没到货但壳已经撤注」的放宽窗。缺席/false ⇒ 继续注。 */
-    modeShellGateTranslation?: boolean;
     /** design/73 §7.2(server ≥7.12.0):`GET /v1/outcomes` 机械信号只读聚合面可用。server 谓词逐项对着该
      *  路由的拒绝臂:①可查询的账面在场(`outcomeSink.summary` —— File sink 只写 JSONL、没有查询面 ⇒ 501);
      *  ②多租户下 operator 名单非空(单用户形无此门 —— 唯一的用户就是 operator)。
@@ -3361,7 +3443,9 @@ export interface Capabilities {
     retainBackgroundProcesses?: boolean;
     /** TaskRequest.interactiveTools 认词(`routes/capabilities.ts` 的能力对象 硬编码 true;-p 无人值守语义探测位 —— 见 TaskRequest 注)。 */
     interactiveTools?: boolean;
-    /** TaskRequest.cwd honored(`routes/capabilities.ts` 的能力对象 `cwdHonored`:local 单用户 host-adapter 才 true;多租户 fail-closed)。 */
+    /** TaskRequest.cwd honored(`routes/capabilities.ts` 的能力对象 `cwdHonored`:local 单用户 host-adapter 才 true;多租户 fail-closed)。
+     *  🔴 K-32 扩项(server ≥7.106.0 / S-895):本位也是请求键 {@link TaskRequest.inheritEnv} `"all"` 的**精确兑现读数** —— 谓词(host 车道 ∧
+     *  非托管)与那个键的车道门 + 射程门逐组合相等(契约附录 B.1 该行 / §18)。`false` ⇒ 发 `"all"` 会拿 400(非 host 车道)或 422(托管)。 */
     projectContext?: boolean;
     /** TaskRequest.mcpServers honored(`routes/capabilities.ts` 的能力对象 `mcpInjectionHonored`:单用户才 true,多租户 ignore)。 */
     mcpInjection?: boolean;
@@ -3529,20 +3613,23 @@ export interface Capabilities {
         vectorMode: "native" | "portable" | "lexical" | null;
         [k: string]: unknown;
     };
-    /** 本部署的 **SQL 事务读语义**(server `routes/capabilities.ts:216` =
-     *  `projectSqlEngineCapability(deps.sqlEngineFacts?.())`,实现在 `src/sql-engine-posture.ts:57`;S-131)。
-     *  判据**逐字**是驱动连接初始化**回读复核过**的那份事实(`plugins/sql-driver.ts` 的 `SqlEngineFacts`),
-     *  与 operator 面 `GET /v1/diagnostics/wiring` 的 `sqlEngine` 段同源(那一段另有一个 `version`,纯排障料,
-     *  刻意不进本位)⇒「诊断页说悲观、能力位说乐观」结构上不可能。
-     *  🔴 `null` = 本部署**没有 SQL 后端**(env-only worker / local 文件后端),**不是**「读不出来」。
-     *  🔴 `txnMode: null` = 这个引擎**没有该指示面**,**不是** `"optimistic"`。
-     *  受众是运维与部署自述:一个多副本部署不登服务器就能答出「本仓的连接跑在什么读语义上」。 */
-    sql?: null | {
-        engine: "tidb" | "innodb" | "pg" | (string & {});
-        isolation: string;
-        txnMode: "pessimistic" | null;
-        [k: string]: unknown;
-    };
+    /** **「这台副本真的在持久化吗」**(K-32 扩项;server ≥7.106.0 / S-866 ①;铸点发布字节 `dist/http/routes/capabilities.js` 应答字面量
+     *  `store: projectStoreCapability(deps.storePosture ?? …, deps.sqlEngineFacts?.())`,段形属主 `dist/store-posture.d.ts` 的 `StoreCapability`)——
+     *  运维**声明**的后端、**装配出**的后端、降级成因与 SQL 读语义收进一位。段形与读法见 {@link StoreCapability}。
+     *  🔴 **恒在场**(≥7.106.0 每个应答都有它,不是 present-iff);**缺席 = 老 server(< 7.106.0)** —— 那一代只有顶层 `sql`
+     *  (`null` 四义不分:没配 SQL / local 文件店 / 降级到内存 / 连接初始化被拒)与 `/health.storeDegraded`,读不出「以为在持久化、其实在内存」。
+     *  🔴 **顶层 `sql` 自 7.106.0 删除,不留旧键**(wire-changes R1,零别名):本包同批删了 `Capabilities.sql`(BREAKING 型面),
+     *  读它的消费端改读 `caps.store?.sql`(对象逐字同形)。对着 ≤7.105.0 的 server,旧顶层 `sql` 仍会到达,经索引签名读到 `unknown`
+     *  —— 本包不为它留第二个具名读位(双读 = 两个写者一个语义面)。 */
+    store?: StoreCapability;
+    /** **「这台引擎此刻接没接着中心、你的额度执不执行」**(K-32 扩项;server ≥7.106.0 / S-866 ②;铸点发布字节
+     *  `dist/http/routes/capabilities.js` 应答字面量 `centerWiring: deps.centerWiring?.(gatedPrincipal(req, deps.config))`,段形属主
+     *  `dist/capabilities/center-wiring.d.ts` 的 `CenterWiring`,投影 `buildCenterWiring`)。段形与读法见 {@link CenterWiringCapability}。
+     *  🔴 **present-iff 接了中心**(`SEMA_REGISTRY_URL` → `config.configCenter` 在场;与 {@link sealedKey} 同为契约附录 B.1 逐键登记的
+     *  present-iff 例外):缺席是**键不在**,不是 `null`,两种含义 —— 老 server(< 7.106.0)/ 这台引擎没接中心(纯 env / `CONFIG_PROVIDER=local`),
+     *  同一体的 `version` 能分;两种下都读作「本面答不了中心接线与额度执行」,**不许**读作「额度在执行」。
+     *  🔴 **按调用方**(`caller` 是本次请求已验 principal 的租约读数):**不许跨身份缓存**本位。读 caps **不** admit、不打中心。 */
+    centerWiring?: CenterWiringCapability;
     /** **远端车道可 detach**(server `routes/capabilities.ts:233` = `Boolean(deps.runStore)`)—— 零新机制,
      *  说的就是既有的那条腿:`POST /v1/tasks/stream` 带请求头 `x-detach-on-disconnect: true` ⇒ 客户端断连
      *  **不杀** run,它在 server 跑完;回来按响应头 `X-Task-Id` 走 `GET /v1/runs/:id` 与 `/events`
@@ -3599,7 +3686,7 @@ export interface Capabilities {
      *  🔴 位为假时是 **501**(换部署形态),与 {@link memoryConsolidationDriver} 的 404(开旋钮)分家。 */
     memoryOptOutGrant?: boolean;
     /** `permissionMode: "auto"` 的**缺省态披露**(server `routes/capabilities.ts:463`;裁决在
-     *  `src/auto-mode-face.ts` 的 `judgeAutoModeArming`)。**四项刻意不合成一个布尔** —— 合成后
+     *  `src/auto-mode-face.ts` 的 `judgeAutoModeArming`)。**各项刻意不合成一个布尔** —— 合成后
      *  「这份二进制不认识 auto」与「认识但本机没有 entitlement 源」会得到同一个 `false`,而壳对这两种要做的
      *  事不同(前者别给这一档;后者给,但别宣称在筛)。
      *   · `accepted` —— 提交面按五词闭集收 `"auto"`(恒 `true`,server 写的是字面量);
@@ -3607,8 +3694,8 @@ export interface Capabilities {
      *     桩 / 一次性 CLI 不挂席位时如实 `false`);
      *   · `entitlementSource` —— **center 源在不在**,绝不冒充「你被授权了」(授权是 per-principal 的,
      *     部署级布尔对它说不了话);自 S-80 起它是**三态里的一格**,`false` 不再意味着 auto 不武装;
-     *   · `intentArming` —— 这对 server+core 走的是哪套极性:`true` = core #521 的**意图武装式**
-     *     (用户开 + org 拒),`false` = 旧式「org 授予」。壳据此渲「无 center 也能 auto」与否;
+     *   · ~~`intentArming`~~ —— ⚰️ K-35:7.57.0–7.106.0 在这里还有一只「意图武装式 / 旧式 org 授予」极性位(7.106.0 起单极恒真),
+     *     server 7.107.0 起**恒缺席**(wire-changes R2),本包删声明;缺席不是「旧式极性」—— 读下面两键;
      *   · `armed` —— **此刻会不会武装**(按当前运行时真值答;旧式 core 下按旧谓词答,不得假阴);
      *   · `reason` —— **仅** `armed:false` 时在场,server 闭六词集(`AUTO_MODE_UNARMED_REASONS`)。
      *     `local_denied` = 本机 `PERMISSIONS_DISABLE_AUTO_MODE`,`org_denied` = center deny ——
@@ -3723,26 +3810,38 @@ export interface Capabilities {
      *  声明过 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`)——
+    /** 本部署的**执行车道自述**(server ≥7.86.0 / S-426;铸点 = `projectExecutionLaneCapability(deps.config)`,属主发布字节
+     *  `dist/capabilities/execution-lane.js`(7.106.0))——
      *  「这台引擎的工具跑不跑在**本机**」第一次由引擎自己回答,消费端不必再用「本壳 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"` ⇒ 消费端分辨不出「本机有手」与「压根没手」;
-     *    要分辨得开是另一条轴,不是把车道词偷偷换义。
+     *  · `provider` —— 车道词,**八词**闭集(server `ExecutionLane` = `"in-process"` ∪ `RemoteExecProvider`,词表属主
+     *    `dist/execution-lane-caps.js` 的 `EXECUTION_LANE_WORDS`;测试对它做发布字节对拍)。🔴 **缺省词(S-602,server ≥7.97.0,
+     *    BREAKING 值形)**:`REMOTE_EXEC` 未设 ⇒ **`"in-process"`** = 本部署**没有执行车道(无手)**—— core 落 `StubExecutionEnv`,手带整族不挂,
+     *    `toolsOnThisHost:false`(7.86.0–7.96.x 这一形折报 `"host"` / `true`,把无手部署说成「工具在本机」)。**例外形**:单机缺省
+     *    `CONFIG_PROVIDER=local`(`sema` turnkey)且 `REMOTE_EXEC` 未设 ⇒ config 的隐式尾臂铸 **`"host"`**(`dist/config.js` 的
+     *    `ctx.configProvider === "local" ? { provider: "host", singleMachineDefault: true } : undefined`)—— 手就在本机、**没有 OS 沙箱**。
+     *    `in-process ⇒ 无手` 恒成立,**反向不成立**(`excludeTools` / `excludeAllTools` 真卸载、场景 `hands:"none"` 都能在 `host` 上摘手 ——
+     *    「这一 run 有没有手」读 `wiring_manifest` 的 `tools.entries[].mountedBy === "hands"` 条目数,不读本位)。
+     *    ⚠️ 按开集字符串读会让 `in-process` **静默**落进默认分支 —— 按八词穷举,词表外的词按未知处理。
      *  · `toolsOnThisHost` —— 工具跑的那台机器是不是本进程这台(= server 盘上的绝对路径对模型的工具有没有意义),
      *    属主 = `task-cwd.ts` 的 `toolsRunOnThisHost`,与 `skills[].baseDir` 的铸点**同一只函数**。
      *  🔴 **蕴含是单向的,别写成等价**(server 侧对抗复审逮到过的那句):`toolsOnThisHost === false` ⇒
      *  `skills[].baseDir` 恒不发(这一向是承诺);反向**不成立** —— `true` 只是必要条件(扁平形技能
      *  `skills/<name>.md` 结构上没有自己的目录;插件来源技能走的加载器根本不传那个开关)⇒ `true` 时
      *  `baseDir` 按 **present-iff** 读,缺席是合法态。
+     *  · `isolated` —— 见该成员注(server ≥7.106.0 / S-281)。
      *  🔴 **只出词,不出内情**:k8s apiUrl / ssh host / adb serial / 镜像 / 凭据 / `mountPath` 一个字都不上这条 wire。
      *  ⚠️ 缺席(老 server)**不许读作任一侧** —— 那正是本位来之前消费端只能猜的那个状态。 */
     executionLane?: {
-        provider: "host" | "e2b" | "k8s" | "ssh" | "adb" | "local-docker" | "device" | (string & {});
+        provider: "in-process" | "host" | "e2b" | "k8s" | "ssh" | "adb" | "local-docker" | "device" | (string & {});
         toolsOnThisHost: boolean;
+        /** **手在不在 OS 级隔离边界里**(K-32 扩项;server ≥7.106.0 / S-281;铸点 `dist/capabilities/execution-lane.js`
+         *  `...(handsWired ? { isolated: laneIsolated(lane) } : {})`,值 = 车道能力表的 `isolation` 位经**唯一**布尔口 `laneIsolated`;
+         *  `GET /v1/diagnostics/wiring` 的 `executionLane` 段同源同值)。`false` = 手跑在真机上、**没有沙箱**(壳据此说一句
+         *  「no sandbox」,判据 `isolated === false ∧ toolsOnThisHost`);`true` = 隔离车道(e2b / k8s / local-docker …)。
+         *  🔴 **present-iff 本车道有手**(车道能力表 `coreRemoteExecutionEnv === "supported"`):`provider:"in-process"`(无手)⇒ **键缺席**,
+         *  不是 `false`。缺席另一义 = 老 server(< 7.106.0)。两种缺席都按 **unknown** 读,**别读成 `false`**(那会把沙箱部署说成裸机)。 */
+        isolated?: boolean;
         [k: string]: unknown;
     };
     /** 本部署的 **审批推送面带不带 live 事件族**(server ≥7.87.1 / S-455,S-454 的消费半场;
@@ -3766,15 +3865,11 @@ export interface Capabilities {
      *  ② 部署 `AUTONOMY=read-only|plan` ⇒ 请求照常受理,但写面被钳回 roots —— 声明落空。三态压成一位是刻意的
      *  (调用方要做的决定只有一个:还发不发那个键);档位与证据在拒因与 operator 的 `GET /v1/diagnostics/wiring`。
      *  ⚠️ 它**只**说写容纳面这一格 —— `bypassPermissions` 其余两列不受本位影响。
+     *  🔴 K-32 扩项(server ≥7.106.0 / S-895):它**不是** {@link TaskRequest.inheritEnv} `"all"` 的读数 —— 两者共用托管门那一只射程谓词,但本位
+     *  另合了 `TASK_WRITE_FACE_ESCALATION` 与 `AUTONOMY` 两半(「托管 + 旋钮 allow」本位 true 而 `"all"` 仍 422;「单用户 + `AUTONOMY=read-only`」
+     *  本位 false 而 `"all"` 照兑现)。那个键读 {@link projectContext}。
      *  ⚠️ 缺席 = 老 worker(≤7.94)⇒ 按 `true` 兜底(契约附录 B.1:那时任何部署都不拦这条声明)。 */
     taskWriteFaceOpen?: boolean;
-    /** **`approverPosture` 的披露位**(server ≥7.95.0 / S-591 腿③;铸点 `routes/capabilities.ts:659` =
-     *  `taskApproverPostureHonored(deps.config)`,与真消费点同一只谓词)—— 这台部署兑现提交体那句宿主姿态声明
-     *  (「这个 run 的审批卡由宿主自己自动答」)吗?`false` ⇒ 该键被**忽略**(请求照常 202,服务端留一条
-     *  `task_approver_posture_ignored`)—— 刻意**不拒**(续跑腿逐字重放盘上的体,拒会把 parked 任务永久砖死)。
-     *  射程与 {@link taskWriteFaceOpen} 的托管门那一半同一只谓词(托管形 ⇒ 两位同 `false`);`AUTONOMY` 只动那一位、不动本位。
-     *  ⚠️ 缺席 = 老 worker(≤7.94)⇒ 按 `true` 兜底(契约附录 B.1:那时它原样过境)。 */
-    taskApproverPosture?: boolean;
     /** **文件历史捕获开没开、能不能按 run 关掉**(server ≥7.97.0 / S-589 立位;**7.104.0 / S-724 换词**;铸点 int-7104
      *  `routes/capabilities.ts:846` = `fileHistoryCaptureOf(deps.fileHistoryStore, deps.config.fileHistoryCapture)`,闭集属主 server
      *  `src/file-history-capture.ts` 的 `FILE_HISTORY_CAPTURE_WORD_SET` —— 测试对它做源码腿 / dist 腿的词表对拍)。从**装配结果**派生
@@ -3821,6 +3916,85 @@ export interface Capabilities {
     };
     [k: string]: unknown;
 }
+/**
+ * caps `store` 的段形(K-32 扩项;server ≥7.106.0 / S-866 ①)—— 与 server 发布字节 `dist/store-posture.d.ts` 的 `StoreCapability`
+ * **键集逐键相同**(测试对拍;源码 / dist 两腿)。三面同源:`degradedReason` 在场 ⇔ `/health.storeDegraded:true` + 本段 `durable:false`
+ * ⇔ gauge `store_backend_degraded` = 1(server `boot/stores.ts` 铸一次的同一只装配值)。
+ * ⚠️ 本段是**部署自述**,不改任何端点行为。
+ */
+export interface StoreCapability {
+    /** 运维**声明**的后端 = `DB_BACKEND` 词(含缺省推导)。词表属主 = server `DB_BACKEND_WORDS`(config 枚举 / 目录 / caps 同读一只常量)。 */
+    declared: StoreBackendWord;
+    /** **装配出的**后端(同一词表;没装出后端 = `"memory"`)。`declared ≠ backend` 是合法形,由调用方自己读出落差:
+     *  `DB_BACKEND=pg` + `SESSION_BACKEND=memory`(声明 pg、刻意不持久,**无** `degradedReason`)/ `auto` 降级(`degradedReason:"db_unreachable"`)/
+     *  缺省推导 local 起不来(`declared:"local"`、`backend:"memory"`、`"local_unwritable"`)。 */
+    backend: StoreBackendWord;
+    /** `backend !== "memory"`。壳据此渲「pg (durable)」/「pg declared, running in memory: db_unreachable」。 */
+    durable: boolean;
+    /** 🔴 **present-iff 降级臂走过**(按后端族定词,不按失败发生在哪一步):`"db_unreachable"` = SQL 族(`mysql` / `pg`)在
+     *  `SESSION_BACKEND=auto` 下打不开(连接或建表,不分);`"local_unwritable"` = **缺省推导**的 local 文件店建不出来(mkdir / 锁 /
+     *  权限 / 只读挂载 / 磁盘满)。词表属主 = server `STORE_DEGRADED_REASONS`;词表外的词按未知读。缺席 = 没降级(不是「不知道」)。 */
+    degradedReason?: StoreDegradedReason;
+    /** 🔴 **7.105.0 及以前的顶层 `sql` 对象原样搬入**(对象逐字同形,见 {@link SqlEngineCapability})。**present-iff** `backend` 是
+     *  `mysql` / `pg` **且**驱动此刻给得出回读复核过的事实 —— 最近一次连接初始化被拒(S-137 ④)时缺席(此前的顶层 `sql:null` 那一义);
+     *  `local` / `memory` 后端上恒缺席。缺席**不许**推断「未装 SQL 后端」(读 `backend`)。 */
+    sql?: SqlEngineCapability;
+}
+/** `DB_BACKEND` 词表(server `DB_BACKEND_WORDS`;`store.declared` / `store.backend` 同读)。开集尾:新词到货不形变,按未知读。 */
+export type StoreBackendWord = "mysql" | "pg" | "local" | "memory" | (string & {});
+/** `store.degradedReason` 词表(server `STORE_DEGRADED_REASONS`,闭集两词按后端族)。开集尾:词表外的词按未知读。 */
+export type StoreDegradedReason = "db_unreachable" | "local_unwritable" | (string & {});
+/**
+ * 本部署的 **SQL 事务读语义**(S-131;7.105.0 及以前在 `Capabilities.sql`,**7.106.0 起在 {@link StoreCapability.sql}**)—— 与 server
+ * 发布字节 `dist/sql-engine-posture.d.ts` 的 `SqlEngineCapability` 键集逐键相同。值取自驱动在**每条池连接**初始化时 `SET` 完之后的
+ * **回读复核**(`plugins/sql-driver` 的 `SqlEngineFacts`),不是配置里写了什么;与 operator 面 `GET /v1/diagnostics/wiring` 的 `sqlEngine`
+ * 段同源(那一段另有 `version`,刻意不进本段)。受众是运维与部署自述:多副本部署不登服务器就能答出「连接跑在什么读语义上」。
+ */
+export interface SqlEngineCapability {
+    /** 引擎词(server `SqlEngine`:`tidb` / `innodb` / `pg`)。开集尾:词表外按未知读。 */
+    engine: "tidb" | "innodb" | "pg" | (string & {});
+    /** 会话事务隔离级(回读值,逐字;MySQL 协议腿恒 `REPEATABLE-READ`)。 */
+    isolation: string;
+    /** TiDB 的 `tidb_txn_mode`;🔴 `null` = 这个引擎**没有该指示面**(InnoDB / PG),**不是** `"optimistic"`。 */
+    txnMode: "pessimistic" | null;
+}
+/**
+ * caps `centerWiring` 的段形(K-32 扩项;server ≥7.106.0 / S-866 ②)—— 与 server 发布字节 `dist/capabilities/center-wiring.d.ts` 的
+ * `CenterWiring` 键集逐键相同(测试对拍)。投影 = `buildCenterWiring`:`lease:"absent"` ⇒ `leaseHealth` / `failMode` / `caller` **三键缺席**;
+ * `lease:"configured"` ⇒ 三键在场。
+ */
+export interface CenterWiringCapability {
+    /** 本进程最近一次**实拉**中心成功(server 状态 `lastPull === "ok"`)。LKG 起服 / 从未成功 / 最近一拍刷新失败 = `false`。 */
+    effectivePull: boolean;
+    /** `{version, updatedAt} | null`:`version` 与 `/health.configAppliedVersion` 同一只 ledger 视图(同一事实的第三个面);`updatedAt` 取
+     *  最近一份**整套落地**的候选 —— 两者不同代 ⇒ `null`。 */
+    effectiveRevision: {
+        version: number;
+        updatedAt: string;
+    } | null;
+    /** `"configured"` = 中心三件(URL + 凭证 + `SEMA_REGISTRY_WORKER`)齐、装了租约管理器;`"absent"` = 没装(下面三键缺席)。 */
+    lease: "configured" | "absent" | (string & {});
+    /** **present-iff `lease:"configured"`** —— 最近一次租约谈判的收尾:`ok`(中心合法答复,含 409 not-lease / 耗尽)/ `auth-rejected`
+     *  (中心 401 / 403 / 400,或凭证读不出)/ `unreachable`(不可达 / 5xx / 超时 / 坏体 / 其余状态码,含中心 404 / 429 / 3xx)/
+     *  `unobserved`(本进程还没谈判过)。词表属主 server `LEASE_HEALTH_WORDS`。 */
+    leaseHealth?: "ok" | "auth-rejected" | "unreachable" | "unobserved" | (string & {});
+    /** **present-iff `lease:"configured"`** —— `FLEET_LEASE_FAIL_CLOSED` 生效值(缺席随 `REQUIRE_PRINCIPAL` 派生:多租 `closed`、单用户 `open`)。
+     *  `closed` ⇒ 连接级失败时计费入口答 503 `fleet.lease_unavailable`(可重试,见 {@link import("./errors.js").ServiceStateError});
+     *  `open` ⇒ 照旧放行(warn + 计数)。词表属主 server `LEASE_FAIL_MODES`。 */
+    failMode?: "open" | "closed" | (string & {});
+    /** 用量上报环装了(中心三件齐即装,**不看** `FLEET_ADVERTISE_ADDRESS`,S-866 ④)。 */
+    usageReport: boolean;
+    /** 鉴权桥 issuer:`explicit`(`AUTH_BRIDGE_ISSUER` 显式)/ `fallback`(回退 `SEMA_REGISTRY_URL`)。词表属主 server `CENTER_ISSUER_WORDS`。 */
+    issuer: "explicit" | "fallback" | (string & {});
+    /** **present-iff `lease:"configured"`** —— **本次请求的已验 principal**(与租约门同键)此刻的租约读数(🔴 不许跨身份缓存):
+     *  `enforced`(未到期且有余)· `not-enforced`(中心说「不走租约」且负缓存未过期 ⇒ 壳可渲 unlimited)· `exhausted`(中心判耗尽且窗未过,
+     *  带 `retryAfterSec`,正整数,**只随这一词**)· `unobserved`(无条目 / 过期 / 耗尽而未续成 / 被逐出 / 无 principal —— server 裁 F-1:
+     *  此刻额度没人在判,**不是**「上一态」)。词表属主 server `CALLER_LEASE_WORDS`。 */
+    caller?: {
+        lease: "enforced" | "not-enforced" | "exhausted" | "unobserved" | (string & {});
+        retryAfterSec?: number;
+    };
+}
 /** 写保护名表的**租户面**窄投影(`GET /v1/capabilities.writeProtection`)。**不含行内容**。 */
 export interface WriteProtectionCapability {
     /** 生效表非空 ⇒ 引擎真会对表行弹卡。 */
@@ -4966,7 +5140,9 @@ export interface InboxRow {
     classifierUnavailable?: ClassifierUnavailable;
     /** server ≥7.72.0(core 7.14.0 #688 C3,additive)—— **规则车道读不通的是哪一半**:在场 ⇔ `origin ===
      *  "rule_store_unavailable"`;`store` = 规则店读不了(运维:店与网络),`call` = 店读到了但这条命令按人的
-     *  deny/ask 行读不出来(提示词:命令写法)。形与硬读法逐字见 {@link ToolApprovalFrame.ruleStoreUnreadable}。 */
+     *  deny/ask 行读不出来(提示词:命令写法)。形与硬读法逐字见 {@link ToolApprovalFrame.ruleStoreUnreadable}。
+     *  ⚰️ **退役(server 7.106.0 / core 7.34.0 C-R172)**:与帧上同名位同批退场 —— 继任 = 会话流 `engine_notice` `permission.rule_store_unavailable`;
+     *  保留声明只为读 [7.72.0, 7.106.0) 的旧 server。 */
     ruleStoreUnreadable?: "store" | "call";
     /** 任务目标(从 task ctx 富化;契约明确 "`null` if unavailable" —— 真回 null 的字段,非 OMIT)。 */
     objective: string | null;
@@ -5455,6 +5631,24 @@ export interface MemoryErasureRequest {
      */
     allowUnevidenced?: boolean;
 }
+/**
+ * `POST /v1/sessions/:id/memory/erase`(会话所有者**自助**抹除,契约 §12.5)的请求体 —— 型面**只具名这两键**
+ * (发布字节 server 7.107.0 `dist/http/routes/sessions.js:508-523` 逐键判;本包不给写第三键的 affordance)。
+ *
+ * 🔴 **没有 `select`**:自助面的选择子由**路径**铸成 `{ sessionId: <这个会话> }`(硬限本会话;抹别的范围走 operator 面
+ * {@link MemoryErasureRequest})。体里出现 `select` ⇒ 400 `request.body_shape`(响亮拒,不静默忽略)。
+ * ⚠️ `select` 之外的未知键 server **不拒**:静默忽略、不转发(`:526` 只取两键)—— 所以随包 spec 对这只体是「开集 + 禁 `select`」,
+ * 不是闭形(codex r1 F1)。别指望 server 替你挡住拼错的键名。
+ * 🔴 **`requestId` 的语义与 {@link MemoryErasureRequest.requestId} 相同**(同一个 core 动词 `eraseMemoryEntries`):证据腿上它是
+ * 这次抹除的**幂等身份**,重试必须带**同一个**;server 与引擎都从不替你铸。读法见 {@link MemoryErasureAttestation} 顶注的两腿律。
+ * ⚠️ 与 {@link MemoryOriginClearRequest.requestId}(审计归属)**同名不同义**。
+ */
+export interface SessionMemoryEraseRequest {
+    /** 非空串(缺席 / 空串 / 非串 ⇒ 400 `request.request_id_required`)。 */
+    requestId: string;
+    /** 证据面缺席时的降级授权 —— 一次**人的**签字;缺席时 SDK **不补** `false`(体里就没有这个键)。非布尔 ⇒ 400 `request.field_invalid`。 */
+    allowUnevidenced?: boolean;
+}
 /** 一条被抹除行的坐标(core `ErasedBinding`:快照的 tagged 绑定律,不带账本 trace 的额外键)。 */
 export type MemoryErasedBinding = {
     state: "bound";