/**
 * Native-binding resolver for Electron-runtime mismatches.
 *
 * Why this module exists
 * ----------------------
 * `better-sqlite3` uses raw v8/nan bindings, so its compiled `.node` file is
 * locked to a specific NODE_MODULE_VERSION (Node-API ABI revision). When
 * OpenCode Desktop (Electron 41 → ABI 145) loads a plugin whose `node_modules`
 * was populated by `bun install` / `npm install` under a different runtime,
 * the fetched prebuild is for `node-vNNN` (e.g. ABI 137 for Node 22) and
 * Electron refuses to load it with:
 *
 *   The module '...better_sqlite3.node' was compiled against a different
 *   Node.js version using NODE_MODULE_VERSION 137. This version of Node.js
 *   requires NODE_MODULE_VERSION 145.
 *
 * `onnxruntime-node` (used by `@huggingface/transformers` for local
 * embeddings) is N-API v3 and is ABI-stable across runtimes, so it does NOT
 * have this problem. Only `better-sqlite3` is affected.
 *
 * What this does
 * --------------
 * On plugin load, before constructing any `Database`:
 *
 *  1. If we are NOT running under Electron (`process.versions.electron` is
 *     unset), return null. Bun uses `bun:sqlite` and never reaches this code;
 *     Pi/Node-CLI install matching Node-vNNN prebuilds via npm, which work
 *     natively against the on-disk binary.
 *
 *  2. If we ARE on Electron, locate the `.node` file path that
 *     `better-sqlite3`'s default `bindings()` lookup would try first. Probe
 *     its ABI by attempting a sandboxed `process.dlopen`. If it succeeds
 *     (Electron-compatible), return null — the default lookup will work.
 *
 *  3. Otherwise, look for a cached Electron prebuild at
 *     `<XDG_CACHE_HOME>/cortexkit/native-bindings/better-sqlite3/v<version>/electron-v<abi>-<platform>-<arch>/better_sqlite3.node`.
 *     Download it from the `WiseLibs/better-sqlite3` GitHub release if
 *     missing, extract with `nanotar` (pure-JS, ~45 KB, zero deps), validate
 *     the ABI, and return the absolute path.
 *
 * The caller (`sqlite.ts`) then passes this path through `better-sqlite3`'s
 * documented `nativeBinding` constructor option:
 *
 *   new Database(filename, { nativeBinding: <our cached path> })
 *
 * `better-sqlite3` calls `require()` directly on that path, bypassing the
 * normal `bindings()` lookup chain. This is a first-class API the maintainer
 * added for exactly this kind of cross-runtime extension scenario — see
 * `node_modules/better-sqlite3/lib/database.js` `nativeBinding` handling.
 *
 * Why we don't replace the on-disk binary
 * ---------------------------------------
 * An earlier iteration copied the cached Electron binary over the in-tree
 * `node_modules/.../better_sqlite3.node`. That worked but mutates a shared
 * resource: in monorepo dev setups (or any case where multiple runtimes
 * share one `node_modules`), a Pi process opening the plugin from the same
 * workspace would then load the Electron-ABI binary and fail. Returning a
 * separate cached path keeps the on-disk file untouched so each runtime
 * sees the binary it needs.
 *
 * Failure modes
 * -------------
 * If GitHub is unreachable (corporate firewall, offline laptop, rate limit)
 * AND no cached binary exists, this throws. The caller (sqlite.ts →
 * openDatabase) surfaces a `storage unavailable` error and Magic Context
 * disables itself for the run. The user can connect to the network and
 * restart, or wait for a cached binary from a previous successful launch.
 */
/**
 * Resolve the absolute path to a `better-sqlite3` `.node` binary that the
 * current runtime can load.
 *
 *   - Returns `null` outside Electron (Bun uses `bun:sqlite`; Pi/Node CLI
 *     loads matching prebuilds from `node_modules` natively).
 *   - Returns `null` on Electron when the on-disk binary already matches
 *     the runtime's ABI (rare but possible — a future OpenCode build that
 *     post-install-rebuilds for Electron would hit this fast path).
 *   - Returns the cached/downloaded prebuild path on Electron when the
 *     on-disk binary's ABI doesn't match.
 *
 * The returned path is suitable as the `nativeBinding` option to
 * `new Database(filename, { nativeBinding })`. better-sqlite3 calls `require()`
 * directly on it, bypassing the default `bindings()` lookup chain — this is
 * a documented public API in better-sqlite3, not an internal hack.
 */
export declare function resolveBetterSqliteNativeBinding(): Promise<string | null>;
//# sourceMappingURL=native-binding.d.ts.map