/**
 * chat-transport daemon auto-spawn (T-CHAT-AS-TERMINAL CAT.1d).
 *
 * Re-point of the legacy `src.legacy/chat/daemon/autospawn.ts`. The legacy
 * autospawn fired from the legacy MCP server boot (`src.legacy/index.ts`),
 * which is no longer the active server — the live MCP entrypoints are
 * `src/mcp/server.js` + `src/mcp/chat-bridge-server.js` (G.8 wiring). So the
 * NEW chat MCP bridge (`src/mcp/chat-bridge-server.ts`) calls this on boot to
 * opportunistically ensure the NEW chat-transport daemon
 * (`src/channels/daemon/`) is running, so `chat_send` has a socket to dial and
 * inbound Telegram lands in the umbrella inboxes — without the operator having
 * to remember `opensquid chat-daemon start` after every reboot.
 *
 * Behavior (mirrors the legacy contract):
 *   - No-op when no chat platform is configured (`loadChatConfig` → nothing).
 *   - No-op when a daemon is already running.
 *   - Otherwise acquire an atomic spawn-lock (`fs.open(lock, 'wx')`) so two
 *     concurrent MCP servers don't double-spawn; the loser waits briefly for
 *     the winner's pidfile. Stale lock (> 15s) is reclaimed.
 *   - Always async + non-throwing: callers fire-and-forget without try/catch.
 *
 * `startDaemon` (lifecycle.ts) spawns `process.argv[1]` (the running binary,
 * `dist/cli.js`) with the `chat-daemon-worker` token — which `src/cli.ts`
 * short-circuits to `runDaemonWorker()`. The MCP server's `process.argv[1]` is
 * `dist/mcp/chat-bridge-server.js`, NOT `dist/cli.js`, so we override
 * `entrypoint` to the CLI binary (resolved alongside the MCP server in dist/).
 *
 * Imports from: node:fs, node:path, ../config, ../../runtime/paths, ./lifecycle.
 * Imported by: src/mcp/chat-bridge-server.ts (boot) + tests.
 */
import { startDaemon, status } from './lifecycle.js';
export interface AutoSpawnResult {
    status: 'spawned' | 'already_running' | 'waited_for_peer' | 'no_config' | 'error';
    pid?: number;
    error?: string;
}
/**
 * Resolve the CLI binary (`dist/cli.js`) so the spawned worker re-invokes the
 * right entrypoint regardless of which binary is doing the autospawn. From the
 * MCP server at `dist/mcp/chat-bridge-server.js`, the CLI sits at `dist/cli.js`
 * — two dirs up + `cli.js`. Honors `OPENSQUID_CLI_ENTRYPOINT` for tests.
 */
export declare function resolveCliEntrypoint(): string;
/**
 * Injection seams for tests — so a unit test can exercise the autospawn FSM
 * WITHOUT reading the developer's real chat config or spawning a live daemon
 * (the live cutover is the operator's job, never the test suite's).
 */
export interface EnsureChatDaemonDeps {
    /** Override the spawned worker's entrypoint (defaults to `dist/cli.js`). */
    entrypoint?: string;
    /** Override the "is any platform configured" probe. */
    isConfigured?: () => Promise<boolean>;
    /** Override the liveness probe (defaults to `lifecycle.status`). */
    statusFn?: typeof status;
    /** Override the spawn (defaults to `lifecycle.startDaemon`). */
    startFn?: typeof startDaemon;
}
/**
 * Best-effort: ensure the chat-transport daemon is running. Returns on the
 * no-op paths (no config, already running, peer-spawning). Never throws.
 */
export declare function ensureChatDaemonRunning(opts?: EnsureChatDaemonDeps): Promise<AutoSpawnResult>;
//# sourceMappingURL=autospawn.d.ts.map