@sema-agent/client-core 0.56.0 → 0.58.0

package/dist/hitl/toolApprovalWire.d.ts

@@ -78,7 +78,8 @@
  *    🔴 方向纪律:reason/note 只做归因,绝不参与裁决;缺席 ⇒ 现状字节不变。
  */
 import { type GateCurrentPending, type HitlClientLike } from './hitlBridge.js';
-import type { RuleSuggestion, ToolApprovalRespondAck } from '@sema-agent/sdk';
+import { RULE_OFFER_MATCHES, RULE_OFFER_BATCH_MEMBER_KINDS, RULE_OFFER_UNCOVERED_REASONS } from '@sema-agent/sdk';
+import type { RuleSuggestion, ToolApprovalRespondAck, PersistedRuleAnchor as SdkPersistedRuleAnchor, RuleOfferMatch as SdkRuleOfferMatch, RuleOfferBatchMember as SdkRuleOfferBatchMember, RuleOfferUncoveredDetail as SdkRuleOfferUncoveredDetail, RuleOfferUncoveredReason as SdkRuleOfferUncoveredReason } from '@sema-agent/sdk';
 /** fs 写权限 gate 判定:未来的一等 kind(tool_approval)或按 toolName(server 桥首批=fs 写三件,
  *  [820] 表)。AskUserQuestion 永不进这里(ask 桥先判)。 */
 export declare function isFsApprovalGate(gate: {
@@ -140,29 +141,68 @@ export interface FsApprovalWireDeps {
  *  引用比较/JSON.stringify 串比较都会假报「编辑过」。 */
 export declare function structurallyEqual(a: unknown, b: unknown): boolean;
 /**
- * 一条「不再询问」候选的匹配形(server/core 闭词表,两代同词)。
+ * 一条「不再询问」候选的匹配形 —— **sdk 8.2.0 `RULE_OFFER_MATCHES` 派生**(四员闭词表:
+ * `exact` / `prefix` / `wildcard` / `subpath`)。
+ *
+ * 🔴 **B-025 的病形就在这一行**(0.43.0–0.57.0):本包按当时 server 的两员词表**手抄**
+ *    `'exact' | 'prefix'`,而 core design/382 / #510 把词表扩到四员之后手抄的那份没跟 ⇒
+ *    一条合法的 `match:"wildcard"` single 会被 {@link readRuleTriple} 判成坏形**整条丢掉**,
+ *    卡上那一格「不再询问」凭空消失。词表属上游,消费端手抄一份就是给自己立第二个判官。
+ * 🔴 **比铸点更窄的消费型面就是一句谎**(sdk 8.2.0 头注逐字):server 的 wire 校验器
+ *    `RuleMatchSchema = z.enum(PERSISTED_RULE_MATCHES)` 对这四个词一律放行 —— 更窄的型面
+ *    让 `switch` 在编译期自称穷尽,而运行期真会来第四个词。
+ * ⚠️ **端要跟的差分**:本类型从两员变四员是 0.58.0 唯一的非 additive 型面动作。在
+ *    `RuleOfferMatch` 上写 `switch`/穷举的端会在 `wildcard`/`subpath` 两格上编译红 —— 那正是
+ *    要显形的东西(此前那两格在端上是**静默不可达**,因为本包在读器里就丢掉了)。
  */
-export type RuleOfferMatch = 'exact' | 'prefix';
+export type RuleOfferMatch = SdkRuleOfferMatch;
 /**
- * `batch` 臂的一个成员 —— 复合命令**某一段**的规则(core `SegmentRuleSuggestion` 逐字)。
+ * `batch` 臂的一个成员 —— **sdk 8.2.0 `RuleOfferBatchMember` 判别联合**(core design/382 §2.3 B3):
+ *   · `kind:'command'` —— 历史形:复合命令某一段的 Bash 规则(四座 + 判别位);
+ *   · `kind:'directoryRead'` —— `cd <dir>` 段铸的**目录只读授权**(`rule` = 规范
+ *     `Read(//dir/**)` 文本,`directory` = 词法规范绝对目录;本臂**没有** `match`/`command`)。
+ *
  * `segment` = 这条成员是从哪一段折叠后的命令文本铸出来的:**渲染座,永不参与裁决**;
- * 它与 `rule`/`command` 同属 **UNTRUSTED-for-display**(原始 post-rewrite 命令字节)。
- * 上游形与本包归一形**共用这一个**(成员上没有下标这回事,两代/两腿逐字相同)。
+ * 它与 `rule`/`command`/`directory` 同属 **UNTRUSTED-for-display**。
+ *
+ * 🔴 **B-025 的第二半**:0.57.0 的成员形只认「三元组 + segment」、**没有** `directoryRead` 臂 ⇒
+ *    一只带 `directoryRead` 成员的合法 batch 被**整只丢掉**。本形改由 sdk 派生后该臂被认回。
+ * 🔴 **成员 `kind` 不识 ⇒ 丢整只 batch,绝不丢单个成员** —— 这是 core design/382 §2.3 的
+ *    **规范性降级臂**(逐字:"drops the WHOLE batch offer — never the single member ... and never
+ *    the whole card"),{@link readRuleOffers} 照此实现,判据钉在 run-rule-offers-reader 门里。
+ * ⚠️ **本包窄读器另收一条 pre-B3 兼容臂**:`kind` **缺席**的成员按 `kind:'command'` 归一
+ *    (server ≥7.46.0 到 B3 落地之间铸的成员没有判别位;窄读域只许等于或宽于铸点域)。
+ *    归一形上 `kind` 恒在场 —— 端拿到的成员永远是判别联合,零分支差异。
  */
-export interface RuleOfferBatchMember {
-    rule: string;
-    match: RuleOfferMatch;
-    command: string;
-    segment: string;
-}
+export type RuleOfferBatchMember = SdkRuleOfferBatchMember;
+/**
+ * `uncoveredDetail` 的一行 —— **sdk 8.2.0 派生**(design/382 §3.5 additive 明细座)。
+ * `segment` = 折叠后的段原字节(UNTRUSTED-for-display,与成员 `segment` 同一条纪律),
+ * `reason` = 闭三词集 {@link RuleOfferUncoveredReason}。
+ */
+export type RuleOfferUncoveredDetail = SdkRuleOfferUncoveredDetail;
+/** 「为什么这段仍未被覆盖」的闭三词集(server `UNCOVERED_SEGMENT_REASONS`,core 属主)。 */
+export type RuleOfferUncoveredReason = SdkRuleOfferUncoveredReason;
 /**
- * **wire 上的**一条 offer —— 与上游 core `RuleOffer` 逐字同形(**没有** `offerIndex`)。
+ * 三张闭词表的**运行期**再导出(sdk 8.2.0 `as const` 单源)。
+ *
+ * 🔴 **端拿它做判定,别再手抄字面量** —— 本包自己的窄读器就读这两张表(B-025 的根因正是手抄);
+ *    再导出让三端与包**共用同一份数组对象**,词表加员时一处改、四处跟。
+ */
+export { RULE_OFFER_MATCHES, RULE_OFFER_BATCH_MEMBER_KINDS, RULE_OFFER_UNCOVERED_REASONS };
+/**
+ * **wire 上的**一条 offer —— 与上游 sdk/core `RuleOffer` 逐字同形(**没有** `offerIndex`)。
  *
  * 🔴 为什么与归一形 {@link RuleOffer} 分开声明(异源对抗复审 [medium] 采纳):`offerIndex` 是
  * **本包铸的座**(见 {@link RuleOffer} 顶注),把它写进 {@link ToolApprovalFrame.ruleOffers} 的
  * 入参型 = 要求宿主为一个上游根本不发的字段负责 —— 真实 7.46.0 帧会**类型不合**,宿主只能强转,
  * 或者自己伪造一个本该由窄读器按**当前这条腿**算出来的下标(而两条腿的下标语义还不一样)。
  * ⇒ 入参面(帧/行)用本形,出参面(卡入参)用带下标的归一形,两者刻意不互相赋值。
+ *
+ * 🔴 **0.58.0(B-025)两处补形**,与 sdk 8.2.0 的 `RuleOffer` 逐字对齐:
+ *   · batch 成员改用判别联合 {@link RuleOfferBatchMember}(`command` | `directoryRead`);
+ *   · batch 臂补 **additive** `uncoveredDetail?`(缺席合法 —— server 对坏形的座**只丢座不丢批**,
+ *     所以缺席**不是**「没有未覆盖段」;真源恒是 `uncoveredSegments` 那个 count)。
  */
 export type WireRuleOffer = {
     kind: 'single';
@@ -173,19 +213,21 @@ export type WireRuleOffer = {
     kind: 'batch';
     rules: readonly RuleOfferBatchMember[];
     uncoveredSegments: number;
+    uncoveredDetail?: readonly RuleOfferUncoveredDetail[];
 };
 /**
  * 一张审批卡上的**一个**「不再询问」选项(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`**。上游 wire 形的类型供给口 `@sema-agent/sdk` 自 **8.2.0** 起
+ * 已经把 `RuleOffer` / `RuleOfferMatch` / `RuleOfferBatchMember` / `RuleOfferUncoveredDetail`
+ * 一起补齐(S-134 锚②)⇒ 本形的**每一个成员类型**都已改由 sdk 派生(见上面四条),本联合
+ * 只在两臂上各加一位本包铸的座。0.43.0–0.57.0 那段「先追 server 不等 SDK」的自铸记账随
+ * `AHEAD_OF_ANCHOR` 的 `ruleOffers` 登记一起**在 0.58.0 退役**。
+ * 语义来源锚 = `@sema-agent/core` `dist/core/permission-rule-model.d.ts`(`RuleOffer` 逐字契约)+
+ * `@sema-agent/server` `dist/approval-card.d.ts`(两臂 zod 形与两条腿的下标语义)+
+ * sdk 8.2.0 `dist/resources/tool-approvals.d.ts`(同形的类型面锚)。
  *
  * ── `offerIndex` 是本包铸的座(上游形上没有这一位)──────────────────────────────────────
  * core 的契约原话:消费端丢掉不认识的成员时**必须保住每个留下来成员的原始 wire 下标**,做不到就
@@ -193,6 +235,8 @@ export type WireRuleOffer = {
  * 键就是**下标**(`persistRule.batchOfferIndex`)。本包的窄读器是**逐条丢坏的**(一条坏 offer 不该
  * 让另一条真 offer 消失,与 server `boundedRuleOffers` 同向),压紧就会让下标前移 ⇒ 人点的第 k 个
  * 与服务端兑的第 k 个指向两条不同规则。所以窄读时把**原始下标**显式记在这一位上,兑付时按它回报。
+ * ⚠️ **「逐条丢坏」是 offer 级的,不是成员级的**:一只 batch 里有一个 `kind` 不识的成员 ⇒ **整只
+ * batch 丢**(core design/382 §2.3 规范性降级臂,理由见 {@link RuleOfferBatchMember} 顶注)。
  * 🔴 `offerIndex` 的定义域 = 「本包在**这条腿上**收到的那个数组里的下标」:
  *   · **活卡帧腿**(`ToolApprovalFrame.ruleOffers`):server 同步腿是纯前缀截、零逐条丢弃 ⇒ 它恒等于
  *     core 的 offer index,**是**合法选择键,`surfaceToolApprovalFrameAndRespond` 按它回兑;
@@ -214,12 +258,19 @@ export type RuleOffer = {
     /** 见本联合顶注。**batch 臂的兑付就是按这个数**(文本不可抄:合取批没有单条文本)。 */
     offerIndex: number;
     /** 1..5 条逐段规则(段序,按规则文本去重)。勾这一项 = 对**全体成员**一次性说是,
-     *  合取批**没有成员级选中**(要更窄的答案就选 single 臂或只批这一次)。 */
+     *  合取批**没有成员级选中**(要更窄的答案就选 single 臂或只批这一次)。
+     *  🔴 成员是判别联合({@link RuleOfferBatchMember}):`command` 臂带 `match`/`command`,
+     *     `directoryRead` 臂带 `directory` 且**没有**那两位 —— 端渲之前先读 `kind`。 */
     rules: RuleOfferBatchMember[];
     /** 铸卡时刻的诚实余量披露:这批兑完之后,按当时的覆盖快照仍未被任何规则放行的段数。
      *  0 = 「兑完这批,这条复合命令在那份快照的口径下就全覆盖了」。它是**对铸卡快照的陈述**,
      *  不是长期保证(并发删规则会让它过时)。 */
     uncoveredSegments: number;
+    /** design/382 §3.5 **additive** 明细座(0.58.0 起透传)—— 逐段给闭三词集的因由。
+     *  🔴 **缺席 ≠ 「没有未覆盖段」**:server 对坏形的座**只丢座不丢批**,老引擎更是压根不铸;
+     *     真源恒是 {@link uncoveredSegments} 那个 count。在场时**行数不强制**等于 count
+     *     (窄读器只丢坏行,不拿它反过来否决整只 batch —— additive 位绝不回头削弱既有位)。 */
+    uncoveredDetail?: readonly RuleOfferUncoveredDetail[];
 };
 /** 三选卡的原始决断(vendor 卡的三个选项 + abort + 表面失败)。allow_session=第 2 项
  *  (vendor 产出非空 permissionUpdates:setMode acceptEdits / cwd 外 addDirectories)。 */
@@ -627,8 +678,8 @@ export interface ToolApprovalFrame {
      *    7.44 及更旧的引擎今天仍在场(pin 未抬的部署、混舰队)。新键在场时**本键整条不看**。
      *    包内出口只有 {@link ApprovalCardRequest.ruleOffers} 一个,消费端不感知这次换键。
      * 🔴 本键留在 interface 与 {@link TOOL_APPROVAL_FRAME_KEYS_MIRROR} 里**不是**遗留包袱:
-     *    SDK 7.2.0 的运行期锚 `TOOL_APPROVAL_FRAME_KEYS` 仍含它,删掉会让对账门的
-     *    「SDK 锚的每个键本仓都有」当场红 —— 退役登记要等 SDK 跟着 server 一起退。
+     *    SDK **8.2.0** 的运行期锚 `TOOL_APPROVAL_FRAME_KEYS` 仍含它(node 直读实证),删掉会让
+     *    对账门的「SDK 锚的每个键本仓都有」当场红 —— 退役登记要等 SDK 跟着 server 一起退。
      */
     ruleSuggestions?: RuleSuggestion[];
     /**
@@ -646,8 +697,10 @@ export interface ToolApprovalFrame {
      * 🔴 文本由 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 带退出条件登记。
+     * ✅ **锚已追平(0.58.0 / sdk 8.2.0 提货,S-134 锚②)**:sdk 8.2.0 的运行期锚
+     *    `TOOL_APPROVAL_FRAME_KEYS` **已含本键**(node 直读 18 项实证),对账门
+     *    (run-approval-frame-keys-test.mjs)的 `AHEAD_OF_ANCHOR` 登记按它自己的退出条件
+     *    **随本批删除** —— 0.43.0–0.57.0 那条「先追 server 不等 SDK」的领先记账到此结清。
      * 耐久路对偶 = `PendingCheckpoint.ruleOffers`(同契约、**下标语义不同**:那条腿 server 已逐条
      * 丢弃压紧过,且无兑付口 ⇒ 下标只是展示座),由 {@link surfaceFsApprovalAndDecide} 消费。
      */
@@ -767,7 +820,7 @@ export interface ToolApprovalFrame {
      *    (帧 → {@link ApprovalCardRequest.inputHasBidi})。
      * 🔴 判据**不看 `message`**(引擎/策略写的说明文本,不是待执行输入)——两个来源折进一个布尔会让
      *    端无法判断该给哪一段加显形标记。
-     * 🔴 本键**领先** SDK 运行期锚一代(sdk 7.2.0 尚无)⇒ 对账门 AHEAD_OF_ANCHOR 带退出条件登记。
+     * 🔴 本键**领先** SDK 运行期锚一代(sdk 8.2.0 仍无)⇒ 对账门 AHEAD_OF_ANCHOR 带退出条件登记。
      * 耐久路今天**无对偶**(server 7.46.0 的 `PendingCheckpoint`/`riskDescriptor` 均未声明本键;
      * server 侧那份在**卡内**,不是行上的键)⇒ durable 行 → 卡那条腿不 stamp。
      */
@@ -914,78 +967,38 @@ export interface RespondToolApprovalOpts {
 }
 export type RespondToolApprovalFn = (approvalId: string, decision: ToolApprovalRespondDecision, opts?: RespondToolApprovalOpts) => Promise<ToolApprovalRespondAck | void>;
 /**
- * respond 回执的**包内视图** —— sdk `ToolApprovalRespondAck` 的 additive 超集(#334,0.43.0)。
+ * respond 回执的**包内视图**。
  *
- * 为什么是超集而不是直接用 sdk 那个形:server 7.46.0 的兑付回执上有两个**规范文本回显位**,而
- * sdk 7.2.0 的 `ToolApprovalRespondAck` 声明里还没有它们(与 `ruleOffers` 同一次锚滞后)。缺这两位,
- * 「规则真正存成了什么样」在包边界上被吞掉 —— 而编辑臂的落盘文本**可能与人敲的原字节不同**
- * (core 会把 `Bash(adb *)` 规范成 `Bash(adb:*)`),批臂更是一次落多条。
- *
- * 🔴 **超集只加不改**:继承 sdk 那个形的每一位,语义与字节零改动;既有消费端读 `rulePersisted` /
- *    `ruleRefusal` / `noteRecorded` 的写法一字不用动(返回型变宽对读方是源码兼容的)。
- * 🔴 sdk 锚补上这两位那天,本形按 `probeCause` 先例回收(直接用 sdk 形)。
+ * 🔴 **0.58.0(sdk 8.2.0 提货)起本形已按它自己写下的退役条款回收 —— 现在它就是 sdk
+ *    `ToolApprovalRespondAck` 本身**(别名保留只为源码兼容,端 import 的名字一个都不用改)。
+ *    0.43.0–0.57.0 它是一个 additive 超集,理由 = server ≤7.48.0 早已在回执上发的三位规范文本
+ *    回显(`persistedRule` / `persistedRules` / `persistedRuleAnchors`)当时**不在** sdk 声明里
+ *    (与 `ruleOffers` 同一次锚滞后,§7d P-44 登记的那一族)。sdk 8.2.0 的 S-134 锚③把三位
+ *    一起补上(`dist/resources/tool-approvals.d.ts` 的 `ToolApprovalRespondAck` 逐字在场)⇒
+ *    退役条件满足,超集不再有存在理由(留着 = 两份会各自漂的同名形)。
+ * 🔴 **判形与窄读一个字节没改**:{@link readToolApprovalRespondAck} 的每一条纪律照旧 ——
+ *    三位规范文本回显**整只判形**(半份清单/半份归属表比没有更坏)、单复数**同场即互斥矛盾**、
+ *    回显在场而 `rulePersisted !== true` 即自相矛盾、锚与清单**逐位置同文本**。上游补的是**类型**,
+ *    不是判官:wire 是 JSON,sdk 的 optional 声明是 server 的承诺不是本层的前提。
+ * 🔴 **锚缺席时端的呈现口径**(0.44.0 立,退役后仍然成立,故留在此处):`persistedRuleAnchors`
+ *    缺席(≤7.47 引擎)时本包对 `persistedRules` 做到的相关性只有 **id + decision + 基数**
+ *    ({@link surfaceToolApprovalFrameAndRespond} 的臂相关性门)—— 基数抓得到「少报/多报」,
+ *    **抓不到**「条数对但内容是另一批规则」。⇒ 那种情形下端要把它渲成「**引擎报告**落盘的规则」,
+ *    **不是**「你刚才选的那批规则」。锚在场时限制解除(`offerIndex` 已把清单钉在用户真选的那只 offer 上)。
  */
-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 ⇒ 字段省略;**缺席 ≠ 空**。
-     *
-     * ✅ **P-39 已到货**(server 7.48.0,client-core 本批):上游补的 additive 锚 =
-     *    {@link ToolApprovalRespondAckView.persistedRuleAnchors}(每条带 `offerIndex` + `memberIndex`)。
-     *    本注按 `probeCause` 先例跟批收紧 —— 下面这段记的是**锚缺席时**(≤7.47 引擎)仍然成立的残余:
-     * 🔴 **锚缺席 ⇒ 逐条归属证不出**(异源对抗复审三轮 [medium] 登记的原始形)。那种情形下本包对这一位
-     *    做到的相关性只有 **id + decision + 基数**({@link surfaceToolApprovalFrameAndRespond} 的臂相关性
-     *    门):条数必须等于所选 batch 的成员数。基数抓得到「少报/多报」,**抓不到**「条数对但内容是
-     *    另一批规则」—— 因为回执上没有任何锚能把这 N 条与那只 offer 对上(文本等式在这一位上不成立:
-     *    落盘的是**规范化后**的文本,与 offer 上的文本按设计可以不同,拿文本去比就是装第二个判官)。
-     * 🔴 ⇒ **锚缺席时端的呈现口径**:把它渲成「**引擎报告**落盘的规则」,**不是**「你刚才选的那批规则」。
-     *    两句话在正常情形下指同一件事,但只有前一句是本包在无锚时能背书的。
-     *    **锚在场时**这条限制解除:`offerIndex` 已经把这份清单钉在用户真选的那只 offer 上。
-     */
-    persistedRules?: readonly string[];
-    /**
-     * server ≥7.48.0(P-39 正位解;#340/#334 批臂回执的**归属锚**)——批臂兑付成功时,每条落地规则
-     * 与它**出自哪只 offer 的哪个成员**的对应关系。
-     *
-     * 直证(engine 7.48.0 fixture `@sema-agent/server/dist/tool-approval.js`):park 迟到腿 `:1360` 与
-     * live 腿 `:1461` 两处逐字铸
-     * `persistedRuleAnchors: persisted.members.map(m => ({ offerIndex: persistRule.batchOfferIndex,
-     *  memberIndex: m.memberIndex, rule: m.rule }))`。
-     * 🔴 **载体是 respond 的 200 体**(与 `rulePersisted`/`persistedRules` 同级),**不是帧** ——
-     *    所以它进的是本 ack 视图,不进 {@link TOOL_APPROVAL_FRAME_KEYS_MIRROR}。
-     * 🔴 **只在批臂 ∧ 兑付成功 ∧ server 交得出 `members` 时在场**;单臂/失败/老 server ⇒ 缺席
-     *    (**缺席 ≠ 空数组**:空数组会被读成「一条都没落」)。
-     * 🔴 **整只判形**(与 `persistedRules` 同族):坏形一律整只降缺席 —— 半份归属表比没有更坏,
-     *    它驱动的断言是「这条规则出自**你选的那只批**」。判形见 {@link readPersistedRuleAnchors}。
-     * 🔴 它**不替代** `persistedRules`:后者是展示序的规范文本清单(端逐条回显的那一份),
-     *    本位是给**相关性门**用的归属证据。两位同场时条数必须一致,否则本位整只降缺席
-     *    (additive 位绝不回头削弱既有位的现行为)。
-     */
-    persistedRuleAnchors?: readonly PersistedRuleAnchor[];
-}
+export type ToolApprovalRespondAckView = ToolApprovalRespondAck;
 /**
  * {@link ToolApprovalRespondAckView.persistedRuleAnchors} 的成员形(server 7.48.0 逐字三键)。
  *
+ * 🔴 **0.58.0 起直接是 sdk 8.2.0 的同名形**(S-134 锚③同批补;本包不再自铸)。此前本包自铸的
+ *    那份三键**逐字同形**,唯一差别是本包给三位钉了 `readonly` —— 别名化之后跟随 sdk 声明
+ *    (读方源码兼容;本包自己的铸点仍只在 {@link readPersistedRuleAnchors} 一处,不外泄可写引用)。
+ *
  * `offerIndex` = 兑付时发出去的 `persistRule.batchOfferIndex`(整表同值 —— server 的 map 闭包捕获的
  * 就是那一个值);`memberIndex` = 该条在 batch offer 成员表里的下标;`rule` = **落盘后**的规范文本
  * (与 `persistedRules` 的同序成员同值;规范化是引擎的活,本包不复判文本)。
  */
-export interface PersistedRuleAnchor {
-    readonly offerIndex: number;
-    readonly memberIndex: number;
-    readonly rule: string;
-}
+export type PersistedRuleAnchor = SdkPersistedRuleAnchor;
 /**
  * respond 回执的**结构化读口**(wire 是 JSON:注入面可能是旧 liveClient 的 raw fetch,也可能是
  * 比本包新一版的 SDK)。坏形一律降 `undefined` —— 与 `controlRouter.errCodes` 同族纪律:
@@ -1087,6 +1100,54 @@ export declare function readToolApprovalRespondRefusal(err: unknown): ToolApprov
  *  `AgentEvent` 的臂了(durable 腿也回放),所以结构识别与 union 收窄两条路都成立;本函数仍按
  *  结构读(不依赖类型收窄),因为它同时服务 raw SSE 与 durable 回放两条入口。 */
 export declare function isToolApprovalFrame(ev: unknown): ev is ToolApprovalFrame;
+/**
+ * `ruleOffers`(server ≥7.46.0 的判别联合)的结构读。
+ *
+ * 🔴 **[C228]/L-103(0.57.0)起本口是公面**(additive 导出,语义与字节一字未改)。此前它只经
+ * **卡端口**({@link ApprovalCardRequest.ruleOffers})出包 —— 不走卡端口架构的宿主(浏览器端没有
+ * Ink 三选卡,自己拿帧渲)只能在自己那边**重铸一遍**同一把窄读器,而这把窄读器承载的是
+ * **兑付安全**判据(原始下标不前移、逐条丢坏、闭集 kind),重铸一次 = 多一份会各自漂的判官。
+ * ⇒ 公面出口是「判定归包、呈现归端」在这一条腿上的兑现,不是便利函数。
+ * 🔴 **两代 wire 键请走 {@link readRuleOfferSupply}**:本函数只读**新键**(server ≥7.46.0 的
+ * `ruleOffers`);退役键 `ruleSuggestions`(server ≤7.45)的归一在那一口,两键的取舍序也在那里
+ * (新键在场即定局,绝不混编)。手里只有新键才直接用本口。
+ * 🔴 **`offerIndex` 的定义域随腿不同**,消费前必读 {@link RuleOffer} 顶注:活卡帧腿上它是合法
+ * **选择键**(可当 `persistRule.batchOfferIndex` 回兑),durable 行腿上它只是展示/对账座
+ * (server `boundedRuleOffers` 已压紧过一次)——**本函数不知道调用方在哪条腿上**,分辨是调用方的事。
+ *
+ * 🔴 **逐条丢坏、原始下标不前移**:坏 offer 逐条丢弃(一条坏的不该让另一条真的消失,与 server
+ * `boundedRuleOffers` 同向),但留下来的每一条都带**原始 wire 下标** {@link RuleOffer.offerIndex} ——
+ * core 的契约原话:做不到保住原始下标的消费端「must suppress its persistence actions entirely」,
+ * 因为 `batch` 臂的兑付键就是下标。压紧 = 人点的第 k 个与服务端兑的第 k 个指向两条不同规则。
+ * 🔴 `kind` 是**闭集判别位**:不认识的 kind ⇒ 丢这一条(不猜、不降级成 single)。
+ * 全部不合形/非数组/超帽 ⇒ 整体缺席(卡不渲「不再询问」档)。
+ */
+export declare function readRuleOffers(v: unknown): RuleOffer[] | undefined;
+/**
+ * 两代 wire 供给 → **包内单一形**(#334/[5223],0.43.0):新键优先,新键整只读不出来才看旧键。
+ *
+ * 🔴 **[C228]/L-103(0.57.0)起本口是公面**(additive 导出,语义与字节一字未改;0.56.0 及更早的
+ * 内部名是 `readOfferSupply`,**纯改名**没有第二个消费点)。宿主手里拿到的是**一整帧/一整行**,
+ * 上面同时可能有 `ruleOffers`(新)与 `ruleSuggestions`(旧)两个键 —— 这一口是三端唯一该调的那个:
+ *   `readRuleOfferSupply(frame.ruleOffers, frame.ruleSuggestions)`。
+ * 两代键的取舍序是**判据不是便利**(见下面两段红条),端各写一遍必然在 `null` 那一格上各错一遍。
+ *
+ * 🔴 **新键在场即定局,绝不混编**:新键**有载体**而读出空(数组在但全条坏形、或压根不是数组)
+ * 也**不**回落旧键 —— 一台 7.46 引擎不会同时按两代形铸候选,拿旧键顶上去等于把一份异源素材
+ * 冒充成这次 ask 的候选。
+ *
+ * 🔴 **`null` 与 `undefined` 同视为「新键缺席」**(异源对抗复审 [medium] 追问后的**明示裁定**,
+ * 不是漏判):判据是**代价不对称**——
+ *   · 认 null 为缺席的失效面:一台 **7.46** 引擎把新键发成 `null` **且**同时发了旧键。这不可能
+ *     发生:7.46 的三腿上旧键一个字都不铸(engine fixture 直证,同文件 0 命中)⇒ 回落读到的
+ *     只会是 `undefined`,结果与「整只缺席」逐字节相同,没有异源素材可混;
+ *   · 认 null 为坏形的失效面:任何把「缺席」序列化成 `null` 的中转层(JSON 规范化包装器、
+ *     某些 SQL/JSONB 读面、mock)会让**所有 ≤7.45 引擎**的「不再询问」档整段消失 —— 那正是
+ *     [5223] 这一批要修的病本身,只是换了个触发条件。
+ * ⇒ 取「null == 缺席」。安全面上它**不新增**任何攻击面:一个能塞 `{ruleOffers:null, ruleSuggestions:[…]}`
+ * 的注入面,同样能只塞 `{ruleSuggestions:[…]}`,而后者为了兼容 7.44 本来就必须收。
+ */
+export declare function readRuleOfferSupply(offers: unknown, legacy: unknown): RuleOffer[] | undefined;
 /** 帧腿的宿主车道参数(#229 respond-note 批,0.29.0)。 */
 export interface ToolApprovalFrameLaneOpts {
     /**
@@ -1150,4 +1211,3 @@ export interface ToolApprovalFrameLaneOpts {
     windowIsCurrent?: boolean;
 }
 export declare function surfaceToolApprovalFrameAndRespond(frame: ToolApprovalFrame, respond: RespondToolApprovalFn, streamArgs: unknown | undefined, signal?: AbortSignal, lane?: ToolApprovalFrameLaneOpts): Promise<ToolApprovalFrameOutcome>;
-export {};