export interface GenerateDriverOptions {
    /** Absolute paths to the run-fallback files this build decided NOT to fold — see `discover()`'s fold/taint loop in `../index.ts`. */
    files: readonly string[];
    /** The build root — threaded to `collectEntities` exactly as `discover()` threads its own `path` argument, so cross-directory stack-prefix disambiguation (chant #932) is computed the same way for this subset. */
    buildRoot: string;
}
/**
 * Generate the driver module's full TypeScript source. Written to a tmp file
 * and bundled (see `./bundle.ts`) before being handed to a sandboxed child —
 * never executed directly by the parent process.
 */
export declare function generateDriverSource(options: GenerateDriverOptions): string;
/**
 * chant #1113 — generate the driver module that evaluates a project's
 * `chant.config.ts` INSIDE the sandboxed child and hands back plain JSON.
 *
 * Same machinery as {@link generateDriverSource} above, deliberately: one
 * literal-specifier dynamic `import()` esbuild can trace and inline, one IPC
 * message back, `./child-errors.ts` for classification so a permission denial
 * names the config file rather than leaking `ERR_ACCESS_DENIED`. The only
 * difference is what crosses — a config is data, not an entity graph, so there
 * is no naming/`AttrRef` step and no `EntitySetWire`; the child instead runs
 * `./config-wire.ts`'s serializability scan and refuses to hand back a config
 * that `JSON.stringify` would silently mangle.
 *
 * The child returns the raw module namespace's chosen export as-is — the
 * `default ?? config ?? namespace` selection and Zod validation
 * (`normalizeConfig`) stay in the parent, where they were, so `--sandbox`
 * changes where the file is *evaluated* and nothing about how its result is
 * interpreted.
 */
export declare function generateConfigDriverSource(configPath: string): string;
/**
 * chant #1131 — generate the driver module that imports a project's
 * `lint.policies` modules INSIDE the sandboxed child, runs their checks over
 * the build result the parent hands it, and sends back plain
 * `PostSynthDiagnostic`s.
 *
 * Same machinery again: literal-specifier dynamic `import()`s esbuild can trace
 * and inline, `./child-errors.ts` for classification so a permission denial
 * names the policy file, one IPC message back. Two things are specific to this
 * one:
 *
 *  - **It receives before it sends.** The run and config drivers are fully
 *    parameterized by their generated source; a policy check needs the finished
 *    build result, which is neither known at bundle time nor something to bake
 *    into a source literal. It arrives as one IPC message (see `./fork.ts`'s
 *    `send`). The `process.on("message", …)` registration is top-level and
 *    synchronous, so it is in place before the event loop can deliver anything
 *    — a message the parent sent before the child finished booting is queued on
 *    the channel, not lost.
 *  - **Checks run wrapped, not raw.** `runPostSynthChecks` (chant's own, from
 *    `../../lint/post-synth.ts`) is invoked ONCE over every check from every
 *    policy module, exactly as `cli/commands/build.ts` invokes it in-process —
 *    so the checks share one `PostSynthContext` and run in one order, and the
 *    diagnostics come back in the same sequence. The wrapper around each check
 *    is what makes a bad return value attributable: it scans that check's own
 *    output and throws a `PolicyWireError` naming the module the check was
 *    loaded from, rather than reporting an offending index in a merged array.
 */
export declare function generatePolicyDriverSource(policyPaths: readonly string[]): string;
//# sourceMappingURL=driver.d.ts.map