/**
 * log10x_compile_status, poll an async Compiler run started by
 * log10x_compile, and surface what the engine is actually doing.
 *
 * Reads the disk job record, probes liveness (docker container / local pid),
 * scans the output folder for produced units + the linked `.10x.tar`, and
 * parses the engine's `printResults` JSON out of the captured log. The first
 * time it sees a terminal run it captures the exit code into the record and
 * frees the container, so repeat polls stay cheap and idempotent and the
 * compiled library stays readable.
 *
 * The point of this tool is to make the compiler NOT a black box at scale: it
 * promotes the engine's scan-failure aggregates (how many files failed, by
 * language, with capped samples) and the link report (merge/exclude counts +
 * the symbol-type histogram) into the envelope, instead of leaving them
 * buried in a multi-hundred-thousand-line log. Those diagnostics appear once
 * the compiler-10x image carries the engine `scanHealth` / `linkReport`
 * change; on an older image the tool degrades to unit counts + a log tail.
 */
import { z } from 'zod';
import { type StructuredOutput } from '../lib/output-types.js';
export declare const compileStatusSchema: {
    job_id: z.ZodString;
    log_lines: z.ZodDefault<z.ZodNumber>;
    view: z.ZodOptional<z.ZodDefault<z.ZodLiteral<"summary">>>;
};
interface CompileStatusArgs {
    job_id: string;
    log_lines: number;
    view?: 'summary';
}
export declare function executeCompileStatus(args: CompileStatusArgs): Promise<string | StructuredOutput>;
export {};