/**
 * Chat-daemon worker entrypoint (v0.7.1 Phase A).
 *
 * Spawned as a detached child by `lifecycle.startDaemon()`. Owns the
 * single long-poll connection per chat platform. The MCP server side
 * stays out of the polling business entirely — outbound RPC (Phase B)
 * and inbox tailing (Phase C) replace the in-process gateway.
 *
 * Lifecycle inside the worker:
 *   1. Write our PID to ~/.opensquid/chat-daemon.pid
 *   2. Build the chat gateway from ~/.opensquid/config.json
 *   3. Start every configured adapter (their long-poll loops run as
 *      side effects of start())
 *   4. Install SIGTERM / SIGINT handlers that stop the gateway and
 *      remove the pidfile before exit
 *   5. Park on process.stdin (which is /dev/null in detached mode)
 *      so the event loop stays alive
 *
 * Crash behavior: any unhandled exception from gateway.start() prints
 * to the (parent-redirected) log file and exits non-zero. The pidfile
 * is cleaned up in the SIGTERM handler — if we crash before installing
 * it, the pidfile may linger, and the next `status` call will report
 * `stale_pid` (lifecycle.startDaemon cleans up stale pidfiles before
 * spawning).
 */
export declare function runDaemonWorker(dataRoot?: string): Promise<never>;
//# sourceMappingURL=worker.d.ts.map