/**
 * `instar server start|stop` — Manage the persistent agent server.
 *
 * Start launches the server in a tmux session (background) or foreground.
 * Stop kills the server tmux session.
 *
 * When Telegram is configured, wires up message routing:
 *   topic message → find/spawn session → inject message → session replies via [telegram:N]
 */
import { SessionManager } from '../core/SessionManager.js';
import { TelegramAdapter } from '../messaging/TelegramAdapter.js';
import { TopicMemory } from '../memory/TopicMemory.js';
import { QuotaTracker } from '../monitoring/QuotaTracker.js';
import { UserManager } from '../users/UserManager.js';
/**
 * Pure: should the emergency "fix command" gate intercept this message?
 *
 * Fix commands ("fix auth", "restart sessions", "clean processes", …) are
 * mechanical server-side operations that only make sense in the Agent Attention
 * topic, where the agent posts actionable notifications the user taps to resolve.
 * In ANY other topic, a message that merely starts with "restart" / "fix " /
 * "clean " is ordinary conversation ("restart the build", "fix the login page",
 * "clean up this function") and must route to the session — never be swallowed.
 *
 * The previous logic ran this verb test in every topic and, on a non-attention
 * topic, bounced the message back with "I didn't recognize that command" while
 * also swallowing it (the gate `return`s). That is exactly why a user trying to
 * revive a stuck session by typing "restart sessions" in that session's own
 * topic never reached the session: the gate ate the message and replied with a
 * help list that even advertised "restart sessions" as valid. Scoping the gate
 * to the attention topic closes that hole.
 */
export declare function shouldInterceptFixCommand(text: string, topicId: number, attentionTopicId: number | null | undefined): boolean;
interface StartOptions {
    foreground?: boolean;
    dir?: string;
    /** When false, skip Telegram polling (used when lifeline owns the Telegram connection).
     *  Commander maps --no-telegram to telegram: false. */
    telegram?: boolean;
}
export declare function wireTelegramRouting(telegram: TelegramAdapter, sessionManager: SessionManager, quotaTracker?: QuotaTracker, topicMemory?: TopicMemory, userManager?: UserManager, fixCommandHandler?: (topicId: number, text: string) => Promise<boolean>, getHubDeps?: () => import('../threadline/hubCommands.js').HubBindDeps | null, getTopicOperatorStore?: () => import('../users/TopicOperatorStore.js').TopicOperatorStore | null, getAttentionTopicId?: () => number | null | undefined): void;
export declare function startServer(options: StartOptions): Promise<void>;
export declare function stopServer(options: {
    dir?: string;
}): Promise<void>;
/**
 * Restart the agent server — handles launchd/systemd lifecycle correctly.
 *
 * When autostart (launchd/systemd) is active, simply stopping the server causes
 * the service manager to respawn it with the OLD binary within seconds. This
 * makes it impossible to apply patches. The restart command handles this by:
 *   1. Temporarily disabling the autostart service
 *   2. Stopping the running server
 *   3. Re-enabling autostart (which starts the server with the new binary)
 *
 * Without autostart, falls back to stop + start.
 */
export declare function restartServer(options: {
    dir?: string;
}): Promise<void>;
export {};
//# sourceMappingURL=server.d.ts.map