/**
 * Hook-timeout windows a harness declares on the entries it installs.
 *
 * Every subprocess harness kills a hook that runs past its window. Session
 * start is the one hook that can legitimately take minutes: it may run the
 * interactive PKCE browser login, which waits on a human. The tool-lifecycle
 * hooks only make permission checks.
 *
 * **The invariant these constants exist to hold** (asserted in
 * `hook-timeout.test.ts`): every declared session-start window is strictly
 * greater than {@link DEFAULT_LOGIN_TIMEOUT_MS}. The login must always
 * terminate on its own terms and record a clean `timeout` outcome the user can
 * act on — never be SIGKILLed mid-flow by the harness, which surfaces nothing
 * and leaves the session with no user identity (and, under `enforce`, every
 * subsequent tool denied for a reason nothing explains).
 *
 * **Units differ per harness and are not guessable** — each was verified
 * against the harness's own binary, because getting one wrong is silent:
 *
 * | Harness      | Unit         | Evidence                                                          |
 * |--------------|--------------|-------------------------------------------------------------------|
 * | claude-code  | seconds      | `timeout: number().describe("Timeout in seconds")`, `timeout * 1000` |
 * | codex        | seconds      | documented per-handler timeout                                     |
 * | cursor       | seconds      | documented per-hook timeout                                        |
 * | gemini-cli   | milliseconds | `DEFAULT_HOOK_TIMEOUT = 6e4`; `Hook timed out after ${timeout}ms`  |
 * | antigravity  | seconds      | `timeout_seconds`; validated `"must be between 5 and 120 seconds"` |
 *
 * Antigravity additionally **validates** its range, so it caps what any harness
 * can be given — which is why the login window has to fit inside 120s.
 */
/**
 * Wall-clock budget for a session-start hook: the interactive login, plus the
 * agent DCR registration and delegation record that follow it.
 *
 * Generous on purpose. It is an upper bound on a hook that is *waiting*, not a
 * latency target — nothing is spinning, and the login gives up on its own well
 * before this.
 */
export declare const SESSION_START_HOOK_WINDOW_MS = 300000;
/**
 * Budget for the tool-lifecycle hooks. A permission check, plus the batched
 * per-word round trips shell decomposition can add.
 */
export declare const TOOL_HOOK_WINDOW_MS = 60000;
/**
 * Hard ceiling on a session-start window, per harness, where the harness
 * validates or silently rejects the value. Antigravity refuses anything over
 * 120 seconds; the others impose no documented maximum.
 */
export declare const HOOK_TIMEOUT_MAX_MS: Readonly<Record<string, number>>;
/** The unit a harness's hook config expresses timeouts in. */
export type HookTimeoutUnit = "seconds" | "milliseconds";
/**
 * The session-start hook timeout to declare for `harness`, in that harness's
 * own unit, clamped to any ceiling the harness enforces.
 *
 * Throws if the clamped result would not outlast the login. That is a build-time
 * failure on purpose: a harness whose maximum window is shorter than the login
 * cannot host the login as it is configured, and shipping it would reintroduce
 * exactly the silent mid-flow kill this module exists to prevent.
 */
export declare function sessionStartHookTimeout(harness: string, unit: HookTimeoutUnit): number;
/** The tool-lifecycle hook timeout to declare for `harness`, in its own unit. */
export declare function toolHookTimeout(harness: string, unit: HookTimeoutUnit): number;