/**
 * Mode detection at server boot.
 *
 * log10x-mcp targets two distinct user states:
 *
 *   - **Analysis mode**: a deployed log10x environment exists. The
 *     TSDB resolves (Grafana Cloud, AMP, GCP Managed, Datadog Prom,
 *     self-hosted Prometheus, or 10x Cloud) AND `tenx_pattern_bytes_total`
 *     series are present. The full analysis catalog (top_patterns,
 *     find_*, pattern_mitigate, dependency_check, etc.) is meaningful.
 *
 *   - **POC mode**: no TSDB resolves. The user is a prospect with no
 *     log10x deployment yet. Only POC tools + install advisors make
 *     sense; analysis tools would 5xx on every call.
 *
 *   - **Analysis-pending mode**: TSDB resolves but zero `tenx_*` series
 *     yet. Fresh deploy: nothing has been scraped yet (or the engine
 *     was just installed and hasn't emitted metrics). Register analysis
 *     tools AND install advisors together so the user has the
 *     onboarding affordance alongside the still-empty analysis surface.
 *
 * The mode is **fixed at boot**. If the user later configures a
 * backend, restarting the MCP picks it up. There is no runtime toggle
 * and no CLI flag.
 *
 * Why this lives in its own module (not inline in `src/index.ts`):
 *   - testable in isolation
 *   - reusable by `log10x_doctor` for diagnostic output
 *   - keeps the `main()` boot path readable
 */
import type { CustomerMetricsBackend } from './customer-metrics.js';
export type Mode = 'analysis' | 'analysis_pending' | 'poc';
export interface ModeResolution {
    mode: Mode;
    /** Backend handle, present in analysis + analysis_pending modes only. */
    backend?: CustomerMetricsBackend;
    /** Which detection path matched, when applicable. */
    detectionPath?: string;
    /** Detection-cascade trace for the doctor / debug surface. */
    trace: Array<{
        path: string;
        status: string;
        reason: string;
    }>;
    /** Human-readable one-liner explaining why this mode was chosen. */
    reason: string;
    /** Wall-clock duration of the probe in milliseconds. */
    probeDurationMs: number;
    /**
     * True when no backend/key was configured and the server attached
     * read-only to the public demo dataset instead of falling to POC mode.
     * Mutating tools are denylisted while this is set.
     */
    demoFallback?: boolean;
}
/**
 * PromQL probe asking "are there any live 10x pattern series right now?"
 *
 * MUST name the metric the analysis tools actually read
 * (`all_events_summaryBytes_total`, see promql.ts BYTES_METRIC). The probe
 * previously counted `tenx_pattern_bytes_total`, a series NO engine emits and
 * that appears nowhere else in this codebase or the Grafana dashboards. On a
 * correctly-configured install it always returned zero, so every analysis boot
 * fell to `analysis_pending` ("fresh deploy — patterns appear after 24h") and
 * `log10x_top_patterns` reported no data over a live 194-pattern deployment.
 * Steady-state `analysis` was only ever reached via a probe TIMEOUT, never a
 * successful count. Verified 2026-08-19 against the public demo backend, which
 * exposes all_events_* but not tenx_pattern_bytes_total.
 *
 * `count(...)` over an absent metric is an empty vector, which the probe reads
 * as seriesCount 0 (same as a genuinely fresh deploy), so the two are
 * indistinguishable until the metric name is right.
 */
export declare const TENX_SERIES_PROBE = "count(count by (message_pattern) (all_events_summaryBytes_total))";
/**
 * Detect the operating mode for this MCP boot.
 *
 * The probe budget is bounded (default 5s) so a slow / flaky backend
 * does not block startup. On probe timeout, we optimistically land in
 * `analysis` mode and let individual tool calls surface real-time
 * "backend not reachable" errors with clear remediation. The
 * alternative (falling to POC mode on timeout) would hide a real
 * backend from users with transient network blips.
 */
export declare function detectMode(opts?: {
    probeTimeoutMs?: number;
    /** The backend the ENV LOADER already built (credentials / API key /
     *  demo-license), so mode-detect can probe the same backend the tools will
     *  use instead of only its own `resolveBackend()` cascade. Prevents a
     *  signed-in user whose metrics are SaaS-hosted (no CUSTOMER_METRICS_* env
     *  vars) from being misclassified into POC mode (F3). */
    loadedBackend?: {
        queryInstant(promql: string, timeoutMs?: number): Promise<unknown>;
    };
    /** Skip the loadedBackend probe for a demo env — the keyless path below owns
     *  demo messaging and setup. */
    loadedIsDemo?: boolean;
    /** Nickname of the loaded default env, for the reason string. */
    loadedNickname?: string;
}): Promise<ModeResolution>;
/**
 * Tool-set membership per mode. Source of truth for which tools the
 * MCP registers in each mode. Used by `src/index.ts` boot to gate
 * `registerLog10xTool` calls.
 *
 * "Always" tools register in every mode (auth, doctor, env discovery).
 * "Analysis" tools require a TSDB and meaningful pattern data;
 * skipped in POC mode but kept in analysis_pending.
 * "Install" tools (advisors, configure_*) register in POC mode and
 * analysis_pending mode (fresh deploy). Hidden in steady-state
 * analysis mode where they would be noise.
 * "POC" tools (`log10x_poc_*`) register in POC mode only.
 */
export declare const TOOL_MODES: Record<string, ('analysis' | 'analysis_pending' | 'poc' | 'always')[]>;
/**
 * Should this tool register in the given mode?
 */
export declare function shouldRegisterTool(toolName: string, mode: Mode, opts?: {
    demoFallback?: boolean;
}): boolean;
/** Human-readable mode summary for doctor / log output. */
export declare function formatModeResolution(res: ModeResolution): string;