/**
 * Daemon auto-spawn from MCP server (v0.7.1 Phase D).
 *
 * On MCP server boot, we want to opportunistically ensure the chat-
 * daemon is running so chat_send routes through the daemon (Phase B)
 * and inbound messages land in per-project inboxes (Phase C). Without
 * auto-spawn the user has to remember `opensquid chat-daemon start`
 * once per machine after every reboot, which defeats the
 * "unconscious tool" goal.
 *
 * Behavior:
 *   - No-op if no chat_connections configured (no point in a daemon
 *     with zero adapters).
 *   - No-op if daemon already running.
 *   - Otherwise try to acquire an atomic spawn lock (fs.open(lock,
 *     'wx') — EEXIST = another MCP server is spawning). If acquired,
 *     spawn and release. If not, wait briefly for the other process's
 *     pidfile to appear.
 *   - Always async fire-and-forget — never blocks MCP server boot.
 *
 * Stale lock handling: a lockfile older than ~15s is assumed stale
 * (longer than the plausible spawn time) and is unlinked before
 * retry. Prevents permanent jam if a previous spawner crashed.
 */
export interface AutoSpawnResult {
    status: "spawned" | "already_running" | "waited_for_peer" | "no_config" | "skipped" | "error";
    pid?: number;
    error?: string;
}
/**
 * Best-effort: ensure a chat-daemon is running. Returns immediately
 * on the no-op paths (no config, already running, peer-spawning).
 * Never throws — callers can fire-and-forget without try/catch.
 */
export declare function ensureDaemonRunning(opts?: {
    dataRoot?: string;
    /** For tests: override the entrypoint passed to startDaemon. */
    entrypoint?: string;
}): Promise<AutoSpawnResult>;
//# sourceMappingURL=autospawn.d.ts.map