/**
 * api 域编排：把端点挂上宿主、把帧接进流，卸载时全部收回。端点表是本域对外的**完整承诺**（路径由客户端锁定，
 * 改一处就要两端同改）；它在装配期构造而不是模块级常量——写成常量各端点就得自己去别处找依赖，而症状是测试里换不掉真实现。
 */
import type { ApiDeps } from "../../deps.js";
/** 浏览器出口：路由注册与帧订阅的生命周期。 */
declare class ApiService {
    /** 是否已装配；单例实例重复装配是编程错误，当场暴露。 */
    private installed;
    /** 摘除器：路由与帧订阅混在一起，卸载时逐个调用。 */
    private disposers;
    /**
     * 装配：挂路由、接帧。**中途抛错整单回滚**：建面抛错时一条路由都还没挂，注册第 N 条抛错时前 N-1 条
     *  已挂在宿主上，帧订阅抛错时 8 条路由全都挂在宿主上——各种情况的摘除器都得当场摘干净，
     *  不能随异常一起丢失（见下方两张局部表）。
     *
     *  **这是结构性收口，不是修一处已经发生的线上故障**：装的三步今天都找不到可达抛点（建面的真实
     *  实现只建 Map + setInterval、四个端点构造只存字段），所以下面那段回滚在生产上一条也走不到。
     *  写它是为了「任一步将来开始抛错」时边界已经就位；判据由注入建面端口的那条用例撑着
     *  （`test/unit/api/service.test.ts` 的「建面失败」一条），不靠今天能复现。
     */
    install(deps: ApiDeps): void;
    /** 卸载：摘路由、退订帧、停掉流。**先摘空、逆序、逐项隔离**——一条摘除器抛错就跳出循环的写法，
     *  等于把其余路由与帧订阅永久留在宿主上（实测 8 条只摘 3 条、帧订阅 0 条、连 streamHub.release()
     *  都没跑到），而 `installed` 卡在 true 还会让二次装配撞上「api 域只能装配一次」。
     *  重复调用无害：摘出来的是空表（卸载链可能走到不止一次）。 */
    release(): void;
}
/** 本域唯一的编排实例：类不外放，外面 `new` 不出第二份路由表。 */
export declare const apiService: ApiService;
export {};