export declare function isObjectLike(value: unknown): value is object;
export interface RetryErrorSnapshot {
    aborted: boolean;
    code: unknown;
    details: string;
    invalidCode?: boolean;
    invalidStatus?: boolean;
    statusCode?: number;
}
export interface RetryErrorContext {
    cause: unknown;
    causeResponse: unknown;
    response: unknown;
    snapshot: RetryErrorSnapshot;
}
export declare function snapshotRetryErrorContext(error: unknown, detailsMode?: "always" | "for-404", captureCause?: boolean): RetryErrorContext;
export declare function snapshotRetryError(error: unknown, detailsMode?: "always" | "for-404"): RetryErrorSnapshot;
export declare function normalizeRetryError(error: unknown): {
    statusCode?: number;
    message: string;
};
/**
 * Default classifier. Returns `true` to retry (fall through to the next
 * candidate), `false` to stop and surface the error.
 *
 * Decision order, driven by the numeric `statusCode` when one is present:
 *  1. An abort/timeout (the caller's `abortSignal` fired, or a `TimeoutError`)
 *     -> stop. Retrying another candidate with the same aborted signal is
 *     pointless and would swallow the caller's intent.
 *  2. A positively-retryable status (`RETRYABLE_STATUS` or `>= 500`) -> retry.
 *  3. A 4xx client error NOT in the retryable set (e.g. 404/410) -> stop.
 *     These are errors that are unlikely to change across providers. Use a
 *     custom classifier when an application needs stricter 4xx handling.
 *  4. Otherwise -> retry. A generic thrown error with no recognizable status is
 *     treated as a transient/unknown failure. This reproduces the router's
 *     historical "retry on any thrown error" behavior.
 *
 * Note: classification is intentionally status-based. A client error surfaced
 * only as a message string (no `statusCode`) is treated as unknown -> retried.
 * Callers wanting message-based or stricter policies should pass a custom
 * {@link ShouldRetryThisError} (and may call this as a fallback).
 */