import type { FailureAnalysis } from "@fjall/util/aws";
import { type ResourceEvent, type CloudFormationEventMonitor } from "../../aws/utils/cloudformationEvents.js";
import type { DeploymentContext } from "../../types/deployment/DeploymentTypes.js";
import type { AwsProvider } from "../../aws/AwsProvider.js";
import type { EventLogWriterFactory } from "../../aws/utils/cloudformationEvents.js";
/** Deploy/destroy default — CloudFormation stacks can take up to 30 minutes */
export declare const DEFAULT_DEPLOY_TIMEOUT_MS = 1800000;
/**
 * Total wall-clock budget for one monitored deploy, covering the CDK child AND
 * any re-attach that follows it killing. Both halves draw on this one number,
 * so a deploy cannot quietly take twice what was asked for. The one exception
 * is a re-attach after the CDK child's own timeout while the engine watches
 * for a hung update: it gets `HUNG_UPDATE_REATTACH_BUDGET_MS` of its own, so
 * it can still end an update ECS rolled back (FJL-901).
 *
 * A stack that legitimately outruns 30 minutes — Aurora Global, a CloudFront
 * distribution, an RDS restore — is not a failure, it is a deploy whose budget
 * was set by someone who had not met it. `FJALL_DEPLOY_TIMEOUT_MS` is how the
 * operator says so; the deploy-test harness sets it from each suite's declared
 * `deployMs`. A non-numeric or non-positive value throws rather than falling
 * back, because silently deploying under a budget the operator did not choose
 * is the failure this whole seam exists to stop.
 */
export declare function resolveDeployTimeoutMs(): number;
/**
 * Watch a deploy's stack until it settles, for at most `timeoutMs`: the
 * deploy's own budget, so the events keep flowing to the ECS tail, the
 * runbook and the failure analysis for as long as the CDK child can run.
 */
export declare function startStackMonitoring(monitor: CloudFormationEventMonitor, stackName: string, onResourceProgress?: (event: ResourceEvent) => void, timeoutMs?: number): Promise<{
    success: boolean;
    status?: string;
    failureReason?: string;
    logPath?: string;
}>;
/** Grace budget for the monitor to finish analysing after a failed deploy. */
export declare const MONITORING_ANALYSIS_GRACE_MS = 10000;
/**
 * Await the monitor's failure analysis after a failed CDK exit, bounded by a
 * grace timeout so a hung monitor can never deadlock the deploy result (Q12).
 *
 * Two waits are required: `waitForStackComplete` resolves from its own poll
 * loop the moment the stack reaches a terminal state, while the analysis is
 * computed slightly LATER by the event poll loop (`handleStackCompletion`
 * awaits a DescribeStacks before storing it) — so after the monitoring
 * promise settles, the analysis is polled briefly within the same grace
 * budget. A null `monitoringPromise` means monitoring never started (CDK
 * failed pre-CloudFormation): return immediately, no analysis is coming.
 */
export declare function settleMonitoringAnalysis(monitor: CloudFormationEventMonitor | null, monitoringPromise: Promise<unknown> | null, graceMs?: number): Promise<FailureAnalysis | null>;
export declare class CdkEventMonitor {
    private eventLogWriterFactory?;
    private onFailureAnalysis?;
    constructor(options?: {
        eventLogWriterFactory?: EventLogWriterFactory;
        onFailureAnalysis?: (analysis: FailureAnalysis) => void;
    });
    createEventMonitor(operation: "deploy" | "destroy", stackName: string, region: string, context: DeploymentContext, aws: AwsProvider): Promise<CloudFormationEventMonitor>;
}