export declare function loadOncallChatsByApp(botsJsonPath?: string): Map<string, Set<string>>;
export declare function pickBotEntryByName<T extends {
    larkAppId: string;
    botName: string | null;
}>(botEntries: T[], name: string, targetChatId: string | undefined, oncallChatsByApp: Map<string, Set<string>>): T | undefined;
export type BotMentionEntry = {
    larkAppId: string;
    botOpenId?: string | null;
    botName: string | null;
    cliId?: string | null;
};
export type OutgoingMention = {
    open_id: string;
    name?: string;
};
export declare function knownBotOpenIdsFromCrossRef(crossRef: Readonly<Record<string, string>>, entries?: BotMentionEntry[], selfAppId?: string): Set<string>;
export declare function hasKnownBotMention(_text: string, mentions: OutgoingMention[], entries: BotMentionEntry[], crossRef: Record<string, string>, selfAppId?: string): boolean;
/**
 * Blank out Markdown code spans/blocks so a bot name written *inside code* — an
 * example command in backticks, a fenced snippet, a quoted `@Bot` in an
 * explanation — is NOT mistaken for a real `@Bot` handoff by the prose
 * auto-injection scanner (which would otherwise wake that bot). Only presence
 * detection needs to be code-aware; positions are irrelevant, so each matched
 * region collapses to a single space.
 *
 * Fenced blocks (a run of ≥3 backticks or ≥3 tildes, closed by an equal-length
 * run) are removed first so their fences aren't misread as inline runs; then
 * balanced inline backtick runs (`…`, ``…``) go. `~~strike~~` (double tilde) is
 * NOT a fence and is deliberately left intact — an @Bot inside strikethrough is
 * still a real prose mention. Unbalanced stray backticks are harmless literals.
 */
export declare function stripCodeSpans(text: string): string;
/**
 * Decide who a botmux-generated reply should @ in the footer.
 *
 * The footer's `发送给：@owner` is an implicit convenience for human readers —
 * it is NOT the message's explicit @ targets (those come from --mention /
 * --mention-back / prose @Name and are rendered separately). It must not wake a
 * bot: bot-to-bot routing should be explicit in the message body/--mention.
 *
 * When the reply explicitly targets a known bot (a handoff), this default
 * owner-courtesy ping is redundant noise, so it is suppressed entirely
 * (`sendTo: undefined`). To also loop a human in on a handoff, the caller opts
 * in explicitly via --mention-back / --mention <owner>, which land in
 * `mentions[]` and render regardless of this function — i.e. owner-addressing
 * is opt-IN for handoffs, not opt-out. Without an explicit bot target the
 * default addressing (owner / oncall last-caller) is unchanged.
 */
export declare function buildFooterAddressing(s: {
    ownerOpenId?: string;
    lastCallerOpenId?: string;
    lastCallerIsBot?: boolean;
}, opts: {
    isOncall: boolean;
    isSubstitute?: boolean;
    hasExplicitBotMention?: boolean;
    knownBotOpenIds?: Set<string>;
}): {
    sendTo: string | undefined;
    cc: string[];
};
/**
 * Ordered, de-duplicated @ recipients for the footer `发送给：` line.
 *
 * All real mentions (the human addressee + explicit mention targets + cc) are
 * consolidated onto one footer line instead of dangling a trailing @ block at
 * the bottom of the card body. The human addressee (`sendTo`) goes first, then
 * explicit mention targets (which may include sibling bots for a handoff), then
 * cc. Ids already rendered inline inside the body prose (`inlinedIds`) are
 * skipped so the same person isn't @-ed twice.
 *
 * Placement only — these were already real Lark mentions wherever they sat, so
 * notification / cross-bot wake behaviour is unchanged.
 */
export declare function orderedFooterRecipients(opts: {
    sendTo?: string;
    mentionIds?: string[];
    cc?: string[];
    inlinedIds?: Iterable<string>;
}): string[];
//# sourceMappingURL=bot-routing.d.ts.map