@sema-agent/server 7.43.0 → 7.44.0

package/dist/boot/memory-boundary.js

@@ -1,104 +1,20 @@
-/**
- * #214 记忆边界不变式(板 [3492]② 立案,[3521] 裁1 与 core #151 同窗)—— 启动期把「结构性写不进的记忆
- * 部署形」说出来。
- *
- * 病根(test 仓 [3479] 实测,[3490]② 定位):core 的记忆工具面是 `memory_search`/`memory_get` 两只**只读**
- * 工具;**写**记忆没有专用工具 —— 模型用 fs 工具往记忆根写文件,harvest 再从那里收编。于是整条链的成立
- * 条件是「记忆根落在该次任务的 fs 授权边界之内」。server 把根交给 core(`RunnerDeps.memoryEngineDir`)
- * 之后,没有任何一处保证这一点,也没有任何一处说过「这台部署的记忆写面够不着」。默认根是
- * `~/.ai-agent`(或 `AGENT_DATA_DIR`),默认围栏是任务 cwd —— 两者天然不相交:用户说「记住 X」,模型照
- * 提示词去 Write,拿回一个 `path_not_in_root`,而回执早就发出去了。
- *
- * 判据形态 = **纯函数 + 启动 warn,不拒启**。理由是诚实:共享挂载 / bind mount / operator 自己把根塞进
- * `additionalDirectories`,都是真实可行的部署形,而我方在 boot 期看不全。看得全的是「按我们自己接的线,
- * 这条链**结构上**走不通」——那句必须说出来。围栏根算不出来时**不说话**(判不了就闭嘴,别把猜测当告警)。
- *
- * ⚠️ 这不是 fail-open 的托词:真正的 fail-closed 归属面在别处(多租户记忆整体 dark、remote lane 默认 dark)。
- * 本模块判的是「已经决定要开记忆」之后的**可达性**,而可达性的证据一半在部署环境里,不在进程里。
- *
- * ── 指路:声明 `false` 之后引擎那边发生什么(core 5.27.0,[3612] F2;#231 提货批)────────────────────
- * 本模块两条 warn 的收尾句都在劝 operator 表态(`MEMORY_PERSISTENCE_CAPABLE=true|false`)。表 `false`
- * 之后的语义自 core 5.27.0 起**不止是披露**:该会话成为**受限会话** —— materialize/search/harvest 按
- * 已提交账(ledger + shadow)供给,磁盘上无事务背书的分歧既不收编也不供给,而是留盘 + 响亮点名
- * (`restricted_divergence`,`HarvestRejectionCode` 新成员;server 侧把它计进
- * `memory_harvest_rejections_total{code}` + 一条 warn,见 `boot/runner-deps.ts` 的 harvest 报告站点),
- * 等下一次非受限会话走正常门收编。
- * ⚠️ **这一层只在 file 记忆引擎上**(受限视图 = `FileMemoryEngineBackend` 的实装,`materialize` 取它是
- * `?? this.backend` 的可选 seam):`MEMORY_ENGINE_BACKEND=pg|tidb` 的两条腿读侧走库、盘上只是每任务投影,
- * 没有「读磁盘即收编」的通道,`false` 在它们上仍买到披露/写门/零收编 harvest 三件。
- * ⚠️ **口径别混**:受限 = **会话级 verdict 单键**(declared-false 那一个键);`writeScope:null` 的只读
- * **平面**(请求键 `memoryWrite:false` 的 per-run 暂停 / org 层默认只读 / 双根非写面)**保持 adopt-on-read
- * 原样**。受限是会话的**声明**,永远不是平面的**结构**。
- *
- * ── 本仓的 `adoptionRestricted` 消费位:**没有**(记档,免下次重找)──────────────────────────────────
- * core 5.27.0 同批 additive 两件:`MemoryEngine.materialize` 第三参 `opts?.adoptionRestricted` 与
- * `MemorySessionHandle.adoptionRestricted` 读面。本仓**两件都不碰**,而且是结构性的:记忆引擎由 core 的
- * runner 自己驱动(我方只交 `RunnerDeps.memoryBackend` / `memoryEngineDir`),`grep -rn "\.materialize("
- * src test` 零命中 ⇒ 没有调用点可以传第三参,也没有 handle 可读。受限判据因此**只能**从
- * `TaskSpec.memoryPersistenceCapable` 一条路进去(`boot/resolve-spec.ts` 直通),我方显式**不铸**受限会话、
- * 也**不投**这个读面(硬造一个消费点 = 造给自己看的 wire 键)。哪天真要在诊断面露它,先有消费方需求。
- */
 import { resolve } from "node:path";
-/**
- * #266 A3 源头修(黑板 [4080]/[4082]/[4083],A-044)—— `memoryPersistenceCapable` 的**装配层有效值**:
- * operator 显式 env 恒赢;env 缺席时,`REMOTE_EXEC=host` 腿自动补 `true`;其余一律缺席(现行为)。
- *
- * ## 为什么 host 腿可以自动声明(而且只有 host 腿)
- * core r13/r14 的 withhold 判据是「执行环境暴露 remote 面」——它对 host 腿是**误伤**:host 腿的文件
- * 工具就跑在**这台机器**的 fs 上(`hostSemanticsLane`,与 core 的 remote 判决是两根轴,见下方 facts 注),
- * 记忆根也在这台机器上,「执行车道与记忆根共享文件平面」这个 capable=true 所断言的**车道级事实**由
- * 构造成立。剩下的围栏维(记忆根是否落在该次任务的 fs 授权边界内)在 in-process 上**同样存在**而 core
- * 并不 withhold——它由本模块的 ② 号 warn、fs 门的 `path_not_in_root` 拒绝、`additionalDirectories`
- * 旋钮这套既有处置管,不归 withhold 判据管。所以 host 腿自动 true 与 in-process 的默认行为**同等诚实**。
- * 沙箱腿(e2b/k8s/ssh/local-docker)文件平面在沙箱盘,withhold 是对的,恒不自动。
- *
- * ## 为什么不是「围栏覆盖记忆根」的更严合取
- * boot 期对 host 腿**算不出**围栏根(host factory 每任务另铸 `sema-host-*` 子目录、per-session cwd 可整个
- * 换掉 workspaceBase——见 boot/stores.ts 的 codex 已核注释),那个合取在恰恰需要它的腿上永不可满足;
- * 而且它断言的是 per-task 事实,不是本键的车道级语义。
- *
- * ## 位置与纪律
- * 单源:resolve-spec 的 spec 直通、`shouldDiscloseNoPersistentMemory` 判别式、boot 审计的 declared 位
- * 三处都必须读本函数,禁各自重算(operator-knob 律:显式 env 的优先权在这一个函数里执法一次)。
- * 自动补位在 boot 日志上必须可见(stores.ts 的 info 行),部署方随时可用显式 env 覆盖。
- */
 export function effectiveMemoryPersistenceCapable(config) {
     if (config.memoryPersistenceCapable !== undefined)
         return config.memoryPersistenceCapable;
     return config.remoteExec?.provider === "host" ? true : undefined;
 }
-/** 词法包含判定:`child` 是否落在 `root` 之内(含相等)。纯词法,不碰 fs —— boot 期这些路径可能还没被
- *  创建,而 `realpath` 会把「同一棵树的两种写法」这个我们**不想**放过的差别悄悄抹平。
- *  先过 `resolve` 折掉 `.`/`..`/重复分隔符(codex 复审:`/srv/ws/../mem` 不该被读成落在 `/srv/ws` 里),
- *  再按 `root + "/"` 前缀判,所以 `/srv/workspace-2` 不会被 `/srv/workspace` 吃掉。 */
 function isInside(child, root) {
     const c = resolve(child);
     const r = resolve(root);
     return c === r || c.startsWith(r === "/" ? "/" : `${r}/`);
 }
-/**
- * 判两件事,互斥(remote 上不叠 host 的围栏话 —— 围栏根本不在这台机器上,说了是噪音):
- *
- * ① **remote 车道**(只可能因为 `MEMORY_ENGINE_REMOTE_LANE=allow` 才在这里还有引擎):core 5.26.0 的
- *    r13/r14 收窄把 `# Memory` 写指令在 remote executionEnv 上撤了(沙箱手带够不着 host 记忆根),
- *    官方恢复路径是声明 `memoryPersistenceCapable: true`。未声明 ⇒ 点名 warn,把恢复旋钮写进句子里。
- * ② **host 车道**:记忆根不在任何一个已知围栏根内 ⇒ 模型被教着往一个 fs 工具够不到的路径写。
- *
- * 两极声明都让本模块闭嘴,但理由不同,别合并:
- *  · `true` = operator 自证有推断看不见的持久通道(共享挂载 / 自定义 writer),我们的结构判断本就不该
- *    压过部署方对自己环境的声明;
- *  · `false` = operator 已经承认「本机存不下」,引擎据此改口披露只读 —— 再 warn 一次是把已知情的事
- *    当新闻报。
- */
 export function buildMemoryWriteBoundaryAudit(facts) {
     const { memoryRoot, lane, hostSemanticsLane, coreRemoteExecutionEnv, declaredCapable, containmentRoots, engineBackend } = facts;
     if (memoryRoot === undefined)
-        return { warnings: [] }; // 引擎未接
+        return { warnings: [] };
     if (declaredCapable !== undefined)
-        return { warnings: [] }; // 部署已表态(两极,理由见头注)
-    // ① 写指令被撤 —— 判据是 **core 的 remote 判决**,不是文件平面(codex round2 [medium],已核真:
-    // `REMOTE_EXEC=host` 的文件平面是本机,但 core 照样判它 remote 并撤掉写指令。按文件平面分腿会让
-    // 这一形整个静默 —— 恰恰是最容易被忽略的那台机器:记忆看着是开的,写指令没了,没人说过一句)。
+        return { warnings: [] };
     if (coreRemoteExecutionEnv) {
         const plane = hostSemanticsLane
             ? `the model's file tools DO run on this worker's filesystem, but core classifies this execution environment as ` +
@@ -118,13 +34,9 @@ export function buildMemoryWriteBoundaryAudit(facts) {
         };
     }
     if (containmentRoots.length === 0)
-        return { warnings: [] }; // 围栏根算不出 ⇒ 不判(见头注)
+        return { warnings: [] };
     if (containmentRoots.some((root) => isInside(memoryRoot, root)))
         return { warnings: [] };
-    // 第一条恢复路径按**后端腿**指对旋钮(2026-08-12 复扫 low:pg/tidb 腿上 MEMORY_ENGINE_DIR 不接线,
-    // 而「in-process + MEMORY_ENGINE_BACKEND=pg + 未配 LOCAL_DATA_ROOT」恰恰是这条 warn 的默认命中形 ——
-    // 照旧文案去拧只会一直修不好)。另外两条(additionalDirectories / MEMORY_PERSISTENCE_CAPABLE=false)
-    // 两条腿都真有效,不分腿。
     const relocateRoot = engineBackend === "file"
         ? `point MEMORY_ENGINE_DIR at a path under the workspace`
         : `point LOCAL_DATA_ROOT at a path under the workspace (on the "${engineBackend}" memory plane the root is ` +

package/dist/boot/org-memory.js

@@ -1,10 +1,6 @@
 import { fetchPrincipalOrgMemory } from "../config-center/http-client.js";
 import { createMemoryScopeAdmission, createOrgMemoryDirectory, parseOrgDirectoryStatic } from "../org-memory-admission.js";
 const ORG_PREFIX = "org:";
-/** 部署自证 org scope 集(core 准入门的 deployment origin 词表):env 钉的 MEMORY_SCOPE(org 形时)
- *  + **单用户部署**的 projects 登记簿 org 键(N2:requirePrincipal !== true 的部署无租户边界,operator
- *  登记簿条目归 deployment)。多租户下登记簿 org 键**不入**此集——它们由 resolve-spec 按 request 盖章,
- *  走目录判决。 */
 function collectDeploymentOrgScopes(config) {
     const scopes = new Set();
     if (config.memoryScope !== undefined && config.memoryScope.startsWith(ORG_PREFIX))
@@ -18,7 +14,6 @@ function collectDeploymentOrgScopes(config) {
     }
     return [...scopes];
 }
-/** 依赖收窄到真实消费面(warn/inc 各一手)——接口隔离让测试用真形字面量,零铸形([2704] §1)。 */
 export function createOrgMemoryAdmissionWiring(opts) {
     const { config, logger, metrics } = opts;
     const deploymentMemoryScopes = collectDeploymentOrgScopes(config);
@@ -31,30 +26,17 @@ export function createOrgMemoryAdmissionWiring(opts) {
     }
     const directory = centerLeg !== undefined
         ? createOrgMemoryDirectory({
-            // 复审 D-2 修:走 org 段专用读取口而不是整封 caps 读。两者同一条 HTTP 腿、同一道 C8 回声核,
-            // 差别只在**解析投影**:org 腿只读 principal+orgMemory 两字段,治理面(runtimeCaps/budget)的
-            // 值漂移因此不再连坐 org 授权面(此前:一封 runtimeCaps 漂移的响应会让形状完全正确的 org 段
-            // 读不出来 ⇒ 目录记 fetch_failed ⇒ 准入瞬时拒)。C3「两张表失败域互不干扰」至此是双向的。
             fetchSection: (principal) => fetchPrincipalOrgMemory(centerLeg.baseUrl, centerLeg.token, principal, fetch, centerLeg.worker),
             grantTtlMs: config.memoryOrgGrantTtlMs,
             unavailableBackoffMs: config.memoryOrgUnavailableBackoffMs,
         })
         : staticJson !== undefined
             ? createOrgMemoryDirectory({
-                staticTable: parseOrgDirectoryStatic(staticJson), // 启动期 fail-loud(坏表拒启动)
+                staticTable: parseOrgDirectoryStatic(staticJson),
                 grantTtlMs: config.memoryOrgGrantTtlMs,
                 unavailableBackoffMs: config.memoryOrgUnavailableBackoffMs,
             })
             : undefined;
-    // C12 能力探测:多租户 + **记忆面真点亮** + 登记簿有 org 用面 + 目录源缺席 ⇒ 拒启动(见文件头注)。
-    //
-    // 复审 D-1(7.1.0 后修):探测原先少了「记忆面是否真点亮」这一维,是假阳。多租户下记忆引擎只在
-    // `MEMORY_ENGINE` 开 **且** backend 非 file 时才装(boot/stores.ts:file 形在 requirePrincipal 下恒
-    // 走 memoryEngineBackendFor() = undefined,「file 底座无租户隔离」);记忆面 dark ⇒ resolve-spec 的
-    // `memoryEngine ? memorySpecForRequest(...) : undefined` 根本不铸 spec.memory ⇒ 登记簿里的 org 键
-    // 一次也到不了 core 准入门。此时拒启动既拦下了一个本来跑得好好的部署,报错串里那句「every request
-    // selecting these projects would be refused at prepare」也是假陈述——探测的成立前提就是「这些键真会
-    // 被请求带到准入门」。
     const memoryPlaneLive = config.memoryEngineEnabled && config.memoryEngineBackend !== "file";
     if (directory === undefined && config.requirePrincipal === true && memoryPlaneLive) {
         const orgProjects = Object.entries(config.projects)
@@ -69,12 +51,6 @@ export function createOrgMemoryAdmissionWiring(opts) {
     const memoryScopeAdmission = directory !== undefined
         ? createMemoryScopeAdmission(directory, {
             mode: config.memoryOrgAdmissionMode,
-            // §5 观测:outcome 闭集 metric + 审计日志线(per-principal 归因走日志,principal 不入 metric label)。
-            // 复审 D-3(7.1.0 后修)两处:①`mode` 进 metric label —— 不然 audit 模式记的 would-refuse 与
-            // enforce 模式的真拒在同一条 `outcome="denied"` 曲线上不可辨,而「照算不真拒、看曲线」正是
-            // audit 这个诊断位存在的唯一用途(二值闭集,基数代价为零);②principal 真的进日志行 —— 归因
-            // 由 resolver 塞进 details(此前 details 里根本没有 principal,「per-principal 归因走日志」
-            // 这句注释与 CHANGELOG 7.0.0 的同款公开陈述都不成立:运维只看得到「某个 org scope 被拒」)。
             onOutcome: (outcome, details) => {
                 metrics.inc("memory_admission_total", { outcome, mode: config.memoryOrgAdmissionMode });
                 if (outcome !== "ok" || details !== undefined)

package/dist/boot/parked-revive-gate.js

@@ -1,11 +1,3 @@
-/**
- * [1596]/[1597] 跨副本父约束重供席工厂 —— durable park 的**赎回腿**(design/181 件二 / #179)。
- *
- * 从 main.ts 的装配体里提出来的**唯一理由不是内聚,是可测**:main.ts 顶层 `void main()`,谁 import 它
- * 谁就启动一整个服务,所以那条腿的**运行期**语义在原地一格都钉不住(此前只有源码字符串钉)。提出来之后
- * 「重建出来的链到底裁决成什么样」变成可断言的事实(test/parked-revive-gate-wiring.test.ts 运行期钉 +
- * 治理矩阵的第三维消费腿)。装配次序契约不变:main.ts 仍在同一位置构造,构造条件逐字保持。
- */
 import { join } from "node:path";
 import { createAutoModeDecider, NodeExecutionEnv } from "@sema-agent/core";
 import { recordFailOpen } from "../observability/fail-open.js";
@@ -13,19 +5,6 @@ import { decodeCheckpointScope } from "../security.js";
 import { createApprovalBaselinePolicy, createDeploymentGovernanceInputs, } from "../deployment-governance.js";
 import { applyRuntimeGovernance } from "../runtime-governance.js";
 import { DeferredSandboxPathEnv, isSandboxPathAdjudicationLane, sandboxPathEnvSlots } from "./deferred-sandbox-path-env.js";
-/**
- * host 腿裁决 env 的 cwd:**从不创建**的占位目录(resolve-spec 的 `fs-write-gate-unrooted` 同族)。
- *
- * 赎回腿拿不到子代的工作目录(park 时未持久化,design/181 §2.2 的 v2 候件票),而 `NodeExecutionEnv`
- * 的构造要求一个 cwd。占位形的语义:**绝对形写目标照常按真身裁决**(cwd 与它们无关),相对形则在
- * 一个不存在的根上 canonicalize —— 段匹配照旧命中(守卫段是路径**段**判据),方向 fail-closed。
- * 真正兜住相对形的是构造口内的 `RelativeTargetLexicalEnv` 词法臂(`PathAdjudication.cwd` 缺席即自动补层)。
- * ⚠️ core 5.19.0(#108)后这句话的射程变窄了:守卫改按 `ToolCallRequest.cwd ?? rootPath` 解析写目标,
- * 引擎盖了戳的调用**根本走不到**本占位根(戳优先),词法臂也随之让位给真身裁决(全文见
- * `deployment-governance.ts` 的 `RelativeTargetLexicalEnv` 类注)。本占位根今天只在缺戳形上承重,
- * 语义不变、方向仍 fail-closed,故保留不动。
- * 绝不回落 `process.cwd()`:那是**服务自己的**启动目录,把它当成子代的盘是拿错基准(resolve-spec W4 同案)。
- */
 function hostGateCwd(config, localRoot) {
     return join(config.localDataRoot ?? localRoot, "parked-revive-unrooted");
 }
@@ -33,15 +12,7 @@ export function createParkedReviveInheritedGate(deps) {
     const { config, question, approvalExemptionStore, logger, localRoot, approverSeat } = deps;
     const slots = deps.slots ?? sandboxPathEnvSlots;
     return async (row, identity) => {
-        // A-010.1:三位决议链元数据。**async 的唯一理由**就是其中两位要按 principal 现解 entitlement
-        // (core 的 resolver 座本身也是 sync-or-async),而这条腿的消费点(parked-decide 的 `decideParkedAgent`)
-        // 从来就在 async 里,「席位必须同步」是本文件此前自设的约束,不是结构事实。
         const metadata = await chainMetadataOf(deps, row, identity);
-        // lane 分形与 resolve-spec 同一判别式(单一属主,取值处只此一个)。
-        // 🔑 沙箱腿的 slot 键 = **row.sessionId**(子代自己的会话,design/181 §2.2 裁定):revive 后 core 以
-        //    该 sessionId 铸 env 并注册 slot(subagent → prepare-task → 工厂装饰器),这个键真能绑上。
-        //    键 rootSessionId 跨副本恒 unbound ⇒ 每一次结构化写 fail-closed ⇒ 整条腿瘫痪。
-        //    未绑时转发面报错 → core 读成 unresolvedSymlink → 守卫策略 deny(成文的 fail-closed 行为)。
         const pathAdjudication = isSandboxPathAdjudicationLane(config.remoteExec?.provider)
             ? {
                 env: new DeferredSandboxPathEnv({
@@ -51,8 +22,6 @@ export function createParkedReviveInheritedGate(deps) {
                 }),
             }
             : { env: createHostAdjudicationEnv(config, localRoot) };
-        // 审批基线:durable 轴(问答门 + F4 审批门 + 会话豁免探针)。exempt 锚 = row.rootSessionId
-        // ——与 /decide 的 remember grant 同键([1591] 候裁②),重建链上的豁免语义与原链一致。
         const rootSessionId = row.rootSessionId;
         const baseline = createApprovalBaselinePolicy(config, {
             question,
@@ -63,11 +32,7 @@ export function createParkedReviveInheritedGate(deps) {
                 }
                 : {}),
         });
-        // 折叠属主 = applyRuntimeGovernance → core tightenTaskSpec(本腿一条 policy 都不自己合成)。
-        // `objective: ""` 只是折叠所需的最小 TaskSpec 座——本腿只取回 toolPolicy,spec 的其余面不出本函数。
         const governed = applyRuntimeGovernance({ objective: "", toolPolicy: baseline }, createDeploymentGovernanceInputs(config, pathAdjudication));
-        // 治理段无可施加时 applyRuntimeGovernance 原样返回 base ⇒ 基线本身即为链(恒非 undefined,无需断言)。
-        // shellGate 只在治理段真产出档位时出现在载体上(缺席 = 本次没有 live 值可交,core 用 seed 兜底)。
         return {
             parentConstraints: [
                 {
@@ -80,43 +45,6 @@ export function createParkedReviveInheritedGate(deps) {
         };
     };
 }
-/**
- * 重建条目的**决议链元数据**(core 5.22.0 F-012)—— 三位的逐字重算,**一次** entitlement 现解喂全三位
- * (第三位与两位 mandate 的 `forceDurableGate` 项读的是同一次 caps,分两次解会开一个「同一条链里两位读到
- *  不同代 entitlement」的窗)。
- *
- * 为什么它承重:5.22.0 把 re-supply 契约从 count 换成 `cpv1:` 内容摘要
- * (`constraintChainDigest`),而摘要 **把这两位卷了进去**。park 时那一层记的是什么,赎回腿就必须供
- * 什么——供多了、供少了都是 `resume.parent_constraint_mismatch` 响亮拒(pre-CAS,checkpoint 留
- * pending)。**不许**为了让摘要对上而回读 checkpoint 里记的那两位再原样回声:那等于把「重算出同一条链」
- * 换成「抄一份自证」,摘要的防篡改语义当场归零。
- *
- * core 的原式(`prepare-task.js` 的 `inheritedGateForChildren`):
- * ```
- * durableMandate = runtimeCaps.forceDurableGate || (spec.durableApproval !== undefined && !isLiveApproverSeat(spec.onAsk      ?? deps.onAsk))
- * contentMandate = runtimeCaps.forceDurableGate || (spec.durableApproval !== undefined && !isLiveQuestionFace(spec.onQuestion ?? deps.onQuestion))
- * ```
- * 本仓三项对位:
- *  · `spec.durableApproval !== undefined` —— 本工厂**只在** `config.durableApproval` 为真时构造
- *    (main.ts 的构造条件逐字),故这一项在本函数射程内恒成立;
- *  · 审批席 = `spec.onAsk ?? deps.onAsk` 的**在场性**。本仓两个装配点(deps 级
- *    `createRunnerDepsOnAsk`、per-task 级 `routes/tasks.ts` 的 `boundAsk`)受**同一个**条件闸
- *    ——`toolApproval` 协调器在不在场——所以这个布尔在两位上恒等,`approverSeat` 在不在场即判据。
- *    ⚠️ 判据是**在场性**不是同一只闭包:身份不同不影响摘要(全文见 {@link ParkedReviveGateDeps.approverSeat});
- *  · 问答席 = resolve-spec 的 `liveQuestionFace`:在场 ⇒ spec 不 stamp sentinel、`deps.onQuestion` 的
- *    协调器生效(`isLiveQuestionFace` 判 true);缺席 ⇒ spec stamp `QUESTION_AWAITS_RESUME`
- *    (该 sentinel 被 `isLiveQuestionFace` 判 false)。两支都归结为 `question` 在不在场。
- *
- * ✅ **原「已披露残余」销账(A-010.1 同车)**:`runtimeCaps.forceDurableGate`(center 逐 principal 的
- * 授权位)此前写着「在本装配点解不出来——resolver 是 async 而重供席位的形是同步 `(row) => gate`」。那条
- * 阻塞是**本文件自设**的,不是结构事实:唯一的消费点(`parked-decide.ts` 的 `decideParkedAgent`)本来
- * 就在 async 里。席位随本件改成 async 之后,该位与 `autoModeArmed` 走同一条 caps 现解腿一并补齐 —— 否则
- * 「该位为真 + 部署装了活体席」这个组合上 park 记 true 而本腿供 false,摘要恒不匹配、这批 principal 的
- * parked 卡同样永不可赎(与 A-010.1 同族同因的第二个总失效面)。
- *
- * ⚠️ 时点语义与 toolPolicy 轴同族:两位都按**当前** entitlement 现解,挂起期间被撤/被授 ⇒ 摘要对不上
- * ⇒ core pre-CAS 响亮拒(带 `parked_resume.startup_failed` 码可观测),绝不静默按新姿势跑。
- */
 async function chainMetadataOf(deps, row, identity) {
     const caps = await resolveCapsFor(deps, identity);
     const forced = caps?.forceDurableGate === true;
@@ -126,36 +54,6 @@ async function chainMetadataOf(deps, row, identity) {
         ...autoModePostureOf(deps, row, caps),
     };
 }
-/**
- * 本行 principal 的 entitlement 现解(三位元数据共用**一次**)。
- *
- * principal 从哪来:**调用方交下来的 {@link ParkedReviveIdentity}**,值 = `decodeCheckpointScope(cp.scope)`。
- * `cp.scope` 由 `boot/resolve-spec.ts` 写成 `encodeCheckpointScope(auth.principal)`(legacy resume 腿反向
- * 读回 `principal: decodeCheckpointScope(cp.scope)` 是同一等式的另一半),所以它就是那条 run 的
- * `spec.principal`,与 core 喂给 `runtimeCapsResolver(spec.principal)` 的**同一个**值 —— 摘要两侧因此
- * 解到同一份 caps。
- *
- * ⚠️ **不要退回去读 `row.scope`**。写行那一侧(core `subagent.js` 的 `ctx.principal ?? opts.background.scope`,
- * 本仓 `capabilities/scenarios.ts` 填字面 `"default"`)用的是 `principal ?? "default"` 这套约定,与
- * `encodeCheckpointScope` 的 `"_"` 哨兵**不同源**:有 principal 时两套折出同一个字符串(encode 只在
- * null/undefined 时才替换),匿名时分别是 `"default"` 与 `"_"`,而且那一列上**匿名与真名叫 `default` 的
- * 租户不可分辨** —— 有损。
- *
- * 🔴 A-057.44(2026-08-19 两半皆修,本注随之改真)—— **匿名** run 上两者分别是 `"default"` 与 `"_"`,
- * 修前分区查询直接落空 ⇒ 本函数在匿名部署上根本到不了(decide 退回 legacy resume 腿,而那条腿
- * `getCtx(子代会话)` 必 null ⇒ 恒 409)。第一半:`findParkedAgentForCheckpoint` 现在按
- * `backgroundScopesForCheckpointScope(cp.scope)` 的**别名集**查(匿名时把 `"default"` 一并纳入),
- * 于是本函数在匿名部署上首次可达。
- *
- * 第二半(codex 对抗复审 medium,验真后采纳)——**principal 不再从 `row.scope` 解**。本注的上一版警告过
- * 「谁哪天弥合那个匿名未命中,必须连本函数一起重看:`decodeCheckpointScope("default")` 会解出字符串
- * `"default"` 并把它当租户名递进 resolver」。那句警告在第一半落地的当天就兑现了:`row.scope` 在
- * `principal ?? "default"` 约定下**结构性有损**(匿名与一个真名叫 `default` 的租户在这一列上同形),
- * 解错的后果不是拒绝而是**解到另一份 caps** ⇒ 与 park 时冻的摘要对不上 ⇒ 刚变得可达的那批卡又赎不回。
- * ⇒ 席位多收一位 {@link ParkedReviveIdentity}:权威 principal 由**调用方**从 `decodeCheckpointScope(cp.scope)`
- * 现算并传下来(`parked-decide.ts` 的 `decideParkedAgent`),该列由 `encodeCheckpointScope(auth?.principal)`
- * 铸、与 core 喂给 `runtimeCapsResolver` 的是同一个值,无损。参数**必填**:漏传是编译错,不是静默回退。
- */
 async function resolveCapsFor(deps, identity) {
     if (deps.resolveRuntimeCaps === undefined)
         return undefined;
@@ -163,61 +61,15 @@ async function resolveCapsFor(deps, identity) {
         return await deps.resolveRuntimeCaps(identity.principal);
     }
     catch (err) {
-        // 留痕是必需的:否则「这批卡为什么突然赎不动」查无痕迹。
         deps.logger.warn("parked_revive_caps_unresolved", { principal: identity.principal ?? null, err: err instanceof Error ? err.message : String(err) });
         return undefined;
     }
 }
-/**
- * A-010.1 —— 重建条目的**第三位**决议链元数据 `autoModeArmed`(core 5.22.0 F-012 与两位 mandate 同车)。
- *
- * ## 病(本函数存在的唯一理由)
- * core 的摘要口(`tool-policy.js` `constraintChainEntryOf`)把**三**位卷进 `cpv1:` 摘要,而判据是
- * 「条目上有没有 `autoMode` 这个键」:park 时 `prepare-task.js` 的 `inheritedGateForChildren` 写
- * `...(autoModeDecider !== undefined ? { autoMode: { decider } } : {})`,赎回时 `runtask.js` 的 pre-CAS
- * 门按 `pc.autoMode !== undefined` 逐字重算。本腿此前只供 policy/onAsk/两位 mandate,**从不供** autoMode
- * ⇒ auto-mode 权益 principal 的每一条跨副本 parked 赎回摘要恒不匹配、`resume.parent_constraint_mismatch`
- * 响亮拒、卡永不可赎(方向 fail-safe,但功能面对这批 principal 是整条失效)。
- *
- * ## core 的原式(逐字对位,不绕过)
- * ```
- * if (runtimeCaps?.autoMode === true && deps.autoMode !== undefined) autoModeDecider = createAutoModeDecider(…)
- * ```
- * 两个半场本仓分别对位:
- *  · `deps.autoMode !== undefined` ⇒ {@link ParkedReviveGateDeps.autoModeSeatMounted}(装配面恒挂,见
- *    `boot/runner-deps.ts` 的 `autoMode:{onBreakerOpen}`——**信任门**,单挂它武装不了任何东西);
- *  · `runtimeCaps.autoMode === true` ⇒ {@link resolveCapsFor} 按**本行的 principal** 现解(时点语义、
- *    principal 从哪来、resolver 缺席/抛错怎么判,全在那只函数的头注)。
- *
- * ## ⛔ 已披露残余:decider 的**身份**跨不了进程(P-DEBT,不是等价替换)
- * 摘要只看键在不在,但 core 在赎回后的每一次继承 ask 上会**真的调** `pc.autoMode.decider`
- * (`prepare-task.js` 的继承包装器,顺序:分类器 → 冻结审批席)。而那只 decider 是祖先任务上的活闭包
- * (绑着它自己的 session 转写窗 + brain),跨副本重建不出来 —— 与本文件 `approverSeat` 那格「诚实的降级」
- * 同族。本腿交的是 **core 自己的构造器**铸的一只 decider,其 classify 腿如实拒答 ⇒ core 收到
- * `unavailable`(它自己 `.catch(() => ({kind:"unavailable"}))` 的同一形)⇒ **不产生任何自动裁决**,原样
- * 落到祖先冻结审批席那条链上(本腿的席位又是无 ALS 的降级形 ⇒ `approverUnavailable` ⇒ 再 park 给人)。
- * 方向:分类器本会 `allow` 的调用改成问人(**更严**);本会 `block` 的也改成问人(**不是自动放行**,但
- * 确实比自动拒松一档)。所以它按 P-DEBT 记债而不是当合法兜底 —— tag
- * `server.parked-revive.ancestor-classifier-unreachable`,逐次计数 + 一次性 warn,收口件二选一:core 把
- * 分类器判据持久进链条目,或让祖先 decider 有可跨进程重建的形。
- */
 function autoModePostureOf(deps, row, caps) {
     if (deps.autoModeSeatMounted !== true || caps?.autoMode !== true)
         return {};
     return { autoMode: { decider: createUnreachableAncestorClassifier(deps, row) } };
 }
-/**
- * 祖先分类器的**跨进程降级形**(全部理由在 {@link autoModePostureOf} 的残余段)。
- *
- * 内核用 core 自己的 `createAutoModeDecider` 铸 —— 超时/熔断/verdict 词表(`unavailable` 这个词本身)
- * 都归 core 单一属主,本仓只提供一条**如实拒答**的 classify 腿,绝不在此手抄 `{kind:"unavailable"}`。
- * `failureThreshold: 1` 让熔断一拍即开:第一次被咨询就把一次性告警喊出来,之后每次 `decide` 在 core 内
- * 早返 `unavailable`(不再进 classify、不再起 15s 定时器)。
- *
- * 🔴 计数**必须**打在外层 `decide` 上、不能打在 `classify` 里:熔断开了以后 core 早返、classify 再也不
- * 被调用,计数打在里面就永远只记 1 —— 而这个 tag 的语义(和普查表里那一行的文字)是「**丢了祖先分类器
- * 判决的继承 ask 次数**」。打在里面等于让遥测读数与它自称的含义不是一回事,债就在账上消失了。
- */
 function createUnreachableAncestorClassifier(deps, row) {
     const inner = createAutoModeDecider({
         failureThreshold: 1,
@@ -240,8 +92,6 @@ function createUnreachableAncestorClassifier(deps, row) {
         },
     };
 }
-/** host 腿的裁决 env(真 fs;构造是纯字段赋值,不 spawn)。**每次赎回现铸**——与「禁 memoize」同因:
- *  cwd 占位读的是活 config 的 `localDataRoot`。 */
 function createHostAdjudicationEnv(config, localRoot) {
     return new NodeExecutionEnv({ cwd: hostGateCwd(config, localRoot) });
 }

package/dist/boot/permission-rules-audit.js

@@ -1,35 +1,6 @@
-/**
- * #203 §3(design/203 v2 §6 F4 的**残余采纳**)—— 默认 ON 的**休眠行审计**。
- *
- * 🔴 这条审计存在的唯一理由:`PERMISSION_RULES_ENABLED` 的默认值在本车从 OFF 翻成 ON,而**旋钮翻转
- * 与规则行的寿命是两条独立的时间线**。三张表自 #154 车二起就随中央 `ensureSchema` 建、并且从来没有被
- * 清过,所以下面这两类部署在升级的那一刻会突然带着**既有**规则行开始放行:
- *   · 曾经把旋钮开过一段时间又关掉的部署(行留在库里,只是没人读);
- *   · 从旧库恢复/克隆出来的部署(行跟着数据一起来的)。
- * 对运维来说,这是「我什么都没改,worker 却开始少问我了」——一次**放宽面**上的静默变化。审计做的事
- * 很小但是承重:在启动日志里把它说出来,让「少问」是一条能被读到的因果,而不是一次玄学。
- *
- * ── 三条判据,逐条有理由 ────────────────────────────────────────────────────────────────────────
- *  ① **店缺席 ⇒ 整条不上场**(零 I/O、零行)。店缺席包括:显式关旋钮、`local` 车道没接 File 店的旧
- *     部署、以及压根没有 backend 的 env-only worker。没有店就没有行,谈不上唤醒。
- *  ② **零桶 ⇒ 不打行**。一条「0 条既有规则随默认 ON 激活」的行是纯噪音:它对读日志的人不传递任何
- *     可行动的信息,却让真正有东西被唤醒的那一行变得不显眼。
- *  ③ **运维**显式**表过态(`PERMISSION_RULES_ENABLED` 被设成 true 或 false)⇒ 不打行**。那些行本来
- *     就是活的(或者旋钮被显式关着、店根本没装配),默认值翻不翻转对它们零影响 —— 说「随默认 ON
- *     激活」是**假话**,而在启动日志里说假话比不说更坏。判据用 `permissionRulesEnabledExplicit`
- *     (config.ts 与 `dbBackendExplicit` 同姿势),不是猜。
- *
- * ── 失败方向 ────────────────────────────────────────────────────────────────────────────────────
- * 数不出来(库抖动 / 文件读不了)⇒ **不拒启、也不编一个 0 出来**:返回 `undefined` + 一条 warn。
- * 这是一条纯诊断面(它不参与任何放行/拒绝判决),所以它的降级方向是「安静地不知道」而不是「谎报
- * 零」——`{ buckets: 0 }` 会被下游读成「确认没有休眠行」,那是把一次读失败伪装成一个结论。
- * 因为它零判决,这条 fail-open 不属于 `docs/FAIL-OPEN-CENSUS.md` 的安全轴 P 类,故不占 `recordFailOpen`
- * 的标签;它的可见性由那条 warn 承担。
- */
-/** boot 期一次性调用。返回读数(`undefined` = 没店 / 数不出来),绝不抛。 */
 export async function auditDormantPermissionRules(ctx) {
     if (ctx.stores === undefined)
-        return undefined; // ①
+        return undefined;
     let buckets;
     try {
         buckets = await ctx.stores.countBuckets();
@@ -42,32 +13,6 @@ export async function auditDormantPermissionRules(ctx) {
         return undefined;
     }
     if (buckets > 0 && !ctx.explicit) {
-        // ②③ 都不成立才说话。文案给的是**一条可行动的因果**:看到少问了 ⇒ 这里有 N 只既有桶 ⇒ 用
-        // `GET /v1/rules` 看、用 `DELETE /v1/rules` 收,或者把旋钮显式关掉。
-        //
-        // 🔴 **local-owner 桶的现状必须同拍说清**(#203 收官件 / #205 件5,core 5.24.0 提货批):
-        // `countBuckets` 数的是**所有**桶,其中可能有一只**身份缺席**的 local-owner 桶(File 后端 =
-        // `permission-rules/local-owner.json`,SQL 后端 = owner_key `local-owner` 的行)。而 `GET`/`DELETE
-        // /v1/rules` 两口是 **principal 寻址**的(无 principal 一律 401,契约上刻意的边界)—— 对那只桶,
-        // 上面那句「inspect with GET / revoke with DELETE」是**兑不出来的承诺**。
-        //
-        // ⚠️ 文案只说**兑得出来**的话(codex 对抗复审 R1-[medium],验真后改):第一稿在这里写的是
-        // 「adopt it into a principal first」——**本仓没有那条路**。收编入口的来源词表逐字只有
-        // `{kind:"principal"}`(`adoption/wire.ts` 的 `AdoptionSourceSchema`,`.strict()` 拒 local-owner),
-        // core 的 `adoptFilePermissionRuleStore` 在 src/ 下零调用点,SQL 侧连对应原语都没有。指一条走不通
-        // 的路比不指更坏:运维会去试,试不通才发现自己被误导。
-        // 今天**真能做的**只有两件:①`PERMISSION_RULES_ENABLED=false` 把整条车道关掉(上面已给);
-        // ②运维直接动存储。
-        // 🔴 第二条的**谓词必须是真的**(codex 对抗复审 R2-[medium],验真后改):第一稿写的是
-        // 「owner_key='local-owner'」——那条 SQL **一行都删不到**。`buildRuleOwnerKey`
-        // (`plugins/permission-rule-store-sql.ts`)把 owner_key 算成 `sha256("local-owner")` 的十六进制,
-        // 字面判别式存在**另一列** `owner_kind` 上。给一条匹配零行的删除语句比不给更坏:它会静默成功,
-        // 运维以为收回了权限而规则还在放行。真谓词 = `permission_rule` 表的 `owner_kind='local-owner'`。
-        // File 后端那侧是固定文件名,照给。
-        // 店层与车道层其实已接通(core 5.24.0 的 `removePersistedRule` 收 `RuleOwner`,本仓
-        // `rules-consent.ts` 的 `listRules`/`removeRule` 已能寻址该桶,格见
-        // `test/rules-consent-local-owner.test.ts`),缺的只是一个 HTTP 开口 —— 开不开、开在哪条门
-        // (operator 面 / run-local 面)属产品面裁定,不在本车擅开。
         ctx.logger.info("permission_rules_activated_by_default", {
             buckets,
             knob: "PERMISSION_RULES_ENABLED",