@sema-agent/client-core 0.77.1 → 0.78.0

package/dist/hitl/toolApprovalWire.d.ts

@@ -1,115 +1,19 @@
-/**
- * ⇄ B7 批搬迁(2026-07-27,设计稿 §3 B7):cli `src/sema/liveToolApprovalWire.ts`(508 行)——
- *    **拆**(设计稿原文:「liveToolApprovalWire.ts | 509 | …… | **拆分**,B7;工具 schema 属
- *    agent-types 域」)。
- *
- * ── 拆缝在哪 ────────────────────────────────────────────────────────────────────────────────
- * **进包(本文件)**:gate 判定(`isFsApprovalGate` / `toolNameIsFsWrite`)· 结构等值
- *   (`structurallyEqual`,ctrl+g amend 的「真编辑过」判据)· 同步帧契约与判别式
- *   (`ToolApprovalFrame` / `isToolApprovalFrame` / `isFromSubagent`)· 徽章合成
- *   (`subagentBadgeFor`)· gate 文案兜 path(`pathFromGateMessage`)· **两条决断腿的编排**
- *   (`surfaceFsApprovalAndDecide` durable-park 腿 / `surfaceToolApprovalFrameAndRespond` 同步帧腿)。
- * **留宿主**:**卡本身**(`surfaceApprovalCard`)—— 它要 leader `ToolUseConfirm` 队列、壳的
- *   vendored `Tool` 注册表(`FileWriteTool`/`FileEditTool`/`NotebookEditTool`/`EngineWorkflowTool`)、
- *   `applyPermissionUpdates` 与 `AppState.toolPermissionContext`。那是**端的渲染与权限态**,
- *   web/桌面各有各的形(浏览器根本没有 Ink 三选卡)。落点 = 下面的 `ApprovalCardPort`。
- *
- * 🔴 **拆缝的失效形**([paired-mechanisms-must-share-premise]):卡口没装 ⇒ 两条腿都拿不到人的
- *   决断。**这不是「静默不启用」可以接受的面** —— 同步帧腿上引擎正同步阻塞着,不 respond 就干等
- *   TTL;durable 腿上 run 卡在 suspended。所以本口:
- *     · **计 miss**(`approvalCardPortMisses()`,宿主自检恒应为 0);
- *     · 缺席时返回 `{kind:'failed', reason:'no approval card port installed …'}` —— 与壳原文
- *       「no leader ToolUseConfirm queue registered(print/non-REPL mode)」**同一条 fail-soft 语义**
- *       (print/headless 本来就没有卡面),调用方照旧走 fail-closed deny / 诚实红。
- *
- * 🔴 搬迁差分(逐条,零行为变化):
- *   1. `toolForName`(4 个 `require('../tools/…')`)整条留宿主 —— 工具注册表是壳资产。
- *   2. `getLeaderToolUseConfirmQueue` / `getLeaderSetToolPermissionContext` / `applyPermissionUpdates` /
- *      `getAppStateStoreRef` / `syntheticAssistantMessage` / `stubToolUseContext` 全部随卡留宿主。
- *   3. `logForDebugging` → `hostLog('debug'|'error', …)`(本包零 `utils/debug`,portability 门盯着)。
- *   4. `require('./fleetClient.js').readEngineActiveBgTasks()` → 静态 import 包内
- *      `fleet/fleetLedger.js` 的同名读口(B6 已搬入;延迟 require 的理由「纯 wire 模块不背 fleet 图
- *      冷启动」在包内不成立 —— 同一个包)。⚠️ try/catch 保留:台账不可用时兜 taskId 短形那一支
- *      仍要成立。
- *
- * ── 以下为原文件的领域说明(逐字保留)────────────────────────────────────────────────────────
- *
- * liveToolApprovalWire — 权限三选卡的壳侧半场([816] 壳侧承诺① / [819]② / [820] 四模式表,2026-07-14)。
- *
- * WIRE(server 1.191 已到货,[830]①):引擎对 fs 写工具(Write/Edit/NotebookEdit)出 ask ——
- * 真腿=同步 `tool_approval` 帧(named SSE,redactDeep+16KiB 帽)→ 三选卡 → POST
- * /v1/tool-approvals/:id/respond {allow|allow_session|deny}(本文件下半)。durable park 腿
- * (checkpointGate → approvals.decide)🔴 **现势(REF-CC-023/031,2026-08-02)**:不是「旧引擎兜底」——
- * [2150] S1 半场(83-87 行)证实产品默认 durable 投递下,引擎对 Bash 出的 durable park 就是**活路径**
- * (r1 E5 fail-stuck 实例);synthApprovalProbe 合成单测仍在,但这条腿今天会被真用户真流量走到。
- * 本模块把 gate 面翻成壳的 VENDORED CC 权限对话框(PermissionRequest → FileWritePermissionRequest,
- * 三选文案逐字 CC 207:`Yes` / `Yes, allow all edits during this session (shift+tab)`[cwd 外变体带
- * dirname] / `No`,题干 `Do you want to create <basename>?` verb=create/overwrite/write to)——零新 UI,
- * 键行为(1/2/3、shift+tab 聚焦第 2 项、esc=reject)全部继承 vendor 组件。
- *
- * 决断腿:
- *  - Yes(accept-once)→ HitlBridge.decideTool({decision:'approve'})(D-1 绑定 verbatim,合 [819]②)。
- *  - Yes-allow-all(accept-session)→ 同 approve,且 permissionUpdates 里 vendor 产出的
- *    `{type:'setMode', mode:'acceptEdits', destination:'session'}` 经 leader setter 落壳 AppState →
- *    seamQuery 的 permissionModeField 下一 turn 起 stamp `permissionMode:"acceptEdits"`([816] 壳侧
- *    承诺②:accept-session=升 intent,wire 已通)。cwd 外变体还带 addDirectories(session)——照 CC 收。
- *  - No(reject)→ decideTool({decision:'deny'});调用方(liveHitlAskWire)对该 call 的重放 tool_end
- *    stamp REJECT_MESSAGE,vendor 的 renderToolUseRejectedMessage 渲 `User rejected <op> to <path>`
- *    (subtle 色,CC 逐字)。
- *
- * 🔴 fail-soft 铁律(与 ask 桥同款):leader 队列未注册(print/非 REPL)、pending 蒸发、decide 409/404
- *   都返回 failed —— 调用方回退「flush + 原样终帧」的诚实红,绝不更糟。
- * 🔴 UNTRUSTED:gate args 为模型作文(service 已 redact),只渲染绝不回喂;决断只带 decision 枚举。
- *
- * ── #144 半场(client-core 0.28.0)────────────────────────────────────────────────────────────
- * ① **透传** `persistedRuleShadowed`(server ≥7.13.0,来源锚 = engine fixture
- *    `@sema-agent/server/dist/tool-approval.d.ts` 同名键;ADDITIVE、`tool_approval` only)——
- *    帧 → {@link ApprovalCardRequest.persistedRuleShadowed},壳据此渲「你的规则仍在,只是这次被
- *    要求逐次确认」。🔴 它是 **display 值,不是身份通道**:脱敏后的展示文本,不保证与规则店里那条
- *    规则逐字节相同、更不是它的 id;下游「删除/撤销规则」面拿它当身份用 = 删错或删不掉。
- * ② **deny 归因通道**({@link ApprovalCardDenyDecision.reason}):两腿不同形 ——
- *    durable `/decide` **有** reason 位 ⇒ 原文上 wire(包内按 server 4096 上限截断);
- *    live 帧腿 `/v1/tool-approvals/:id/respond`:✅ **#229 已兑现**(0.29.0 respond-note 批,
- *    server ≥7.15.0)—— 端点收 **`note`**(不是 reason;与 durable `AskDecisionBody.note`
- *    同词同源同一列 `decision_note`),deny reason 经 {@link RespondToolApprovalOpts.note} 上 wire。
- *    发送前置两道门:能力位 `approvalDecisionNote`(SDK 6.16 成文「位缺席就别发」)+ 2048 上限
- *    (server 超限响亮 400 且**连决断一起拒**,所以超限 ⇒ 整条不发 + 留痕,诚实缺席优先于
- *    静默截断);真落行与否看 ack 的 `noteRecorded`(缺席 ≠ false)。
- *    🔴 方向纪律:reason/note 只做归因,绝不参与裁决;缺席 ⇒ 现状字节不变。
- */
 import { type GateCurrentPending, type HitlFailureStage, type HitlSafetyCode, type HitlClientLike } from './hitlBridge.js';
 import { type RuleStoreUnreadableKind } from '../gateVocabulary.js';
 import { type DecideReceiptView } from '../decideReceipt.js';
 import { RULE_OFFER_MATCHES, RULE_OFFER_BATCH_MEMBER_KINDS, RULE_OFFER_UNCOVERED_REASONS, RULE_OFFERS_ABSENCE_REASONS, DENIAL_LIMIT_KINDS } from '@sema-agent/sdk';
 import type { RuleSuggestion, ToolApprovalRespondAck, PersistedRuleAnchor as SdkPersistedRuleAnchor, RuleOfferMatch as SdkRuleOfferMatch, RuleOfferBatchMember as SdkRuleOfferBatchMember, RuleOfferUncoveredDetail as SdkRuleOfferUncoveredDetail, RuleOfferUncoveredReason as SdkRuleOfferUncoveredReason, AskOrigin as SdkAskOrigin, RuleOffersAbsence as SdkRuleOffersAbsence, DenialLimitKind as SdkDenialLimitKind, DenialLimitFallback as SdkDenialLimitFallback } from '@sema-agent/sdk';
-/** fs 写权限 gate 判定:未来的一等 kind(tool_approval)或按 toolName(server 桥首批=fs 写三件,
- *  [820] 表)。AskUserQuestion 永不进这里(ask 桥先判)。 */
 export declare function isFsApprovalGate(gate: {
     kind?: unknown;
     toolName?: unknown;
 } | undefined | null): boolean;
 export declare function toolNameIsFsWrite(name: string): boolean;
-/** shell 执行工具判定(Bash)。[2150] S1 半场:引擎对 Bash 发 durable park 时,fs 谓词不认 ⇒
- *  park 落「其余 gate 透传」= run 留 suspended、session 锁死(r1 E5 fail-stuck 实例)。 */
 export declare function toolNameIsShellExec(name: string): boolean;
-/** 工具审批 gate 判定(durable park 分诊用的**超集**谓词):一等 kind / fs 写三件 / shell 执行。
- *  decide 腿(approvals.decide)对两族同构;卡形分发归壳 ApprovalCardPort(toolForName 已含
- *  bash → BashPermissionRequest 映射,sema-cli a35e2b2)。`isFsApprovalGate` 保留原语义不动
- *  (公开面消费者按 fs 写理解它,把 Bash 塞进去是撒谎)。 */
 export declare function isToolApprovalGate(gate: {
     kind?: unknown;
     toolName?: unknown;
 } | undefined | null): boolean;
-export type FsApprovalOutcome = 
-/** `receipt`(B-070 / L-200,0.65.0):这次 decide 的 **200 回执读数**
- *  ({@link import('../decideReceipt.js').DecideReceiptView})。两件事靠它:
- *   · **续跑挂在哪条 run 上** —— `handoffTaskId` 在场 ⇒ workflow 车道把续跑交给了**宿主新铸**的
- *     run(sdk README §9.0.0:「poll 它,不要盯那张卡」),重挂腿必须换挂过去;
- *   · **那个已决动作最后被怎么处置** —— `executionOutcome`(只在幂等回放形上)。
- *  🔴 **缺席什么都不证明**:老 server / 终局形 / 回体读不动,三形同样缺席。尤其
- *     `executionOutcome` 缺席 = **未知**,禁读成 allowed(上游两处逐字,见 `decideReceipt.ts` 顶注)。
- *  🔴 **它不是「门已解决」的证据**:200 只是投递受理(B-070 的病根就是把它当解决)。 */
-{
+export type FsApprovalOutcome = {
     kind: 'decided';
     gatedCallId?: string | undefined;
     denied?: boolean | undefined;
@@ -117,58 +21,10 @@ export type FsApprovalOutcome =
 } | {
     kind: 'aborted';
     gatedCallId?: string | undefined;
-}
-/** 0.74.1(CC-67):宿主撤卡,零 decide;见 {@link ApprovalCardDecision} 的 retracted 臂。 */
- | {
+} | {
     kind: 'retracted';
     gatedCallId?: string | undefined;
-}
-/** `retryExhausted`(Inkglow-1085 P0a,0.37.0):decide 出站在**瞬断类**失败上重试一次仍未送达
- *  (两发都没拿到引擎的语义答复)—— 在场即真。消费方(parkResolver)据此走**重呈臂**(re-attach
- *  重放 park ⇒ 同一张卡重新交给用户),不合成 `hitl_unanswered` 判死 turn。缺席 = 语义类失败
- *  (引擎答了且拒了)或卡面失败,既有 fail-soft 语义逐字节不变。
- *  `code`(#357,0.47.0):**取件当拍队列里没有本 run 的可决行** —— `findPendingForTask` 的
- *  结构化判别位原样透传(此前本类型没有这个位,消费点只能拿 `reason` 的文案子串猜,而
- *  `parkResolver.isAlreadyResolvedFailure` 的头注把「fs 腿没有 code」记成了已知缺口)。
- *  🔴 只透传取件腿那一个码:decide 失败(409/404 语义答复)不落这个位 —— 那两件事对消费点
- *  是不同处置(前者「这一拍没有行」可以重探,后者是引擎的语义答复)。 */
-/** `currentPending`(#363,0.47.0):**decide 失败**那一类才可能带 —— server S-02(≥7.52)在
- *  409 `approval_stale` 拒体上铸的 additive **指路键**,说的是「你手上那条已经不是当前的了,
- *  **当前**这条长这样」。壳据此**一跳重定位**再 decide,免整队重拉。
- *  🔴 缺席是常态,而且缺席**什么都不证明**:老 server / 非工具门 / 行读失败 / 本次失败根本
- *     不是 stale 臂,四种情形在 wire 上同形(server 自己的 F 类留痕账逐字如此)。
- *  🔴 它**不参与任何裁决** —— 见 `GateCurrentPending` 顶注;消费方拿它当指路,不当放行凭据。
- *  🔴 **取件腿的 `no_pending` 恒不带这一位**:那一腿连 decide 都没发,谈不上「你决的那条过期了」。 */
-/** `errorCode`(0.60.0,上游候包件 ②;与 0.47.0 补 `currentPending` **同形**):这次失败的
- *  **引擎机器码**,原样透传(`readWireErrorCode` 单源读口)。
- *  🔴 **它与 {@link code} 是两个命名空间,绝不合并**:`code` 是**本包铸**的取件腿判别位(闭集,
- *     今天只有 `no_pending`),本位是 **server/core 铸**的 wire 码(开集,`resume.preflight_rejected`
- *     / `approval_stale` / …)。合成一个位会让消费点拿两种语义当一种用。
- *  🔴 **为什么非补不可**:本类型把 typed 错**拍平成 `reason` 串**,于是只读 outcome 形的消费者
- *     对机读码全盲,要分辨拒绝族只能去正则匹配那句拍平文案(里面嵌的是 `String(e)`,上游改一个
- *     词就静默空转)。
- *  🔴 **缺席不带语义**:取件腿的失败、卡口失败、以及抛出物身上根本没有码的传输类失败,三形同样
- *     缺席 —— 缺席 ≠「不是引擎拒的」。
- *  🔴 **只搬码,不搬正文**:错误正文可能含凭据/内部路径,照旧只进 `reason` 的既有拍平位,
- *     不经本位外流。 */
-/** `stage`(0.60.0,异源对抗复审 [medium] 采纳:B-037 候包件 ② 的**完整**兑现):这次失败**停在
- *  链条的哪一段**。四类失败此前在本形上不可分 —— 「取件那一拍没有可决行」「卡口没装」「引擎语义
- *  拒绝」「出站瞬断耗尽」拍平之后**只剩一个 `reason` 串**,消费点要分流只能去正则匹配那句文案
- *  (里面嵌的是 `String(e)`,上游改一个词就静默空转)。⇒ 本位是**必填**的:一个可选的阶段位等于
- *  又留了一格「读不出就猜」。
- *   · `fetch`  —— 取件腿(`findPendingForTask`)没给出可决行,或读面自己炸了;
- *   · `input`  —— 行上没有可呈现的工具入参(卡渲不出来);
- *   · `card`   —— 卡口那一段失败(没装卡口 / 卡口自己报失败);
- *   · `decide` —— 决断已经发出去了(引擎语义拒绝、或出站瞬断耗尽)。
- *  🔴 **只有 `decide` 这一段代表「引擎那一头知道这次决断」**——安全停(是否要重呈、能否重试)
- *     的第一问就是它,而前三段一个字节都没送出去。 */
-/** `safetyCode`(0.60.0,同批):本包**自己**的安全停判别位({@link HitlSafetyCode} 闭五词)。
- *  🔴 与 {@link errorCode}(server/core 铸的 **wire** 码,开集)、{@link code}(取件腿的闭集判别位)
- *     是**三个命名空间**,绝不合并 —— 「本地拦下的」「引擎拒的」「这一拍没有行」是三件不同的事,
- *     出路也不同(重呈 / 换参数或等 / 重探)。
- *  🔴 与 ask 腿 `parkResolver.GateOutcome.failed.code` **同形同源**(那一腿早有这一位,fs 腿此前没有
- *     —— 同形存量清剿:两件 hitl 文件一次改齐)。 */
- | {
+} | {
     kind: 'failed';
     stage: HitlFailureStage;
     gatedCallId?: string | undefined;
@@ -179,123 +35,21 @@ export type FsApprovalOutcome =
     retryExhausted?: true;
     currentPending?: GateCurrentPending | undefined;
 };
-/** 本桥消费的 wire 面(liveHitlAskWire 的 AskGateWireDeps 同形切片,mock 可注入)。 */
 export interface FsApprovalWireDeps {
     client: HitlClientLike;
-    /** L-80(对抗复审 r2 [medium]):**这一次调用**真把卡交给卡口时回调一次 —— 每次调用各自的回执,
-     *  不是进程级计数(那会把并发会话 A 的呈卡算到 B 头上)。缺席 = 不关心。 */
     onPresented?: () => void;
 }
-/** 结构等值(键序无关深比较)——updatedInput「真编辑过」判定用。zod parse 会产新引用与重排,
- *  引用比较/JSON.stringify 串比较都会假报「编辑过」。 */
 export declare function structurallyEqual(a: unknown, b: unknown): boolean;
-/**
- * 一条「不再询问」候选的匹配形 —— **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 = SdkRuleOfferMatch;
-/**
- * `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`/`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 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;
-/**
- * 三张闭词表的**运行期**再导出(sdk 8.2.0 `as const` 单源)。
- *
- * 🔴 **端拿它做判定,别再手抄字面量** —— 本包自己的窄读器就读这两张表(B-025 的根因正是手抄);
- *    再导出让三端与包**共用同一份数组对象**,词表加员时一处改、四处跟。
- */
 export { RULE_OFFER_MATCHES, RULE_OFFER_BATCH_MEMBER_KINDS, RULE_OFFER_UNCOVERED_REASONS };
-/**
- * 一只 ask 的**出身** —— **sdk 8.3.0 `AskOrigin` 派生**(core `ASK_ORIGINS`,7.14.0 起十一词:
- * `content_question` / `ancestor_marked` / `org_unavailable` / `org_rule` / `rule_store_unavailable` /
- * `hook` / `ask_rule` / `denial_limit_fallback` / `shell_gate_tighten` / `safety_tighten` / `policy`;
- * **引擎在门上盖章**,不是策略的自称)。
- *
- * 🔴 **词表唯一属主是 core**,本别名只是型面供给(闭集给补全,`(string & {})` 让新词读得出来)——
- *    端一律按**开集**分支:认不得的词渲「未知出身」,**绝不**渲成「没有出身」。
- * ⚠️ **sdk 8.8.0 的联合滞后一代**:它还写着 7.13.x 的 `unresolvable`,而 core 7.14.0 已把那一员
- *    **BREAKING 换成 `ancestor_marked`**(无 alias)。本包的**运行期**词表 `ASK_ORIGIN_WORDS`
- *    (`gateVocabulary.ts`)跟的是 **core 的真字节**,sdk 追平那天 `run-gate-vocabulary-test.mjs`
- *    的滞后登记会自红逼删。一条 pre-7.14 的耐久行带 `"unresolvable"` ⇒ 非成员 ⇒ 投影**省略**那一格。
- * 🔴 与 {@link ToolApprovalFrame.governanceForced} **不是**一回事(sdk 顶注逐字):本词答「哪一类
- *    权威提的问」,那一位答「**本部署运维治理层**是不是这只 ask 的门」;`origin:"policy"` 覆盖
- *    任何部署 ToolPolicy 的 ask ⇒ 两者顶替不了对方。
- */
 export type AskOrigin = SdkAskOrigin;
-/**
- * {@link ToolApprovalFrame.ruleOffersAbsence} 的闭三词 —— **sdk 8.3.0 `RuleOffersAbsence` 派生**
- * (`mandated` / `shadowed` / `lane_cannot_speak`)。ADVISORY 展示元数据,**永不是裁决输入**。
- */
 export type RuleOffersAbsence = SdkRuleOffersAbsence;
-/** {@link DenialLimitFallback.limit} 的闭二词 —— **sdk 8.3.0 派生**(`consecutive` / `total`)。 */
 export type DenialLimitKind = SdkDenialLimitKind;
-/**
- * **auto 模式分类器的限额回落卡** —— **sdk 8.3.0 `DenialLimitFallback` 派生**(S-114 /
- * core 7.4.0 #548;四成员全必填)。
- *
- * 🔴 `autoDenyAfterMs` **只用来渲倒计时**:窗的执行全在引擎,消费端(与 server)都**不得**据它
- *    自铸第二只定时器 —— 两只窗重叠比原缺陷更坏且静默(sdk 顶注逐字)。
- * 🔴 与 {@link ToolApprovalFrame.requiresRealApproval} 是**同一次铸造盖的孪生键**;
- *    **缺席不是断言**(绝大多数 ask 根本不是回落卡)。
- */
 export type DenialLimitFallback = SdkDenialLimitFallback;
-/**
- * 两张新闭词表的**运行期**再导出(sdk 8.3.0 `as const` 单源;与上面三张同一条纪律)。
- *
- * ⚠️ **本包自己不拿它们做窄读判定**,这与 `RULE_OFFER_MATCHES` 一族刻意不同,理由写在两处帧键的
- *    JSDoc 里:`origin` 与 `ruleOffersAbsence` 的词表属主是 core、server 侧已按闭集拒过词表外的值,
- *    包再校一遍只会在 core 加员当天把一个**合法**值判没(`wiring_manifest.autoMode.reason` 的
- *    透传纪律逐字同规)。再导出是给端的 `switch` 一份可数的表 —— 端仍必须带 `default` 臂。
- */
 export { RULE_OFFERS_ABSENCE_REASONS, DENIAL_LIMIT_KINDS };
-/**
- * **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';
     rule: string;
@@ -307,142 +61,29 @@ export type WireRuleOffer = {
     uncoveredSegments: number;
     uncoveredDetail?: readonly RuleOfferUncoveredDetail[];
 };
-/**
- * 一张审批卡上的**一个**「不再询问」选项(core 5.58.0 design/375 §3.1 的判别联合,server ≥7.46.0
- * 起在 `tool_approval` 帧 / `card_json` / durable park 行**三腿同形**发出)。
- *
- * ── 为什么本包仍自铸这个形(记账,不是偷懒)──────────────────────────────────────────────
- * **只为了多一位 `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 下标**,做不到就
- * 「must suppress its persistence actions entirely (fail toward asking)」—— 因为 `batch` 臂的兑付
- * 键就是**下标**(`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` 按它回兑;
- *   · **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 臂或只批这一次)。
-     *  🔴 成员是判别联合({@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)。 */
-/** allow 决断臂(命名形,typeshape B4 口径;0.26.0 因 persistRule 位达 4 成员抽名)。 */
 export interface ApprovalCardAllowDecision {
     kind: 'allow';
     allowSession: boolean;
     updatedInput?: unknown;
-    /** #225 件1:卡上选中的持久规则候选**原文**({@link ApprovalCardRequest.ruleSuggestions} 之一);
-     *  缺席/空串 = 本次不兑付。表外文本会在编排层被丢键留痕(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
- * {@link ApprovalCardAllowDecision} 抽名同姿势)。
- */
 export interface ApprovalCardDenyDecision {
     kind: 'deny';
-    /**
-     * #144 半场(0.28.0):这次拒绝的**归因原文**——人手打的拒绝说明,或壳侧权限规则自动 deny 的
-     * 机器判据(rule-deny / dontAsk / headless fail-closed 三条路)。缺席/空白 = 不带归因,调用方
-     * 落回既有缺省拒因,**现状字节不变**。
-     *
-     * 🔴 **方向纪律**:reason 只进归因通道,**绝不参与裁决** —— 带不带它、内容是什么,都不改变
-     * 这次决断仍是 deny(两条腿上的 `decision` 位逐字节不动)。
-     * 🔴 **两腿不同形**(见 {@link surfaceFsApprovalAndDecide} / {@link surfaceToolApprovalFrameAndRespond}):
-     *   · durable park 腿(`/decide`)wire **有** reason 位 ⇒ 原文上 wire(包内按 server 上限截断);
-     *   · live 帧腿(`/v1/tool-approvals/:id/respond`)的 `decision` 仍是三词闭集,归因走**另一个键
-     *     `note`**(与 durable `AskDecisionBody.note` 同词同源同一列 `decision_note`)—— 本位的原文经
-     *     两道门后落到 `RespondToolApprovalOpts.note` 上 wire:能力位
-     *     `approvalDecisionNoteCapable === true`,且长度不超 `MAX_RESPOND_NOTE_CHARS`;任一不满足则
-     *     只留痕不发(绝不自造侧信道)。发了还要看 ack 的 `noteRecorded` 才算落行。
-     *     ⚠️ 本段 0.28.0 原文写的是「wire 无 reason 位、只留痕不发,候 server 补位」—— server 7.15.0
-     *     已到货、0.29.0 #229 已兑现,那句话从此不成立(2026-08-13 类型/wire 超集台账普查时发现该
-     *     JSDoc 已陈旧;实现坐标见 {@link surfaceToolApprovalFrameAndRespond} 里的 note 两道门)。
-     * 与 `{kind:'failed'}` 的 `reason` **不同义**:那一位是「卡面本身不可用」的诊断,不是人的拒因,
-     * 两者绝不互相顶替。
-     */
     reason?: string;
 }
 export type ApprovalCardDecision = ApprovalCardAllowDecision | ApprovalCardDenyDecision | {
@@ -450,913 +91,122 @@ export type ApprovalCardDecision = ApprovalCardAllowDecision | ApprovalCardDenyD
 } | {
     kind: 'failed';
     reason: string;
-}
-/**
- * 0.74.1(CC-67)—— **无决断收口**:宿主把一张**已经没有决断口**的卡撤掉(换会话 / 换引擎 / 跟踪器报 gone),
- * 包见到它**一个字节都不发**(流内帧腿不 respond、durable-park 腿不 decide),不计 decided。
- * 🔴 不复用 `aborted`:那是「用户放弃 = 拒」(照旧 deny 真 POST);撤卡 = 替用户 POST 一次他没做过的拒绝,
- *    悬挂的子代 ask 会被误拒。`reason` 只留痕,不上 wire。
- */
- | {
+} | {
     kind: typeof RETRACTED_CARD_DECISION_KIND;
     reason?: string;
 };
-/** 卡口「无决断收口」结局值(单源;见 {@link ApprovalCardDecision})。 */
 export declare const RETRACTED_CARD_DECISION_KIND: "retracted";
-/** 卡口的入参 —— cli `surfaceApprovalCard` 的 `req` 逐字。 */
 export interface ApprovalCardRequest {
     toolName: string;
     args: object;
     callKey: string;
-    /**
-     * #348([5298] 定谳;server ≥7.48.0 帧位早在场)—— **core 的 tool-call id**,消费端用它把审批卡
-     * 锚到助手消息里那个 `tool_use` 块。
-     *
-     * 🔴 **与 {@link ApprovalCardRequest.callKey} 不同义,别互相顶替**:`callKey` 是本包铸的**卡身份
-     *    键**(呈现台账/重开腿的主键,live 帧腿 = `hitl-frame:${approvalId}`);本位是**引擎侧的工具调用
-     *    身份**,是卡与 transcript 里那个 `tool_use` 块之间**唯一**的 wire 事实锚。
-     * 🔴 **为什么非它不可**(server `dist/tool-approval.d.ts:64` JSDoc 逐字记载的 #348 病形):此前帧上
-     *    只有 `approvalId`,而那个 id 之后**再没有任何帧提到过** ⇒ 宿主只能拿它当 key 铸卡,卡永远停在
-     *    awaiting_approval。「拿最近一次 `tool_start` 当锚」这类补偿**不成立** —— 审批帧比 `tool_start`
-     *    **先到**(cli 帧级取证 4020ms vs 4142ms)。
-     * 🔴 **缺席 = 老引擎(≤7.47)或闭合帧**,不是「这次没有工具调用」:消费端必须按
-     *    [provenance-needs-wire-fact] 降级 —— 有本位就用它 join,缺席则回落既有 `callKey` 台账推断,
-     *    **绝不编造**一个 id。
-     */
     toolCallId?: string;
     signal?: AbortSignal;
-    /**
-     * 后台子代 ask 的归属徽章(卡头 `· @name`;宿主 ask 恒缺席)。
-     * ⚠️ **出身声明订正**(0.30.0 发包扫描,2026-08-14):本段 0.28.0 原文写的是「CC swarm workerBadge
-     * **原生位**」。类型/wire 超集台账普查逐份直证的结果与那句话相反 —— CC 语料九份
-     * (cli220/221/222/223 + pretty218/219/220/221/223)`workerBadge` **全 0 命中**(正控:同一把探针在
-     * 同目录对 `permissionMode` 有命中,证明它会说话),`@sema-agent/agent-types` 0.2.0 镜像的 TS AST
-     * 声明名集合(1651 个名字)里也没有这个名字。⇒ 这一位按现有证据是 **sema 自铸**,不是 CC 原生位;
-     * 终判(让位/改名/登记为超集)候台账 `docs/type-superset.json` 的 `_covenant`「未建工作」条清账。
-     * 🔴 三端读到的 `.d.ts` 注释随 dist 出包,所以订正必须落在这里 —— 只在不进 tarball 的台账里留话,
-     *    消费端读到的仍是那句错误出身断言。
-     */
     workerBadge?: {
         name: string;
         color: string;
     };
-    /** wire 层降级说明(卡 content 上方 dim 行,ToolUseConfirm.wireNote 超集位)——argsOmitted 等
-     *  不可注入 args 的提示走这里([1543]③ 记账的 note 位,2026-07-23 落位)。 */
     wireNote?: string;
-    /**
-     * 0.72.14:这只 ask 的工具入参在本读面上**不可得**(悬挂的流内 ask)。为真 ⇒ 卡上渲的 `args` 不是工具的真实入参,
-     * 端**不要**给「编辑后批准」;包侧收到带改写的批准会拒发(见 `ToolApprovalFrameOutcome.editRefused`)。缺席 ≠ false。
-     */
     argsUnavailable?: true;
-    /**
-     * 治理强制位(server ≥7.5.0,2026-08-08 补透传)。**缺席 ≠ false**:只在为真时在场,缺席 = 无治理
-     * 来源的证据。壳应据此把门呈成**表态掀不掉**(而不是引导用户去改 `permissionMode`);呈现形是壳
-     * 半场,本包只保证这一位到得了卡口 —— 此前它在帧类型上就不存在,于是宿主无论怎么写都读不到。
-     *
-     * 🔴 **本位是双源合流**(0.30.0 发包扫描订正,2026-08-14;本段原文只写「原样来自
-     * {@link ToolApprovalFrame.governanceForced}」,而 [C170] 那一批起 durable 腿也往这一位灌):
-     *   · **活卡帧腿**:`ToolApprovalFrame.governanceForced`(进程内治理标记表);
-     *   · **durable park 行腿**:`PendingCheckpoint.governanceForced`(`surfaceFsApprovalAndDecide` 的
-     *     行 → 卡重铸处 stamp,条件同样只认 `=== true`)。
-     * ⚠️ 上游对这两位的关系有逐字声明(sdk 6.17.2 `PendingCheckpoint` JSDoc):判据属主是
-     * `governanceOriginOf`(行上取证格 ∧ 部署姿态合取),与活卡帧那位**语义同族、判据不同源**,
-     * 「同一只 ask 两条腿的在场性可以不一致」。⇒ 宿主**不许**把本位读成「活卡帧的治理标记」:
-     * 帧腿缺席不等于 durable 腿缺席,反之亦然;要区分来源就看你拿到的是哪条腿的卡。
-     */
     governanceForced?: true;
-    /** 委派出处链(core 5.9.0 W1)——原样来自 {@link ToolApprovalFrame.delegation};只读展示增强,
-     *  `agentName` UNTRUSTED-for-display。子代 ask 才在场。 */
     delegation?: ToolApprovalDelegation;
-    /**
-     * 持久规则候选(#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**。
-     */
     ruleOffers?: RuleOffer[];
-    /**
-     * 持久规则候选的**只读**对偶([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;而这条腿压根没有兑付口 ⇒ 它只是展示/对账座。
-     * 缺席 = 无候选/老行/坏形(三者同形,不猜);既有卡口不读本键 ⇒ 卡形字节不变。
-     */
     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;
-    /**
-     * **S-30①(0.48.0;server ≥7.53 / core 5.60.0 #438;sdk 7.4.0 起在 `PendingCheckpoint` 上声明)**
-     * —— 原样来自 **durable park 行** `PendingCheckpoint.hasBidiControls`:这条 park 行的**执行载荷**里
-     * 含至少一个 DIRECTIONAL 格式控制符(Trojan Source:人眼读到的顺序 ≠ 真正执行的字节顺序)。
-     *
-     * 🔴 **与 {@link inputHasBidi} 刻意分键不合流**(上游把名字取得不同,正是为了不让人合并):
-     *   · {@link inputHasBidi} = **同步腿**(`tool_approval` 活卡帧),server 对**帧自身序列化后的 args**
-     *     现算(E-14);
-     *   · 本键 = **durable 腿**,值**完全由 core 供**(park mint 时 `PendingAction.hasBidiControls`,
-     *     反范式成 durable 行的 `has_bidi_controls` 列;server `listPending` 读列 `=== 1` 才铸,**不重算**)。
-     *   两者是**同语义、不同源、不同算点**的两个量 ⇒ 同一只 ask 的两条腿在场性**可以不一致**,合成一位
-     *   就是拿一个量冒充另一个([same-name-different-meaning-crosses-layers])。端要渲一个徽标的话,
-     *   读**两位的并**是允许的(那是端的呈现决定),但两位在本层必须各自到货。
-     * 🔴 **缺席绝不折成 `false`**(类型 `true`,与 {@link governanceForced} / {@link inputHasBidi} 同族):
-     *   缺席 = **没检出**(干净 / core 有界扫描没够着 / 列诞生前 park 的老行),消费端**禁**读成
-     *   「已确认干净」—— 那是对用户下一个证不出的断言。
-     * 🔴 **披露位,不是清洗位;本包字节零改**:清洗会改掉即将被执行的那串字节(卡上显示的与真跑的不是
-     *   同一个东西),比不披露更坏。显形(转义/高亮/加标记)归端。
-     */
     hasBidiControls?: true;
-    /**
-     * 被越级的持久 allow 规则**原文**(#144,原样来自 {@link ToolApprovalFrame.persistedRuleShadowed}
-     * 的合形值)——壳据此渲「你的规则仍在,只是这次调用被要求逐次确认」;缺席 = 卡形与 0.27.0
-     * 字节不变(不渲该行)。
-     *
-     * 🔴 **display 值,不是身份通道**:它是一段**已过脱敏**的展示文本(core `inlineUntrusted` +
-     * server `redactSecrets`),不保证与规则店里存着的那条规则逐字节相同,更不是规则的 id/句柄。
-     * 下游的「删除/撤销这条规则」面**不许**把它当身份用(拿它去 match 规则店 = 删错规则或删不掉),
-     * 也不许把它回喂给模型/工具入参;要操作规则必须走规则店自己的枚举与标识。
-     * 🔴 **缺席 ≠「你没有规则」**:键只在「有规则命中 ∧ 规则清不掉这只 ask」时在场,绝大多数 ask
-     * 压根没有规则命中(缺席),而命中且清掉了的那些根本不会变成卡。
-     */
     persistedRuleShadowed?: string;
-    /**
-     * 结构化探针因由(#280 件1,0.30.4;server ≥7.21.0-rc #253)——**双源合流**
-     * ({@link governanceForced} 同形,两腿在场性可以不一致):
-     *   · **活卡帧腿**:{@link ToolApprovalFrame.probeCause} 原样;
-     *   · **durable park 行腿**:`PendingCheckpoint.riskDescriptor.probeCause`(server 对
-     *     riskDescriptor 整体透传,与活帧同值 —— core `buildRiskDescriptor` 铸)。
-     * 🔴 **开集(unknown),包只搬运**:载体形判(非 null 非数组对象)之外零校验零改写 ——
-     * 内部结构(code/roots/further)的窄读、消毒与呈现全部归端(壳 `probeCauseNote` 窄读器:
-     * 形不合整只按缺席,呈现走 wireNote 车道)。缺席 = 无因由/老引擎/坏载体形(三者同形,不猜),
-     * 卡形字节不变。UNTRUSTED-for-display:code/roots 是工具作文面,只渲染绝不回喂模型/工具入参。
-     */
     probeCause?: unknown;
-    /**
-     * 规则出处证据(#281 件4b,0.30.8;server ≥7.23.0 / core 5.35.0 design/252 G-2)——原样来自
-     * {@link ToolApprovalFrame.ruleEvidence} 的**载体形合形值**(单源:活卡帧腿;durable 行腿今天
-     * 无对偶,见帧上同名键的 JSDoc 末段)。缺席 = 老 server / 坏载体形(两者同形,不猜),卡形与
-     * 0.30.7 字节不变。
-     *
-     * 🔴 **开集(unknown),包只搬运**:成员级窄读(具名缺席词、矛盾形丢成员、整只拒读)与**呈现
-     * 谓词**全部归端。呈现谓词不是可选项 —— 无治理车道部署下引擎对**每一只** ask 都 stamp 全具名
-     * 缺席([4050] live 实测 / [4051] 定性为契约行为),「在场即渲」会给每张卡糊三行 not wired。
-     * 端侧形照 [4051] 背书的正解:成员**有值**、或缺席词**不在良性白名单**(`unavailable` = 审计链
-     * 断,恒可见;未知词可见)才占卡面一行;窄读侧仍如实留全部成员。
-     * 🔴 **展示/对账元数据,永不是裁决输入**:它不参与也不改变本次决断的任何字节。
-     * 🔴 **不是身份通道**(与 {@link persistedRuleShadowed} 同族警示):`orgRule` 是脱敏后的展示文本、
-     * `personalRuleDots` 是耐久身份**数组**——下游删除/撤销规则面不许拿 `orgRule` 当规则身份,也不许
-     * 把 dots join 成一个标量 id;要操作规则走规则店自己的枚举与标识。
-     * UNTRUSTED-for-display:只渲染,绝不回喂模型/工具入参。
-     */
     ruleEvidence?: unknown;
-    /**
-     * 安全类 ask 出身位(#283,0.36.0;server ≥7.33.0 / core 5.37)——原样来自
-     * {@link ToolApprovalFrame.requiresRealApproval}(**单源:活卡帧腿**;durable 行腿今天无对偶,
-     * 见帧上同名键的 JSDoc 末段)。在场 = 这只 ask **拒绝 blanket-allow**:一切自动放行必须让位
-     * (含记住的规则、`allow_session`、bypass 姿态)——那正是[4390]③ 预埋壳侧读器时写死的消费语义。
-     * 缺席 = 这不是一次安全类 ask / 老 server(两者同形,不猜),卡形与 0.35.0 字节不变。
-     *
-     * 🔴 **缺席绝不折成 `false`**(类型 `true` 而非 `boolean`,与 {@link governanceForced} 同族纪律):
-     * 折成 false 会把「没有证据」渲成「已确认这是普通 ask」,而这一位的整个存在理由就是不让自动放行
-     * 在安全类门上悄悄生效。
-     * 🔴 **与 {@link governanceForced} 分键不合流**:那位答「门是运维治理层下的」,本位答「引擎侧安全
-     * 策略/hook 判这门必须真人过目」。两句话对用户的下一步建议不同(改不改 permissionMode),
-     * 合并即谎报出身。
-     * 🔴 **展示 + 放行闸,不是裁决输入**:它不改变本次决断的任何字节,只约束宿主**自动**决断的资格;
-     * 人真按下的 allow 仍是 allow。
-     * 🔴 **分工写死,别把「包搬运了」读成「包挡住了」**:本包只保证这一位**到得了卡口**,
-     * 它**不**改写、不否决、也不收窄你回给 wire 的决断动词 —— `surfaceToolApprovalFrameAndRespond`
-     * 对 {@link ApprovalCardDecision} 的映射与 0.35.0 逐字节相同。⇒ 「在场时不要走自动放行」「在场时
-     * 卡上要不要还给人一个会话级选项」这两条策略**属于宿主**,包不替你执行;要它变成包级强制,是一次
-     * **行为面**改动(会改到人已按下的决断的字节),按宪法三问单独立项,不在本过境批内。
-     */
     requiresRealApproval?: true;
-    /**
-     * CC-27(0.71.1;cli 1.0.117 接入档打回):根外读 ask 附的读根候选,帧 → 卡**原样透传**(live 帧腿;durable
-     * `ApprovalCard` 无此位,回放腿缺席)。在场 = 卡上渲一格「把 `dir` 加为本会话读目录」动作,`dir` 原样回传显完整;
-     * 缺席 = 今日行为(非根外读 / 引擎早于 7.19.0)。0.71.0 只镜像了帧键名、卡零该位,文档曾说反 —— §42 S-8 已订正。
-     */
     readRootCandidate?: ReadRootCandidateView;
-    /** [4851]:窗三键透传(server ≥7.34;壳 readAskDeadlineMs 消费渲倒计时)。只在
-     *  `windowIsCurrent === true` 的 live 腿上过境(重放腿=旧余量,续窗即假倒计时);**全部**缺席
-     *  =该帧无窗不渲,半套在场读器按「expiresAtMs 优先、expiresInMs 兜底」回落。 */
     expiresInMs?: number;
-    /** 同门:窗绝对到点(server 时钟 epoch ms)。 */
     expiresAtMs?: number;
-    /** 同门:server 出帧时刻(壳时钟校偏用)。 */
     serverNowMs?: number;
-    /** 本地**收帧**时刻(`Date.now()`,与窗任一键同拍盖下)。壳读器明文优先这枚锚:卡口串行
-     *  阻塞下,排队靠后的卡若按「呈现那一刻」起算余量,等待的时间会被整段还给窗。 */
     receivedAtMs?: number;
-    /**
-     * S-15 第五单(0.59.0;**单源:活卡帧腿**)——「**为什么这张卡没有『不再询问』这一格**」,
-     * 原样来自 {@link ToolApprovalFrame.ruleOffersAbsence}(闭三词,按开集读)。
-     *
-     * 🔴 **与 {@link ruleOffers} 引擎侧互斥**:两者同时在场 = 上游坏形,本包不合成、不裁决,原样上卡
-     *    让端看得见(包替上游把矛盾湮灭掉,排障时说不清是谁窄没的)。
-     * 🔴 **缺席不是断言**:缺席同时覆盖「有报价」与三扇结构门 ⇒ 端**禁**据缺席渲任何一句肯定话。
-     * ⚠️ `mandated` 臂**不得**指向「去写一条规则」(门是强制的,写了也消不掉)。
-     */
     ruleOffersAbsence?: string;
-    /**
-     * S-114(0.59.0;**单源:活卡帧腿** —— durable park 行今天不携本键,见帧上同名键的 ⚠️ 记账)——
-     * 这只 ask 是 **auto 模式分类器的限额回落卡**,四成员全在的窄读结果
-     * (`{consecutive,total,limit,autoDenyAfterMs}`)。
-     *
-     * 🔴 **端的渲染判别位**:本键在场 ⇒ 渲「自动拒(限额回落)· 已连续拒 N / 累计 M,触的是
-     *    (consecutive|total) 这道界」,并**必须**同时把 {@link requiresRealApproval} 的「这一次得真人批」
-     *    呈出来(两键孪生)。
-     * 🔴 **`autoDenyAfterMs` 只渲倒计时,绝不据它自铸定时器**(引擎已有一只窗;两只窗重叠比原缺陷
-     *    更坏且静默)。`0` = 不武装 ⇒ 不渲倒计时,**不是**「立刻拒」。
-     * 🔴 **四成员缺一整键不上卡**(与 server `readDenialLimitFallback` 的 `.strict()` 同判据):
-     *    半张卡上的计数会被人当成真实次数读。
-     */
     denialLimitFallback?: DenialLimitFallback;
-    /**
-     * S-125③/#564(0.59.0;**单源:活卡帧腿**)—— 这只 ask 的**出身**,原样来自
-     * {@link ToolApprovalFrame.origin}(core 闭八词,按开集读;见 {@link AskOrigin})。
-     *
-     * 🔴 **缺席 = 老引擎 / 非 ask 路径,不是 `"policy"`**。
-     * 🔴 与 {@link governanceForced} 分工不互替(见帧上同名键)。
-     * ⚠️ 渲「自动拒(限额回落)」的判别位**首选 {@link denialLimitFallback} 对象**(它带计数与窗);
-     *    本词是分诊/审计座,单独在场只说明「这类门提的问」,给不出计数。
-     */
     origin?: string;
-    /**
-     * **core 7.14.0 #688 C3**(0.67.0;**ADDITIVE**,`"tool_approval"` only)—— 这只 ask 是因为
-     * **持久规则那条腿读不出来**才问人的,而它**具体哪一头**读不出来:
-     *   · `store` —— 那个人的**持久规则店整体**读不出来(读失败 / 超时 / 适配器抛了);
-     *   · `call`  —— 店读到了,但**这一次调用**对不上他的 deny/ask 规则行(收紧 lexer 的 `unreadable`:
-     *     展开里有读不懂的词 / 引号未闭合 / 语法错 —— 引擎自己的那句话在 `message` 上)。
-     *
-     * **双源合流**(与退役前的 `classifierUnavailable` 两腿装配**同形同位**):
-     *   · **活卡帧腿**:{@link ToolApprovalFrame.ruleStoreUnreadable} 的窄读产物;
-     *   · **durable park 行腿**:`PendingAction.tool_approval.ruleStoreUnreadable` 的孪生位
-     *     (core `checkpoint-store.d.ts:818` / 摘要行 `:1924-1926` 逐字同名),经**同一把**窄读器。
-     *
-     * 🔴 **在场 ⇔ `origin === "rule_store_unavailable"`**(core 7.14.0 合同逐字):缺席 = 这条腿把店
-     *    和这次调用都读通了,**或者压根没接规则店** —— 两形在这一格上不可分,端**禁**把缺席渲成
-     *    「你的规则都好着呢」。
-     * 🔴 **为什么非有它不可**:`origin` 那一个词盖了**两种机制**,而对人的下一步是**相反**的 ——
-     *    `store` 要去修部署的规则店,`call` 要去改他自己那条规则/这条命令。只给 origin 的卡会把人
-     *    指到错的地方(core `ask-origin.d.ts:98-104` 顶注逐字点名这件事)。
-     * 🔴 **闭二词按闭集判**(与 `cause` 同一条,与 `origin`/`ruleOffersAbsence` 的开集纪律不同):
-     *    core 在**唯一 stamp 点**上把政策自报的值剥掉后才盖章(合同逐字「A policy's self-declared
-     *    value is removed at the stamp」)⇒ 表外值到不了消费端,真读到就是坏形,渲一句成因就是编事实。
-     *    人话两句走**唯一铸点** `ruleStoreUnreadableDetail`(三端零自拼)。
-     */
     ruleStoreUnreadable?: RuleStoreUnreadableKind;
 }
-/**
- * 🔴 **拆缝口** —— 弹「三选卡」并等人的决断。壳 = vendored CC `PermissionRequest`;
- * 桌面/web = 各自的模态。缺席 ⇒ 两条决断腿都 `failed`(= 壳原文 print/non-REPL 的同一条路)。
- */
 export type ApprovalCardPort = (req: ApprovalCardRequest) => Promise<ApprovalCardDecision>;
-/** 装卡口(传 null 卸)。返回还原函数。 */
 export declare function installApprovalCardPort(port: ApprovalCardPort | null): () => void;
-/** W1 带 key 变体:装/卸某会话的卡口(多会话宿主每会话一键,互不顶盖)。 */
 export declare function installApprovalCardPortFor(sessionKey: string, port: ApprovalCardPort | null): () => void;
-/** 🔴 宿主自检:恒应为 0。非 0 = 有 gate 到达时卡口不在,那次审批走了 fail-closed 路径。 */
 export declare function approvalCardPortMisses(): number;
-/** W1 带 key 变体(miss 计数逐键)。 */
 export declare function approvalCardPortMissesFor(sessionKey: string): number;
-/** 卡口在不在(壳原文 `getLeaderToolUseConfirmQueue()` 那个存在性判据的等价物)。 */
 export declare function hasApprovalCardPort(): boolean;
-/** W1 带 key 变体。 */
 export declare function hasApprovalCardPortFor(sessionKey: string): boolean;
-/** W1 读端:某会话的卡口(未装 = null;**不计 miss** —— miss 只在决断腿真到达时计)。 */
 export declare function approvalCardPortFor(sessionKey: string): ApprovalCardPort | null;
-/** 测试钩:卸口 + 清计数(只卸口不清计数会让「未装配时 misses 为 0」的断言恒假 —— host.ts 同款教训)。 */
 export declare function _resetApprovalCardPortForTest(): void;
-/**
- * 共享卡面:弹 vendored CC 三选卡(PermissionRequest)→ 等用户决断。两条腿共用:
- *  - 旧 durable park 腿(surfaceFsApprovalAndDecide → HitlBridge.decideTool)
- *  - 新同步帧腿(server 1.191 `tool_approval` 帧 → POST /v1/tool-approvals/:id/respond)
- * 决断落地(decide/respond)由调用方做;卡的渲染/键行为/本地 permissionUpdates
- * (accept-session 升 intent,[816] 壳侧承诺② —— 与决断通道无关,两腿都要)由**宿主卡口**做。
- */
 export declare function surfaceApprovalCard(req: ApprovalCardRequest): Promise<ApprovalCardDecision>;
-/**
- * 弹 CC 三选卡 → 等决断 → 经 HitlBridge decide(durable park 腿,server 桥前的 checkpointGate 面;
- * 合成单测/旧引擎兜底保留)。decide 成功即引擎驱到下一状态(sync);调用方随后 attach runs.events
- * 续流(与 ask 桥完全同 loop)。
- *
- * @param argsByCall tool_start.args(toolCallId → args)——题干/diff 的一手源;缺则 pending.input。
- */
-export declare function surfaceFsApprovalAndDecide(deps: FsApprovalWireDeps, taskId: string, argsByCall: Map<string, unknown>, signal?: AbortSignal, 
-/**
- * 这张 park 的**待批 call 身份**(server ≥7.41.0 的 `done{suspended}.result.toolCallId` /
- * durable `suspended` 事件同键;供给见 `frameRouter.parkGatedCallId`,缺席是常态)。
- *
- * 🔴 它必须从**取件**这一步就起作用,不能只拿去删扣留帧(0.41.0 件④ 的异源复审 finding①):
- * 取件按 taskId + 族谓词选**第一行**,同 task 同族多行排队时那可能是旁观者 —— 只用身份删帧就成了
- * split-brain(决断绑的是旁观者行、删掉的是主角帧):用户其实在批准/拒绝**另一个**工具调用,
- * 而真 park 原地不动、反复重挂。
- * 🔴 **不 fail-closed**:身份在场但队列里没有对应行时**照旧回落**既有两条腿(taskId + 族谓词)。
- * 这个 join(checkpoint 的 `pendingAction.toolCallId` ↔ `/v1/approvals` 行的 `toolCallId`/
- * `boundCallId`)本仓没有对真 server 的实证,而 fail-closed 的失效面是**每一次审批都决断不了**;
- * 回落的失效面则与本键出现之前逐字节相同。方向按代价不对称取:宁可退回原状,不赌一个没实证的键。
- */
-parkGatedCallId?: string): Promise<FsApprovalOutcome>;
-/** server 包 src/tool-approval.ts 头注的帧契约(redactDeep + 16KiB 帽;超帽 argsOmitted 仍出帧)。 */
+export declare function surfaceFsApprovalAndDecide(deps: FsApprovalWireDeps, taskId: string, argsByCall: Map<string, unknown>, signal?: AbortSignal, parkGatedCallId?: string): Promise<FsApprovalOutcome>;
 export interface ToolApprovalFrame {
     type: 'tool_approval' | 'tool_approval_complete';
     approvalId: string;
     toolName?: string;
-    /** server ≥1.307([1940] 兑现 [1939],ADDITIVE):引擎 tool-call id——与 assistant 消息
-     *  `tool_use` block 的 `call_…` 同一枚。**审批卡锚这个**,不锚 approvalId(现铸 uuidv7,流上
-     *  再无人提起 ⇒ 按它键的卡永不被回收)也不锚「最近一次 tool_start」(审批帧先于 tool_start
-     *  到达,契约 §4a-bis 实测 4020ms vs 4142ms)。`tool_approval_complete` 上刻意不带(免多锚
-     *  歧义)。旧 server 缺席 ⇒ 消费方保留 approvalId 兜底但必须能被真 id 收敛。 */
     toolCallId?: string;
     message?: string;
     args?: unknown;
     argsOmitted?: boolean;
     outcome?: 'allowed' | 'denied' | 'expired';
-    /** server 1.258([1535] 审批链,[1549]①3 判别式定谳):**在场即子代**——server 只对后台子代
-     *  lane 的 ask 出此键(宿主自身 ask 的 sourceTaskId=sessionId 已在 server 侧收口不上帧)。
-     *  ⚠️ 值=子代 sessionId 非 a… handle(fence 实测 2026-07-23)——不是 fleet 台账键。 */
     sourceTaskId?: string;
-    /**
-     * core 1.378 RB-39②([1550]):Runner 填充的只读显式判别键——委派子代 gate 的 ask 恒带,
-     * 受信 internals 事实不可伪造。在场即子代(优先于 sourceTaskId 权宜式)。
-     *
-     * 🔴 **字面 `true` 不是 `boolean`**(#307 双扫 S47,2026-08-19;SDK 7.1.0/7.2.0
-     * `dist/resources/tool-approvals.d.ts` 的 `fromSubagent?: true` 逐字)——与本 interface 上
-     * `governanceForced?: true` / `requiresRealApproval?: true` 同族的**在场即真**键:
-     * wire 上只有「在场」与「缺席」两态,`false` 根本不是合法取值。此前这里写 `boolean` 是本仓
-     * 自铸的宽形,把一个不存在的第三态写进了契约。
-     * 缺席 = **没有显式判别证据**(不是「明确不是子代」),读法见 {@link isFromSubagent}。
-     */
     fromSubagent?: true;
-    /** core 1.378 RB-39②:展示身份(UNTRUSTED-for-display,server redact 后上帧)——徽章名一手源。 */
     sourceAgentName?: string;
-    /**
-     * server ≥7.5.0([2942]/[2943],ADDITIVE;≤7.4.0 恒缺席)——**治理强制**位:此门来自运维治理层
-     * (部署侧 `AUTONOMY` / `commandPolicy` / `MANUAL_MODE_SHELL_GATE` / `SENSITIVE_WRITE_PATTERNS`),
-     * 不是模型默认门、也不是本次请求的客户端表态。它回答「我都开了 `bypassPermissions` 为什么还在问」。
-     *
-     * 🔴 **缺席 ≠ `false`**(与风险两轴同族纪律):本键**只在为真时在场**。缺席 = 「没有治理来源的
-     * 证据」,它既覆盖真的非治理 ask,也覆盖 server 侧判据够不着的形(治理 shell 门停在 `classify`
-     * 档时,一次 shell ask 出自分类器还是别的门无从分辨——server 选择让键缺席而不是猜)。所以缺席
-     * **不得**被渲染成「这门可以用表态绕开」。
-     *
-     * 分工:本包只做**透传**(帧 → {@link ApprovalCardRequest.governanceForced}),徽标呈现是壳半场。
-     */
     governanceForced?: true;
-    /**
-     * core 5.9.0 W1([2535],ADDITIVE):ask 的**委派出处链**(最内层孙代帧胜出)。与
-     * {@link fromSubagent} 同门在场(只有子代 ask 带)。只读展示增强 —— 卡可以说清这只 ask 是从哪
-     * 一层浮上来的。`agentName` 与 {@link sourceAgentName} 同属 UNTRUSTED-for-display。
-     */
     delegation?: ToolApprovalDelegation;
-    /**
-     * ⚠️ **退役键**(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 **8.2.0** 的运行期锚 `TOOL_APPROVAL_FRAME_KEYS` 仍含它(node 直读实证),删掉会让
-     *    对账门的「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`)。
-     * ✅ **锚已追平(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} 消费。
-     */
     ruleOffers?: readonly WireRuleOffer[];
-    /**
-     * server ≥7.55.0 / core #490 修②(S-15 第五单;**ADDITIVE**,`"tool_approval"` only。
-     * 真发直证 = engine 7.60.0 fixture `@sema-agent/server/dist/tool-approval.d.ts` 的
-     * `ruleOffersAbsence?: RuleOffersAbsence` 声明 + 同包 `approval-card.js` 的 `readRuleOffersAbsence`
-     * 单点窄读;运行期锚直证 = sdk 8.3.0 `TOOL_APPROVAL_FRAME_KEYS` 27 项已含本键)——
-     * {@link ruleOffers} 的**缺席因由**:规则车道在场却无可给时,引擎点名**哪扇门关了**
-     * (闭三词 `mandated` / `shadowed` / `lane_cannot_speak`,见 {@link RuleOffersAbsence})。
-     *
-     * 🔴 **引擎侧与 {@link ruleOffers} 互斥**:有报价就没有本键,有本键就没有报价。
-     * 🔴 **缺席不是断言**:缺席同时覆盖「有 offers」与上面三扇结构门,一帧分不出来 ⇒ 端**禁**把
-     *    缺席渲成「这台部署没有规则车道」(那句话看 `capabilities.permissionRules`)。
-     * 🔴 **ADVISORY 展示元数据,永不是裁决输入**(sdk/server 两侧顶注同文)。
-     * 🔴 **本包按开集读、不做闭集校验**(与 `wiring_manifest.autoMode.reason` 的透传纪律逐字同规):
-     *    词表属主在 core,server 侧对词表外的值**已经**整键不铸 ⇒ 包再校一遍,只会在 core 加员当天
-     *    把一个合法值判没。型面上给了 {@link RuleOffersAbsence} 与运行期表 `RULE_OFFERS_ABSENCE_REASONS`,
-     *    端写 `switch` 必须带 `default` 臂。
-     * ⚠️ **`mandated` 臂端侧有指路义务**:那一臂**不得**把人指向「去写一条规则」——门是强制的,写了
-     *    也消不掉(server 顶注逐字)。
-     */
     ruleOffersAbsence?: string;
-    /**
-     * server ≥7.57.0 / core 7.4.0 #548(S-114;**ADDITIVE**,`"tool_approval"` only。真发直证 =
-     * engine 7.60.0 fixture 同文件的 `denialLimitFallback?: DenialLimitFallback` 声明 + 同包
-     * `approval-card.js` 的 `readDenialLimitFallback`(`.strict()` 形校验,与 `card_json` 同一函数);
-     * 运行期锚直证 = sdk 8.3.0 `TOOL_APPROVAL_FRAME_KEYS` 27 项已含本键)——这只 ask 是 **auto 模式
-     * 分类器的限额回落卡**:分类器连续(缺省 3)或累计(缺省 20)拒到限额的**那一次**调用不再静默
-     * deny,而是落成一张**必须真人批**的卡。
-     *
-     * 🔴 与 {@link requiresRealApproval} 是**同一次铸造盖的孪生键** —— 端读到本键时那一位必然也在场;
-     *    反向不成立(安全类 ask 有别的出身)。
-     * 🔴 **四成员全必填**(core 形上没有可选位):少一位不是「老 core」而是**坏值**,server 整键不铸,
-     *    本包的窄读器 {@link readDenialLimitFallback} 同判 —— 绝不半铸一张让人误读计数的卡。
-     * 🔴 **`autoDenyAfterMs` 只用来渲倒计时**:窗的执行全在引擎(窗到即 deny,并在 `tool_end.gate`
-     *    上盖 `settlement.kind:"denial_limit_window_expired"` —— engine ≥7.64.0 起这一个词就说完了
-     *    「是引擎的限额回落窗自己拒的」,不再需要旧形那三个键的合取;包面谓词
-     *    `isDenialLimitAutoDeniedGate`)。
-     *    消费端**不得**据它自铸第二只定时器 —— 两只窗重叠比原缺陷更坏且静默(server/sdk 两侧同一条禁令)。
-     *    `0` = 不武装(部署把旋钮关了,或 TOTAL 档的卡恒 0 等人)。
-     * 🔴 **缺席不是断言**:绝大多数 ask 根本不是回落卡。
-     * ⚠️ **耐久腿(park 行)今天不携本键**(core 7.4.0 的 `PendingAction` 上没有这一位)⇒
-     *    durable 行 → 卡那条腿不 stamp,与 {@link requiresRealApproval} 同一格记账。
-     */
     denialLimitFallback?: DenialLimitFallback;
-    /**
-     * **core 7.14.0 #688 C3**(0.67.0;**ADDITIVE**,`"tool_approval"` only)——
-     * `AskRequest.ruleStoreUnreadable ∈ {"store","call"}`(core `ask-origin.d.ts:116`
-     * `RULE_STORE_UNREADABLE_KINDS` / `isRuleStoreUnreadable`;`tool-policy.d.ts:308` 是 ask 臂上的声明)。
-     * 「持久规则那条腿读不出来」这件事的**机制位**:`store` = 店整体读不出来 / `call` = 这条调用对不上
-     * 那个人的 deny/ask 规则行。
-     *
-     * 🔴 **在场 ⇔ `origin === "rule_store_unavailable"`**(合同逐字)。缺席 = 这条腿把店和这次调用都读
-     *    通了,**或**本部署压根没接规则店 —— 两形不可分,端禁读成「你的规则都好着呢」。
-     * 🔴 **一个 origin 词盖两种机制,而下一步相反** —— 这正是它单独占一格的理由
-     *    (core `ask-origin.d.ts:98-104` 顶注)。措辞铸点 `ruleStoreUnreadableDetail`,端零自拼;
-     *    引擎在 `message` 上给的**这一次**的散文(lexer 那句话)由 `askOriginDetail(origin, message)`
-     *    让位渲出(0.65.0 B-080③ 已有的臂),两者并列不互替。
-     * 🔴 **闭二词按闭集判**:core 在唯一 stamp 点剥掉政策自报的值之后才盖章 ⇒ 表外值到不了消费端。
-     * ⚠️ **sdk 8.8.0 的运行期锚 `TOOL_APPROVAL_FRAME_KEYS`(27 项)尚无本键** ⇒ 镜像**领先**一代,
-     *    对账门里挂着一条带退出条件的 `AHEAD_OF_ANCHOR` 登记(sdk 8.9.x 同拍补上那天它自红逼删)。
-     *    ⚠️ 0.67.0 同批**删掉**了上一代那条同形登记(`classifierUnavailable` 随 core 7.14.0 退役)。
-     */
     ruleStoreUnreadable?: string;
-    /**
-     * 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`
-     * 的同名键)——这只 ask **命中了**调用方的一条持久 allow 规则,而那条规则**没能清掉它**。
-     * 值 = 被越级的那条规则**原文**(core `AskRequest.persistedRuleShadowed`,core 侧已过
-     * `inlineUntrusted`;server 侧与 `message`/`sourceAgentName` 同待遇 `redactSecrets` 后上帧)。
-     *
-     * 🔴 它存在的理由是一次真实的用户面回归:core 5.25.0 收窄消音边界后(「Allow rules silence the
-     * CLASSIFIER's questions, never a MANDATED one」),此前被规则消掉的 ask 重新出现 —— 没有这个键,
-     * 人看到的是「我明明点过『不再询问』,它怎么又问」,唯一合理的结论是「我的规则坏了/没存上」。
-     *
-     * 🔴 **缺席 ≠「你没有规则」**:键只在「有规则命中 ∧ 规则清不掉这只 ask」时在场。绝大多数 ask
-     * 压根没有规则命中(缺席),而**命中且清掉了**的那些根本不会变成 ask(被消音了,没有卡)。
-     * 🔴 与 {@link governanceForced} **刻意分列不合并**:那个键答「门是谁下的」(运维治理层),本键
-     * 答「你那条规则怎么了」。不可消音的来源有三类(governance / doctrine `always` / 工具自带 mark),
-     * 合并会让后两类要么谎报治理出身、要么丢掉规则解释。
-     * 🔴 **UNTRUSTED-for-display,且不是身份通道** —— 详见
-     * {@link ApprovalCardRequest.persistedRuleShadowed} 的同名警示(下游删除规则面不许拿它当规则身份)。
-     *
-     * 耐久路(park 行)的对偶是行上的 **`riskDescriptor.shadowedRule`**(server `redactPendingDisclosures`
-     * 逐字脱敏后随 `projectPendingForWire` 上 wire;⚠️ **键名与本处顶层键不同**,那正是它长期被漏掉的原因)。
-     * ✅ **0.64.2 起已消费**(件⑥):`surfaceFsApprovalAndDecide` 把它投到**同一个卡位**
-     * {@link ApprovalCardRequest.persistedRuleShadowed} —— 两条腿说的是同一件事,端读一个形。
-     * ⚠️ 本段 0.28.0 原文写的是「shadowedRule 的耐久对偶仍未消费——那一路是独立的一件」,那句话到 0.64.2
-     * 不再成立:它不是一件「独立的展示件」,而是壳**让位臂的输入** —— 不投的直接后果是耐久路上一条
-     * 「规则清不掉」的 ask 被当成普通 ask 自动放行(cli B-058 离线真跑证实)。
-     */
     persistedRuleShadowed?: string;
-    /**
-     * server ≥7.21.0-rc(#253 件 G1,core 5.33.0 backlog #239;**ADDITIVE**,`"tool_approval"` only。
-     * 真发直证 = engine 7.22.0 fixture `@sema-agent/server/dist/tool-approval.d.ts` 同名键)——
-     * 这只 ask **为什么**被收紧的**结构化探针因由**:被拦工具自声明 `reversibilityProbe` 且判不出
-     * 可回滚时,引擎在 maybe 档收紧点铸;wire 契约形 = `{ code, roots:{shown,total},
-     * further?:{shown,total} }`(server `ProbeCauseSchema` `.strict()`,活卡帧与 durable `card_json`
-     * 经同一 `readProbeCause` 单点铸造 ⇒ 两面结构性同值)。
-     *
-     * 🔴 **本包刻意不拥有这个形**(类型 = unknown 开集;#280 件1,0.30.4):内部结构(code/roots/
-     * further)的校验与呈现归呈卡端的窄读器(壳 `probeCauseNote.readProbeCauseKey` 同款「形不合整只
-     * 按缺席」纪律),包只做**载体形**判(非 null 非数组对象)+ 原样搬运 —— 两层各校一遍会让
-     * 「谁把键窄没的」在排障时说不清,且包侧校严一档就把上游 additive 内键挡在边界外。
-     * 🔴 **缺席 ≠「没有原因」**:只有 maybe 档收紧且探针真给了 cause 的 ask 才有它(工具 opt-in
-     * 供给,非常驻字段 —— [3980] test 定谳的负控:mandate 路径 ask 帧不带)。
-     * 🔴 本键**领先** SDK 运行期锚一代(sdk 6.17.2 的 `TOOL_APPROVAL_FRAME_KEYS` 尚无)⇒ 对账门
-     * (run-approval-frame-keys-test.mjs)AHEAD_OF_ANCHOR 带退出条件登记,#144
-     * `persistedRuleShadowed` 同形先例:SDK 锚补上当天登记自红逼删。
-     * 耐久路对偶 = `PendingCheckpoint.riskDescriptor.probeCause`(同值;server 对 riskDescriptor
-     * 整体透传),由 {@link surfaceFsApprovalAndDecide} 的行 → 卡重铸处消费。
-     * UNTRUSTED-for-display:code/roots 是工具作文面(server 已 redact),端呈前消毒,只渲染绝不回喂。
-     */
     probeCause?: unknown;
-    /**
-     * server ≥7.23.0 / core 5.35.0 design/252 G-2(#281 件4b,0.30.8;**ADDITIVE**,`"tool_approval"`
-     * only。运行期锚直证 = sdk 7.1.0 `TOOL_APPROVAL_FRAME_KEYS` 已含本键)——这只 ask 背后的
-     * **规则出处证据**:组织策略快照 `orgRevision`、命中的组织规则原文 `orgRule`、被越级的个人规则
-     * add dots `personalRuleDots`(规则的耐久身份,**构造上就是数组**——按数据渲染/对账,绝不 join
-     * 成一个标量 id)。
-     *
-     * 🔴 **每个成员各自是「值 或 具名缺席」**(`…Absent`,上游五词 + 开集读:词表属主是引擎)。
-     * `not_wired` 没有这条车道 / `not_adjudicated` 车道在但这次没问 / `unavailable` **问了而源读不出**
-     * (唯一意味「审计链断了」而不是「空」的那个词——手上这只 ask 正是随后的 fail-closed 收紧) /
-     * `no_match` 问了没人说话 / `not_reported` 缝答了但没带身份。
-     * 🔴 **具名缺席 ≠ 省略键**,而且 [4050] live 实测:**无治理车道**部署下 7.23.0 对**每一只** ask 都
-     * stamp 本键为全具名缺席(`{"orgRevisionAbsent":"not_wired",…}`)——[4051] 定性为**契约行为非缺陷**
-     * (把「没接治理」从裸 undefined 里拆出来正是该键的设计承重)。⇒ 「在场即渲」的天真消费形会给每张
-     * 审批卡糊三行 not wired;呈现必须带**谓词**(成员有值、或缺席词不在良性白名单 —— `unavailable`
-     * 恒可见、未知词可见),那一层归端(壳 `ruleEvidenceNote` 单源,[4051] 背书为正解形)。
-     * 🔴 **展示/对账元数据,永不是裁决输入**;server 只转录引擎盖的记录,自己绝不铸缺席词。
-     * 🔴 **本包刻意不拥有这个形**(类型 = unknown 开集,与 {@link probeCause} 同裁):载体形判
-     * (非 null 非数组对象)之外零校验零改写。成员级窄读**单源在端**——包内校严一档,就会把上游
-     * additive 成员挡在边界外,还让「谁把成员窄没的」在排障时说不清;而端侧窄读器有一条更硬的纪律:
-     * **窄读域只许等于或宽于铸点域,绝不更窄**([4050] 随批立)——整只拒读语义下「更窄」会连坐吞掉
-     * 同记录里兄弟成员的合法证据。
-     * 🔴 **缺席 ≠「没有治理」**:帧上无本键 = 老 server,或窄读丢了一条畸形记录 —— 两者同形,不猜。
-     * 耐久路今天**无对偶**(sdk 7.1.0 的 `PendingCheckpoint` / `riskDescriptor` 均未声明本键),故
-     * durable 行 → 卡那条腿不 stamp;上游补位后按 {@link probeCause} 的双源合流形跟批。
-     * UNTRUSTED-for-display:`orgRule` 是策略作文面(core `inlineUntrusted` + server redact 后上帧),
-     * 端呈前消毒,只渲染绝不回喂模型/工具入参。
-     */
     ruleEvidence?: unknown;
-    /**
-     * server ≥7.33.0(#283,core 5.37 起铸;**ADDITIVE**,`"tool_approval"` only。来源锚 = engine fixture
-     * `@sema-agent/server/dist/tool-approval.d.ts` 的同名键)——这只 ask 是一次**安全类** ask:
-     * 它**拒绝 blanket-allow**。出身是 core 自己的两条安全策略(`createUnverifiableDeletePolicy` /
-     * `createTranscriptIntegrityPolicy`)与 PreToolUse hook 族在 `AskRequest.requiresRealApproval` 上铸的位。
-     *
-     * 🔴 **契约 = 真才带,缺席绝不编 `false`**({@link governanceForced} 同形,故类型是 `true` 而不是
-     * `boolean`):缺席 = 这不是一次安全类 ask —— 那是**正常的否定形**,不是坏形、也不是「老 server」的
-     * 同义词(两者今天同形,不猜)。
-     * 🔴 **与卡内那一位的在场契约刻意不同、别混**(server `ApprovalCardSchema` 顶注逐字):durable
-     * `ApprovalCard.risk.requiresRealApproval` 是**恒在布尔**(投影层已把缺席按 `=== true` 归一化),
-     * 而本键走帧顶层、只在为真时在场。⇒ 「帧上没有」与「卡上是 false」是两条不同的陈述,别互相推导。
-     * 🔴 **与 {@link governanceForced} 刻意分列不合并**:那个键答「门是谁下的」(运维治理层
-     * AUTONOMY/commandPolicy/守卫集),本键答「这门为什么掀不掉」(引擎侧安全类策略/hook 出身)。
-     * 合并会让任一方谎报出身 —— 而消费端对这两句话的正确反应不同:治理位该劝「别去改
-     * permissionMode」,本位该劝「这一次必须真人过目,记住的规则与 bypass 姿态都让位」。
-     * 🔴 本键**领先** SDK 运行期锚一代(sdk 7.1.0 的 `TOOL_APPROVAL_FRAME_KEYS` 尚无)⇒ 对账门
-     * (run-approval-frame-keys-test.mjs)AHEAD_OF_ANCHOR 带退出条件登记,#144 `persistedRuleShadowed`
-     * 与 #280 `probeCause` 同形先例:SDK 锚补上当天登记自红逼删。
-     * 耐久路今天**无对偶**(sdk 7.1.0 的 `PendingCheckpoint` / `riskDescriptor` 均未声明本键;server 侧
-     * 那份在**卡内** `risk` 子树,不是行上的键)⇒ durable 行 → 卡那条腿不 stamp,行为钉在
-     * run-durable-card-display-keys-test.mjs ⑨ 段;上游补位后按 {@link probeCause} 的双源合流形跟批。
-     */
     requiresRealApproval?: true;
-    /**
-     * server ≥7.57.0 / core 7.5.0(S-125③/#564;**ADDITIVE**,`"tool_approval"` only。真发直证 =
-     * engine 7.60.0 fixture `@sema-agent/server/dist/tool-approval.d.ts` 的 `origin?: string` 声明;
-     * 运行期锚直证 = sdk 8.3.0 `TOOL_APPROVAL_FRAME_KEYS` 27 项已含本键)——**谁提的这一问**:
-     * core 在门上盖章的闭八词(见 {@link AskOrigin};server 逐字透传,**不自铸第二张资格表**)。
-     *
-     * 🔴 **缺席 = 老引擎 / 非 ask 路径,不是 `"policy"`**(端最容易犯的那一步):`policy` 是一个
-     *    **正面事实**(这只 ask 出自部署 ToolPolicy),把缺席折进去等于替引擎编一句它没说的话。
-     * 🔴 **按开集分支**(词表属主是 core):认不得的词渲「未知出身」而不是「没有出身」。本包
-     *    **不做闭集校验**,理由与 {@link ruleOffersAbsence} 同 —— 抄一份词表就是给自己立第二个判官。
-     * 🔴 与 {@link governanceForced} **顶替不了对方**:本键答「哪一类权威提的问」,那一位答
-     *    「**本部署运维治理层**是不是这只 ask 的门」;治理策略产的与普通策略产的在本词上同形。
-     * ⚠️ **端的渲染判别位**:`origin === 'denial_limit_fallback'` 与 {@link denialLimitFallback}
-     *    在场是同一件事的两个面(core 同一次铸造)—— 渲「自动拒(限额回落)」时**读对象**(它带
-     *    计数与窗),本词只作分诊/审计座。
-     */
     origin?: string;
-    /**
-     * #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 8.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 前赋值,字段注逐字「新壳借此给旧族帧
-     * 补倒计时」)。这只 ask 的**决策窗**:到点后引擎按 `UNATTENDED_APPROVAL_POLICY`(缺省 park)
-     * 处置,卡上的按键此后 404 `tool_approval.not_pending`([4845] Postgres 直读实证)。
-     *
-     * 🔴 三键**信封级**(不进 card 语义):壳的倒计时读器(`readAskDeadlineMs`)以
-     *    `expiresAtMs`(+`serverNowMs` 时钟校偏)优先、`expiresInMs` 兜底 —— **半套在场时按此
-     *    优先序回落消化**(异源对抗复审纠偏:早注「任一缺席整段不渲」与真实读器不符);**全部**
-     *    缺席 = 旧 server / 该帧无窗,才是不渲。0.38.1 及更早的白名单投影把三键丢在包边界外
-     *    ([4851] 头号请托的实体)——帧到了、壳读器预埋了、中间这一格空转,[4845]「卡挂着像活的」
-     *    的直接成因。缺席 ≠ 「永不过期」。
-     * 🔴 过境有闸:三键只在 `ToolApprovalFrameLaneOpts.windowIsCurrent === true`(live 流)时上卡
-     *    —— durable 账本重放的历史帧带的是铸帧时刻的旧余量,续窗 = 假倒计时(见 stamp 段注)。
-     */
     expiresInMs?: number;
-    /** 窗绝对到点时刻(server 时钟,epoch ms)。与 {@link expiresInMs} 同门在场。 */
     expiresAtMs?: number;
-    /** server 出帧时刻(epoch ms)——壳用它对本地时钟校偏后再消费 expiresAtMs。 */
     serverNowMs?: number;
-    /**
-     * CC-08(0.71.0;core 7.19.0 #803,sdk 9.6.0 `TOOL_APPROVAL_FRAME_KEYS` 第 30 员):**根外读卡附读根候选**。
-     * 在场 = 这只 ask 是「读了 trackedCwd 之外的目录」那一形,且引擎给出一个「把 `dir` 加为本会话读目录」的
-     * 候选动作;`clearsThisAsk: true` 是穷举表恰一臂(第二成员域 = {true})。
-     * 🔴 只按在场渲,`dir` 原样回传、显完整 dir(不截、不归一);缺席 = 今日行为(非根外读,或引擎早于 7.19.0)。
-     */
     readRootCandidate?: ReadRootCandidateView;
 }
-/**
- * 根外读 ask 附的「把 `dir` 加为本会话读目录」候选(core 7.19.0 #803;sdk 9.6.0 帧键第 30 员)。
- * 穷举表恰一臂:`clearsThisAsk` 域 = {true}。`dir` 原样(不截、不归一);声明之外的成员不过境。
- */
 export interface ReadRootCandidateView {
     dir: string;
     clearsThisAsk: true;
-    /**
-     * 0.73.6 —— `"exact"`(core ≥7.22.0 / server ≥7.85.0):**`dir` 这一串不是目录**,是命令点名的那条路径本身
-     * (`cat ~/.gitconfig` 的 `~/.gitconfig`)。消费端必须**逐字添加这一串**;展成目录模式(`<dir>/**`)授不到任何东西、
-     * 卡还在。渲染按它分支:在场那格不要说成「授权这个目录」。**缺席 = 目录出路,逐字节同旧;只读在场,永不读缺席。**
-     */
     covers?: 'exact';
 }
-/** {@link ToolApprovalFrame.delegation} 的形(命名形,不用内联匿名 —— typeshape 门 B4 棘轮口径)。 */
 export interface ToolApprovalDelegation {
-    /** 宿主侧那次委派调用的 tool-call id —— 卡的归属锚。 */
     parentToolCallId: string;
-    /** 委派深度(宿主直接子代 = 1)。 */
     depth: number;
-    /** 子代 agent 名。**UNTRUSTED**:spawning model 的自由文本(server 已脱敏+限长)。 */
     agentName?: string;
 }
-/**
- * 本地值拷贝的**运行时键集镜像**([1950]② 建议形):对账测试拿它与 SDK 0.1.6+ 的同源锚
- * `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", "ruleOffers", "ruleOffersAbsence", "denialLimitFallback", "ruleStoreUnreadable", "readRootCandidate", "origin", "inputHasBidi", "parked", "persistedRuleShadowed", "probeCause", "ruleEvidence", "requiresRealApproval", "expiresInMs", "expiresAtMs", "serverNowMs", "delegation", "outcome"];
-/**
- * 子代帧判别:显式键 fromSubagent(core 1.378 RB-39②)优先;缺席退 sourceTaskId 在场性权宜式
- * (server 1.258 [1549]①3,旧代际兼容)。
- *
- * 🔴 **`=== true` 是在场判别,不是布尔求值**(#307 S47 复核结论,2026-08-19)。`fromSubagent`
- * 的 wire 形是 `?: true`(见上方声明),所以运行期只可能是 `true` 或缺席;一个**显式 `false`**
- * 只能来自注入面或不合契约的实现,它承载的信息是「这个载体不合契约」,**不是**「引擎明确判定不是
- * 子代」。故这里刻意**不**把 `false` 当成否定证据:它与缺席同档 —— 落回 `sourceTaskId` 在场性
- * 那条旧代际权宜臂。
- *
- * 为什么这个方向是对的(而不是「显式 false ⇒ 直接 return false」):
- *   · 本判据的**唯一消费面是展示归属**(`workerBadge` 徽章 + `delegation` 出处链,见下方卡口),
- *     不参与任何放行/收窄决策 —— 两个方向的代价不对称:多一枚徽章只是噪声,少一枚徽章是把
- *     「这是子代发起的」这条事实对用户藏起来;
- *   · `sourceTaskId` 本身就是 server 只对后台子代 lane 才出的键(见其声明),它在场是**独立的**
- *     子代证据。让一个不合契约的 `false` 去否决一条独立成立的证据,等于让注入面拿到一个
- *     「隐藏子代身份」的开关;
- *   · 与本文件 `governanceForced` 的「缺席 ≠ false」同族纪律:在场即真的键上,非 `true` 一律读作
- *     「没有这条证据」,而不是「有一条相反的证据」。
- * 反漂移:类型侧 `?: true` 已让**编译期**的显式 false 不可能构造;本臂守的是运行期(wire/注入面)
- * 的越界载体,pure 门有对应负控(`fromSubagent:false` + sourceTaskId 在场 ⇒ 仍判子代)。
- */
 export declare function isFromSubagent(frame: ToolApprovalFrame): boolean;
-/** 三选卡决断 → respond 端点的 wire 枚举(server parseToolApprovalDecision)。 */
 export type ToolApprovalRespondDecision = 'allow' | 'allow_session' | 'deny';
-/**
- * POST /v1/tool-approvals/:id/respond 的注入面。
- *
- * 🔴 FIX①(2026-08-07):**SDK 6.3.0 起这是一等资源** `client.toolApprovals.respond`,返回
- * `ToolApprovalRespondAck`(`{approvalId, delivery:"applied", decision, rememberApplied?,
- * updatedInputForwarded?}`)。此前本位钉死 `Promise<void>` —— 于是 ack 上那两个**诚实位**在类型层
- * 就不可能被读到:
- *   · `rememberApplied:false`(server 1.239)= allow_session 的 grant **没落店**(典型:无 sessionId)
- *     ⇒ 壳照渲「本会话全放行」就是把一个没发生的授权渲成发生了;
- *   · `updatedInputForwarded`(server 1.241)= 编辑后的 args 是否真被透传给引擎(措辞诚实:
- *     forwarded ≠ applied)。
- * 返回型放宽成 `ack | void` 而不是硬钉 ack:**注入面的实现方**(旧 liveClient / mock / 测试桩)
- * 回 void 仍然合法(assignable),消费端按 {@link readToolApprovalRespondAck} 结构化读,缺席=未知。
- */
-/** respond 的可选参(命名形,typeshape B4 口径;0.26.0 因 persistRule 位达 3 成员抽名)。 */
 export interface RespondToolApprovalOpts {
     signal?: AbortSignal;
     updatedInput?: unknown;
-    /** #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`。
-     *  🔴 编排层(本文件)只在能力位确认 + 上限内才填本位 —— 注入面原样透传,别自己再判。 */
     note?: string;
 }
 export type RespondToolApprovalFn = (approvalId: string, decision: ToolApprovalRespondDecision, opts?: RespondToolApprovalOpts) => Promise<ToolApprovalRespondAck | void>;
-/**
- * respond 回执的**包内视图**。
- *
- * 🔴 **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 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 type PersistedRuleAnchor = SdkPersistedRuleAnchor;
-/**
- * respond 回执的**结构化读口**(wire 是 JSON:注入面可能是旧 liveClient 的 raw fetch,也可能是
- * 比本包新一版的 SDK)。坏形一律降 `undefined` —— 与 `controlRouter.errCodes` 同族纪律:
- * 「拿到一个不好用的值」不如「诚实地什么都没有」。两个可选布尔位非布尔时**单独**降缺席
- * (它们直接决定要不要渲「本会话全放行」,透传一个 `'yes'` 字符串会让 `!== false` 这类读法说反话)。
- *
- * 🔴 `decision` 判到 **wire 三词闭集**而不是「是不是串」(对抗复审二轮):ack 上那两个布尔位会
- * 触发**高危安全声明**(「工具正在用原始入参跑」),所以一个 `decision:'garbage'` 的回执绝不许被
- * 当成合规 ack 放行。**相关性**(「这个 ack 是不是**这一次**审批的回执」)不在本函数判 —— 本函数
- * 只认形,对不对得上由 {@link surfaceToolApprovalFrameAndRespond} 拿着 frame 与刚发出的 decision 核。
- */
 export declare function readToolApprovalRespondAck(v: unknown): ToolApprovalRespondAckView | undefined;
-/**
- * 一张 `tool_approval` 帧消费完的产物(FIX①,2026-08-07 **BREAKING**:此前是裸的
- * `ToolApprovalRespondDecision | 'unresolved'` 字符串)。
- * 迁移判据一句话:`const out = await surfaceToolApprovalFrameAndRespond(…); out.decision === 'deny'`。
- */
 export interface ToolApprovalFrameOutcome {
-    /** 用户(或 fail-closed)落定的决断;`'unresolved'` = respond 没送达(引擎按 TTL 自决)。 */
     decision: ToolApprovalRespondDecision | 'unresolved';
-    /** 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;
-    /**
-     * 0.72.14:入参不可得的卡(悬挂的流内 ask)上收到了「编辑后批准」⇒ 包侧**一个字节都没发**,`decision` 为 `'unresolved'`,
-     * 这只 ask 在引擎上仍然挂着。端应重新出卡(跟踪器 `requeue`)。缺席 = 没发生这件事。
-     */
     editRefused?: true;
-    /**
-     * 0.74.1(CC-67):宿主用 `{ kind: 'retracted' }` 撤了这张卡 ⇒ 包侧**一个字节都没发**,`decision` 为 `'unresolved'`,
-     * 这只 ask 在引擎上仍然挂着。与 `editRefused` 同款:附加诊断位,不是新的决断态;缺席 = 没发生这件事。
-     */
     retracted?: true;
 }
-/**
- * #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 & {
@@ -1364,169 +214,16 @@ export type ToolApprovalRespondRefusal = (ToolApprovalRespondRefusalFields & {
 }) | (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 收窄两条路都成立;本函数仍按
- *  结构读(不依赖类型收窄),因为它同时服务 raw SSE 与 durable 回放两条入口。 */
 export declare function isToolApprovalFrame(ev: unknown): ev is ToolApprovalFrame;
-/**
- * `denialLimitFallback` 的**窄读器**(S-114,0.59.0)—— wire 是 JSON:注入面 / 旧 server / 比本包新
- * 一版的 server 都可能给别的形,坏形一律降**缺席**(与 `readToolApprovalDelegation` 同族纪律)。
- *
- * 🔴 **四成员全必填,缺一整只丢**(与 server `approval-card.ts` 的 `readDenialLimitFallback`
- *    `.strict()` 同判据,与 core 的形一字不差):半只对象上的 `consecutive` 会被人当成**真实的
- *    连续拒次数**读,而它可能只是一个恰好在场的键。「一格空白的计数」比不渲这张卡更坏。
- * 🔴 **两个计数与窗按「有限非负数」判,不折 0**:`Number.isFinite` 单独会放行负数,而三者的定义域
- *    按上游契约本就非负(计数是次数,窗是 ms 且 `0` = 不武装,是**合法读数**不是缺席)。
- *    NaN / Infinity / 负数 = 坏形降缺席,**绝不猜**(同文件 `delegation.depth` 的旧教训)。
- * 🔴 **`limit` 按开集读**(非空串即收):闭二词表 `DENIAL_LIMIT_KINDS` 只作再导出给端数,
- *    包内**不拿它做判定** —— 词表属主是 core,抄一份就是给自己立第二个判官(B-025 的病形);
- *    server 侧已按闭集拒过词表外的值,包再校一遍只会在 core 加员当天把一个合法值判没。
- *    ⚠️ 这条与「四成员全必填」不矛盾:必填说的是**在场性**,开集说的是**取值域**。
- *
- * 🆕 **0.64.2 起在公面上**(cli L-174③;此前是模块私有):壳侧此前自持一份同判据的副本
- * (`src/sema/askFrameNotes.ts`),那是**第二个判官** —— 上游哪天在四成员上加一位、或把某一位的
- * 定义域改了,两份判据各漂各的,而屏上看到的是哪一份取决于素材走了哪条腿。导出的用途正是让那份
- * 副本整只退役:端读**包内窄读产物**({@link ApprovalCardRequest.denialLimitFallback})时不必再判
- * 一遍,端拿到**裸帧/裸行**时也有同一把读器可用。
- * 🔴 **导出的是读器,不是许可**:`autoDenyAfterMs` 仍然只许渲倒计时(窗的执行全在引擎),
- *    这一条不因它上了公面而松动。
- * ⚠️ **与 server `.strict()` 的一格差**(L-120③,如实写在两侧):对象上**多出的成员**本读器剥后
- *    保留四键,server 侧整只拒收 —— 包比 server 宽一格,方向是「多键不误杀」。端不要把「包读出来了」
- *    当成「server 也会收」。
- */
 export declare function readDenialLimitFallback(v: unknown): DenialLimitFallback | undefined;
-/**
- * `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 {
-    /**
-     * server 能力位 `capabilities.approvalDecisionNote` 的读数(宿主从自己的 caps 缓存供给)。
-     * 🔴 SDK 6.16 成文:**位缺席就别发 `note`** —— 老 server 对未知请求键静默忽略且照回 200,
-     * 「这台不认识 note」与「记上了」在响应上不可分,发了只造「已留档」的错觉。
-     * 缺席/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` 头注逐字:「账本重放的历史帧带的是铸帧时刻的旧余量,
-     * 拿它算『本地 now + 余量』等于给一只早就过期的 ask 续一个新窗」)。
-     * 🔴 窗三键**只在本位 === true 时**过境到卡:durable 账本 tail 会把旧 `tool_approval` 行连
-     * 冻结三键逐字重放,重放腿不设防 = 过期 ask 在屏上拿到一个精确但完全错误的倒计时,比
-     * 「卡挂着没倒计时」更坏。缺席 = 不知道来路 ⇒ **不 stamp**(fail-closed:退回无窗渲染,
-     * 老宿主不传本位时行为 = 0.38.1,零回归)。live 腿的宿主接线随各端提货批补 `true`。
-     */
     windowIsCurrent?: boolean;
-    /**
-     * 0.72.14:这只 ask 的**工具入参在本读面上不可得**(悬挂的流内 ask 从 `GET /v1/approvals` 的 `livePending` 段读出,
-     * 该段刻意不带入参)。为真 ⇒ 卡上明说「看不到入参」,且「编辑后批准」的改写不转发(没有原文可编,转发一个空对象
-     * 会把工具的真实入参换掉)—— 收到带改写的批准时**整次不发**,结局标 `editRefused`。只由 `surfaceSuspendedAskAndRespond` 置;流内帧腿不传。
-     */
     argsUnavailable?: true;
 }
 export declare function surfaceToolApprovalFrameAndRespond(frame: ToolApprovalFrame, respond: RespondToolApprovalFn, streamArgs: unknown | undefined, signal?: AbortSignal, lane?: ToolApprovalFrameLaneOpts): Promise<ToolApprovalFrameOutcome>;