import type { GraphClientConfig } from "../lib/graph-client.js";
import { type MessageInput } from "../lib/message.js";
/**
 * `to` and `subject` are optional here but required in `MessageInput`, because
 * the threaded path REFUSES both — Graph sets them from the message being
 * replied to. The standalone path still requires them, enforced in
 * `createStandaloneDraft` rather than by the type. `MessageInput` stays strict
 * for outlook-mail-send, which has only the one path.
 */
export interface DraftInput extends Omit<MessageInput, "to" | "subject"> {
    to?: string[];
    subject?: string;
    /** The message being replied to. Present: the draft is created as a reply and
     *  lands under that message's conversation. Absent: a standalone new message. */
    replyToMessageId?: string;
    /** Only meaningful with `replyToMessageId`. Selects createReplyAll. */
    replyAll?: boolean;
}
export interface DraftResult {
    draftId: string;
    /** The conversation the draft belongs to, null on the standalone path — a new
     *  message has no parent conversation. Reported so Task 1651's detection rule
     *  ("absence of a conversationId means threading was lost") extends to drafts,
     *  which it could not while this went unrecorded. */
    conversationId: string | null;
    threaded: boolean;
    attachments: string[];
}
/**
 * Create a draft via Graph, attach any files to it, and return an id naming a
 * Drafts-folder message that already carries them and is ready for
 * outlook-draft-send. Never sends.
 *
 * TWO PATHS (Task 1726).
 *
 * Standalone (`replyToMessageId` absent) — `POST /me/messages` with a message
 * resource built from to/subject/body. Graph assigns a fresh conversation, so the
 * draft is attached to nothing. Unchanged.
 *
 * Threaded (`replyToMessageId` present) — `POST /me/messages/{id}/createReply`
 * (or `createReplyAll`), which returns a DRAFT carrying the parent's
 * conversationId, so the reply lands under the original in the operator's mail
 * client. The body is passed as `comment`, which Graph composes above its own
 * quoted original: the same email outlook-mail-reply produces on the send path,
 * so "draft it" and "send it" yield identical output. Graph sets the recipients
 * and the `RE:` subject from the original message.
 *
 * Before 1726 these two capabilities were mutually exclusive — mail-reply
 * threaded but always sent, draft never sent but always detached — so an account
 * instructed "draft, never send" could not answer an email in its own thread.
 *
 * REFUSE, NEVER IGNORE. Three of the standalone path's inputs cannot be honoured
 * once Graph composes the message, and each refuses rather than being silently
 * dropped: `to` and `subject` (Graph sets both from the original) and `isHtml:
 * true` (`comment` is not an HTML surface, so the threaded path is plain text
 * only). Accepting them silently would assert a draft the caller did not get —
 * the same class of silence 1726 exists to close. The refusals land before any
 * Graph write, so a rejected call leaves no orphan draft.
 *
 * Attachment paths validate BEFORE the create on both paths, so a bad path leaves
 * nothing behind. An attach failing Graph-side after the create does leave an
 * orphan; it is operator-visible in the Drafts folder — the same exposure
 * mail-reply carries.
 *
 * The returned id is durable only because the plugin opts into immutable ids
 * (IMMUTABLE_ID_PREFER in graph-client). A regular Outlook id is NOT stable — it
 * rotates when the item is moved or re-saved, including by the operator's own
 * mail client, and the old value then 404s (Task 1688).
 */
export declare function runDraft(config: GraphClientConfig, input: DraftInput): Promise<DraftResult>;
//# sourceMappingURL=draft.d.ts.map