/**
 * ADHDev — Windows IDE version detection (execution-free)
 *
 * On Windows the resolved "CLI" for a VS Code fork (Cursor, Antigravity, …)
 * frequently resolves to the GUI Electron executable itself, because the
 * case-insensitive filesystem matches `...\cursor\cursor.exe` against the
 * real `Cursor.exe`. Running `<that exe> --version` boots the GUI instead of
 * printing a version (Electron ignores the unknown flag and opens a window).
 *
 * To learn the version WITHOUT spawning anything, we read the bundled
 * `product.json` / `package.json` that ship next to the executable. VS Code
 * forks embed their version there. This is a pure filesystem read.
 *
 * It also exposes a guard so any remaining `--version` exec path can refuse to
 * spawn a binary that is a known GUI executable for an IDE provider.
 */
/**
 * Read an IDE version from disk (no process spawn).
 *
 * @param exePath Absolute path to the GUI executable (or any path inside the
 *   IDE install dir — we read the manifest relative to its directory).
 * @returns The version string, or null if it could not be determined.
 */
export declare function readWin32IdeVersionFromDisk(exePath: string): string | null;
/**
 * True when `binPath` resolves to a known GUI executable for some IDE.
 *
 * Used as a safety net: any code path about to run `<bin> --version` must skip
 * the spawn when the binary is actually the GUI Electron exe, since that would
 * launch the IDE window. Comparison is case-insensitive on the basename
 * (Windows filesystem semantics) against every provider's `processNames.win32`.
 *
 * @param binPath Resolved binary path that would be exec'd.
 * @param win32ProcessNames Map of provider type → list of GUI exe names
 *   (from provider.json `processNames.win32`, e.g. `["Cursor.exe"]`).
 */
export declare function isKnownWin32GuiExe(binPath: string | null | undefined, win32ProcessNames: Record<string, string[]>): boolean;
