/**
 * Transient-network failure classification for CDK deploy children
 * (the 2026-07-20 incident fix).
 *
 * A CDK child killed by a network blip (connection reset, DNS failure, TLS
 * handshake death) does NOT stop the CloudFormation operation it already
 * started — CFN keeps executing server-side while the CLI reports a false
 * failure and wedges the deploy slot. The classifier below decides whether a
 * deploy-child failure is worth probing CloudFormation for an in-flight
 * operation (re-attach) or retrying the spawn (bounded backoff).
 *
 * NOTE: cli/src/util/agent/errorCodes.ts carries a sibling NETWORK_ERROR
 * regex serving a DIFFERENT contract (agent error categorisation for exit
 * codes). Deliberately not shared: that regex matches bare /network/i-class
 * wording, which here would false-positive on stack names like
 * "MyAppNetwork". Do not couple the two.
 */
import type { EcsRollbackVerdict } from "../../types/ecsRollbackVerdict.js";
import { type HungUpdateWatch } from "./hungUpdateWatch.js";
/** True when the failure text carries a transient network signature. */
export declare function isTransientNetworkFailure(text: string): boolean;
/**
 * True when the deploy child was killed by our own spawn timeout.
 *
 * Same predicament as a network kill, different cause: the child is dead and
 * the CloudFormation operation it started is not. It therefore warrants the
 * same CFN probe — but NOT the same retry. A transient failure retries
 * because the premise "no operation in flight ⇒ nothing was mutated" makes a
 * re-spawn safe; a timeout carries no such premise. The deploy was running
 * fine and simply outlived its budget, so re-running it buys another timeout.
 *
 * Anchored on the exact string `CdkProcessManager` resolves — a substring of
 * customer stack output cannot forge it.
 */
export declare function isCdkProcessTimeout(text: string): boolean;
/**
 * Why a deploy child died in a way the parent can recover from: the child is
 * gone, and the CloudFormation operation it started may not be.
 */
export type RecoverableChildFailure = "timeout" | "transient-network";
/** What killed the child, as the re-attach messages name it. */
export declare function describeChildDeath(cause: RecoverableChildFailure): string;
/** The line announcing the probe for an operation the dead child left running. */
export declare function childFailureNotice(cause: RecoverableChildFailure, stackName: string): string;
/**
 * True when a stack status names a running operation worth re-attaching to.
 * REVIEW_IN_PROGRESS is excluded: it is a pre-execution changeset
 * placeholder, not a running operation that will reach a terminal state.
 */
export declare function isReattachableInProgressStatus(status: string): boolean;
/** Maximum re-spawns after a transient failure with no in-flight operation. */
export declare const MAX_TRANSIENT_NETWORK_RETRIES = 2;
/**
 * Backoff before retry N+1 (index N). Length MUST equal
 * MAX_TRANSIENT_NETWORK_RETRIES — pinned by transientNetworkRecovery.test.ts.
 */
export declare const TRANSIENT_RETRY_BACKOFF_MS: readonly number[];
/**
 * Waits before each re-read of a stack's status that failed in a way a retry
 * may pass: a throttle, a timeout or a network fault. Once they are spent,
 * the last read is the verdict.
 */
export declare const STATUS_READ_RETRY_BACKOFF_MS: readonly number[];
/**
 * The refusal when a dead child's stack cannot be read. An operation the
 * child started may still be running, so neither a re-attach nor a re-spawn
 * is safe: the re-spawn's premise, that nothing is in flight, was never
 * read. `reason` must be pre-masked; `fetchStackStatusRead` builds it so.
 */
export declare function statusUnreadableAfterChildDeath(cause: RecoverableChildFailure, stackName: string, reason: string): string;
/**
 * The refusal when a zero-exit `cdk deploy`'s stack cannot be read to
 * confirm it converged. `reason` must be pre-masked.
 */
export declare function deploySuccessUnconfirmed(stackName: string, reason: string): string;
/**
 * The failure of a deploy whose CDK child outlived its budget and left no
 * operation to re-attach to. Raising the deploy timeout is advice only when
 * the stack merely ran out of time: not after the engine cancelled a hung
 * update, not when ECS rolled the service deployment back, which more time
 * would not have changed, and not when CloudFormation settled at a rollback.
 */
export declare function timedOutDeployFailure(stackName: string, observed: string | undefined, verdict: EcsRollbackVerdict | undefined, watch: Pick<HungUpdateWatch, "cancelled"> | undefined): string;