/**
 * 会议角色预设 → per-bot 有效配置的绑定层。
 *
 * 背景：角色预设过去存在每个 bot 自己的
 * `vcMeetingAgent.meetingConsumer.consumerProfiles` 下，并把执行方 `agentAppId`
 * 写死进每条预设。这带来两个用户可见的坏行为：
 *
 *   1. 没配过预设的 bot 被拉进会议时一个角色都选不到；
 *   2. 预设里写死的 `agentAppId` 可能指向**另一个** bot（bootstrap 在当前 bot
 *      结构上不合格时会静默兜底换人），于是「拉 A 进会 → B 被拉进监听群」。
 *
 * 现在的不变量：**没有自己预设的 bot 继承 fleet 共享目录**
 * （`~/.botmux/config.json` 的 `vcMeetingAgent.consumerCatalog`），且共享目录里的
 * 条目从类型上就**没有** `agentAppId`——执行方在这一层绑定为「收到这场会议事件
 * 的那个 bot 自己」，于是「拉错 bot」在共享目录里不可表达。共享目录也没配过时用
 * 内置默认目录，所以任何 bot 被拉进会都直接有角色可跑，不需要先去 Dashboard 配。
 *
 * 操作者显式配置永远优先，共享目录只在该 bot 什么都没配时生效：
 *
 *   - per-bot `consumerProfiles`（显式空数组 = 「这个 bot 不要任何角色」）：原样
 *     沿用，**包括**里面的 `agentAppId`——操作者可以有意把不同角色分给不同 bot
 *     做多 agent 分工，读路径不能替他改主意；
 *   - 老模型的执行方策略（`agentCandidates` 等），那些 bot 继续走候选名单卡。
 *
 * 唯一的例外是**机器播种残留**（v2 带 `defaultProfileBootstrap` 出处标记，v1 按
 * 逐字段精确形状识别）：它不是操作者意图，读路径上直接忽略，让这些 bot 也回到
 * 共享目录——上面第 2 条坏行为正是这么来的（播种把另一个 bot 的 appId 焊进了
 * 预设），忽略掉它就等于在读路径上修好，磁盘残留原样留着，零迁移写盘。
 */
import { type VcMeetingSharedConsumerCatalog } from '../global-config.js';
import type { VcMeetingAgentConfig } from '../bot-registry.js';
/** 测试用：清掉「同一条错误只告警一次」的去重状态。 */
export declare function __resetSharedConsumerCatalogWarnState(): void;
export interface BindVcMeetingConsumerCatalogDeps {
    /**
     * 便于测试注入；默认读全局配置。
     *
     * `undefined` = 「从没配置过」，会落到内置默认目录（与 Dashboard 读到的是同一
     * 个常量）。要表达「所有 bot 都不要角色」请返回 `{ profiles: [], ... }`。
     */
    readCatalog?: () => VcMeetingSharedConsumerCatalog | undefined;
}
/**
 * 把会议角色预设绑定到某个 bot 的有效 VC 配置上。
 *
 * - bot 有操作者写的 `consumerProfiles` / 老模型执行方策略 → 原样返回
 * - bot 只有机器播种残留，或什么都没配 → 继承共享目录，`agentAppId` = `botAppId`
 * - 共享目录显式清空 / 校验不过 → 原样返回（没配过则用内置默认目录）
 *
 * 纯函数，不改入参。
 */
export declare function bindVcMeetingConsumerCatalogToBot(botAppId: string, cfg: VcMeetingAgentConfig, deps?: BindVcMeetingConsumerCatalogDeps): VcMeetingAgentConfig;
//# sourceMappingURL=vc-meeting-shared-consumer-catalog.d.ts.map