import type { GraphClientConfig } from "./graph-client.js";
/**
 * Recipients cross this plugin's boundary in two directions, and the two shapes
 * are not interchangeable — which is why there are two types here, not one.
 */
/** A recipient as Graph RETURNS it. Every field optional: nothing is guaranteed,
 *  so reads go through `addrs`, which drops entries carrying no address. */
export interface RawRecipient {
    emailAddress?: {
        address?: string;
    };
}
/** A recipient as this plugin CONSTRUCTS it for a Graph write. Complete by
 *  construction, which is why `recip` returns this rather than `RawRecipient`:
 *  it is the honest type, and it is assignable wherever a `RawRecipient` is
 *  expected, so one strict return type serves every call site — including
 *  `GraphMessage`, whose recipient fields require the complete shape. */
export interface Recipient {
    emailAddress: {
        address: string;
    };
}
/** The subset of a Graph draft this plugin reads back after a create. `id` is
 *  optional because Graph's contract does not guarantee it; every caller guards
 *  with `if (!draft?.id) throw` before use and TypeScript narrows from there. */
export interface DraftMsg {
    id?: string;
    conversationId?: string | null;
    toRecipients?: RawRecipient[];
    ccRecipients?: RawRecipient[];
}
/** Graph recipient list to plain addresses. */
export declare function addrs(list: RawRecipient[] | undefined): string[];
/** Plain addresses to a Graph recipient list. Deliberately does NOT sanitise:
 *  the only caller that needs trimming and blank-dropping is `buildMessage`,
 *  which does it first. Adding it here would silently change the cc/bcc paths of
 *  draft, mail-reply and draft-edit. */
export declare function recip(list: string[]): Recipient[];
/**
 * PATCH cc/bcc onto a draft Graph has just created for a reply.
 *
 * Graph's createReply/createReplyAll sets the recipients from the message being
 * replied to; anything extra has to be PATCHed onto the returned draft. The cc
 * merge de-duplicates against the cc Graph already put on the draft, so
 * replyAll plus an explicit cc does not double an address.
 *
 * It does NOT de-duplicate against `toRecipients`: a cc naming someone already
 * on the To line lands in both fields. That is pre-existing behaviour, held
 * deliberately by the extraction that created this module (Task 1729). Whether
 * it is a defect or an explicit-cc-wins decision is open in Task 1745 — this is
 * the one place a change would land.
 *
 * No-ops when neither cc nor bcc is supplied, so callers need no guard.
 */
export declare function applyCcBccToDraft(config: GraphClientConfig, draftId: string, existingCc: RawRecipient[] | undefined, cc: string[], bcc: string[], tool: string): Promise<void>;
//# sourceMappingURL=recipients.d.ts.map