/**
 * error-handler — single-responsibility catch handler for the
 * top-level `parseAsync().catch(...)` block.
 *
 * Goals:
 *  - One `process.exitCode` write path: route every exit-code change
 *    through the supplied `setExitCode` callback (which `cli-context.ts`
 *    centralises).
 *  - Match on `instanceof` against the typed error hierarchy in
 *    `@opensip-cli/core`; fall back to the data-driven
 *    `getErrorSuggestion` (Layer 2 Phase 1) for unknown shapes.
 *  - The typed-error → exit-code policy lives in contracts'
 *    `mapToolErrorToExitCode` (audit-round-2 Finding C). This handler
 *    keeps only the *CLI-specific* layer: per-class action hints (e.g.
 *    "Run opensip fit --list...") that don't belong in the
 *    headless contracts package.
 *  - Keep the renderer pluggable so unit tests can capture the rendered
 *    `ErrorResult` without touching Ink.
 */
import { type ErrorResult } from '@opensip-cli/contracts';
export interface HandleParseErrorOptions {
    readonly setExitCode: (code: number) => void;
    readonly render: (result: ErrorResult) => Promise<void>;
    /**
     * Whether `--json` was requested (read from argv at the composition root —
     * these errors fire outside a handler, so no parsed opts are available). When
     * true, every error becomes a structured `CommandOutcome` on stdout (the
     * `one-outcome-shape` contract, §5.5); when false, human rendering is
     * byte-identical to launch.
     */
    readonly jsonRequested: boolean;
}
/**
 * The catch handler for `program.parseAsync()`. Maps the thrown error to a
 * `CommandOutcome` (launch, §5.5): `--json` emits the structured outcome
 * on stdout, human mode renders byte-identically to launch. Routes the exit code
 * through `setExitCode`. Never throws.
 */
export declare function handleParseError(error: unknown, opts: HandleParseErrorOptions): Promise<void>;
/**
 * Top-level fatal-error handler for failures BEFORE Commander's parse
 * loop runs (bootstrap registration, dynamic plugin imports, preflight
 * I/O). Sets `process.exitCode` (not `process.exit(N)` — the latter
 * skips the pending stderr flush, and any structured-logging hook on
 * bootstrap failure has nowhere to attach), writes the error line to
 * stderr, and emits a `cli.bootstrap.failed` log event so observability
 * pipelines see the failure. Audit 2026-05-23 G1.
 *
 * Exit code: a typed `ToolError` (e.g. the `PluginIncompatibleError` the
 * Phase-3 fail-closed admission path throws) routes through the canonical
 * `mapToolErrorToExitCode` policy so a fail-closed plugin yields exit 5
 * (`PLUGIN_INCOMPATIBLE`) even when it surfaces from bootstrap rather than
 * Commander's parse loop. Untyped errors keep the historical exit 1.
 *
 * Synchronous because every step here is sync — stderr write,
 * structured-log call, exit-code set. The top-level caller doesn't
 * need to `await` it (Node exits naturally with the configured
 * `process.exitCode` after the event loop drains), but the call site
 * is fine to `await` either way.
 */
export declare function handleFatalBootstrapError(error: unknown, log: {
    error: (entry: Record<string, unknown>) => void;
}): void;
//# sourceMappingURL=error-handler.d.ts.map