/**
 * [ref] §4.3 —— **收编面**(operator lane):`POST /v1/adoption` 发起、`GET /v1/adoption/:id` 读状态。
 *
 * 形态:一次性的**部署级动作**,不是常驻业务面 —— 所以它 billable=false(零模型工作)、operator-only、
 * 且在没有 SQL 后端的部署上诚实 501(收编重绑的是多租身份轴,local 后端根本没有那个轴)。
 *
 * ── 三条拒的分家(183 §7.3 拒绝可判别)──────────────────────────────────────────────────────────
 *  · `adoption.source_already_bound` (409):同一个源已绑到**别的**目的地 = 二次收编/多租转让,
 *    183 D7 明确拒,非本协议射程。与「已收编回执」不同形 —— 后者是 200。
 *  · `adoption.destination_conflict` (409):目的地侧已有与源侧重叠的逻辑键。**响应列出冲突表族**,
 *    运维据此知道该去清理哪张表;源/目的地两侧字节零变更。
 *  · `adoption.destination_unrepresentable` (409):目的地身份装不进这次收编会**派生**出来的某个键
 *    (典型:memory 的 `proj:` 键 = 新 tenant 段 + 原有项目段后缀,合起来越过列宽)。与上一条分家的理由:
 *    运维的动作完全不同 —— 那条要去清理另一个 principal 的行,这条要换一个更短的目的地身份。
 *  · `not_found.adoption` (404):operator 拿着一个不存在的 id 来读。
 *
 * 幂等:同参数重跑秒回**同一份** `AdoptionReceipt`(`immutableReport` 逐字节恒同 —— 它在 phase 6
 * 一次落库,此后原样回放)。并发同参 POST 由 `adoption_log.from_principal` 的 UNIQUE 仲裁:恰一行落库,
 * 两条连接拿到同一个 adoptionId、同一份回执。
 *
 * 分层:本模块不值 import `server.ts`(那条边闭合运行时装载环),只 `import type`。
 */
import type { IncomingMessage, ServerResponse } from "node:http";
import type { RouteCtx, RouteMatch, RouteIdsOf } from "../route-ctx.js";
export declare function handleAdoption(req: IncomingMessage, res: ServerResponse, match: RouteMatch<AdoptionRouteId>, ctx: RouteCtx): Promise<void>;
export declare const ADOPTION_ROUTES: readonly [{
    readonly id: "adoption-submit";
    readonly path: "/v1/adoption";
    readonly credentialGated: readonly ["POST"];
    readonly methods: readonly ["POST"];
}, {
    readonly id: "adoption-detail";
    readonly pattern: RegExp;
    readonly label: "/v1/adoption/:id";
    readonly methods: readonly ["GET"];
}];
/** 本域可分派行的 `id` 闭集 —— handler 的 `switch` 按它判穷尽(漏一口 = 编译红)。 */
export type AdoptionRouteId = RouteIdsOf<typeof ADOPTION_ROUTES>;
//# sourceMappingURL=adoption.d.ts.map