export interface ExtensionLoadResult {
    path: string;
    ok: boolean;
    message?: string;
    /** Non-gating: @danypops/vehicle-client-pi's pi-load-harness checks two
     * further Pi extension load paths (native ESM, jiti tryNative:false)
     * beyond the one path above (jiti tryNative:true) already gates install.
     * Surfaced as observational evidence only, for two independent reasons:
     * (1) native-esm can legitimately fail for a perfectly loadable extension
     * on an older Node without TS type-stripping support, with no real-world
     * signal yet on how often that's a false alarm; (2) this check only
     * verifies the module *imports* cleanly -- unlike the gating check above,
     * it never calls the extension's exported factory, so it cannot catch a
     * factory that throws once actually registered (confirmed directly: the
     * BROKEN test fixture, whose factory always throws, reports ok:true on
     * every one of these paths). Complementary evidence for an import-time
     * failure class, not a broader replacement for the gating check. */
    additionalLoadPaths?: PiLoadPathResult[];
}
export interface PiLoadPathResult {
    path: "native-esm" | "jiti-try-native-false" | "jiti-try-native-true";
    ok: boolean;
    error?: string;
}
export interface InstallValidationResult {
    ok: boolean;
    source: string;
    extensions: ExtensionLoadResult[];
    message?: string;
}
export interface InstallValidator {
    validate(source: string): Promise<InstallValidationResult>;
}
/**
 * Shared with ExecInstaller.install() (the single ad hoc path, which validates then commits
 * itself) and SetupManager.apply() (the batch path, which validates every package change
 * concurrently via Installer.validate() before ever calling installOnly() on any of them) --
 * one formatting rule for "why was this install refused", not two copies that could drift.
 */
export declare function assertInstallValidationOk(validation: InstallValidationResult): void;
/** Strips packed's own "npm:" scheme -- what npm pack itself expects is a
 * bare registry spec (name, name@version) or a local path. Returns
 * undefined for git:/https:/local sources: nothing here to stage from an
 * npm tarball, so headless validation is out of scope for them. */
export declare function bareNpmSpec(source: string): string | undefined;
/** Runs pi-extension-harness's mock-pi-cli against one extension entry
 * point, in its own load-only mode (--tool omitted): a real, isolated
 * subprocess exercising Pi's own production jiti load path. */
export declare function validateExtensionLoadsHeadless(entryPath: string, timeoutMs?: number): Promise<ExtensionLoadResult>;
/** Stages the real npm tarball in isolation and headlessly load-checks
 * every pi.extensions entry it declares. A non-npm source has nothing to
 * stage and passes through as ok. A package with no pi.extensions passes
 * only if it declares some other pi manifest resource (skills/prompts/
 * themes) or has a matching pi convention directory on disk -- otherwise
 * it isn't a Pi package at all (a plain npm dependency like is-number or
 * is-buffer) and is refused rather than silently admitted as a dead
 * `packages` entry pi itself would never load anything from. */
export declare class HeadlessInstallValidator implements InstallValidator {
    private readonly timeoutMs?;
    constructor(timeoutMs?: number | undefined);
    validate(source: string): Promise<InstallValidationResult>;
}
//# sourceMappingURL=install-validation.d.ts.map