@sema-agent/client-core 0.77.0 → 0.77.2

package/dist/sessionMap.js

@@ -1,29 +1,3 @@
-/**
- * sessionMap.ts — 「客户端会话 id ↔ 引擎会话 id」映射的**单一键形与 merge 判定**
- * (A-028.12,#244 族E,2026-08-15)。
- *
- * ## 收编前的形(census top-10 §2)
- * 同一概念两端各持一份、**键名零重合**:
- *   · 壳 `sessionIdMapping.ts`:`{shellSessionId, engineSessionId, lastEngineTaskId, engines{}}`,
- *     `.session-map.json` 侧车(lock + temp→fsync→rename 原子写);
- *   · web `engine-history-wire.ts`:`{uiId:{s:engineId,t:activeTaskId}}`,localStorage。
- * 与 B18 seatContract 修的「同一契约两份声明、编译器永不告警」同形。本件定**单一键形**
- * (壳形为正:显式键名 + per-engine 命名空间,web 缩写形迁移归 web 半场)+ 两个纯 merge 判定;
- * 存储经 {@link SessionMapStorePort} 归端(cli = lock+原子写两进程纪律,web = localStorage)。
- *
- * 🔴 merge 语义 = 壳 `persist`/`persistEngineEntry` 传给 lockedReadMergeWrite 的那两个闭包**逐字**:
- * `partial ?? prior` 逐字段让位、`engines[key]` 命名空间不互相覆盖、身份键缺席=拒写(skip 判定
- * 带 reason 出境,落日志的措辞归端)。
- */
-/**
- * The engine NAMESPACE key for a CONNECTED engine target's base url: the lowercased origin
- * (scheme+host+port — TOFU 同粒度). ⚠️ ROLE decides the namespace, not the url shape: the
- * SELF-SPAWNED engine is always keyed `'local'` (callers pass no url — its port can drift across
- * boots, one logical engine), while a `connect`ed target is keyed by origin EVEN when loopback
- * (a second local engine on another port is a DIFFERENT engine with a different data root).
- * Pure; never throws. A malformed non-empty url falls back to the raw lowercased string
- * (honest separation beats aliasing it onto another namespace).
- */
 export function engineNamespaceKeyFor(baseUrl) {
     if (!baseUrl)
         return 'local';
@@ -34,24 +8,13 @@ export function engineNamespaceKeyFor(baseUrl) {
         return baseUrl.toLowerCase();
     }
 }
-/** 缺省时钟(可注入 —— 测试与「同一批双写同刻」的端语义都经它)。 */
 const isoNow = () => new Date().toISOString();
-/**
- * 顶层记录 merge(壳 `persist` 闭包逐字):`shellSessionId` 取 `partial ?? prior`,两处都缺 =
- * 拒写;成写 = `{...prior, ...partial, shellSessionId, updatedAt: now()}`。
- */
 export function mergeSessionMapRecord(prior, partial, now = isoNow) {
     const shellSessionId = partial.shellSessionId ?? prior?.shellSessionId;
     if (!shellSessionId)
         return { ok: false, reason: 'no-shell-session-id' };
     return { ok: true, record: { ...prior, ...partial, shellSessionId, updatedAt: now() } };
 }
-/**
- * per-engine entry merge(壳 `persistEngineEntry` 闭包逐字):`engines[key]` 内
- * `partial ?? priorEntry` 让位;`prior.engines` 作 spread 基底 —— 未被本次改动的其它 engine key
- * 原样保留(两个不同 key 的并发写互不覆盖的**判定半场**;「基底必须是锁内新鲜读」的进程纪律
- * 归端的存储实现)。拒写序:先 engineSessionId 后 shellSessionId(与壳日志序一致)。
- */
 export function mergeEngineEntry(prior, key, partial, shellSessionId, now = isoNow) {
     const priorEntry = prior?.engines?.[key];
     const engineSessionId = partial.engineSessionId ?? priorEntry?.engineSessionId;

package/dist/sessionMemoryStatus.d.ts

@@ -1,25 +1,4 @@
-/**
- * sessionMemoryStatus.ts — 会话记忆姿态的**三端公共读面**(S-53;server ≥7.53 / core 7.0.2 #511 件1;
- * sdk 7.4.0 `sessions.memoryStatus` + `SessionMemoryStatus`)。
- *
- * ## 本件为什么在库里而不是在壳里
- * 这条读面上有**两处判定**,三端(TUI / web / desktop)各写一遍必然各错一遍:
- *   ① **同 status 不同码**:`GET /v1/sessions/:id/memory-status` 的 404 有**两个**互不相干的含义 ——
- *      `not_found.session`(会话未知/非属主)与 `not_found.route`(<7.53 的老 server 压根没这条路由,
- *      答通用回退)。按 **status** 分诊必然把「你的部署没这个面」说成「你这个会话不存在」。
- *      判据只能锚 `errorCode`([anchor-on-the-deciding-quantity]:决定处置的量是码,不是 status)。
- *   ② **五键缺席语义逐键不同**(sdk `SessionMemoryStatus` 顶注逐字):`optOutSource` / `lastCaptureAt`
- *      在**健康会话**上就合法缺席,其余三键只在源不可读时缺席。零历史会话的真形 =
- *      `{captureOptedOut:false, committedCount:0, foldedCount:0}`,**没有任何降级**。
- *      把「缺席」一律读成「没有/关着/0」就是对用户下一个证不出的断言
- *      ([honest-absence-not-fabricated-zero])。
- *
- * ## 分工(与仓内既有形同款)
- * **纯判定 + 薄封装**:IO 归宿主注入(`MemoryStatusClientLike`,与 `HitlClientLike` 同款 duck-type),
- * 本件不构造 client、不认 baseUrl、不碰凭据。**一句面向用户的话都不铸** —— 措辞与是否上屏归端。
- */
 import type { SessionMemoryStatus } from '@sema-agent/sdk';
-/** 宿主注入的读口切片(duck-typed,与 {@link HitlClientLike} 同因:宿主可以注入自己的传输层)。 */
 export interface MemoryStatusClientLike {
     sessions: {
         memoryStatus(sessionId: string, opts?: {
@@ -29,124 +8,42 @@ export interface MemoryStatusClientLike {
         } & SessionMemoryStatus>;
     };
 }
-/**
- * 读数体 = sdk 五键 + server 7.85.0 S-403 新键 `autoConsolidationArmed`(0.72.9 CC-39②;core #863 W1 唯一读法
- * `autoRunOnRecommendationEffective` 组,与 manifest `autoConsolidation` 段在场性同源)。sdk 9.6.0 尚未声明 ⇒ 本包按结构读;
- * 缺席 = 老 server(<7.85.0)**判不了**,不折 false —— 读法见 {@link readAutoConsolidationArmed}。
- */
 export type MemoryStatusFacts = SessionMemoryStatus & {
     readonly autoConsolidationArmed?: boolean;
 };
-export type MemoryStatusVerdict = 
-/** 200:读到了。`facts` 的**每一键**都按 wire 原样(合形才在场),缺席语义见 {@link readCaptureOptOut} 等。 */
-{
+export type MemoryStatusVerdict = {
     readonly kind: 'ok';
     readonly sessionId: string;
     readonly facts: MemoryStatusFacts;
-}
-/** 本部署**没有这个面** —— 端应当**别提供这个入口**(不是报错,是诚实的能力缺席)。 */
- | {
+} | {
     readonly kind: 'unsupported';
     readonly reason: MemoryStatusUnsupportedReason;
-}
-/** 会话未知**或非本 principal 所有**(server 反枚举:两者同码同串,判不出更细的,别猜)。 */
- | {
+} | {
     readonly kind: 'not_found';
-}
-/** 分类不明**如实说** —— 绝不编一个具体原因(`classifyTurnWireError` ④ 臂同款纪律)。 */
- | {
+} | {
     readonly kind: 'failed';
     readonly error: unknown;
 };
-export type MemoryStatusUnsupportedReason = 
-/** 501 `capability.*` —— 引擎未接线 / pg+tidb 记忆后端不自带控制面。**换部署形态**才可能有。 */
-'capability'
-/** 404 `not_found.route` —— 支持区间内 <7.53 的老 server 无本路由(通用回退)。**升 server**。 */
- | 'route'
-/** 501 `feature.*` —— 面在、开关关着。**防御臂**:今天这条路由的门序里没有 feature 臂
- *  (sdk 顶注的门序 401→501 capability→404→501→200),留着是因为 `capability.*` 与 `feature.*`
- *  同为 501 而**处置相反**(SDK `CapabilityUnavailableError` / `FeatureDisabledError` 顶注逐字),
- *  合流会把「叫管理员开开关」说成「换部署形态」。今天不可达 ⇒ 不是缺口,是不合流的登记。 */
- | 'feature';
-/**
- * 一次 `memoryStatus` 失败(任意抛出物)→ 处置分型。**永不抛**。
- *
- * 🔴 **结构视图读,不 `instanceof`**(与 `readDecideCurrentPending` 逐字同因):抛出来的是不是 SDK 的
- *    `APIError` 由**宿主**决定 —— 跨 realm / 双 SDK 实例下 `instanceof` 会把一个读得懂的错判成读不懂。
- * 🔴 **码优先、status 只作兜底**,且兜底只敢兜 501:
- *    · 501 在本路由上无歧义(两条 501 臂都是「面不在/没开」)⇒ 无码时按 `capability` 兜底是安全的;
- *    · 404 **恰恰相反**:两个码的处置相反,无码的 404 判不出 ⇒ 落 `failed`(如实说不知道),
- *      **绝不**挑一个猜 —— 猜错任一向都是对用户的一句假断言。
- */
+export type MemoryStatusUnsupportedReason = 'capability' | 'route' | 'feature';
 export declare function classifyMemoryStatusFailure(e: unknown): MemoryStatusVerdict;
-export type CaptureOptOutReading = 
-/** 存在一条单向 capture opt-out 记录(`captureOptedOut:true` + `optOutSource:"record"`)。 */
-{
+export type CaptureOptOutReading = {
     readonly state: 'opted_out';
-}
-/** 记录店可读且无记录 ⇒ capture 开着(`captureOptedOut:false`,`optOutSource` 合法缺席=健康默认态)。 */
- | {
+} | {
     readonly state: 'active';
-}
-/** 记录店失败 ⇒ **判不了**(`optOutSource:"fault"` 伴 `captureOptedOut` 缺席)。
- *  🔴 端**禁**把它渲成「开着」或「关着」—— 那是把一次读取失败说成一个姿态。 */
- | {
+} | {
     readonly state: 'indeterminate';
 };
-/**
- * `captureOptedOut` × `optOutSource` 的**合读**。两键必须一起读:单读 `captureOptedOut` 的话,
- * 「缺席」既可能是 fault(判不了)也可能是老 server 没给,读成 `false`(capture 开着)是最坏的方向 ——
- * 它会让端向用户断言「你的对话正在被记忆」,而真相是**不知道**。
- *
- * 🔴 **`fault` 一票否决,先于任何布尔位判**(对抗复审 [medium] 采纳,0.48.0):
- * 上游契约里 `optOutSource:"fault"` 与 `captureOptedOut` **缺席**同行,所以
- * `{captureOptedOut:false, optOutSource:"fault"}` 是一个**自相矛盾**的形。首版按「布尔位优先」写,
- * 于是这个形被判成 `active` —— 一个带着故障标记的载荷被读成「记忆确定开着」,正是本模块存在要防的
- * 那件事。矛盾形**不该产出确定判决**:版本斜差 / 畸形 200 体 / 中间层改写都能造出它,而端拿到
- * `active` 之后不会再问第二遍。⇒ 见到 `fault` 一律 `indeterminate`,布尔位说什么都不算数。
- */
 export declare function readCaptureOptOut(s: SessionMemoryStatus): CaptureOptOutReading;
-export type LastCaptureReading = 
-/** 有已提交贡献,且拿到了最新一次的时刻。 */
-{
+export type LastCaptureReading = {
     readonly state: 'known';
     readonly atMs: number;
-}
-/** **真的一次贡献都没有**(`committedCount === 0` 且 `lastCaptureAt` 缺席)。 */
- | {
+} | {
     readonly state: 'none';
-}
-/** 台账不可读(`committedCount` 缺席)⇒ `lastCaptureAt` 的缺席推不出任何东西。 */
- | {
+} | {
     readonly state: 'indeterminate';
 };
-/**
- * `lastCaptureAt` 的**三态**读法 —— 本件存在的理由就是这一格:
- * sdk 顶注逐字说 `lastCaptureAt` 缺席**同时**覆盖「台账不可读」与「根本没有已提交贡献」两形,
- * 所以**单读这一键判不出任何东西**。判别材料是**另一键**:`committedCount` 与它同一次台账读 ⇒
- * · `committedCount === 0`(台账可读、真零)+ 本键缺席 ⇒ 真的没有 → `none`;
- * · `committedCount` 缺席(台账不可读)⇒ 推不出 → `indeterminate`;
- * · `committedCount > 0` 却本键缺席 ⇒ 上游说不会发生;**防御性落 `indeterminate`**,
- *   绝不折成 `none`(那会把「有贡献」渲成「从没有过」)。
- */
 export declare function readLastCapture(s: SessionMemoryStatus): LastCaptureReading;
-/**
- * 读一次会话记忆姿态。**永不抛**:一切抛出物过 {@link classifyMemoryStatusFailure} 成判决。
- *
- * 🔴 `sessionId` 必须是**引擎捕获值**(壳从 wire 上拿到的那个 id),不是宿主自铸/自选的串 ——
- *    server 侧记录与台账按**裸 sessionId** 键控且**活过会话**,喂一个被回收的 id 会读到**上一代**
- *    的计数/opt-out(元数据,无内容字节;server 侧成文的跨代注意)。空串在本层直接落
- *    `failed` 而不发请求:那一发必然是对某个不属于本会话的东西提问。
- * 🔴 200 体**畸形键不铸**(非 number 的计数 / 非 boolean 的 opt-out 一律降键缺席):降键的后果是
- *    上面两个读法答 `indeterminate`(「不知道」),而**采信**一个坏形的后果是拿它当真值渲 ——
- *    两害相权,如实不知道。
- */
 export declare function readSessionMemoryStatus(client: MemoryStatusClientLike, sessionId: string, opts?: {
     signal?: AbortSignal;
 }): Promise<MemoryStatusVerdict>;
-/**
- * 「这台部署的记忆自动整理武装了没有」:`armed` / `unarmed` / `indeterminate`。
- * 🔴 缺席 = 老 server(<7.85.0)**判不了**,不折 `unarmed`;坏形同样 `indeterminate`(不抛)。三个词对运维是三条不同的下一步
- * (与 manifest `autoConsolidation` 段「缺席 = indeterminate」同律;server 用 core 唯一读法组这一位,端别按席自判)。
- */
 export declare function readAutoConsolidationArmed(facts: MemoryStatusFacts | null | undefined): 'armed' | 'unarmed' | 'indeterminate';

package/dist/sessionMemoryStatus.js

@@ -1,40 +1,4 @@
-/**
- * sessionMemoryStatus.ts — 会话记忆姿态的**三端公共读面**(S-53;server ≥7.53 / core 7.0.2 #511 件1;
- * sdk 7.4.0 `sessions.memoryStatus` + `SessionMemoryStatus`)。
- *
- * ## 本件为什么在库里而不是在壳里
- * 这条读面上有**两处判定**,三端(TUI / web / desktop)各写一遍必然各错一遍:
- *   ① **同 status 不同码**:`GET /v1/sessions/:id/memory-status` 的 404 有**两个**互不相干的含义 ——
- *      `not_found.session`(会话未知/非属主)与 `not_found.route`(<7.53 的老 server 压根没这条路由,
- *      答通用回退)。按 **status** 分诊必然把「你的部署没这个面」说成「你这个会话不存在」。
- *      判据只能锚 `errorCode`([anchor-on-the-deciding-quantity]:决定处置的量是码,不是 status)。
- *   ② **五键缺席语义逐键不同**(sdk `SessionMemoryStatus` 顶注逐字):`optOutSource` / `lastCaptureAt`
- *      在**健康会话**上就合法缺席,其余三键只在源不可读时缺席。零历史会话的真形 =
- *      `{captureOptedOut:false, committedCount:0, foldedCount:0}`,**没有任何降级**。
- *      把「缺席」一律读成「没有/关着/0」就是对用户下一个证不出的断言
- *      ([honest-absence-not-fabricated-zero])。
- *
- * ## 分工(与仓内既有形同款)
- * **纯判定 + 薄封装**:IO 归宿主注入(`MemoryStatusClientLike`,与 `HitlClientLike` 同款 duck-type),
- * 本件不构造 client、不认 baseUrl、不碰凭据。**一句面向用户的话都不铸** —— 措辞与是否上屏归端。
- */
-/**
- * 一次 `memoryStatus` 失败(任意抛出物)→ 处置分型。**永不抛**。
- *
- * 🔴 **结构视图读,不 `instanceof`**(与 `readDecideCurrentPending` 逐字同因):抛出来的是不是 SDK 的
- *    `APIError` 由**宿主**决定 —— 跨 realm / 双 SDK 实例下 `instanceof` 会把一个读得懂的错判成读不懂。
- * 🔴 **码优先、status 只作兜底**,且兜底只敢兜 501:
- *    · 501 在本路由上无歧义(两条 501 臂都是「面不在/没开」)⇒ 无码时按 `capability` 兜底是安全的;
- *    · 404 **恰恰相反**:两个码的处置相反,无码的 404 判不出 ⇒ 落 `failed`(如实说不知道),
- *      **绝不**挑一个猜 —— 猜错任一向都是对用户的一句假断言。
- */
 export function classifyMemoryStatusFailure(e) {
-    // 🔴 **取属性本身要设防**(对抗复审 R2 [medium] 采纳,0.48.0):`e` 是**任意抛出物** ——
-    //    它完全可以是一个带抛错 getter 的对象或敌意 `Proxy`,那样连 `e.errorCode` 这一下都会抛。
-    //    而本函数是被 {@link readSessionMemoryStatus} 在 **`catch` 块里**调用的:`catch` 内抛出的
-    //    异常**不会**再被同一个 `try` 接住 ⇒ 分类器一抛,包装器那句「永不抛」当场破功。
-    //    (R1 那轮把归一化移进 try 只堵了正常返回路,这条是**失败路**上的同一个洞 —— 同形第二处。)
-    //    两键**各读一次**存下来,读不动就当「没有可判的机器码」落 `failed`,把原抛出物原样带出。
     let code;
     let status;
     try {
@@ -62,53 +26,14 @@ export function classifyMemoryStatusFailure(e) {
         return { kind: 'unsupported', reason: 'capability' };
     return { kind: 'failed', error: e };
 }
-/**
- * `captureOptedOut` × `optOutSource` 的**合读**。两键必须一起读:单读 `captureOptedOut` 的话,
- * 「缺席」既可能是 fault(判不了)也可能是老 server 没给,读成 `false`(capture 开着)是最坏的方向 ——
- * 它会让端向用户断言「你的对话正在被记忆」,而真相是**不知道**。
- *
- * 🔴 **`fault` 一票否决,先于任何布尔位判**(对抗复审 [medium] 采纳,0.48.0):
- * 上游契约里 `optOutSource:"fault"` 与 `captureOptedOut` **缺席**同行,所以
- * `{captureOptedOut:false, optOutSource:"fault"}` 是一个**自相矛盾**的形。首版按「布尔位优先」写,
- * 于是这个形被判成 `active` —— 一个带着故障标记的载荷被读成「记忆确定开着」,正是本模块存在要防的
- * 那件事。矛盾形**不该产出确定判决**:版本斜差 / 畸形 200 体 / 中间层改写都能造出它,而端拿到
- * `active` 之后不会再问第二遍。⇒ 见到 `fault` 一律 `indeterminate`,布尔位说什么都不算数。
- */
 export function readCaptureOptOut(s) {
-    // 🔴 **完整真值表,不是「fault 一票否决 + 看布尔位」**(对抗复审 R2 [medium] 采纳,0.48.0)。
-    //    上游契约把这两键**成对**定死,只有两个组合是有定义的:
-    //      · `true`  × `"record"`  = 有一条单向 opt-out 记录        ⇒ opted_out
-    //      · `false` × **缺席**    = 记录店可读且无记录(健康默认态)⇒ active
-    //      · 缺席    × `"fault"`   = 记录店失败                     ⇒ indeterminate
-    //    其余组合(`false`×`record` / `true`×缺席 / `true`×`fault` / …)在契约上**不存在** ——
-    //    它们只可能来自版本斜差、畸形 200 体或中间层改写。R1 那轮只挡了带 `fault` 的两格,
-    //    于是 `{captureOptedOut:false, optOutSource:"record"}`(记录明明在,布尔位却说没关)
-    //    仍被确定判成 `active`,`{captureOptedOut:true}`(没有来源佐证)仍被判成 `opted_out`。
-    //    这是**隐私姿态**的断言,方向两边都危险 ⇒ 凡不在真值表上的组合一律 `indeterminate`。
-    //    ⚠️ 这里**不担心**版本斜差把已知答案降级成「不知道」:五键是同一批(S-53)进的面,
-    //    更老的 server 根本没有这条路由(答 404 `not_found.route` ⇒ 走 `unsupported`,到不了这里)。
     if (s.captureOptedOut === true && s.optOutSource === 'record')
         return { state: 'opted_out' };
     if (s.captureOptedOut === false && s.optOutSource === undefined)
         return { state: 'active' };
     return { state: 'indeterminate' };
 }
-/**
- * `lastCaptureAt` 的**三态**读法 —— 本件存在的理由就是这一格:
- * sdk 顶注逐字说 `lastCaptureAt` 缺席**同时**覆盖「台账不可读」与「根本没有已提交贡献」两形,
- * 所以**单读这一键判不出任何东西**。判别材料是**另一键**:`committedCount` 与它同一次台账读 ⇒
- * · `committedCount === 0`(台账可读、真零)+ 本键缺席 ⇒ 真的没有 → `none`;
- * · `committedCount` 缺席(台账不可读)⇒ 推不出 → `indeterminate`;
- * · `committedCount > 0` 却本键缺席 ⇒ 上游说不会发生;**防御性落 `indeterminate`**,
- *   绝不折成 `none`(那会把「有贡献」渲成「从没有过」)。
- */
 export function readLastCapture(s) {
-    // 🔴 `known` 的**合取**条件(对抗复审 [medium] 采纳,0.48.0):时刻在场 **且** 台账可读
-    //    **且** 真有贡献。首版只判「时刻在场」,于是 `{committedCount:0, lastCaptureAt:X}` 这个
-    //    **自相矛盾**形(台账明说零贡献,却给得出「最近一次捕获」的时刻;两者本是**同一次台账读**)
-    //    被判成 `known` —— 端会据此确定地渲一个时间。同理 `committedCount` 缺席(台账不可读)时,
-    //    那个时刻是从哪来的也说不清 ⇒ 一并落 `indeterminate`。
-    //    判据锚在「真正决定这件事的量」上:决定「有没有捕获过」的是**台账计数**,时刻只是它的附属。
     if (typeof s.lastCaptureAt === 'number') {
         return typeof s.committedCount === 'number' && s.committedCount > 0
             ? { state: 'known', atMs: s.lastCaptureAt }
@@ -118,46 +43,16 @@ export function readLastCapture(s) {
         return { state: 'none' };
     return { state: 'indeterminate' };
 }
-// ── ③ 薄封装(唯一一处 IO) ───────────────────────────────────────────────────────────
-/**
- * 读一次会话记忆姿态。**永不抛**:一切抛出物过 {@link classifyMemoryStatusFailure} 成判决。
- *
- * 🔴 `sessionId` 必须是**引擎捕获值**(壳从 wire 上拿到的那个 id),不是宿主自铸/自选的串 ——
- *    server 侧记录与台账按**裸 sessionId** 键控且**活过会话**,喂一个被回收的 id 会读到**上一代**
- *    的计数/opt-out(元数据,无内容字节;server 侧成文的跨代注意)。空串在本层直接落
- *    `failed` 而不发请求:那一发必然是对某个不属于本会话的东西提问。
- * 🔴 200 体**畸形键不铸**(非 number 的计数 / 非 boolean 的 opt-out 一律降键缺席):降键的后果是
- *    上面两个读法答 `indeterminate`(「不知道」),而**采信**一个坏形的后果是拿它当真值渲 ——
- *    两害相权,如实不知道。
- */
 export async function readSessionMemoryStatus(client, sessionId, opts) {
     if (typeof sessionId !== 'string' || sessionId.length === 0) {
         return { kind: 'failed', error: new Error('memoryStatus: empty sessionId') };
     }
-    // 🔴 **归一化整段在 try 内**(对抗复审 [medium] 采纳,0.48.0):首版只把那一发 `await` 圈进
-    //    try,归一化在 try 外读属性 —— 而本函数吃的是**宿主注入**的 duck-typed client,它完全可以回一个
-    //    带抛错 getter 的对象 / 一个 Proxy。那种载荷会让本函数**向外 reject**,当场毁掉顶注写死的
-    //    「**永不抛**」承诺,而所有调用点都是照着那句话写的(没人给它套 try)。
-    //    圈进来的代价是零,漏在外面的代价是一个只在畸形宿主上才现形的 unhandled rejection。
     try {
         const raw = await client.sessions.memoryStatus(sessionId, opts?.signal ? { signal: opts.signal } : {});
         if (typeof raw !== 'object' || raw === null) {
             return { kind: 'failed', error: new Error('memoryStatus: malformed body') };
         }
         const o = raw;
-        // 🔴 **身份绑定:回声的 sessionId 必须与请求的**逐字相等**,否则整只落 `failed`**
-        //    (对抗复审 [medium] 采纳)。首版对不相等的回声**照收**,并把**对方**的 id 当成
-        //    结果返回 ⇒ 一次缓存错配 / 中间层串台 / 依赖故障,就会把**另一条会话**的记忆元数据
-        //    (计数、opt-out 姿态)呈现在当前会话的面板上。这条通道的上游对同一件事的纪律是
-        //    **宁缺席不串台**(server 对缺 `sessionId` 的通告如实不投),本层照同一条办。
-        //    ⚠️ 契约上 `sessionId` 是**必填回显**(`SessionMemoryStatusResponse`),所以缺席/非串
-        //    同样是坏形 —— 一并落 failed,**不**退回「就当是我请求的那个」。
-        //    🔴 **「严格相等会不会误杀合法场景」已对真 server 源码验真**(不是推断):server 的
-        //    `GET /v1/sessions/:id/memory-status` 回显的是 `safeDecode(<路径段>)`,而 SDK 发的是
-        //    `encodeURIComponent(sessionId)` ⇒ 往返是 `decodeURIComponent(encodeURIComponent(x)) === x`
-        //    的恒等,对任何合法串都字节相等;且 200 体里 `sessionId` 是**无条件**铸的(不在条件拷贝
-        //    那一组里)。⇒ 严格相等**杀不掉**任何合法回声,缺席也确实只可能是坏形。
-        //    (坏 percent-encoding 由 server 在更早的门答 400 `request.path_malformed`,落 `failed`。)
         if (typeof o.sessionId !== 'string' || o.sessionId !== sessionId) {
             return { kind: 'failed', error: new Error('memoryStatus: response sessionId mismatch') };
         }
@@ -172,7 +67,6 @@ export async function readSessionMemoryStatus(client, sessionId, opts) {
                     ? { optOutSource: o.optOutSource }
                     : {}),
                 ...(typeof o.lastCaptureAt === 'number' ? { lastCaptureAt: o.lastCaptureAt } : {}),
-                // 0.72.9 CC-39②(server 7.85.0 S-403):布尔恒在场;非布尔 / 老 server 缺席 ⇒ 键不在场(不铸 false)。
                 ...(typeof o.autoConsolidationArmed === 'boolean' ? { autoConsolidationArmed: o.autoConsolidationArmed } : {}),
             },
         };
@@ -181,12 +75,6 @@ export async function readSessionMemoryStatus(client, sessionId, opts) {
         return classifyMemoryStatusFailure(e);
     }
 }
-// ── ④ autoConsolidationArmed 三态(0.72.9 CC-39②)──────────────────────────────────────────
-/**
- * 「这台部署的记忆自动整理武装了没有」:`armed` / `unarmed` / `indeterminate`。
- * 🔴 缺席 = 老 server(<7.85.0)**判不了**,不折 `unarmed`;坏形同样 `indeterminate`(不抛)。三个词对运维是三条不同的下一步
- * (与 manifest `autoConsolidation` 段「缺席 = indeterminate」同律;server 用 core 唯一读法组这一位,端别按席自判)。
- */
 export function readAutoConsolidationArmed(facts) {
     if (typeof facts !== 'object' || facts === null)
         return 'indeterminate';

package/dist/sessionModelLatch.d.ts

@@ -1,32 +1,3 @@
-/**
- * ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2):cli src/sema/sessionModelLatch.ts 逐字搬入(零依赖;🔴 三个模块级 latch 是单实例态)。
- */
-/**
- * sessionModelLatch — 件13 (rev2 2026-07-14, CC 2.1.207 对锚): support module for the /model `s`
- * (use this session only) split, anchored on the 207 mechanism (verified against the 2.1.198 pretty
- * source, semantics identical in 207):
- *
- *   wsr(model, get, set, setDefault):                        // pretty.js:493226 (198 coords)
- *     set(a => ({ ...a, mainLoopModel: model, mainLoopModelForSession: null }))   // ALWAYS in-memory
- *     if (setDefault) RQt(model)                              // RQt = eo("userSettings",{model}) —
- *                                                             // the ONLY settings write (493244)
- *     message = `Set model to X${setDefault ? " and saved as your default for new sessions"
- *                                            : " for this session only"}`
- *
- * i.e. in 207 BOTH Enter and `s` write the in-memory mainLoopModel and CLEAR the plan-mode session
- * field; persistence is EXPLICIT (RQt) and only runs on set-as-default. 207 has no auto-persisting
- * model choke point. sema's bundled base DOES auto-persist every mainLoopModel change in
- * state/onChangeAppState.ts, so to reproduce the 207 state shape exactly the session-only commit
- * marks its write with a ONE-SHOT skip-persist flag which the choke consumes: the write then behaves
- * exactly like 207's no-RQt branch (mainLoopModel set in-memory, mainLoopModelForSession null,
- * userSettings untouched → restart reverts to the persisted default).
- *
- * The latch half mirrors "the active model is UNPERSISTED" for NON-React consumers (seamQuery's
- * modelEndpointSwitch runs outside the component tree): a session-only pick must not be promoted to
- * next-boot roster/env state when the engine can route the model by itself. Kept in sync from the
- * onChangeAppState choke (single funnel for every setAppState write): set on a session-only
- * mainLoopModel write OR a plan-mode mainLoopModelForSession write, cleared on a persisted write.
- */
 export declare function setSessionModelLatch(model: string | null): void;
 export declare function getSessionModelLatch(): string | null;
 export declare function markSessionOnlyModelWrite(): void;

package/dist/sessionModelLatch.js

@@ -1,33 +1,3 @@
-/**
- * ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2):cli src/sema/sessionModelLatch.ts 逐字搬入(零依赖;🔴 三个模块级 latch 是单实例态)。
- */
-/**
- * sessionModelLatch — 件13 (rev2 2026-07-14, CC 2.1.207 对锚): support module for the /model `s`
- * (use this session only) split, anchored on the 207 mechanism (verified against the 2.1.198 pretty
- * source, semantics identical in 207):
- *
- *   wsr(model, get, set, setDefault):                        // pretty.js:493226 (198 coords)
- *     set(a => ({ ...a, mainLoopModel: model, mainLoopModelForSession: null }))   // ALWAYS in-memory
- *     if (setDefault) RQt(model)                              // RQt = eo("userSettings",{model}) —
- *                                                             // the ONLY settings write (493244)
- *     message = `Set model to X${setDefault ? " and saved as your default for new sessions"
- *                                            : " for this session only"}`
- *
- * i.e. in 207 BOTH Enter and `s` write the in-memory mainLoopModel and CLEAR the plan-mode session
- * field; persistence is EXPLICIT (RQt) and only runs on set-as-default. 207 has no auto-persisting
- * model choke point. sema's bundled base DOES auto-persist every mainLoopModel change in
- * state/onChangeAppState.ts, so to reproduce the 207 state shape exactly the session-only commit
- * marks its write with a ONE-SHOT skip-persist flag which the choke consumes: the write then behaves
- * exactly like 207's no-RQt branch (mainLoopModel set in-memory, mainLoopModelForSession null,
- * userSettings untouched → restart reverts to the persisted default).
- *
- * The latch half mirrors "the active model is UNPERSISTED" for NON-React consumers (seamQuery's
- * modelEndpointSwitch runs outside the component tree): a session-only pick must not be promoted to
- * next-boot roster/env state when the engine can route the model by itself. Kept in sync from the
- * onChangeAppState choke (single funnel for every setAppState write): set on a session-only
- * mainLoopModel write OR a plan-mode mainLoopModelForSession write, cleared on a persisted write.
- */
-/** The model that is currently ACTIVE but UNPERSISTED (session-only pick or plan-mode override). */
 let sessionModelOverride = null;
 export function setSessionModelLatch(model) {
     sessionModelOverride = model;
@@ -35,7 +5,6 @@ export function setSessionModelLatch(model) {
 export function getSessionModelLatch() {
     return sessionModelOverride;
 }
-/** One-shot mark: the NEXT mainLoopModel change is session-only (207 no-RQt branch) — do not persist. */
 let sessionOnlyWritePending = false;
 export function markSessionOnlyModelWrite() {
     sessionOnlyWritePending = true;
@@ -45,15 +14,6 @@ export function consumeSessionOnlyModelWrite() {
     sessionOnlyWritePending = false;
     return v;
 }
-// ── 件3(F1 模型面批,S3 铁律半场):本会话「用户显式选过模型」标记 ─────────────────────
-// boot 目录回读(replEntry 把 /v1/models default 写进 initialState.mainLoopModel)不经过
-// setAppState ⇒ 不置位;任何经 setAppState 的 mainLoopModel 变更(cmd-model Enter、`s` 键、
-// /model <name>、config 面板)都算显式 pick —— 由 onChangeAppState choke(每个 setAppState
-// 写的单一漏斗)置位,散在 UI 调用点零改动。ensureEngineServesModel 据此区分「运行时回声」
-// (boot 回读的目录 default)vs「用户意图」:回声绝不允许持久化写(不 switchRoster 改 env /
-// 不重排 models.json / 不改档位绑定)。注意与上面 latch 的分工:latch=「当前活跃值未持久化」
-// (s 键/plan override),本标记=「本会话内发生过显式选择」——s 键 pick 也置位(它是显式意图,
-// 是否持久化由件13 latch 在 instant 路径拦截,语义不变)。
 let userModelPickThisSession = false;
 export function markUserModelPickThisSession() {
     userModelPickThisSession = true;

package/dist/sessionPolicyCapability.d.ts

@@ -1,68 +1,18 @@
-/**
- * sessionPolicyCapability — `GET /v1/capabilities.sessionPolicy` 的三端共用四态读面(0.77.0 CC-105;
- * 与 sql / writeProtection / webSearch.backend / executionLane / approvalsStreamLive /
- * deviceExecutor.management / peerLane / permissionRulesWrite / memoryCompliance / memoryOrigin
- * 各只兄弟同一套四态词汇,四口走共用工厂)。引擎的 wire 型面里这一位已声明为可选布尔,读法仍按结构走
- * (声明形与在场性是两件事:声明说「型上可以有」,回体才说「这台有没有」)。
- *
- * ── 这一位答的是哪一个问题 ────────────────────────────────────────────────────────────────
- * 「per-session 工具规则的那一对读写口(`GET` / `PUT /v1/sessions/:id/policy`)在**这台引擎**上挂没挂」。
- * 上游的铸点是一次**设施在场判**(会话规则店接线了没),不是一次身份判:
- *   · 值为真 ⇒ 规则店在场,这对口有人应答(某一次调用成不成功仍由那一次的应答逐次回答:
- *     无主会话 409、非属主 404、放宽方向 403、CAS 不符 409 —— 这一位一个都不预告);
- *   · 值为假 ⇒ 本部署**没有**会话规则店,这对口恒以「这台没有这一面」拒,写入口该藏起来。
- *
- * ── 🔴 四态,不是两态 ───────────────────────────────────────────────────────────────────────
- *   ① `unobserved`   —— 本进程一次能力回体都没观测到。**不是**引擎说过的话。
- *   ② `not_reported` —— 回体观测到了,而**没有**这个键 ⇒ 这份二进制比这一位本身还老。
- *   ③ `absent`       —— 键在、值明确是 `false`:这台没有会话规则店。**正面事实**,与 ② 是两件事。
- *   ④ `present`      —— 键在、值为 `true`:这一面在这台引擎上挂着。
- * 值既不是 `true` 也不是 `false`(`null` / 串 / 数 / 数组 / 对象)⇒ 畸形 ⇒ **删格**(⇒ `unobserved`);
- * 能力回体整只不是对象同判畸形。🔴 三种「没有」(`unobserved` / `not_reported` / `absent`)**不许互折**。
- * 判在场用 `hasOwn`:原型链上继承来的同名键不算这台引擎说过话。
- *
- * ── 🔴 「藏入口」与「别发请求」是两个问题,判官也是两个 ─────────────────────────────────────
- * 本文件只铸前者:{@link sessionPolicyFaceAvailable} 回答「要不要渲这个写入口」,
- * 保守方向 —— 只有明说在场才 `'yes'`,明说不在与「比这一位还老的二进制」都 `'no'`,从没观测过才 `'unknown'`。
- * 后者(「这次编排该不该把请求发出去」)在会话策略写端口那一侧,它拿的是**同一只读数**、不另开一张表,
- * 判据与本函数刻意分开写:一个决定界面长什么样,一个决定要不要动网络,两者对 `unobserved` 的答案
- * 本来就该不同(界面保守地不渲,而一次用户已经点过的动作不该因为「本进程没探过能力面」被凭空挡住)。
- */
-/** 四态读数。`unobserved` 由读口在这一格空缺时铸,不由投影铸。 */
 export type SessionPolicyReading = {
     kind: 'unobserved';
-}
-/** 回体在、键不在 ⇒ 这份二进制比这一位老。**不等于** `false`。 */
- | {
+} | {
     kind: 'not_reported';
-}
-/** 键在、值为 `false`:本部署没有会话规则店 ⇒ 这一对口恒拒。 */
- | {
+} | {
     kind: 'absent';
-}
-/** 键在、值为 `true`:这一面挂着。 */
- | {
+} | {
     kind: 'present';
 };
-/** 能力回体 → 本格读数;畸形一律 `undefined`(= 这一格不写 ⇒ 读口答 `unobserved`)。 */
 export declare function projectSessionPolicyCapability(caps: unknown): SessionPolicyReading | undefined;
-/** 宿主 caps probe 的读面 tee 落点。绝不 throw;畸形 ⇒ 删格;`opts.generation` 关掉旧探测覆盖新读数的竞态。 */
 export declare function noteEngineCapsForSessionPolicy(baseUrl: string, caps: unknown, opts?: {
     generation?: number;
 }): void;
-/** 本进程观测到的读数;这一格空缺 ⇒ `{kind:'unobserved'}`。 */
 export declare function observedSessionPolicy(baseUrl?: string | undefined): SessionPolicyReading;
-/**
- * 「要不要渲会话规则的写入口」的判据单源(三态)。
- * 🔴 只有引擎明说在场(`present`)才 `'yes'`;明说不在(`absent`)与「这份二进制比这一位老」
- * (`not_reported`)都是 `'no'` —— 后者不是在说这一面不存在,是在说**这台说不出**,而一个说不出
- * 的写入口按假 affordance 纪律不渲(真要试,走读口,读是无副作用的那一半)。从没观测过 ⇒ `'unknown'`,
- * 端自己决定渲不渲(它既不是引擎的否定,也不是引擎的肯定)。
- */
 export declare function sessionPolicyFaceAvailable(reading: SessionPolicyReading): 'yes' | 'no' | 'unknown';
-/** doctor 那一行的 detail 串,唯一措辞真源。🔴 两种「读不出」都不许暗示「这一面在」或「这一面不在」。 */
 export declare function sessionPolicyDoctorDetail(reading: SessionPolicyReading): string;
-/** 换代失效口(引擎温切成功后调):清成未观测。空串 ⇒ no-op;绝不 throw。 */
 export declare function forgetSessionPolicyReading(baseUrl: string | undefined): void;
-/** 测试钩子。 */
 export declare function __resetSessionPolicyReadingsForTests(): void;