import { type S3Client } from "@aws-sdk/client-s3";
import { type CloudTrailClient } from "@aws-sdk/client-cloudtrail";
import { type KMSClient } from "@aws-sdk/client-kms";
import { type Result } from "@fjall/generator";
import type { DeployCallbacks } from "../../types/callbacks.js";
export interface DecommissionClients {
    cloudTrailClient: CloudTrailClient;
    s3Client: S3Client;
    kmsClient: KMSClient;
}
export interface DecommissionInput {
    accountId: string;
    /** Trail name the CFN draining deploy should have deleted. */
    trailName: string;
    bucketName: string;
    /** CMK to schedule for deletion; omitted ⇒ KMS step is skipped. */
    keyArn?: string;
    acknowledgeTrailHistoryLoss: boolean;
    abortSignal?: AbortSignal;
}
export type DecommissionOutcome = {
    outcome: "decommissioned";
} | {
    outcome: "blocked-trail-still-exists";
} | {
    outcome: "blocked-awaiting-acknowledgement";
    bucketName: string;
};
/**
 * Decommission a drained member account's trail storage: empty + delete the
 * retained bucket, then schedule the CMK for deletion. Every step probes
 * first and treats already-gone as success, so the whole function converges
 * on re-run after any partial failure.
 *
 * The trail resource itself is never deleted here — CloudFormation owns it,
 * and a trail still present means the draining deploy has not happened
 * (or rolled back), so nothing is touched.
 *
 * Bucket deletion is SDK-side by design: the bucket is RETAIN in the
 * template, and CloudFormation must never be pointed at a non-empty
 * CloudTrail bucket (delivery continues mid-delete, wedging the stack).
 */
export declare function decommissionMemberTrailStorage(clients: DecommissionClients, input: DecommissionInput, callbacks?: DeployCallbacks): Promise<Result<DecommissionOutcome>>;