import { type PlanOptions, type SetupPlan } from "./setup-plan.js";
import type { SetupState } from "./setup-state.js";
/**
 * Whether the package a migration would point `.mcp.json` at can actually be
 * resolved right now.
 *
 * `--migrate` is the one path that rewrites wiring a teammate already has
 * working. Rewriting it toward something that cannot be fetched turns a working
 * configuration into a broken one, and the failure surfaces much later - as a
 * module-not-found from inside the editor's MCP child process.
 */
export type MigrationTarget = {
    spec: string;
    available: boolean;
    /**
     * `not-found` - the registry answered, and this spec is not there. That may
     * mean unpublished, or simply absent from the registry this user is
     * configured against; the check cannot tell those apart and does not claim to.
     * `unverifiable` - no usable answer at all (offline, proxy, timeout, no npm).
     */
    reason?: "not-found" | "unverifiable";
    detail?: string;
};
/** Result shape of a `spawnSync`-style call, narrowed to what the check reads. */
export type RunResult = {
    status: number | null;
    stderr: string;
    error?: NodeJS.ErrnoException;
};
/** Injected by tests so the suite never shells out or reaches a registry. */
export type RunFn = (command: string, args: string[]) => RunResult;
/**
 * Ask npm whether `spec` resolves, using the user's own npm configuration.
 *
 * `npm view` rather than a direct registry request on purpose: it honours the
 * user's `.npmrc`, scoped auth, proxy and custom registry, so a privately
 * published launcher answers correctly instead of looking missing.
 *
 * Fails closed. Everything that cannot be verified - offline, blocked proxy,
 * npm not on PATH, timeout - would also break `npx --yes <spec> serve` at launch
 * time, so "cannot verify" and "would not work" are the same population.
 *
 * The spec is derived from a release constant, never from user input.
 */
export declare function checkMigrationTarget(spec?: string, run?: RunFn): MigrationTarget;
/**
 * Plan, probing the migration target only when a destructive replacement is
 * actually pending.
 *
 * The probe is gated on the *plan*, not on the `--migrate` flag. A flag alone
 * would make setup reach the network in cases that never rewrite anything -
 * no `.mcp.json`, no jam entry, already canonical wiring, or a stop earlier in
 * the plan - which would add a network dependency and an offline timeout for
 * nothing.
 *
 * `computeSetupPlan` is pure, so planning twice costs nothing and keeps the
 * probe out of the planner: the first pass answers "is an unverified
 * replacement pending", the second decides with the fact in hand.
 */
export declare function computeSetupPlanWithPreflight(state: SetupState, options?: PlanOptions, check?: () => MigrationTarget): SetupPlan;