@sema-agent/client-core 0.41.0 → 0.43.0

package/dist/hitl/toolApprovalWire.d.ts

@@ -122,6 +122,88 @@ export interface FsApprovalWireDeps {
 /** 结构等值(键序无关深比较)——updatedInput「真编辑过」判定用。zod parse 会产新引用与重排,
  *  引用比较/JSON.stringify 串比较都会假报「编辑过」。 */
 export declare function structurallyEqual(a: unknown, b: unknown): boolean;
+/**
+ * 一条「不再询问」候选的匹配形(server/core 闭词表,两代同词)。
+ */
+export type RuleOfferMatch = 'exact' | 'prefix';
+/**
+ * `batch` 臂的一个成员 —— 复合命令**某一段**的规则(core `SegmentRuleSuggestion` 逐字)。
+ * `segment` = 这条成员是从哪一段折叠后的命令文本铸出来的:**渲染座,永不参与裁决**;
+ * 它与 `rule`/`command` 同属 **UNTRUSTED-for-display**(原始 post-rewrite 命令字节)。
+ * 上游形与本包归一形**共用这一个**(成员上没有下标这回事,两代/两腿逐字相同)。
+ */
+export interface RuleOfferBatchMember {
+    rule: string;
+    match: RuleOfferMatch;
+    command: string;
+    segment: string;
+}
+/**
+ * **wire 上的**一条 offer —— 与上游 core `RuleOffer` 逐字同形(**没有** `offerIndex`)。
+ *
+ * 🔴 为什么与归一形 {@link RuleOffer} 分开声明(异源对抗复审 [medium] 采纳):`offerIndex` 是
+ * **本包铸的座**(见 {@link RuleOffer} 顶注),把它写进 {@link ToolApprovalFrame.ruleOffers} 的
+ * 入参型 = 要求宿主为一个上游根本不发的字段负责 —— 真实 7.46.0 帧会**类型不合**,宿主只能强转,
+ * 或者自己伪造一个本该由窄读器按**当前这条腿**算出来的下标(而两条腿的下标语义还不一样)。
+ * ⇒ 入参面(帧/行)用本形,出参面(卡入参)用带下标的归一形,两者刻意不互相赋值。
+ */
+export type WireRuleOffer = {
+    kind: 'single';
+    rule: string;
+    match: RuleOfferMatch;
+    command: string;
+} | {
+    kind: 'batch';
+    rules: readonly RuleOfferBatchMember[];
+    uncoveredSegments: number;
+};
+/**
+ * 一张审批卡上的**一个**「不再询问」选项(core 5.58.0 design/375 §3.1 的判别联合,server ≥7.46.0
+ * 起在 `tool_approval` 帧 / `card_json` / durable park 行**三腿同形**发出)。
+ *
+ * ── 为什么本包自铸这个形(记账,不是偷懒)────────────────────────────────────────────────
+ * 上游 wire 形的类型供给口是 `@sema-agent/sdk`,而 sdk 7.2.0(今天 npm 上的最新版)的
+ * `ToolApprovalFrame` / `PendingCheckpoint` 上**只有退役键 `ruleSuggestions`**、没有 `RuleOffer`
+ * 这个名字 —— 与 `requiresRealApproval`(#283)/ 窗三键([4851])同形:**server 已真发、SDK 锚未跟**。
+ * 照那两例的先例:先追 server,不等 SDK;键集侧进对账门的 `AHEAD_OF_ANCHOR` 带退出条件登记
+ * (SDK 补上当天自红逼删)。语义来源锚 = engine 7.46.0 fixture 的
+ * `@sema-agent/core/dist/core/permission-rule-model.d.ts`(`RuleOffer` 的逐字契约)+
+ * `@sema-agent/server/dist/approval-card.d.ts`(两臂 zod 形与两条腿的下标语义)。
+ *
+ * ── `offerIndex` 是本包铸的座(上游形上没有这一位)──────────────────────────────────────
+ * core 的契约原话:消费端丢掉不认识的成员时**必须保住每个留下来成员的原始 wire 下标**,做不到就
+ * 「must suppress its persistence actions entirely (fail toward asking)」—— 因为 `batch` 臂的兑付
+ * 键就是**下标**(`persistRule.batchOfferIndex`)。本包的窄读器是**逐条丢坏的**(一条坏 offer 不该
+ * 让另一条真 offer 消失,与 server `boundedRuleOffers` 同向),压紧就会让下标前移 ⇒ 人点的第 k 个
+ * 与服务端兑的第 k 个指向两条不同规则。所以窄读时把**原始下标**显式记在这一位上,兑付时按它回报。
+ * 🔴 `offerIndex` 的定义域 = 「本包在**这条腿上**收到的那个数组里的下标」:
+ *   · **活卡帧腿**(`ToolApprovalFrame.ruleOffers`):server 同步腿是纯前缀截、零逐条丢弃 ⇒ 它恒等于
+ *     core 的 offer index,**是**合法选择键,`surfaceToolApprovalFrameAndRespond` 按它回兑;
+ *   · **durable 行腿**(`PendingCheckpoint.ruleOffers` → {@link ApprovalCardRequest.ruleOffersReadOnly}):
+ *     server `boundedRuleOffers` 已经逐条丢弃并压紧过一次 ⇒ 行上的下标本就不是 core 的 offer index。
+ *     这条腿**根本没有兑付口**(`/decide` 体无规则位),所以那一位只是展示/对账座,**禁**当选择键。
+ */
+export type RuleOffer = {
+    kind: 'single';
+    /** 见本联合顶注:原始 wire 下标(活卡帧腿=选择键;durable 腿=展示座)。 */
+    offerIndex: number;
+    /** 宿主要兑付的规范规则文本(ENGINE 铸,客户端只能原样回报)。 */
+    rule: string;
+    match: RuleOfferMatch;
+    /** 规则里的命令模式,给不想重解析的宿主直接渲。UNTRUSTED-for-display。 */
+    command: string;
+} | {
+    kind: 'batch';
+    /** 见本联合顶注。**batch 臂的兑付就是按这个数**(文本不可抄:合取批没有单条文本)。 */
+    offerIndex: number;
+    /** 1..5 条逐段规则(段序,按规则文本去重)。勾这一项 = 对**全体成员**一次性说是,
+     *  合取批**没有成员级选中**(要更窄的答案就选 single 臂或只批这一次)。 */
+    rules: RuleOfferBatchMember[];
+    /** 铸卡时刻的诚实余量披露:这批兑完之后,按当时的覆盖快照仍未被任何规则放行的段数。
+     *  0 = 「兑完这批,这条复合命令在那份快照的口径下就全覆盖了」。它是**对铸卡快照的陈述**,
+     *  不是长期保证(并发删规则会让它过时)。 */
+    uncoveredSegments: number;
+};
 /** 三选卡的原始决断(vendor 卡的三个选项 + abort + 表面失败)。allow_session=第 2 项
  *  (vendor 产出非空 permissionUpdates:setMode acceptEdits / cwd 外 addDirectories)。 */
 /** allow 决断臂(命名形,typeshape B4 口径;0.26.0 因 persistRule 位达 4 成员抽名)。 */
@@ -130,8 +212,50 @@ export interface ApprovalCardAllowDecision {
     allowSession: boolean;
     updatedInput?: unknown;
     /** #225 件1:卡上选中的持久规则候选**原文**({@link ApprovalCardRequest.ruleSuggestions} 之一);
-     *  缺席/空串 = 本次不兑付。表外文本会在编排层被丢键留痕(server 亦拒 rule_not_offered)。 */
+     *  缺席/空串 = 本次不兑付。表外文本会在编排层被丢键留痕(server 亦拒 rule_not_offered)。
+     *  ⚠️ 0.42.0 起本位有一个**兄弟位** {@link persistRuleEdited} —— 带上它就是「这段文本是人手改的
+     *  自由文本」,此时本位**不再**要求是候选之一(见该位注)。本位自身的类型与字节一字未动。 */
     persistRule?: string;
+    /**
+     * #225 编辑臂(0.42.0;server #340 `respondFreeFormRules`,[5071] wire 形):{@link persistRule}
+     * 里那段文本是**人在卡上手打/改过的自由文本**,不是帧候选表里的原文。
+     *
+     * 🔴 **缺席 ≠ false**:缺席 = 既有候选臂(表内核对照旧、语义与 0.41.0 逐字节相同);
+     *    `true` = 编辑臂。刻意只收 `true` 一个值(机读位是二值的,「在场但不是 true」没有语义)。
+     * 🔴 **它不是放行凭据**,是**出身声明**:带上它只会让编排层放弃「必须是候选之一」那道表核
+     *    (见 {@link surfaceToolApprovalFrameAndRespond} 的兑付段),真正的判官仍在引擎侧
+     *    (core `confirmRuleApproval` 同函数体)。客户端**绝不**在这里替引擎预判文本合不合法 ——
+     *    在边界复读解析器就是装第二个更严的判官,`Bash(adb *)` 这类肌肉记忆形会被当场误杀
+     *    ([5071] 定界②,core [5075] 复核确认)。要「边打字边校验」请用
+     *    {@link import('./editedRuleTextPrecheck.js').precheckEditedRuleText} 的注入口 —— 那是**引擎
+     *    自己那只**判官,不是第二份。
+     * 🔴 **能力位在场才发**:`true` 而 {@link ToolApprovalFrameLaneOpts.respondFreeFormRulesCapable}
+     *    未确认 ⇒ 编排层**整条丢 persistRule**(决断照送),见该位注。
+     */
+    persistRuleEdited?: true;
+    /**
+     * #334 批臂(0.43.0;server ≥7.46.0 `ParsedPersistRule` 的 `{kind:'batch', batchOfferIndex}` 那一支,
+     * design/377):人在卡上勾的是一条 **`kind:'batch'` 的合取批 offer**。
+     *
+     * 值 = 那条 offer 的 {@link RuleOffer.offerIndex}(**原始 wire 下标**)。
+     * 🔴 **为什么批臂传下标而不是文本**:合取批没有单条可抄的文本(它是 1..5 条规则的一次性授权),
+     *    文本等式在这一臂上不存在 ⇒ 选择键只能是下标。single 臂的防伪锚仍是**文本等式**,下标
+     *    **不许**旁路它(server 侧同款:`batchOfferIndex` 窄开只指 batch)。
+     * 🔴 **三臂互斥**(server `PERSIST_RULE_BATCH_EXCLUSIVE_ERROR`,同场**响亮 400 且连决断一起拒**):
+     *    本位与 {@link persistRule}/{@link persistRuleEdited} 同场 ⇒ 编排层**整条持久臂丢弃 + 留痕**,
+     *    决断照送。两臂说的是两次不同的授权,替人挑一个 = 替人改主意;而让 400 把决断一起打掉,
+     *    是把附带愿望的失败升级成主动作的失败(方向与 note 超限那条同一纪律)。
+     * 🔴 **表核不让位**:本位只在「该下标在**本帧**的 offers 里真是一条 `kind:'batch'`」时上 wire ——
+     *    越界 / 指向 single / 负数 / 非整数一律丢键留痕(server 会 400,包边界先挡下来,决断不受连累)。
+     * 🔴 **必须由宿主供给能力位**(异源对抗复审四轮 [medium] 订正 —— 本段初稿写的是「批臂供给自闸、
+     *    没有独立能力位」,与实装**相反**,而这段注释随 `.d.ts` 出包 = 三端读到的接入契约):
+     *    编排层只在 {@link ToolApprovalFrameLaneOpts.respondBatchRuleOffersCapable} `=== true` 时把本位
+     *    送上 wire。**宿主不供给这一位 ⇒ 现代引擎上每一次批臂勾选都会被丢**(决断照送 + 一条如实通知)。
+     *    理由见那一位的顶注:帧上有 batch offer 只证明**出帧端**认识新形,不证明**收 respond 的那台**
+     *    认识它(滚动升级 / 多副本 / 代理),而旧解析器对本键是**响亮 400 且连决断一起拒**。
+     * 缺席 = 这次不是批臂(候选臂/编辑臂/不兑付),现状字节不变。
+     */
+    persistRuleBatchOfferIndex?: number;
 }
 /**
  * deny 决断臂(命名形,typeshape B4 口径;0.28.0 因 `reason` 位抽名,与 0.26.0
@@ -211,26 +335,56 @@ export interface ApprovalCardRequest {
      *  `agentName` UNTRUSTED-for-display。子代 ask 才在场。 */
     delegation?: ToolApprovalDelegation;
     /**
-     * 持久规则候选(#225 件1,原样来自 {@link ToolApprovalFrame.ruleSuggestions} 的合形项)——
-     * 卡据此渲「不再询问」档;缺席/空 = 卡形与 0.25.0 字节不变(不渲该档)。
-     * 🔴 卡只许把其中一条的 `rule` **原样**放进决断的 `persistRule`(不拼、不改写);
-     * 出身裁剪(MANDATED ask 不提供本档)候 core 5.25.0 出身键 wire 过境,见 #144/[3438]/[3442]。
+     * 持久规则候选(#225 件1;0.43.0 起是 {@link RuleOffer} 判别联合)——卡据此渲「不再询问」档;
+     * 缺席/空 = 卡形不渲该档。
+     *
+     * 🔴 **包内单一形出口**(#334/[5223],0.43.0 **BREAKING**):本键**同时**是两代 wire 的落位 ——
+     *    新引擎的 {@link ToolApprovalFrame.ruleOffers}(server ≥7.46.0)与旧引擎的
+     *    {@link ToolApprovalFrame.ruleSuggestions}(≤7.45,归一成 `kind:'single'`)经**同一把**窄读器
+     *    合形后落这里。**新键优先、两键同场时旧键整条不看**(绝不混编两代素材)。
+     *    ⇒ 消费端(cli/web/desktop)读包内这一个形,不感知上游换键。
+     *    ⚠️ 0.42.0 及更早本键的类型是 sdk `RuleSuggestion[]`(无 `kind`/无 `offerIndex`);
+     *    换形是**破坏性**的,呈卡端要按 `kind` 分臂渲(single 一行、batch 一组 + 余量披露)。
+     * 🔴 兑付两条路,别混:
+     *    · `kind:'single'` ⇒ 把该条的 `rule` **原样**放进决断的
+     *      {@link ApprovalCardAllowDecision.persistRule}(不拼、不改写);
+     *    · `kind:'batch'`  ⇒ 把该条的 `offerIndex` 放进
+     *      {@link ApprovalCardAllowDecision.persistRuleBatchOfferIndex}(批没有单条文本可抄)。
+     *    两位**互斥**,同场 ⇒ 编排层整条持久臂丢弃(见那一位的注)。
+     * 🔴 `rule`/`command`/`rules[].segment` 全部 **UNTRUSTED-for-display**。
      */
-    ruleSuggestions?: RuleSuggestion[];
+    ruleOffers?: RuleOffer[];
     /**
-     * 持久规则候选的**只读**对偶([C170] 答问②半场,0.29.0)——原样来自 durable 队列行
-     * `PendingCheckpoint.ruleSuggestions`(server 7.16.0 [3684]② 补齐的供给)的合形项。
-     * 🔴 与 {@link ruleSuggestions} **刻意分键不合流**:那一位的契约是「卡渲可选中的『不再询问』档
-     * → 决断带 {@link ApprovalCardAllowDecision.persistRule} 回兑」,兑付口=同副本活卡腿
-     * `respond.persistRule`;而 durable 腿的 `/decide` 体**无规则位**(SDK 6.17.2 PendingCheckpoint
-     * JSDoc 逐字:display/triage-only)——把行上候选落进那一位,就是一个按下去规则不落地的假
-     * affordance。本键的不变量是**决断字节**:决断绝不因它带 `persistRule`(或任何规则位)——
+     * 持久规则候选的**只读**对偶([C170] 答问②半场,0.29.0;0.43.0 随 {@link ruleOffers} 换形)——
+     * 原样来自 durable 队列行 `PendingCheckpoint.ruleOffers`(server ≥7.46.0)或旧键
+     * `PendingCheckpoint.ruleSuggestions`(server 7.16.0 [3684]② 起的供给,≤7.45)的合形项,
+     * 经与活卡腿**同一把**窄读器归一。
+     * 🔴 与 {@link ruleOffers} **刻意分键不合流**:那一位的契约是「卡渲可选中的『不再询问』档
+     * → 决断带 {@link ApprovalCardAllowDecision.persistRule} / `persistRuleBatchOfferIndex` 回兑」,
+     * 兑付口=同副本活卡腿 `respond`;而 durable 腿的 `/decide` 体**无规则位**(SDK 6.17.2
+     * PendingCheckpoint JSDoc 逐字:display/triage-only)——把行上候选落进那一位,就是一个按下去
+     * 规则不落地的假 affordance。本键的不变量是**决断字节**:决断绝不因它带任何规则位 ——
      * 「只读」限定的是 wire 回兑通道,不是屏面。渲成可选中项是**允许**的,前提=兑付走客户端
      * **本地**落规则(cli 1.0.76 起的形:选中 → 客户端写自己的 settings `permissions.allow` 并把
      * 成败如实上屏,决断仍与两态时代逐字节相同;这正是 CC 第三态的原形——本地文件写)。
+     * 🔴 **本腿的 `offerIndex` 不是选择键**:server `boundedRuleOffers` 已逐条丢弃并压紧过一次,
+     *    行上的下标本就不等于 core 的 offer index;而这条腿压根没有兑付口 ⇒ 它只是展示/对账座。
      * 缺席 = 无候选/老行/坏形(三者同形,不猜);既有卡口不读本键 ⇒ 卡形字节不变。
      */
-    ruleSuggestionsReadOnly?: RuleSuggestion[];
+    ruleOffersReadOnly?: RuleOffer[];
+    /**
+     * #341/[5214]③(0.43.0;server ≥7.46.0 E-14 / [4537]② Trojan Source 族;**ADDITIVE**,
+     * `"tool_approval"` only)——原样来自 {@link ToolApprovalFrame.inputHasBidi}:这只 ask 的
+     * **工具输入**里含 bidi 控制符(LRM/RLM、嵌入/覆写、隔离符)。
+     *
+     * 🔴 **缺席绝不折成 `false`**(类型 `true`,与 {@link governanceForced}/{@link requiresRealApproval}
+     *    同族):缺席同时覆盖「真的没扫到」与「args 序列化不了所以扫不了」两形,读成「已确认干净」
+     *    就是对用户下一个证不出的断言。
+     * 🔴 **披露位,不是清洗位;本包字节零改**:清洗会改掉即将被执行的那串字节(卡上显示的与真跑的
+     *    不是同一个东西),比不披露更坏。显形(转义/高亮/加标记)归端 —— 壳侧基线是
+     *    `renderUntrustedCommandText`(core 导出的展示基线)。本包只保证这一位到得了卡口。
+     */
+    inputHasBidi?: true;
     /**
      * 被越级的持久 allow 规则**原文**(#144,原样来自 {@link ToolApprovalFrame.persistedRuleShadowed}
      * 的合形值)——壳据此渲「你的规则仍在,只是这次调用被要求逐次确认」;缺席 = 卡形与 0.27.0
@@ -412,13 +566,39 @@ export interface ToolApprovalFrame {
      */
     delegation?: ToolApprovalDelegation;
     /**
-     * server ≥7.12.0(#154 车二 / design/179,ADDITIVE)——**引擎铸的**持久规则候选。只在
-     * `capabilities.permissionRules` 谓词为真且引擎对本次裁决真铸出候选时在场;缺席 = 这张卡
-     * 不提供「不再询问」档(老 server / 规则店未接 / 引擎判无候选,三者同形,不猜)。
-     * 🔴 文本由 ENGINE 铸,不由客户端拼:回决时只能把其中一条**原样**报回
-     * (`respond` 体 `persistRule.rule`),报表外文本 = server 拒 `rule_not_offered`。
+     * ⚠️ **退役键**(server ≤7.45;7.46.0 起同文件 0 命中 —— engine fixture 直证)。
+     * server ≥7.12.0(#154 车二 / design/179)起的**引擎铸的**持久规则候选,7.46.0 被
+     * {@link ruleOffers} 整体取代(#334/[5223],core 5.58.0 design/375 的判别联合换形)。
+     *
+     * 🔴 **保读不保写**:本包对它只做**归一读**(→ `kind:'single'` 的 {@link RuleOffer}),理由 =
+     *    7.44 及更旧的引擎今天仍在场(pin 未抬的部署、混舰队)。新键在场时**本键整条不看**。
+     *    包内出口只有 {@link ApprovalCardRequest.ruleOffers} 一个,消费端不感知这次换键。
+     * 🔴 本键留在 interface 与 {@link TOOL_APPROVAL_FRAME_KEYS_MIRROR} 里**不是**遗留包袱:
+     *    SDK 7.2.0 的运行期锚 `TOOL_APPROVAL_FRAME_KEYS` 仍含它,删掉会让对账门的
+     *    「SDK 锚的每个键本仓都有」当场红 —— 退役登记要等 SDK 跟着 server 一起退。
      */
     ruleSuggestions?: RuleSuggestion[];
+    /**
+     * server ≥7.46.0(#334/[5223];core 5.58.0 design/375;**BREAKING 换形**,`"tool_approval"` only。
+     * 来源锚 = engine 7.46.0 fixture `@sema-agent/server/dist/tool-approval.d.ts` 的
+     * `ruleOffers?: readonly RuleOffer[]` 声明 + `@sema-agent/core/dist/core/permission-rule-model.d.ts`
+     * 的 `RuleOffer` 逐字契约)——引擎为这次 ask 铸的「不再询问」选项,判别联合 `single | batch`。
+     *
+     * 🔴 **序即契约**:whole-string exact 的 `single` 在场时恒 index 0、`batch` 至多一条且恒末位;
+     *    core 契约基数 ≤2,server 侧执法帽 `MAX_RULE_OFFERS`=4(容忍余量,消费端按 ≤4 布局)。
+     *    **选择键是原始下标** —— 本包的窄读器逐条丢坏形并把原始下标记在 {@link RuleOffer.offerIndex}
+     *    上(压紧会让「人点的第 k 个」与「服务端兑的第 k 个」指向两条不同规则)。
+     * 🔴 **在场性即承诺**:只在**规则店真装配**时在场;缺席 = 这张卡不提供「不再询问」档
+     *    (老 server / 规则店未接 / 引擎判无候选,三者同形,不猜)。
+     * 🔴 文本由 ENGINE 铸,不由客户端拼:single 臂回决只能把 `rule` **原样**报回
+     *    (`respond` 体 `persistRule.rule`,报表外文本 = server 拒 `rule_not_offered`);
+     *    batch 臂没有单条文本可抄,回决报**下标**(`respond` 体 `persistRule.batchOfferIndex`)。
+     * 🔴 本键**领先** SDK 运行期锚一代(sdk 7.2.0 的 `TOOL_APPROVAL_FRAME_KEYS` 只有退役键
+     *    `ruleSuggestions`)⇒ 对账门(run-approval-frame-keys-test.mjs)AHEAD_OF_ANCHOR 带退出条件登记。
+     * 耐久路对偶 = `PendingCheckpoint.ruleOffers`(同契约、**下标语义不同**:那条腿 server 已逐条
+     * 丢弃压紧过,且无兑付口 ⇒ 下标只是展示座),由 {@link surfaceFsApprovalAndDecide} 消费。
+     */
+    ruleOffers?: readonly WireRuleOffer[];
     /**
      * server ≥7.13.0(#144 / core 5.25.0,[3438] 接力契约 / [3443] 主件;**ADDITIVE**,
      * `"tool_approval"` only。来源锚 = engine fixture `@sema-agent/server/dist/tool-approval.d.ts`
@@ -519,6 +699,40 @@ export interface ToolApprovalFrame {
      * run-durable-card-display-keys-test.mjs ⑨ 段;上游补位后按 {@link probeCause} 的双源合流形跟批。
      */
     requiresRealApproval?: true;
+    /**
+     * #341/[5214]③(server ≥7.46.0;E-14 / [4537]② Trojan Source 族;**ADDITIVE**,`"tool_approval"` only。
+     * 来源锚 = engine 7.46.0 fixture `@sema-agent/server/dist/tool-approval.d.ts` 的 `inputHasBidi?: true`
+     * 声明 + 同包 `dist/tool-approval.js` 的条件 stamp;7.44 fixture 同文件 0 命中)——这只 ask 的
+     * **工具输入**(`AskRequest.args`)里含 bidi 控制符(LRM/RLM、嵌入/覆写、隔离符)。
+     *
+     * 🔴 **真才带,缺席绝不编 `false`**(与 {@link governanceForced}/{@link requiresRealApproval} 同形)。
+     *    缺席同时覆盖「真的没有」与「args 序列化不了(循环引用/抛错的 toJSON/BigInt)所以扫不了」两形,
+     *    消费端**禁**把缺席读成「已确认干净」。
+     * 🔴 **披露位,不是清洗位;字节零改**:审批卡是唯一一处把模型写的命令交给**人眼**判断的面,而
+     *    bidi 覆写让人眼读到的顺序与真正执行的字节顺序不同 —— 人批准的是 A、跑起来的是 B。清洗会改掉
+     *    即将被执行的那串字节,**比不披露更坏**;server 只报「有」,显形归端。本包只做透传
+     *    (帧 → {@link ApprovalCardRequest.inputHasBidi})。
+     * 🔴 判据**不看 `message`**(引擎/策略写的说明文本,不是待执行输入)——两个来源折进一个布尔会让
+     *    端无法判断该给哪一段加显形标记。
+     * 🔴 本键**领先** SDK 运行期锚一代(sdk 7.2.0 尚无)⇒ 对账门 AHEAD_OF_ANCHOR 带退出条件登记。
+     * 耐久路今天**无对偶**(server 7.46.0 的 `PendingCheckpoint`/`riskDescriptor` 均未声明本键;
+     * server 侧那份在**卡内**,不是行上的键)⇒ durable 行 → 卡那条腿不 stamp。
+     */
+    inputHasBidi?: true;
+    /**
+     * #329 随批小件([4845]-5;**ADDITIVE**,`"tool_approval_complete"` only,真才带;server 7.44.0 及
+     * 更早已在场 —— 0.43.0 同形族扫补进镜像的存量漏键,见 {@link TOOL_APPROVAL_FRAME_KEYS_MIRROR} 处注)——
+     * `outcome:"expired"` 一词三义(park / 当场 deny / 无设施 deny)里 **park 那一义的显式判别位**:
+     * 在场 ⇔ 这条 ask 按 park 路由收尾且墓碑已落(⇔ 同一把 `approvalId` 仍可打 `respond` 走迟到受理)。
+     *
+     * 🔴 **缺席禁读作「真 deny」**:无店部署 / deny 政策 / 被连坐 VOID 的兄弟都发不出这个键,
+     *    缺席只是「无 park 证据」。
+     * 🔴 本包今天**只镜像键、不消费**:它只出现在 `tool_approval_complete` 上,而那种帧根本不走卡口
+     *    (`surfaceToolApprovalFrameAndRespond` 消费的是 `tool_approval`)。要把「卡失效」改渲
+     *    「已转后台候批」是一次**行为面**改动(消费者=端的完成帧处理面),按宪法三问单独立项。
+     *    登记在此 = 写明理由的未消费,不是没人发现的丢键。
+     */
+    parked?: true;
     /**
      * server ≥7.34.0(#288/[4429]② —— cli 自己请托的窗三键,**ADDITIVE**,`"tool_approval"` only;
      * 来源锚 = sema-server src/tool-approval.ts 的三键声明+emit 前赋值,字段注逐字「新壳借此给旧族帧
@@ -554,7 +768,7 @@ export interface ToolApprovalDelegation {
  * `TOOL_APPROVAL_FRAME_KEYS` 比对——SDK additive 增键时对账当天红,不再人肉追平。
  * 下面两个类型钉保证镜像与 interface 本身不可能漂移(少键/多键都是编译错)。
  */
-export declare const TOOL_APPROVAL_FRAME_KEYS_MIRROR: readonly ["type", "approvalId", "toolCallId", "toolName", "sourceTaskId", "fromSubagent", "sourceAgentName", "message", "args", "argsOmitted", "governanceForced", "ruleSuggestions", "persistedRuleShadowed", "probeCause", "ruleEvidence", "requiresRealApproval", "expiresInMs", "expiresAtMs", "serverNowMs", "delegation", "outcome"];
+export declare const TOOL_APPROVAL_FRAME_KEYS_MIRROR: readonly ["type", "approvalId", "toolCallId", "toolName", "sourceTaskId", "fromSubagent", "sourceAgentName", "message", "args", "argsOmitted", "governanceForced", "ruleSuggestions", "ruleOffers", "inputHasBidi", "parked", "persistedRuleShadowed", "probeCause", "ruleEvidence", "requiresRealApproval", "expiresInMs", "expiresAtMs", "serverNowMs", "delegation", "outcome"];
 /**
  * 子代帧判别:显式键 fromSubagent(core 1.378 RB-39②)优先;缺席退 sourceTaskId 在场性权宜式
  * (server 1.258 [1549]①3,旧代际兼容)。
@@ -598,8 +812,47 @@ export type ToolApprovalRespondDecision = 'allow' | 'allow_session' | 'deny';
 export interface RespondToolApprovalOpts {
     signal?: AbortSignal;
     updatedInput?: unknown;
-    /** #225 件1:兑付键 —— 帧候选之一的**原文**(编排层已做表内核对与 deny 剥除)。 */
+    /** #225 件1:兑付键 —— 帧候选之一的**原文**(编排层已做表内核对与 deny 剥除)。
+     *  ⚠️ 带 {@link persistRuleEdited} 时表核已让位,本位是人手改的自由文本(类型不变)。 */
     persistRule?: string;
+    /**
+     * #225 编辑臂(0.42.0;server #340,[5071]):{@link persistRule} 是**自由文本**而非候选原文。
+     *
+     * 🔴 **注入面的映射义务**(本包只到这一格,wire 体由宿主/SDK 铸):server 的 respond 体形是
+     *    `persistRule: { rule, edited: true }`。本包刻意保持**扁平兄弟位**(`persistRule: string`
+     *    字节不变 + 一个可选布尔),由注入面把两位合成那个嵌套形:
+     *      `persistRule !== undefined ? { rule: persistRule, ...(persistRuleEdited === true ? { edited: true } : {}) } : undefined`
+     *    改成嵌套形会是既有 `persistRule: string` 消费者的 BREAKING,而这一批的纲领是 additive。
+     * 🔴 **缺席 = 候选臂**(server 侧 `rule_not_offered` 语义一字不变);老 server 收到带 `edited`
+     *    的体会诚实降级为 `rule_not_offered`,这正是 [5071] 选这个键名而不是顶层新键的理由
+     *    (顶层新键在老 server 上是静默 200 什么都不落,坏于诚实降级)。
+     */
+    persistRuleEdited?: true;
+    /**
+     * #334 批臂(0.43.0;server ≥7.46.0,design/377):人勾的是一条**合取批** offer,选择键 =
+     * 该 offer 在帧上的**原始 wire 下标**(编排层已做「该下标真是 batch offer」的表核与三臂互斥)。
+     *
+     * 🔴 **注入面的映射义务**(本包只到这一格,wire 体由宿主/SDK 铸):server 的 respond 体形是
+     *    `persistRule: { batchOfferIndex }`,与文本臂 `persistRule: { rule, edited? }` **同一个字段名、
+     *    三臂互斥**。本包刻意保持**扁平兄弟位**(既有 `persistRule: string` 字节不变),由注入面合成:
+     *      ```
+     *      persistRuleBatchOfferIndex !== undefined
+     *        ? { batchOfferIndex: persistRuleBatchOfferIndex }
+     *        : persistRule !== undefined
+     *          ? { rule: persistRule, ...(persistRuleEdited === true ? { edited: true } : {}) }
+     *          : undefined
+     *      ```
+     *    🔴 **三位绝不同时上体**:server 对同场组合响亮 400 且**连决断一起拒**。编排层已保证本包发出的
+     *    opts 上文本臂与批臂不会同场,注入面只需按上面的优先序取一个,**不要**自己再补一个 fallback。
+     * 🔴 **宿主必须供给能力位**(异源对抗复审五轮 [medium] 订正 —— 本段初稿写的是「批臂供给自闸、
+     *    老引擎零受迫」,与实装**相反**,而这段注释随 `.d.ts` 出包 = 三端读到的接入契约,与
+     *    {@link ApprovalCardAllowDecision.persistRuleBatchOfferIndex} 那段同名残余同批清):
+     *    编排层只在 {@link ToolApprovalFrameLaneOpts.respondBatchRuleOffersCapable} `=== true` 时填本位。
+     *    **宿主漏供这一位 ⇒ 现代引擎上每一次批臂勾选都被丢**(决断照送 + 一条 `surfaceRuleArmNotSent`
+     *    通知)。「老引擎不铸 batch offer 所以本位恒缺席」这句**单独看仍然成立**,但它证不出安全性:
+     *    滚动升级 / 多副本 / 代理下,**出帧的那台**与**收 respond 的那台**可以不是同一个版本。
+     */
+    persistRuleBatchOfferIndex?: number;
     /** #229(server ≥7.15.0):回决备注 —— 与 durable 腿 `AskDecisionBody.note` **同词同源同一列**
      *  (`decision_note`,≤2048)。任何 decision 都可带(deny 的「为什么拒」正是审计面上最值钱的
      *  一条);真落行与否看 ack 的 {@link surfaceToolApprovalFrameAndRespond} 消费的 `noteRecorded`。
@@ -607,6 +860,48 @@ export interface RespondToolApprovalOpts {
     note?: string;
 }
 export type RespondToolApprovalFn = (approvalId: string, decision: ToolApprovalRespondDecision, opts?: RespondToolApprovalOpts) => Promise<ToolApprovalRespondAck | void>;
+/**
+ * respond 回执的**包内视图** —— sdk `ToolApprovalRespondAck` 的 additive 超集(#334,0.43.0)。
+ *
+ * 为什么是超集而不是直接用 sdk 那个形:server 7.46.0 的兑付回执上有两个**规范文本回显位**,而
+ * sdk 7.2.0 的 `ToolApprovalRespondAck` 声明里还没有它们(与 `ruleOffers` 同一次锚滞后)。缺这两位,
+ * 「规则真正存成了什么样」在包边界上被吞掉 —— 而编辑臂的落盘文本**可能与人敲的原字节不同**
+ * (core 会把 `Bash(adb *)` 规范成 `Bash(adb:*)`),批臂更是一次落多条。
+ *
+ * 🔴 **超集只加不改**:继承 sdk 那个形的每一位,语义与字节零改动;既有消费端读 `rulePersisted` /
+ *    `ruleRefusal` / `noteRecorded` 的写法一字不用动(返回型变宽对读方是源码兼容的)。
+ * 🔴 sdk 锚补上这两位那天,本形按 `probeCause` 先例回收(直接用 sdk 形)。
+ */
+export interface ToolApprovalRespondAckView extends ToolApprovalRespondAck {
+    /**
+     * server ≥7.44(#340 编辑臂回显 `editedArmEcho`;7.46 沿用)——**编辑臂**兑付成功时,规则店里
+     * **真正落盘**的那条规范文本。
+     * 🔴 **界面要回显的是这一份,不是输入框里那一份**:core 会规范化人敲的拼写。
+     * 只在编辑臂 ∧ 兑付成功 ∧ 落的是 single 时在场;候选臂/批臂/失败/老 server ⇒ 缺席(≠ 空串)。
+     */
+    persistedRule?: string;
+    /**
+     * server ≥7.46.0(design/377 批臂回执)——**批臂**兑付成功时落地的**全体**成员规范文本,
+     * **展示序**(= batch offer 的成员序,壳逐条回显)。「落地」含 persisted 与 deduped 两种
+     * (等价规则已在店 = 同意已生效)。
+     * 🔴 **复数是契约不是巧合**:合取批一次授权多条规则,把它折成一条(或只报第一条)会让人以为
+     *    自己只批了一条。非数组 / 含非串成员 / 空数组 ⇒ 整只降缺席(半份清单比没有清单更坏)。
+     * 非批臂 / 兑付失败 / 老 server ⇒ 字段省略;**缺席 ≠ 空**。
+     *
+     * 🔴 **在册残余:逐条归属今天 wire 上证不出**(异源对抗复审三轮 [medium] 采纳为**登记**,不是修复)。
+     *    本包对这一位做到的相关性是 **id + decision + 基数**({@link surfaceToolApprovalFrameAndRespond}
+     *    的臂相关性门):条数必须等于所选 batch 的成员数。基数抓得到「少报/多报」,**抓不到**
+     *    「条数对但内容是另一批规则」—— 因为兑付回执上**没有任何锚**能把这 N 条与那只 offer 对上
+     *    (回执不回 `batchOfferIndex`,成员也没有稳定 id;而文本等式在这一位上不成立:落盘的是
+     *    **规范化后**的文本,与 offer 上的文本按设计可以不同,拿文本去比就是装第二个判官)。
+     * 🔴 ⇒ **端的呈现口径**:把它渲成「**引擎报告**落盘的规则」,**不是**「你刚才选的那批规则」。
+     *    两句话在正常情形下指同一件事,但只有前一句是本包能背书的。
+     *    正位解需要**上游补一个 additive 锚**(回执带 `batchOfferIndex`,或成员带稳定标识/摘要)——
+     *    已登记 `docs/INTEGRATION-CLIENTS.md` §7 缺口 **P-39**,按接入文档宪法向 server 点名索要,
+     *    补上当天本注按 `probeCause` 先例跟批收紧。
+     */
+    persistedRules?: readonly string[];
+}
 /**
  * respond 回执的**结构化读口**(wire 是 JSON:注入面可能是旧 liveClient 的 raw fetch,也可能是
  * 比本包新一版的 SDK)。坏形一律降 `undefined` —— 与 `controlRouter.errCodes` 同族纪律:
@@ -618,7 +913,7 @@ export type RespondToolApprovalFn = (approvalId: string, decision: ToolApprovalR
  * 当成合规 ack 放行。**相关性**(「这个 ack 是不是**这一次**审批的回执」)不在本函数判 —— 本函数
  * 只认形,对不对得上由 {@link surfaceToolApprovalFrameAndRespond} 拿着 frame 与刚发出的 decision 核。
  */
-export declare function readToolApprovalRespondAck(v: unknown): ToolApprovalRespondAck | undefined;
+export declare function readToolApprovalRespondAck(v: unknown): ToolApprovalRespondAckView | undefined;
 /**
  * 一张 `tool_approval` 帧消费完的产物(FIX①,2026-08-07 **BREAKING**:此前是裸的
  * `ToolApprovalRespondDecision | 'unresolved'` 字符串)。
@@ -627,9 +922,82 @@ export declare function readToolApprovalRespondAck(v: unknown): ToolApprovalResp
 export interface ToolApprovalFrameOutcome {
     /** 用户(或 fail-closed)落定的决断;`'unresolved'` = respond 没送达(引擎按 TTL 自决)。 */
     decision: ToolApprovalRespondDecision | 'unresolved';
-    /** server 的 200 ack。**缺席 = 未知**(注入面回 void / 旧 server / respond 失败),绝不当成 false。 */
-    ack?: ToolApprovalRespondAck;
+    /** server 的 200 ack(0.43.0 起是 {@link ToolApprovalRespondAckView} —— sdk 形的 additive 超集,
+     *  多两个规范文本回显位)。**缺席 = 未知**(注入面回 void / 旧 server / respond 失败),绝不当成 false。 */
+    ack?: ToolApprovalRespondAckView;
+    /**
+     * #225 件5(0.42.0):respond **抛错**那一支的原文交还位。
+     *
+     * 🔴 修的是一条真断链:此前本函数的 catch 只写一行 `debug` 然后返 `{decision:'unresolved'}`,
+     *    于是 server 的响亮 400(`persistRule.rule` 空/超长、`edited` 非布尔、顶层 `scope`、
+     *    `edit-rejected` 的拒句 …… [5071] G4/G5/G6)在**包边界上被吞掉** —— 宿主的错误反馈面
+     *    无论怎么写都拿不到那句话,人在卡上改了规则被拒,屏上什么都不会说。
+     * 🔴 **不改 `decision` 的语义**:`'unresolved'` 仍是 `'unresolved'`(respond 没落定 = 引擎按
+     *    TTL/abort 自决,这一位的含义一字未动);本位是**附加**的诊断面,不是新的决断态。
+     * 🔴 **缺席 = 没有拒绝原文可交**(respond 成功 / 抛的东西上**三位皆读不出**),绝不造一句。
+     *    在场时**三位都可能缺席其二** —— 有 `status` 没文本(应答体为空)、有文本没 `status`
+     *    (传输层失败)都是真实形。
+     */
+    respondRefusal?: ToolApprovalRespondRefusal;
+}
+/**
+ * #225 件5:respond 抛错的**结构化原文**(不是新的决断态,见
+ * {@link ToolApprovalFrameOutcome.respondRefusal})。
+ *
+ * 三位**各自独立**防御读、各自缺席不铸:`status` 只认有限数、`errorCode` 只认非空串、
+ * `message` 只认真读得出来的文本(取值序与 try 保护见 {@link readToolApprovalRespondRefusal})。
+ * 🔴 **三位皆缺席时整只不铸**(异源复审 [medium] 采纳,0.42.0):此前 `message` 是必填、读不出时
+ *    无条件退 `String(err)`,于是 `throw {}` 会得到一句 `"[object Object]"` —— 那不是 server 说的话,
+ *    是本层编的([honest-absence-not-fabricated-zero])。
+ * 🔴 **原样交还,零加工**:不 trim、不截断、不改写、不按识别表过滤。server 的拒句是给人看的
+ *    指路文本([5071] 三条 400 拒句各自成文),包边界任何一次改写都会让宿主呈的不再是引擎说的那句;
+ *    长度夹取与呈现归端(与 `message`/`approver` 同族口径)。
+ * 🔴 **UNTRUSTED-for-display**:它是 HTTP 应答体上的文本,只渲染,绝不回喂模型/工具入参。
+ */
+interface ToolApprovalRespondRefusalFields {
+    /** HTTP 状态(在场 = 引擎真应答了;缺席 = 传输层失败/注入面自抛,不许反推成 0)。 */
+    status?: number;
+    /** 机读码(开集,原样;缺席 = 应答没带码)。 */
+    errorCode?: string;
+    /**
+     * 拒句原文(server 的响亮拒文案)。
+     * 🔴 **缺席 = 这个抛出物上读不出任何可用文本**(异源复审 [medium] 采纳,0.42.0)——
+     *    此前本位是必填、读不出时无条件铸 `String(err)`,于是 `throw {}` 会得到一句
+     *    `"[object Object]"`、`throw null` 得到 `"null"`:那**不是** server 说的话,是本层编的,
+     *    与本形头注承诺的「读不出原文就缺席」直接冲突([honest-absence-not-fabricated-zero])。
+     */
+    message?: string;
 }
+/**
+ * 🔴 **「在场即至少有一位」写进类型**(异源复审 [medium] 采纳,0.42.0):三位全 optional 的
+ * interface 在类型上允许 `{}`,而实现明确承诺「三位皆缺席时整只返 `undefined`」——
+ * 消费端于是既不能依赖「对象在场 = 至少有一条诊断信息」,也没法穷举安全渲染。
+ * 用**三选一联合**把那条运行期不变量抬到编译期:`{}` 从此不可赋值。
+ */
+export type ToolApprovalRespondRefusal = (ToolApprovalRespondRefusalFields & {
+    status: number;
+}) | (ToolApprovalRespondRefusalFields & {
+    errorCode: string;
+}) | (ToolApprovalRespondRefusalFields & {
+    message: string;
+});
+/**
+ * 从 respond 抛出来的东西上读 {@link ToolApprovalRespondRefusal}。**永不抛、永不造**。
+ *
+ * 键位口径与 {@link import('../wireErrorTriage.js').classifyTurnWireError} 同源([2055] 死键
+ * 纪律:只认活键 `errorCode`,退役的 `code` 槽不做兼容)。
+ *
+ * @returns 三位**全缺席**时返回 `undefined` —— 一个三位皆空的 refusal 对象是「有拒句」的假象。
+ *
+ * 🔴 **文本取值序**(异源复审 [medium] 修):`err.message` 非空串 > 抛出物本身是非空串 >
+ *    受保护的 `String(err)`,且**只接受**真有内容的结果 —— `[object Object]` / `null` /
+ *    `undefined` 三种占位串一律当作「读不出」。
+ * 🔴 **`String(err)` 用 try 包住**:抛出物可以自带 `Symbol.toPrimitive` / `toString` 钩子并在里面
+ *    抛错。本函数的唯一调用点在 `surfaceToolApprovalFrameAndRespond` 的 catch 里,那里的契约是
+ *    「respond 失败 ⇒ 返回 unresolved」;让一个不可信的转换钩子把这条收敛路径变成 reject,
+ *    等于给注入面开了一个「让整次审批消费抛出去」的口。
+ */
+export declare function readToolApprovalRespondRefusal(err: unknown): ToolApprovalRespondRefusal | undefined;
 /** 结构性识别流上的 tool_approval 帧(named SSE frame,payload.type === 帧名)。
  *  ⚠️ 口径更正(2026-08-08):此处原写「非 AgentEvent arm」—— SDK #185a 起这两个帧**是**
  *  `AgentEvent` 的臂了(durable 腿也回放),所以结构识别与 union 收窄两条路都成立;本函数仍按
@@ -644,6 +1012,48 @@ export interface ToolApprovalFrameLaneOpts {
      * 缺席/false ⇒ 不发(fail-closed 到「不发」侧;决断本身照常送达,现状字节不变)。
      */
     approvalDecisionNoteCapable?: boolean;
+    /**
+     * server 能力位 `capabilities.respondFreeFormRules` 的读数(宿主从自己的 caps 缓存供给;
+     * server ≥7.44,#340 [5071] 恒真版本位)。
+     * 🔴 形与判据**逐字照** {@link approvalDecisionNoteCapable} 既有形(同一条 SDK 6.16 成文纪律:
+     *    **位缺席就别发**)。
+     * 缺席/false ⇒ 编辑臂的 `persistRule` **整条不发**(fail-closed 到「不发」侧;决断本身照常送达,
+     * 现状字节不变)。候选臂**不受本位影响**(它是 0.25.0 起就有的既有通道)。
+     *
+     * 🔴 **失效形订正**(异源对抗复审七轮 [medium];本段初稿把 `note` 那一位的失效形抄了过来):
+     *    编辑臂**不是**「老 server 静默忽略且照回 200」——`[5071]` 选 `persistRule.edited` 这个键名
+     *    的**全部理由**就是让老 server **诚实降级** `rule_not_offered`,而形/上限不合时更是响亮 400
+     *    (`PERSIST_RULE_TEXT_ERROR` / `PERSIST_RULE_EDITED_FLAG_ERROR`),**400 连决断一起拒**。
+     *    ⇒ 本位存在的理由不是「分辨静默 200」,是「能提前知道这台不供,就别把人的编辑送出去白跑一趟、
+     *    更别让它把决断打掉」。
+     * 🔴 **「老引擎零受迫」这句话有前提**(§7 **P-40**):本位是**per-baseUrl 的布尔缓存**,
+     *    **不与收 respond 的那个副本绑定**。引擎温切 / 滚动升级 / 多副本代理下,一个陈旧的 `true`
+     *    仍会把新形送到老副本上。宿主的义务:引擎 respawn/restart 后调
+     *    `invalidateEngineCaps(baseUrl, probe?)`;滚动窗口内宁可按 `false` 供(丢持久臂 + 一条
+     *    `surfaceRuleArmNotSent` 通知,远好于把人按下的决断打掉)。
+     */
+    respondFreeFormRulesCapable?: boolean;
+    /**
+     * server 能力位 `capabilities.respondBatchRuleOffers` 的读数(宿主从自己的 caps 缓存供给;
+     * server ≥7.46.0,#334 design/377 恒真版本位 —— 直证 = engine 7.46.0 fixture 的
+     * `@sema-agent/server/dist/http/routes/capabilities.js` 里 `respondBatchRuleOffers: true`)。
+     *
+     * 🔴 形与判据**逐字照** {@link respondFreeFormRulesCapable}(同一条 SDK 6.16 成文纪律:
+     *    **位缺席就别发**)。缺席/false ⇒ 批臂的 `persistRuleBatchOfferIndex` **整条不发**
+     *    (fail-closed 到「不发」侧;决断本身照常送达,现状字节不变)。
+     * 🔴 **为什么「帧上有 batch offer」不能顶替这道门**(异源对抗复审 [high] 采纳,施工时实证
+     *    ——该 caps 位在 7.46.0 上确实存在):供给面只证明**出帧的那一端**认识新形,不证明
+     *    **收 respond 的那个端点**认识它。滚动升级 / 多副本 / 代理后面站着一台 ≤7.45 的实例时,
+     *    旧解析器对 `persistRule.batchOfferIndex` 走的是「`persistRule.rule` 必须是非空串」那条,
+     *    **响亮 400 且连决断一起拒** —— 于是人按下的那次 allow 落不了地,退化成 unresolved/TTL 自决。
+     *    与 note 超限那条同一条纪律:附带愿望的失败绝不许升级成主动作的失败。
+     * 🔴 **本位是 per-baseUrl 缓存,不与 responder 绑定**(§7 **P-40**,与
+     *    {@link respondFreeFormRulesCapable} 同族):陈旧的 `true` 仍会把新形送到老副本上 ⇒
+     *    引擎温切后必须 `invalidateEngineCaps(baseUrl, probe?)`,滚动窗口内宁可按 `false` 供。
+     * 🔴 **只闸兑付,不闸展示**:位缺席时 batch offer 照旧上卡(`ApprovalCardRequest.ruleOffers`
+     *    字节不变)—— 端可以渲、可以走本地落规则那条路,只是**这条 wire 兑付通道**不开。
+     */
+    respondBatchRuleOffersCapable?: boolean;
     /**
      * 这条帧是不是**当下**从 live 流上收到的(异源对抗复审 P1 采纳;壳孪生帧族同名闸的
      * 本包席位 —— 壳 `approvalStreamWire` 头注逐字:「账本重放的历史帧带的是铸帧时刻的旧余量,
@@ -656,3 +1066,4 @@ export interface ToolApprovalFrameLaneOpts {
     windowIsCurrent?: boolean;
 }
 export declare function surfaceToolApprovalFrameAndRespond(frame: ToolApprovalFrame, respond: RespondToolApprovalFn, streamArgs: unknown | undefined, signal?: AbortSignal, lane?: ToolApprovalFrameLaneOpts): Promise<ToolApprovalFrameOutcome>;
+export {};