/**
 * chat-transport daemon CLI (T-CHAT-AS-TERMINAL CAT.1d).
 *
 * Two entry shapes, mirroring the legacy `src.legacy/chat/daemon/cli.ts` so
 * `lifecycle.startDaemon` (which re-invokes `process.argv[1]` with the
 * `chat-daemon-worker` token) keeps working against the NEW binary (`dist/
 * cli.js`):
 *
 *   `opensquid chat-daemon {start|stop|status|restart}` — user-facing, a
 *       commander sub-group registered on the root program.
 *   `opensquid chat-daemon-worker`                       — internal, never
 *       typed by a user. Handled by an EARLY short-circuit in `src/cli.ts`
 *       (before commander parses) because the worker parks the event loop and
 *       never returns. `runChatDaemonWorkerEntry` is that entrypoint.
 *
 * `start` spawns the worker as a detached child and returns once the child has
 * written its pidfile. The wiring is intentionally thin — all the real
 * lifecycle logic lives in `./lifecycle.ts` + `./worker.ts`.
 *
 * Imports from: commander, ./lifecycle, ./worker.
 * Imported by: src/cli.ts.
 */
import type { Command } from 'commander';
/**
 * Internal worker entrypoint — invoked by the detached child that
 * `lifecycle.startDaemon` spawns. Never returns (parks the event loop); signal
 * handlers inside `runDaemonWorker` drive shutdown. On an unexpected throw it
 * logs + exits non-zero so the parent's pidfile-wait fails fast.
 */
export declare function runChatDaemonWorkerEntry(): Promise<never>;
/**
 * Register `opensquid chat-daemon {start|stop|status|restart}` on the root
 * program. Each verb wraps the matching `./lifecycle` function. `start` /
 * `restart` spawn the detached worker via `chat-daemon-worker`; `status` is
 * read-only; `stop` is idempotent.
 */
export declare function registerChatDaemon(program: Command): Command;
//# sourceMappingURL=cli.d.ts.map