export declare const WEBVIEW_LOAD_ERROR_INSTRUMENT_KEY = "webview.load_error";
export declare const WEBVIEW_LOAD_RETRY_INSTRUMENT_KEY = "webview.load_retry";
export declare const WEBVIEW_LOAD_SUCCEEDED_INSTRUMENT_KEY = "webview.load_succeeded";
export declare const WEBVIEW_ORIGIN_PROBE_INSTRUMENT_KEY = "webview.origin_probe";
/**
 * Window during which ONE controller instance emits at most one success
 * log. What it actually suppresses is a repeat success within the life of
 * a single controller — a webview process kill or a transport recovery
 * reloading a page that then goes ready again. The first success of a
 * load cycle always emits, so a recovered boot (`retryCount > 0`) is
 * still reported.
 *
 * Scope is deliberately narrower than the `expo-secure-store` backed
 * cooldown it replaced, in two ways that are BOTH accepted trades for
 * dropping the device-storage dependency from the telemetry path:
 *
 * 1. It does not survive an app restart, so a device relaunching the app
 *    several times an hour emits one success log per launch instead of
 *    one per hour.
 * 2. It does not survive controller re-creation, so remounting
 *    `<WebView>` or recreating the client (see mobile-demo's
 *    ReloadWebViewContextProvider) starts a fresh window. Unmounting the
 *    webview is already an unsupported pattern the SDK warns about.
 *
 * Net effect: this is an in-process loop guard, not a fleet-wide volume
 * control. Do not "fix" either point by reintroducing persistence
 * without revisiting that decision.
 */
export declare const SUCCESS_LOG_COOLDOWN_MS: number;