/**
 * [ref] v2-c —— `POST /v1/memory/{export,import}` 两口的**引擎接线**(core 5.40.0 [ref] v2-c)。
 *
 * ## 为什么需要这个模块(而不是在 main.ts 里直接 new)
 *
 * 本仓**没有**一个长命的 `MemoryEngine` 实例:`boot/stores.ts` 装配出来的 `memoryEngine` 是
 * `{ backend, root }` 二元组,真正的引擎由 **core 的 Runner 每任务现构**
 * (`core/runner/prepare-memory.js`),而且构出来的 `memoryDir` 是**按任务的 scope 平面**决定的
 * (personal / project / dual-root 三形,还要看仓根、项目标记、pinned 目录)。
 * 也就是说「这个部署的那一个记忆引擎」这个东西**在本仓不存在** —— HTTP 面若要一个引擎,必须自己构。
 *
 * ## 为什么自己构是安全的:这两个面是 **backend-scoped**,不碰 `memoryDir`
 *
 * 亲读 core 5.40.0 的 `memory-engine/engine.js`(不信 JSDoc,读实现):
 *  · `exportMemoryScopes` 全身只用 `this.backend.exportSnapshotOf` 与 `this.now()`;
 *  · `importMemoryBundle` 全身只用 `this.backend.importBundleCommit`(校验段是纯函数 `memoryBundleInvalid`)。
 * 两条路径**都不读** `memoryDir` / `controlDir` —— 它们是**店级**的单锁复合面(一个 epoch 里把五张
 * 店面围起来),不是「某个任务挂载的那棵树」上的操作。因此本模块传给构造器的 `memoryDir` 只是**构造器
 * 的必填座**,对这两条路径无影响。
 *
 * 🔴 这条判断是承重的,所以它有**机器钉**而不是只有这段注释:`test/memory-bundle-engine.test.ts` 用一只
 * 假 backend 断言两条路径确实落到 `exportSnapshotOf` / `importBundleCommit`,且给一个**不存在的**
 * `memoryDir` 也照样工作。core 哪天让这两条路径去读挂载树,那道钉当场红 —— 而不是在某个部署上静默
 * 读错一棵树。
 *
 * ## 能力缺席在**构造期**判定(不挂一个注定失败的口)
 *
 * backend 没有那两个可选面(本仓两只 SQL 记忆孪生就没有)⇒ 本工厂返回 **undefined**,两口整个不挂载,
 * HTTP 面诚实 501。
 *
 * 🔴 首版把这件事当成**运行期**事实(照常挂载,让 core 每次抛 `memory.export_incomplete` / 422),
 * 被 codex 交叉复审驳倒([ref] 提货批 [medium],验真后修):`typeof backend.exportSnapshotOf === "function"`
 * 是一次**属性检查**,boot 期就判得出;而且它是**永久**缺席(换后端才会变),不是瞬时状态。照旧挂着
 * 就成了「能力位说 yes、每一次调用都确定性失败」——本仓「says yes ⟺ route works」是结构性承诺,
 * 一个恒假的 yes 会让壳给用户开出一条走不通的迁移流程。
 *
 * ⚠️ 两面是**一个**能力,判据取合取:只有一半也不挂。半挂的形是「导得出、导不进」,而这条产品面的
 * 全部意义是那趟往返。
 *
 * ⚠️ 与**运行期**拒不是一回事,别合并:面齐备但店自陈说不清(chain-degraded)时,core 照样抛
 * `memory.export_incomplete` —— 那是诚实的运行期拒,附录 A 单列一条。绝不在这里回落到「用通用读面拼
 * 一个包」:core 明写那正是它拒绝生产的形(a governance-less export is the laundering shape)。
 */
import { type MemoryBackend, type MemoryExportBundle, type MemoryImportReport, type SessionCaptureRecordStore } from "@sema-agent/core";
/** 两口 HTTP 面消费的窄能力面(`ServiceDeps.memoryBundle{Export,Import}` 的实参来源)。 */
export interface MemoryBundleFaces {
    exportScopes: (scopes: readonly string[]) => Promise<MemoryExportBundle>;
    /** 入参 `unknown`:调用方递交的是未校验的对象,整包判决归 core(理由见 ServiceDeps 同名 seam 的注)。 */
    importBundle: (bundle: unknown, opts?: {
        expectedScopes?: readonly string[];
    }) => Promise<MemoryImportReport>;
}
/**
 * 在**已装配的记忆后端**上建 bundle 两面。命名照 CLAUDE.md 工厂律:返回的是带行为的活对象 ⇒ `create*`。
 *
 * `memoryDir` = 引擎的**挂载平面**(`memoryMountRootOf(backend, root)` 单铸点;全仓自构引擎同一条规则,
 * 由 `test/memory-layout-plane.test.ts` 的归一门咬住)。见文件头:这两条路径**不读它**(机器钉在
 * `test/memory-bundle-engine.test.ts`:给一个不存在的 `memoryDir` 也照样工作),传对的那一只是为了
 * 万一 core 日后真用上时,它拿到的是本部署真正的挂载平面,而不是高一层的配置根。
 */
export declare function createMemoryBundleFaces(store: {
    backend: MemoryBackend;
    root: string;
}, opts?: {
    captureRecordStore?: SessionCaptureRecordStore;
}): MemoryBundleFaces | undefined;
//# sourceMappingURL=memory-bundle-engine.d.ts.map