/**
 * The two wall-clock bounds a deploy runs under, and the job cap derived from them.
 *
 * DEFAULT_MAX_WAIT_SEC bounds the CREATE wait — how long the verb waits for a wallet to reach
 * ACTIVE. Raising it makes a slow backend less likely to report `pending`, at the cost of a job
 * holding its single-flight slot longer.
 *
 * DEFAULT_TICK_WAIT_SEC bounds the OBSERVE wait — how long it waits for one scanner tick, or, for
 * an external scanner, one fresh liveness post. Raising it reduces `installed-unobserved` reports
 * on slow-scheduling scanners; lowering it to 0 skips observation entirely.
 *
 * Both are overridable per call via DeployParams.maxWaitSec / tickWaitSec, and settable through
 * the gateway and the CLI. Change them HERE only: register.ts previously repeated the values as
 * literals inside the job-cap arithmetic, so a change here silently left the cap behind.
 *
 * Three surfaces still QUOTE these numbers in prose rather than deriving them, and a change here
 * has to be carried to all three by hand or they start lying: the `DeployParams` field docs in
 * `orchestrator.ts`, the `--tick-wait` / `--max-wait` option help in `cli/senpi-commands.ts`, and
 * the deploy section of `senpi guide` in `cli/guide-commands.ts`.
 */
export declare const DEFAULT_MAX_WAIT_SEC = 150;
export declare const DEFAULT_TICK_WAIT_SEC = 120;
/**
 * The accepted range for either wait, in seconds — enforced at the gateway, where a caller's number
 * first enters the verb.
 *
 * `0` is in range and meaningful (`--tick-wait 0` skips observation). A NEGATIVE one is not: it
 * yields a cap already in the past, so the watchdog fires before the first step while the journal
 * narrates a deadline the run never had. The ceiling is an hour, twenty-four times the largest
 * default and far past any real backend wait, and it exists because the product below feeds
 * `setTimeout`: `--max-wait 999999999` overflows the 32-bit timer, which Node then clamps to 1ms —
 * an instantly-dead verb from a typo, narrated as a 999999999s deadline. Nothing is money-unsafe
 * either way; the refusal exists because the alternative is a flatly false narration.
 */
export declare const MIN_WAIT_SEC = 0;
export declare const MAX_WAIT_SEC = 3600;
/** Is a caller-supplied wait one this verb will run on? `undefined` = "use the default", so yes. */
export declare function isWaitInRange(value: number | undefined): boolean;
/**
 * Wall-clock cap for the whole job: both waits plus one bounded install, per instance, plus 5
 * minutes of slack.
 *
 * Clamped, and not because the gateway's range check is doubted: this number becomes a `setTimeout`
 * delay AND the figure the watchdog narrates, so the two must agree for every caller. A cap the
 * timer would silently rewrite to 1ms is a deadline the report would then lie about.
 */
export declare function jobCapMs(maxWaitSec: number | undefined, tickWaitSec: number | undefined, instanceCount: number): number;
/**
 * How long a deploy WAITS on one install before it stops waiting.
 *
 * Longer than `MCP_CALL_TIMEOUT_MS` (90s, `job.ts`) on purpose: an install is not one call. It
 * hydrates state from disk, may connect MCP, constructs the runtime and spawns supervised scanner
 * children — a cold box legitimately takes longer than any single tool call.
 *
 * What this bounds and what it does NOT: `installRuntime` is IN-PROCESS work that accepts no
 * signal, so nothing is cancelled here. The wait ends; the install may still land. That is why a
 * timeout is reported as an outcome that is UNKNOWN (`E_INSTALL_INDETERMINATE`) and never unwound
 * — see the D-6 carve-out in `orchestrator.ts` — and why the wallet is fenced for as long as the
 * install is actually in flight, which outlives this deadline (`index.ts` installsInFlight).
 */
export declare const INSTALL_DEADLINE_MS = 120000;
/** The taxonomy code an exceeded install deadline carries, and the orchestrator classifies on. */
export declare const INSTALL_INDETERMINATE_CODE = "E_INSTALL_INDETERMINATE";
/**
 * The taxonomy code the WALLET FENCE refuses with — the bound's other half, which is why it lives
 * beside it rather than in either producer.
 *
 * TWO modules render this code and they must not drift: `index.ts` refuses a direct
 * `senpi.installRuntime` with it, and `deploy/messages.ts` renders the deploy-path detail for the
 * same condition. Both already import {@link INSTALL_DEADLINE_MS} from here — every copy of this
 * message quotes the bound, because "well past ${bound}s means wedged, not slow" is the fact that
 * makes the refusal actionable — so the code that labels them belongs in the same module. A
 * module-private literal in each was one edit away from a taxonomy that answers two different codes
 * for one condition.
 *
 * A SEPARATE code from `E_WALLET_HAS_RUNTIME`: the condition is the same margin account, but the
 * remedy is the opposite. A wallet that HAS a runtime asks the reader to stop or inspect one; a
 * wallet whose install is still running asks them to change nothing and read again shortly. A
 * reader who ran `runtime delete` here would delete a row the in-flight install is about to bind.
 *
 * It is an `E_` code, so the CLI exits 2 and an agent treats it as a decision to obey rather than a
 * transport fault to blind-retry. That is correct, and it is why both messages have to say, in
 * words, that the condition is transient and name the read that resolves it — the exit code alone
 * would otherwise read as permanent.
 */
export declare const WALLET_INSTALL_IN_FLIGHT_CODE = "E_WALLET_INSTALL_IN_FLIGHT";
/**
 * The branded error an exceeded install deadline rejects with.
 *
 * Branded by a `code` PROPERTY rather than by class identity: the orchestrator's classifier runs
 * across a module boundary the deploy suites mock, and `instanceof` is the check that silently
 * answers false there — which would route a timeout back into the rollback this brand exists to
 * suppress. Not sniffed from the message either, for the same reason the taxonomy has one reader:
 * message text is a rendering, not an identity.
 */
export declare function installDeadlineExceeded(deadlineMs: number): Error;
/** Did this error come from {@link withInstallDeadline} giving up on the wait? */
export declare function isInstallDeadlineExceeded(err: unknown): boolean;
/**
 * Bound the WAIT on one install. The work keeps running; only this promise stops caring.
 *
 * The timer is unref'd so a settled deploy never holds the gateway process open, and cleared on
 * either settlement so a fast install leaves nothing pending. A late rejection after the deadline
 * is absorbed by the rejection handler below, so it can never surface as an unhandled rejection.
 */
export declare function withInstallDeadline<T>(work: Promise<T>, deadlineMs?: number): Promise<T>;
//# sourceMappingURL=deadlines.d.ts.map