/**
 * Shared launch orchestration for the compiler tools, spawn the engine
 * detached, persist the job record, and then EITHER wait inline up to a budget
 * for completion (bounded-synchronous) OR hand back a pollable job id.
 *
 * This is the anti-drop shape: the common case (a small compile, and every
 * re-run, which reuses prior units) finishes inside `maxWaitMs`, so the tool
 * returns the finished library + diagnostics in a single call and there is no
 * second phase for an agent to forget. A genuinely long first compile overruns
 * the budget and returns a running handle, but the run finishes on its own
 * (it is detached) and writes to a PINNED output folder, so the work is never
 * lost: polling log10x_compile_status collects it, and because the output is
 * pinned, simply calling the same tool again later returns the finished library
 * near-instantly.
 *
 * Both log10x_compile and log10x_compile_link funnel through here so they share
 * the same precondition handling, record shape, and wait behaviour.
 */
import { type StructuredOutput } from '../lib/output-types.js';
import { type CompileConfig } from '../lib/compile-runner.js';
import { type CompileJobKind } from '../lib/compile-jobs.js';
export interface LaunchParams {
    cfg: CompileConfig;
    kind: CompileJobKind;
    /** Human description of the sources, for headlines. */
    sources: string;
    runtimeName: string;
    mode: 'auto' | 'docker' | 'local';
    /** Inline wait budget in ms; 0 = return the handle immediately. */
    maxWaitMs: number;
    /** Tool name for envelope attribution. */
    tool: string;
    scopeWindow: string;
    candidatesCount: number;
    /** Tool-specific fields merged into the handle payload (e.g. output_folder). */
    startedPayloadExtra: Record<string, unknown>;
}
export declare function launchCompileJob(p: LaunchParams): Promise<string | StructuredOutput>;