/**
 * [ref] 记忆边界不变式(板 [ref]② 立案,[ref] 裁1 与 core [ref] 同窗)—— 启动期把「结构性写不进的记忆
 * 部署形」说出来。
 *
 * 根本问题(test 仓 [ref] 实测,[ref]② 定位):core 的记忆工具面是 `memory_search`/`memory_get`/
 * `memory_index`([ref] 第五单起第三只,枚举面,仍只读)三只**只读**工具;**写**记忆没有专用工具 —— 模型用 fs 工具往记忆根写文件,harvest 再从那里收编。于是整条链的成立
 * 条件是「记忆根落在该次任务的 fs 授权边界之内」。server 把根交给 core(`RunnerDeps.memoryEngineDir`)
 * 之后,没有任何一处保证这一点,也没有任何一处说过「这台部署的记忆写面够不着」。默认根是
 * `~/.ai-agent`(或 `AGENT_DATA_DIR`),默认围栏是任务 cwd —— 两者天然不相交:用户说「记住 X」,模型照
 * 提示词去 Write,拿回一个 `path_not_in_root`,而回执早就发出去了。
 *
 * 判据形态 = **纯函数 + 启动 warn,不拒启**。理由是诚实:共享挂载 / bind mount / 部署方自己在别处开了写通道,
 * 都是真实可行的部署形,而我方在 boot 期看不全。看得全的是「按我们自己接的线,
 * 这条链**结构上**走不通」——那句必须说出来。围栏根算不出来时**不说话**(判不了就闭嘴,别把猜测当告警)。
 *
 * 🔴 **已登记的判据限度(不在本批射程,别把它读成「判据已闭合」)**:② 号 warn 今天唯一算得出围栏根的
 * 腿是 `REMOTE_EXEC` 未设的 in-process 形(`boot/stores.ts` 的 `containmentRoots`),而**恰恰是这条腿
 * 没有文件工具** —— 亲读装的这台 core:`prepare-execution-env.js` 的
 * `handsEnabled = ownedEnv !== undefined || deps.executionEnv !== undefined`,本仓不设 `REMOTE_EXEC` 时
 * `executionEnvFactory` 恒 `undefined` ⇒ `handsEnabled=false` ⇒ `prepareHandsMount` 整个不跑。所以这条
 * warn 描述的失败形(「模型照提示词去 Write,拿回 `path_not_in_root`」)在该腿上并不成立:真相是**一只
 * 文件工具都没有**,而按它给的第一条恢复路径(把根挪进 workspace)会让 warn 闭嘴却仍然写不成。
 * 把判据换成「执行能力 + core 自己的 advertised-writable-dir 准入结局」是一次**新的探测臂**(要读 per-task
 * 的准入结果,而本模块是 boot 期纯函数),按复审停机纪律不在提货批里开;登记在此,免下一位重新发现。
 *
 * 🔴 **不再劝 `additionalDirectories`**(core 7.16.0 [ref] 提货):每个 scope 的家是 `<挂载平面>/<label>`,
 * 平面本身谁的家都不是。交配置根 = 连引擎控制面(`.engine`)一起放行;交平面 = 把每个兄弟 scope 的家
 * (含 org 只读层)一起交给模型;交写家 operator 事前说不出口(label 的真源是引擎注册簿),而 core 的
 * 准入席([ref])本来就自动把写家教给模型。三条路各自要么危险要么多余 ⇒ 整条建议删,只留「挪根」与
 * 「表态 capable=false」两条。
 *
 * ⚠️ 这不是 fail-open 的托词:真正的 fail-closed 归属面在别处(多租户记忆整体 dark、remote lane 默认 dark)。
 * 本模块判的是「已经决定要开记忆」之后的**可达性**,而可达性的证据一半在部署环境里,不在进程里。
 *
 * ── 指路:声明 `false` 之后引擎那边发生什么(core 5.27.0,[ref] F2;[ref] 提货批)────────────────────
 * 本模块两条 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 键)。哪天真要在诊断面露它,先有消费方需求。
 */
/**
 * [ref] A3 源头修(黑板 [ref]/[ref]/[ref],[ref])—— `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` 拒绝、以及 core 准入席自动放行写家
 * ([ref])这套既有处置管,不归 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 declare function effectiveMemoryPersistenceCapable(config: {
    remoteExec?: {
        provider?: string;
    };
    memoryPersistenceCapable?: boolean;
}): boolean | undefined;
/** boot 期可知的全部事实。每一位都必须由调用点从真配置/真装配结果取,禁在本模块内重算(重算=第二真源)。 */
export interface MemoryWriteBoundaryFacts {
    /** 引擎的**挂载平面**根 —— 引擎真正读写条目的那棵树,由 `memoryMountRootOf(backend, root)` 单铸点取
     *  (file 腿 = `<配置根>/memory`,两只 SQL 孪生不钉平面 ⇒ 回到配置根)。`undefined` = 引擎未接 ⇒ 本判据
     *  整体不适用。
     *  🔴 **不是配置根**(2026 提货批订正):配置根比挂载平面高一层,拿它判包含会把「记忆目录在围栏里、
     *  配置根不在」这一真实可行的部署形误报成「结构性写不进」——而那台机器上模型其实存得下。
     *  core 7.16.0([ref])之后写家还要再深一层(`<平面>/<label>`),但 label 归引擎注册簿,boot 期说不出口;
     *  平面是**包含关系上等价**的那一只(家恒为平面的直接子目录),所以判据停在平面,不猜 label。 */
    memoryRoot: string | undefined;
    /** 执行车道名,只进文案(`config.remoteExec?.provider ?? "in-process"`)。 */
    lane: string;
    /** 该车道的文件工具是否跑在**本机** fs 上(in-process / `REMOTE_EXEC=host`)。false = 沙箱盘,与记忆根分平面。
     *  ⚠️ 这一位管的是**文件平面**,与下面的 `coreRemoteExecutionEnv` 是**两根轴**,别合并(codex round2
     *  [medium] 就是把它们当成一根轴的后果):`host` 车道的文件平面就是本机(这一位 true),但 core 眼里它
     *  仍是 remote(那一位也 true)。 */
    hostSemanticsLane: boolean;
    /** core 的 `isRemoteExecutionEnv` 对本部署执行环境的判决 —— 判别位 = `REMOTE_EXEC` 有没有设(**含
     *  `host`**:core 的判别是鸭子类型,`remote-env-host.ts` 把那几件全实现了,亲验坐实)。
     *  5.26.0 的 r13/r14 收窄按的是**这一位**,不是文件平面:凡 core 判 remote,`# Memory` 写指令一律撤,
     *  除非声明 `memoryPersistenceCapable: true`。 */
    coreRemoteExecutionEnv: boolean;
    /** 部署声明 `MEMORY_PERSISTENCE_CAPABLE`(三态)。两极都让本模块闭嘴,但理由不同 —— 见各臂注释。 */
    declaredCapable: boolean | undefined;
    /** 本部署的记忆引擎后端(`config.memoryEngineBackend`)。**只进文案**,不参与任何判决 —— 它在这里的
     *  唯一作用是把「怎么把根挪进围栏」这句话指向**在该腿上真的有效**的那个旋钮:`MEMORY_ENGINE_DIR` 只被
     *  file 腿读(memory-scope 的 `resolveMemoryEngineRoot`),pg/tidb 腿的根是
     *  `<LOCAL_DATA_ROOT|数据根>/memory-work`(boot/stores.ts 两支),那条腿上指 MEMORY_ENGINE_DIR 是让
     *  operator 去拧一个不接线的旋钮 —— 修不好还以为自己修了。 */
    engineBackend: "file" | "pg" | "tidb";
    /** boot 期算得出的文件工具围栏根。空数组 = 算不出(每任务临时目录 / 未配 workspace)⇒ 不判。 */
    containmentRoots: readonly string[];
}
/** 一条启动告警:`tag` 进日志事件名(可被运维按名过滤/告警),`detail` 是给人读的整句(含恢复路径)。 */
export interface MemoryWriteBoundaryWarning {
    tag: "memory_root_outside_write_boundary" | "memory_remote_lane_write_instruction_dropped";
    detail: string;
}
/**
 * 判两件事,互斥(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 declare function buildMemoryWriteBoundaryAudit(facts: MemoryWriteBoundaryFacts): {
    warnings: MemoryWriteBoundaryWarning[];
};
//# sourceMappingURL=memory-boundary.d.ts.map