/**
 * Verification run driver shared by `commandmate verify` and `wait --verify`
 * (Issue #1544).
 *
 * The server answers a verify request with 202 and a run id rather than a
 * verdict — gates are whole test suites and builds — so every caller has to
 * start a run, poll it to a terminal status, and translate that status into an
 * exit code. That sequence lives here once so `verify` and `wait` cannot drift
 * apart on what "passed" means.
 *
 * @module cli/utils/verify-runner
 */
import type { VerificationFlakyDetail, VerificationRunStatus, VerificationRunView } from '../types/api-responses';
import { ApiClient } from './api-client';
/** Matches the wait command's cadence; runs are minutes long, not seconds. */
export declare const VERIFY_POLL_INTERVAL_MS = 5000;
/** Built-in gate id; mirrors WORK_EVIDENCE_GATE_ID in lib/verification/gate-runner.ts. */
export declare const WORK_EVIDENCE_GATE_ID = "work-evidence";
/**
 * Marker a mutexed gate writes into its log tail; mirrors MUTEX_LOG_PREFIX in
 * lib/verification/gate-runner.ts (Issue #1771).
 *
 * Mirrored rather than imported because `tsconfig.cli.json` compiles
 * `src/cli/**` alone with no path aliases, so the CLI bundle never pulls in the
 * server's dependency graph. `tests/unit/verification/gate-mutex.test.ts` pins
 * the two together by importing both.
 */
export declare const MUTEX_LOG_PREFIX = "[mutex]";
/**
 * Marker a retried gate writes into its log tail; mirrors FLAKY_LOG_PREFIX in
 * lib/verification/gate-runner.ts (Issue #1772).
 *
 * Mirrored rather than imported for the same reason the mutex prefix is, and
 * pinned to the runner's spelling by `tests/unit/verification/gate-flaky.test.ts`.
 */
export declare const FLAKY_LOG_PREFIX = "[flaky]";
/**
 * Label a gate whose two runs disagreed. Not a `VerificationGateStatus`: the
 * schema has no such status and #1772 added no migration, so FLAKY is a reading
 * of the marker laid over the stored `passed`/`failed` verdict.
 */
export declare const FLAKY_GATE_LABEL = "FLAKY";
/**
 * Read a retried gate's two runs back out of its log tail (Issue #1772).
 *
 * `verification_gate_results` stores one status, one exit code and one duration,
 * so the second run's numbers only exist in the log — the same carrier
 * work-evidence's counts and the scope gate's evidence already use.
 *
 * @returns null when the gate was never retried, which is every gate that did
 *          not declare `retryOnFail: 1` and every one that passed first time.
 */
export declare function parseFlakyMarker(logTail: string | null | undefined): VerificationFlakyDetail | null;
/**
 * Lines of a failing gate's log echoed to stderr before the rest becomes a
 * count (#1683).
 *
 * log_tail is byte-capped only when stored (options.maxLogTailBytes, default
 * 8KB but configurable up to 1MB), so echoing it whole lets one misconfigured
 * gate flood the terminal and scroll the GATE verdict lines out of sight.
 */
export declare const MAX_PRINTED_LOG_TAIL_LINES = 40;
export interface VerificationRequest {
    worktreeId: string;
    /** 'manual' for the verify command, 'wait' when chained after wait. */
    trigger: 'manual' | 'wait';
    instanceId?: string;
    /**
     * Task the run judges. Omitted lets the server resolve the worktree's own
     * task, which is enough while that task is still open — `wait` names one
     * because the agent may close it before the run starts (#1620).
     */
    taskId?: string;
    /** Omitted means work-evidence plus every gate declared in verify.yaml. */
    gateIds?: string[];
    /** Seconds before the CLI stops polling and reports TIMEOUT. */
    timeoutSec?: number;
    /** Stream the final `RESULT <status>` line goes to. Defaults to stdout. */
    resultStream?: 'stdout' | 'stderr';
    /** Suppress the RESULT line because the caller prints JSON on stdout instead. */
    suppressResultLine?: boolean;
}
export interface VerificationOutcome {
    exitCode: number;
    /** Last observed run; on timeout this is still `running`. */
    run?: VerificationRunView;
}
/**
 * Translate a terminal run status into a process exit code.
 *
 * `error` and `cancelled` mean no verdict was reached, so they take the generic
 * UNEXPECTED_ERROR code rather than VERIFY_FAILED — a caller branching on 20
 * must be able to trust that gates actually ran and judged the work.
 */
export declare function exitCodeForRunStatus(status: VerificationRunStatus): number;
/**
 * Parse `--gates a,b` into a gate id list.
 * @returns The ids, or null when the value names no gate at all.
 */
export declare function parseGateIds(value: string | undefined): string[] | null | undefined;
/**
 * Start a verification run and poll it to a verdict.
 *
 * @throws ApiError when the run cannot be started or the server stops answering
 */
export declare function runVerification(client: ApiClient, request: VerificationRequest): Promise<VerificationOutcome>;
//# sourceMappingURL=verify-runner.d.ts.map