/**
 * chat-daemon ↔ MCP server wire protocol (v0.7.1 Phase B).
 *
 * Shape: JSON-RPC 2.0 over newline-delimited JSON. One JSON object per
 * line; both directions use the same framing. Stateless — the daemon
 * doesn't track client connections beyond the lifetime of a single
 * request/response pair.
 *
 * Transport address (set by `daemonPaths().sockFile`):
 *   - macOS/Linux: ~/.opensquid/chat-daemon.sock (AF_UNIX)
 *   - Windows:     \\.\pipe\opensquid-chat-daemon (named pipe)
 * Node's `net.createServer({path})` accepts both shapes transparently;
 * `daemonSockAddress()` below returns the right form for the host OS.
 *
 * Why not gRPC / HTTP / MCP-style stdio? gRPC drags in a 3 MB grpc-js
 * dependency that we already explicitly avoided in the engine's
 * subprocess design. HTTP needs port allocation + firewall coordination.
 * MCP stdio needs a parent-child relationship — but the daemon is
 * grandparent / orphan to the MCP servers (it outlives them). Local
 * socket + JSON-RPC is the smallest correct surface.
 */
/** Send a chat message via the daemon's owned adapter. */
export interface SendParams {
    channel: string;
    text: string;
    replyTo?: string;
    /** Telegram forum topic id (v0.7.2). Ignored by adapters that don't support threading. */
    threadId?: string;
}
/** v0.7.2 — Create a Telegram forum topic via the daemon's owned bot. */
export interface CreateTopicParams {
    platform: "telegram";
    chat_id: string;
    name: string;
    icon_color?: number;
    icon_custom_emoji_id?: string;
}
export interface CreateTopicResult {
    message_thread_id: number;
    name: string;
}
export interface SendResult {
    ok: boolean;
    platform: string;
    message_id: string;
    delivered_at: string;
}
/** List the platforms the daemon currently has active adapters for. */
export interface ListChannelsParams {
}
export interface ListChannelsResult {
    active_platforms: string[];
    uptime_ms: number | null;
    /**
     * 0.7.4 (#147): platforms whose long-poll lost to a 409 Conflict
     * and degraded to outbound-only mode. Surfaced via
     * `chat_daemon_status` so operators can diagnose "where did my
     * inbound message go?"
     */
    outbound_only_platforms?: string[];
}
/** Liveness probe for the auto-spawn path. */
export interface PingParams {
}
export interface PingResult {
    pong: true;
    pid: number;
    version: string;
}
export type DaemonMethod = "send" | "list_channels" | "ping" | "create_topic";
export interface JsonRpcRequest<P = unknown> {
    jsonrpc: "2.0";
    id: number | string;
    method: DaemonMethod;
    params?: P;
}
export interface JsonRpcSuccess<R = unknown> {
    jsonrpc: "2.0";
    id: number | string;
    result: R;
}
export interface JsonRpcFailure {
    jsonrpc: "2.0";
    id: number | string | null;
    error: {
        code: number;
        message: string;
        data?: unknown;
    };
}
export type JsonRpcResponse<R = unknown> = JsonRpcSuccess<R> | JsonRpcFailure;
export declare const JSON_RPC_PARSE_ERROR = -32700;
export declare const JSON_RPC_INVALID_REQUEST = -32600;
export declare const JSON_RPC_METHOD_NOT_FOUND = -32601;
export declare const JSON_RPC_INVALID_PARAMS = -32602;
export declare const JSON_RPC_INTERNAL_ERROR = -32603;
/**
 * Return the platform-correct socket address for `net.createServer` /
 * `net.connect`. On Unix this is a path on disk; on Windows this is a
 * named-pipe path. Node accepts both behind the same `{path}` API.
 *
 * On Windows we don't actually have a filesystem path to use, so the
 * pidfile name (without the .pid suffix) drives the pipe name to keep
 * dataRoot isolation working across multiple installs.
 */
export declare function daemonSockAddress(dataRoot?: string): string;
//# sourceMappingURL=protocol.d.ts.map