/**
 * Does the plugin we reached actually implement what we advertise? (#1021)
 *
 * `pluginBuildStale` answers a different question. It compares timestamps: is
 * the compiled bridge older than its source. That catches the common cause of
 * a missing handler and is worth reporting, but it is not evidence about the
 * handlers themselves, and a report against 1.2.4 said so exactly: a session
 * reported `pluginBuildStale: false` while an advertised method was absent,
 * and every discovery of that came one failed call at a time.
 *
 * The evidence has been on the wire the whole time. The handshake carries the
 * registered method list read out of the running binary, which the C++ that
 * builds it describes as the only answer a stale DLL cannot fake. Nothing
 * compared it to the surface, so it was used to word an error AFTER a call had
 * already failed and never to say anything beforehand.
 *
 * This compares them. What comes out is not a guess about why a method is
 * missing, and deliberately so: a plugin behind its source, a plugin from
 * another checkout, a partially deployed one and a handler that failed to
 * register all look identical from here, and naming one of them would be
 * inventing a cause. It reports WHICH advertised methods the running plugin
 * does not have, which is the fact, and leaves the diagnosis to the reader.
 */
import type { BridgeCapabilities } from "./bridge.js";
import type { ToolDef } from "./types.js";
export interface BridgeParity {
    /** False when the plugin published no action list, so nothing was compared. */
    checked: boolean;
    /** Distinct bridge methods the advertised surface can dispatch to. */
    advertised: number;
    /** Methods the running plugin registered. */
    registered: number;
    /**
     * Advertised methods the running plugin does not have, sorted. Every one is
     * a call that will come back "Unknown method".
     */
    missing: string[];
    /** One line for a caller to surface, or null when there is nothing to say. */
    message: string | null;
}
/**
 * Compare the advertised surface against what the connected plugin registered.
 *
 * `graph` is the tool graph this server actually dispatches, so a category the
 * user disabled and a plugin's injected actions are counted as they really
 * are rather than from the pristine declaration.
 */
export declare function checkBridgeParity(graph: ToolDef[], capabilities: BridgeCapabilities | null | undefined): BridgeParity;
/**
 * What the binary that answered says about itself, or undefined when nothing
 * answered or it had nothing to add.
 *
 * `project(get_status)` already reports `pluginBuildStale` and
 * `bridgeApiVersion`, and both are read off the SOURCE and the header on disk.
 * `docs/architecture.md` states that distinction and it is the useful one, so
 * the running binary's own account lives here as one field rather than as
 * three more siblings next to them.
 *
 * Undefined on a healthy connected session, so a status payload only grows
 * when there is something to say.
 */
export declare function deployedPlugin(capabilities: BridgeCapabilities | null | undefined, parity: BridgeParity): {
    builtAt?: string;
    missingActions?: number;
    warning?: string;
} | undefined;
/**
 * The same comparison the other way: methods the plugin has that nothing
 * advertises.
 *
 * Not a defect and not reported by default. A handler can exist under an
 * alternate spelling, or ship ahead of the TypeScript that will expose it, and
 * `scripts/audit-handlers.mjs` is where that question is asked properly with
 * the alternate-spelling table to hand. Here for a caller that wants the whole
 * picture rather than only the half that breaks calls.
 */
export declare function unadvertisedMethods(graph: ToolDef[], capabilities: BridgeCapabilities | null | undefined): string[];