/**
 * [ref] 件A([ref] 件3③)——org 记忆准入的装配点:把 org-memory-admission 模块接上 core 5.13.0
 * 的两个 seam(`RunnerDeps.memoryScopeAdmission` / `RunnerDeps.deploymentMemoryScopes`)。
 *
 * 目录源三态(单选,授权面不做双源合并):
 *  · center 在场(configCenter 且非 dryRun)⇒ 远程腿:per-principal caps 响应的 `orgMemory` 段
 *    (走 `fetchPrincipalOrgMemory` —— 与 caps 腿同一条 HTTP 请求形与同一道 principal 回声核,但**只
 *    投影 org 段**读,治理面值漂移不连坐;段键缺席=旧 center 能力握手 ⇒ 目录记 section_absent 瞬时)。
 *    **独立 fetch,不复用 caps 缓存条目**(C3:org 授权段自带判别联合缓存,两张表的失败域互不干扰
 *    ——caps 腿的 deny 缓存/304 复用机制一旦共享,org 面的 gen 拒退与退避语义就会被 caps 语义污染)。
 *    流量记账:每 principal 每 grant TTL(60s)至多多一拍 caps 拉取,有界。
 *  · 无 center 而 `MEMORY_ORG_DIRECTORY_JSON` 在场 ⇒ 单机腿:operator 自证静态表(此处装载=启动期,
 *    坏表 parseOrgDirectoryStatic 直接 throw 拒启动——config 层因 A4 分层不校验,见 config.ts 注)。
 *    两者都在 ⇒ center 胜,env 表忽略 + warn(授权面双源合并=语义地雷,显式拒)。
 *  · 都缺 ⇒ resolver 缺席:core 对 request-origin org scope 铸 `memory.admission_required`(fail-closed),
 *    deployment-origin 走 `deploymentMemoryScopes` 自证通道不受影响(单用户零迁移,v4 §0 伤害①)。
 *
 * 能力探测(C12,fail-loud):多租户(requirePrincipal)部署 **且记忆面真点亮**(MEMORY_ENGINE 开 +
 * backend 非 file——见下方 `memoryPlaneLive` 注)的 projects 登记簿里挂了 org 键 ——这些键在多租户下
 * 按 request-origin 盖章(N2 部署形态维)——而目录源缺席(含 configCenter dryRun 形)⇒ 启动报错:
 * 该部署的每个 projectId 请求都会在 prepare 期被整拒,「audit 在跑但恒拒」不是可运行状态,响亮拒
 * 启动比静默全拒服务诚实(clay 三裁 [ref]:直接 BREAKING,不留兼容臂)。记忆面 dark 的部署里这些
 * 键根本到不了准入门,不在探测范围(复审 D-1)。
 */
import type { RunnerDeps } from "@sema-agent/core";
import type { ServiceConfig } from "../config.js";
import type { Logger } from "../observability/logger.js";
import type { Metrics } from "../observability/metrics.js";
import { type OrgMemoryDirectory } from "../org-memory-admission.js";
export interface OrgMemoryAdmissionWiring {
    memoryScopeAdmission: RunnerDeps["memoryScopeAdmission"];
    /**
     * core 准入 seam 的 deployment-origin **回落表**(boot 期一次值快照)。
     *
     * 🔴 [ref]:这一席**故意**留快照,不跟 `config.projects` 的热应用走,理由是 core 根本不优先吃它:
     * 本仓每个请求都在 `boot/resolve-spec.ts` 现读 `config.projects[...].defaultScopes`(热加的项目当场
     * 进 spec),并在 `memory-scope.ts` 按 `originPolicy.multiTenant` 给每个 `org:` 键**盖章**;core 的
     * `memory-admission` 先看盖章、只有没盖章时才查这张表 ⇒ 单用户部署下热注册项目的 org 键恒被覆盖为
     * `deployment`,这张表陈旧只会让 `governed` / `orgGovernedProvenance` 两个布尔偏保守,**不产生拒绝**。
     * 需要跟着热应用走的是另一个消费点(共享记忆读面)—— 见 {@link deploymentMemoryScopesLive}。
     */
    deploymentMemoryScopes: RunnerDeps["deploymentMemoryScopes"];
    /**
     * 同一份判据的**取值口**([ref] 修):`createSharedMemoryScopeAuthorizer` 的
     * `deploymentScopes` 席用它,每次 `resolve` 现算。
     *
     * 为什么这个消费点必须活取而上面那个可以不:共享记忆读面对 principal-less 请求**直接**把这组 scope
     * 当作全部授权事实交出去(没有第二道盖章腿能纠正它)⇒ 快照在新增方向让新登记的 org 库变成终局式
     * 空集、在撤销方向让已下架的 scope 继续被放行(fail-open),而 `config.projects` 恰恰是 config-center
     * 标注「🟢 热生效」的字段、且 env 腿恒空(只可能由 center 灌)。判据本体与快照同源(同一个
     * `collectDeploymentOrgScopes`),差别只有取值时机。
     */
    deploymentMemoryScopesLive: () => readonly string[];
    /** §7 第二消费者收编:同一个目录实例也喂 memory-policy 面的 `org:` 属主门(`ServiceDeps.orgMemoryDirectory`)。
     *  **同实例**是这条收编的全部意义——「谁属于 org:acme」在一个进程里必须只有一个答案,两面共享同一份
     *  TTL 缓存/退避窗/gen 高水位;各建各的目录会让准入门与策略面在吊销窗内公开分歧。缺席=无目录源
     *  (单用户/无 center 且无 env 表)⇒ 策略面逐字保持收编前的 operator-only 行为。 */
    directory: OrgMemoryDirectory | undefined;
}
/** 依赖收窄到真实消费面(warn/inc 各一手)——接口隔离让测试用真形字面量,零铸形([ref] §1)。 */
export declare function createOrgMemoryAdmissionWiring(opts: {
    config: ServiceConfig;
    logger: Pick<Logger, "warn">;
    metrics: Pick<Metrics, "inc">;
}): OrgMemoryAdmissionWiring;
//# sourceMappingURL=org-memory.d.ts.map