import { type Result } from "@fjall/generator";
import type { DeployCallbacks } from "../../types/callbacks.js";
import type { AwsCredentials } from "../../types/credentials.js";
import type { DestroyResult } from "../../types/params.js";
export interface DirectDestroyParams {
    /** Application name as deployed (stack names derive from it). */
    appName: string;
    /** AWS credentials for the operation. deploy-core never resolves these itself. */
    awsCredentials: AwsCredentials;
    /** Typed callbacks for progress events. CLI and worker implement differently. */
    callbacks: DeployCallbacks;
    abortSignal?: AbortSignal;
    options?: {
        /** Skip the active-deployment guard (matches DestroyOptions.force). */
        force?: boolean;
        /**
         * Per-stack deletion wait budget. Defaults to 60 minutes — Aurora
         * clusters resuming from auto-pause before they delete routinely need
         * far more than the CloudFormationService 10-minute default.
         */
        stackTimeoutMs?: number;
    };
}
/**
 * Destroy an application's stacks directly via the CloudFormation API — no
 * synth, no materialised workspace, no CDK subprocess.
 *
 * CloudFormation deletes a stack using the template it already holds, so the
 * `cdk destroy` lane's validation synth exists only to satisfy the CDK CLI's
 * `--app` requirement. This lane removes that requirement entirely: callers
 * that have no application source in hand (the webapp's dev-substrate destroy
 * worker) probe the full candidate stack set and delete what exists, in the
 * same dependency order the CDK lane uses. It also handles stacks the CDK
 * lane cannot: DeleteStack succeeds on DELETE_FAILED and REVIEW_IN_PROGRESS
 * stacks.
 *
 * Behavioural parity with `destroyApplication` is deliberate, step for step:
 * active-deployment guard → stack-target emission (the reconciler needs the
 * target set persisted before the first DeleteStack) → destroy pre-flight
 * (delete-refusing guards are switched off, or fail closed, before anything
 * is emptied) → per
 * stack: insights log-group capture → pre-empty tagged buckets → DeleteStack
 * → poll to completion with resource events streamed → orphaned-bucket sweep
 * and insights reap. Failure reasons prefer the resource-level event reason
 * over the stack status reason — that is what carries classifiable detail
 * such as Aurora's "is resuming".
 *
 * Every per-stack call runs on the stack's own region: the `UsEast1*` stacks
 * are probed, emptied, deleted and polled through a us-east-1 lane, because
 * a target-region probe of one answers about a stack that does not exist
 * there. Two of the three steps above carry that region with them:
 * `checkActiveDeployments` is handed a `StackProbeTarget` per stack stamped
 * with `stackRegionFor(entry.stackType)`, and `emitStackTargets` resolves
 * each stack through `applicationStackRegionFromName`, so a `UsEast1*` stack
 * that is mid-operation or left by a crashed run is looked up where it
 * actually lives rather than read as absent from the target region. The
 * destroy pre-flight is the step that stays on the target lane, and
 * deliberately: it reads a not-found stack as nothing to probe, and
 * `DELETE_BLOCK_PROBES` covers only RDS, DynamoDB and load-balancer
 * resources, none of which a `UsEast1*` stack holds.
 */
export declare function destroyApplicationDirect(params: DirectDestroyParams): Promise<Result<DestroyResult>>;