export type NativeDbFailure = "abi-mismatch" | "binding-missing" | "unknown";
/**
 * Classify why the native database addon could not be used.
 *
 * Two failure modes look nothing alike and need different instructions:
 *
 *  - `abi-mismatch`    — the addon exists but was compiled for a different Node
 *                        ABI (an nvm switch, or a Homebrew node shadowing nvm).
 *  - `binding-missing` — the addon was never produced at all. This is what an
 *                        install with lifecycle scripts disabled leaves behind:
 *                        better-sqlite3's `install` script
 *                        (`prebuild-install || node-gyp rebuild`) never ran, so
 *                        there is no `build/` directory to load from.
 */
export declare function classifyNativeDbFailure(message: string): NativeDbFailure;
/** The stderr report shown for a native-database failure. */
export declare function nativeDbFailureReport(kind: NativeDbFailure, message: string): string;
/**
 * Fail fast with a clear, actionable message when the native database module
 * (better-sqlite3) cannot be used under the current Node runtime.
 *
 * IMPORTANT: this must actually *open* a database, not merely `require` the
 * module. better-sqlite3 resolves its binding lazily inside the `Database`
 * constructor, so `require("better-sqlite3")` succeeds even when no compiled
 * addon exists anywhere on disk. A require-only check is a false negative for
 * the most common broken install there is, and lets the raw `bindings` stack
 * trace escape from deep inside gateway boot instead.
 *
 * Call this at every process entry that will load the session database (the CLI
 * dispatcher and the daemon entry), BEFORE anything imports better-sqlite3.
 */
export declare function assertNativeRuntime(): void;
/**
 * Restore the executable bit on node-pty's `spawn-helper`.
 *
 * On macOS/Linux node-pty does not merely load `pty.node`; it `posix_spawn`s a
 * sibling binary called `spawn-helper`. node-pty 1.x ships that helper in its
 * published tarball WITHOUT the executable bit and relies on an install-time
 * script to restore it. Any install that skips lifecycle scripts leaves the
 * helper at mode 0644, and then every pty spawn dies with `posix_spawnp
 * failed.` — a message that names neither the file nor the permission problem,
 * so it reads as if the spawned CLI were missing.
 *
 * `jinn-cli`'s postinstall already fixes this, but postinstall is precisely what
 * such installs skip (Homebrew's `std_npm_args` passes `--ignore-scripts` by
 * default). Repairing at startup is therefore the only layer that holds for an
 * install we never got to run scripts in — including one already on disk, where
 * no packaging change helps retroactively.
 *
 * Best-effort by design: a missing helper or a read-only install is not a reason
 * to refuse to boot, and on a healthy install this is a no-op.
 *
 * @param nodePtyRoot Override for tests. Defaults to the resolved node-pty.
 * @returns paths whose mode this call actually changed.
 */
export declare function repairNodePtySpawnHelper(nodePtyRoot?: string): string[];
//# sourceMappingURL=runtime-guard.d.ts.map