@sema-agent/client-core 0.57.0 → 0.59.0

package/dist/engineCapsCache.js

@@ -192,6 +192,37 @@ export function engineCapNestedTrue(baseUrl, parentKey, key) {
         return false;
     return parent[key] === true;
 }
+/**
+ * 同步读口(**任意值 / 嵌套对象**):该 base 的 caps 里 key 上到底有没有值,四态诚实作答。
+ *
+ * 为什么要有它:`engineCapTrue` / `engineCapNestedTrue` / `engineCapString` 三口的返回域分别是
+ * `boolean` / `boolean` / `string|undefined` —— 它们**把四种「读不出」全折成 fail-closed 的一档**,
+ * 那对**放行**问题是对的(能力位缺席就别走那条车道),但对**读面/诊断**问题是错的:一格
+ * `sql: {engine,isolation,txnMode} | null`(server ≥7.60.0)用这三口读,`null`(这台部署确实没库)
+ * 与「老引擎不报」与「还没探到」在屏上会变成同一句话。S-131 那次因此在**壳里**长出了一份窄读器
+ * (归层债),本口是它在包侧的座位。
+ *
+ * 🔴 本口只答「有没有值」,**不答「值成不成形」** —— 后者归各能力位自己的窄读器
+ *   (例:`sql` 的 {@link import("./sqlEngineCapability.js").projectSqlEngineCapability})。
+ *   两层刻意分开:通用口不认识任何一个具体位的形,窄读器不该重新实现一遍缓存与代际。
+ */
+export function engineCapValue(baseUrl, key) {
+    if (!baseUrl)
+        return { kind: 'unobserved' };
+    const caps = capsByBase.get(baseUrl);
+    if (caps === undefined)
+        return { kind: 'unobserved' };
+    if (!(key in caps))
+        return { kind: 'not_reported' };
+    const v = caps[key];
+    // 🔴 `undefined` 与「键不在」同判 `not_reported`:JSON 上没有 `undefined` 这个值,一个显式
+    //    `undefined` 只可能来自宿主自建管线,把它读成「有值」会让下游拿到一个空手。
+    if (v === undefined)
+        return { kind: 'not_reported' };
+    if (v === null)
+        return { kind: 'null' };
+    return { kind: 'value', value: v };
+}
 /**
  * 同步读口(字符串键):该 base 的 caps 里 key 的字符串值,未判/缺键/非字符串 ⇒ undefined。
  *

package/dist/engineErrorCodes.d.ts

@@ -198,6 +198,21 @@ export declare const RESUME_USAGE_WINDOW_EXHAUSTED = "resume.usage_window_exhaus
  *    没被消费」;「还能不能再赎」交给引擎那行原文去说,别替它下结论。
  */
 export declare const RESUME_PREFLIGHT_REJECTED = "resume.preflight_rejected";
+/**
+ * `resume.placement_mismatch`(#376 / core 5.65,design/380 O1③;server ≥7.51.0)—— 这次 resume
+ * 显式带的 `internals.placementRoot` 与 suspend 铸点记下的 `CheckpointState.placementRootSessionId`
+ * **不同**。目标绑定的 env factory 按那个固定点查 placement,静默换根会把这条腿(以及它往下传的
+ * 每一个子代)重新落在**另一台目标**上,而 park 的工作区在原来那台 ⇒ **拒在 CAS 之前**,行仍 `pending`。
+ *
+ * 🔴 **它不在 {@link RESUME_RETRY_LATER_CODES} 里,而且不该在**:server 只在
+ * `resume.usage_window_exhausted` / `resume.preflight_rejected` 两码上铸 `retryAfterSec`
+ * (server 7.51.0 `dist/http/server.js` 的 `CheckpointError` 出口逐字),本码恒无窗;更要紧的是
+ * **等一会儿对它毫无用处** —— 出路是「用记录里的那个 root 重来,或干脆不传 `internals.placementRoot`
+ * 继承记录值」,是**换参数**不是**等时间**。把它放进时间性闭集会让人白等一个永远不会自己好的拒绝。
+ * ⇒ 它与 `resume.preflight_rejected` 一起构成**另一个**闭集:{@link import('./resumeRefusalCopy.js').RESUME_REFUSAL_CODES}
+ * (「有人话可补」的拒绝),两个闭集刻意分家 —— 一个回答「能不能等」,一个回答「该对人说什么」。
+ */
+export declare const RESUME_PLACEMENT_MISMATCH = "resume.placement_mismatch";
 /**
  * 时间性拒绝族的**闭集**。
  *

package/dist/engineErrorCodes.js

@@ -281,6 +281,21 @@ export const RESUME_USAGE_WINDOW_EXHAUSTED = 'resume.usage_window_exhausted';
  *    没被消费」;「还能不能再赎」交给引擎那行原文去说,别替它下结论。
  */
 export const RESUME_PREFLIGHT_REJECTED = 'resume.preflight_rejected';
+/**
+ * `resume.placement_mismatch`(#376 / core 5.65,design/380 O1③;server ≥7.51.0)—— 这次 resume
+ * 显式带的 `internals.placementRoot` 与 suspend 铸点记下的 `CheckpointState.placementRootSessionId`
+ * **不同**。目标绑定的 env factory 按那个固定点查 placement,静默换根会把这条腿(以及它往下传的
+ * 每一个子代)重新落在**另一台目标**上,而 park 的工作区在原来那台 ⇒ **拒在 CAS 之前**,行仍 `pending`。
+ *
+ * 🔴 **它不在 {@link RESUME_RETRY_LATER_CODES} 里,而且不该在**:server 只在
+ * `resume.usage_window_exhausted` / `resume.preflight_rejected` 两码上铸 `retryAfterSec`
+ * (server 7.51.0 `dist/http/server.js` 的 `CheckpointError` 出口逐字),本码恒无窗;更要紧的是
+ * **等一会儿对它毫无用处** —— 出路是「用记录里的那个 root 重来,或干脆不传 `internals.placementRoot`
+ * 继承记录值」,是**换参数**不是**等时间**。把它放进时间性闭集会让人白等一个永远不会自己好的拒绝。
+ * ⇒ 它与 `resume.preflight_rejected` 一起构成**另一个**闭集:{@link import('./resumeRefusalCopy.js').RESUME_REFUSAL_CODES}
+ * (「有人话可补」的拒绝),两个闭集刻意分家 —— 一个回答「能不能等」,一个回答「该对人说什么」。
+ */
+export const RESUME_PLACEMENT_MISMATCH = 'resume.placement_mismatch';
 /**
  * 时间性拒绝族的**闭集**。
  *

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, 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: {
@@ -140,29 +141,106 @@ 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;
 /**
- * **wire 上的**一条 offer —— 与上游 core `RuleOffer` 逐字同形(**没有** `offerIndex`)。
+ * `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` 闭八词:
+ * `content_question` / `unresolvable` / `org_unavailable` / `org_rule` / `hook` / `ask_rule` /
+ * `denial_limit_fallback` / `policy`;**引擎在门上盖章**,不是策略的自称)。
+ *
+ * 🔴 **词表唯一属主是 core**,本别名只是型面供给(闭集给补全,`(string & {})` 让新词读得出来)——
+ *    端一律按**开集**分支:认不得的词渲「未知出身」,**绝不**渲成「没有出身」。
+ * 🔴 与 {@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';
@@ -173,19 +251,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 +273,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 +296,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)。 */
@@ -514,6 +603,40 @@ export interface ApprovalCardRequest {
     /** 本地**收帧**时刻(`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;
 }
 /**
  * 🔴 **拆缝口** —— 弹「三选卡」并等人的决断。壳 = vendored CC `PermissionRequest`;
@@ -627,8 +750,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,12 +769,55 @@ 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} 消费。
      */
     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 且盖
+     *    `settledBy:"timeout"` / `resolution:"window_expired"` / `tool_end.autoDenied:true`)。
+     *    消费端**不得**据它自铸第二只定时器 —— 两只窗重叠比原缺陷更坏且静默(server/sdk 两侧同一条禁令)。
+     *    `0` = 不武装(部署把旋钮关了,或 TOTAL 档的卡恒 0 等人)。
+     * 🔴 **缺席不是断言**:绝大多数 ask 根本不是回落卡。
+     * ⚠️ **耐久腿(park 行)今天不携本键**(core 7.4.0 的 `PendingAction` 上没有这一位)⇒
+     *    durable 行 → 卡那条腿不 stamp,与 {@link requiresRealApproval} 同一格记账。
+     */
+    denialLimitFallback?: DenialLimitFallback;
     /**
      * 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`
@@ -752,6 +918,23 @@ export interface ToolApprovalFrame {
      * 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`
@@ -767,7 +950,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。
      */
@@ -821,7 +1004,7 @@ export interface ToolApprovalDelegation {
  * `TOOL_APPROVAL_FRAME_KEYS` 比对——SDK additive 增键时对账当天红,不再人肉追平。
  * 下面两个类型钉保证镜像与 interface 本身不可能漂移(少键/多键都是编译错)。
  */
-export declare const TOOL_APPROVAL_FRAME_KEYS_MIRROR: readonly ["type", "approvalId", "toolCallId", "toolName", "sourceTaskId", "fromSubagent", "sourceAgentName", "message", "args", "argsOmitted", "governanceForced", "ruleSuggestions", "ruleOffers", "inputHasBidi", "parked", "persistedRuleShadowed", "probeCause", "ruleEvidence", "requiresRealApproval", "expiresInMs", "expiresAtMs", "serverNowMs", "delegation", "outcome"];
+export declare const TOOL_APPROVAL_FRAME_KEYS_MIRROR: readonly ["type", "approvalId", "toolCallId", "toolName", "sourceTaskId", "fromSubagent", "sourceAgentName", "message", "args", "argsOmitted", "governanceForced", "ruleSuggestions", "ruleOffers", "ruleOffersAbsence", "denialLimitFallback", "origin", "inputHasBidi", "parked", "persistedRuleShadowed", "probeCause", "ruleEvidence", "requiresRealApproval", "expiresInMs", "expiresAtMs", "serverNowMs", "delegation", "outcome"];
 /**
  * 子代帧判别:显式键 fromSubagent(core 1.378 RB-39②)优先;缺席退 sourceTaskId 在场性权宜式
  * (server 1.258 [1549]①3,旧代际兼容)。
@@ -914,78 +1097,38 @@ export interface RespondToolApprovalOpts {
 }
 export type RespondToolApprovalFn = (approvalId: string, decision: ToolApprovalRespondDecision, opts?: RespondToolApprovalOpts) => Promise<ToolApprovalRespondAck | void>;
 /**
- * respond 回执的**包内视图** —— sdk `ToolApprovalRespondAck` 的 additive 超集(#334,0.43.0)。
- *
- * 为什么是超集而不是直接用 sdk 那个形:server 7.46.0 的兑付回执上有两个**规范文本回显位**,而
- * sdk 7.2.0 的 `ToolApprovalRespondAck` 声明里还没有它们(与 `ruleOffers` 同一次锚滞后)。缺这两位,
- * 「规则真正存成了什么样」在包边界上被吞掉 —— 而编辑臂的落盘文本**可能与人敲的原字节不同**
- * (core 会把 `Bash(adb *)` 规范成 `Bash(adb:*)`),批臂更是一次落多条。
+ * respond 回执的**包内视图**。
  *
- * 🔴 **超集只加不改**:继承 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` 同族纪律:
@@ -1198,4 +1341,3 @@ export interface ToolApprovalFrameLaneOpts {
     windowIsCurrent?: boolean;
 }
 export declare function surfaceToolApprovalFrameAndRespond(frame: ToolApprovalFrame, respond: RespondToolApprovalFn, streamArgs: unknown | undefined, signal?: AbortSignal, lane?: ToolApprovalFrameLaneOpts): Promise<ToolApprovalFrameOutcome>;
-export {};