import { type ToolError } from '@opensip-tools/core';
export declare const EXIT_CODES: {
    readonly SUCCESS: 0;
    readonly RUNTIME_ERROR: 1;
    readonly CONFIGURATION_ERROR: 2;
    readonly CHECK_NOT_FOUND: 3;
    readonly REPORT_FAILED: 4;
    /**
     * A plugin was rejected by the compatibility gate (release 2.8.0) — its
     * declared `apiVersion` is out of range and it was explicitly requested
     * (fail-closed; the skip path is silent). Dedicated rather than reusing
     * `CONFIGURATION_ERROR` so an incompatible plugin is diagnosable from the
     * exit code alone. Read by the CLI fail-closed admission path (Phase 3).
     */
    readonly PLUGIN_INCOMPATIBLE: 5;
};
/**
 * Canonical mapping from typed `ToolError` subclasses to CLI exit
 * codes. This is the single source of truth for how typed errors flow
 * into the process exit code — both the CLI's top-level
 * `handleParseError` and any tool that chooses to handle its own
 * `ToolError` locally route through this function.
 *
 * The mapping policy (see `Tool` interface JSDoc in
 * `@opensip-tools/core` for the full contract):
 *
 *   - `NotFoundError`       → `CHECK_NOT_FOUND` (exit 3)
 *   - `ConfigurationError`  → `CONFIGURATION_ERROR` (exit 2)
 *   - `ValidationError`     → `CONFIGURATION_ERROR` (exit 2)
 *   - `NetworkError`           → `REPORT_FAILED` (exit 4)
 *   - `PluginIncompatibleError`→ `PLUGIN_INCOMPATIBLE` (exit 5)
 *   - `TimeoutError`           → `RUNTIME_ERROR` (exit 1)
 *   - any other `ToolError`    → `RUNTIME_ERROR` (exit 1)
 */
export declare function mapToolErrorToExitCode(error: ToolError): number;
/** Human-readable diagnosis surfaced when a tool fails, with the exit code it maps to. */
export interface ErrorSuggestion {
    message: string;
    action?: string;
    exitCode: number;
}
/** Matches an arbitrary error against the suggestion-rule table; returns null if no rule fires. */
export declare function getErrorSuggestion(err: unknown): ErrorSuggestion | null;
//# sourceMappingURL=exit-codes.d.ts.map