import type { CommandMessage } from "../channels/interface.js";
/**
 * Map internal channel identifiers to model-facing display names.
 *
 * The key distinction: `weixin` is a remote command transport from the owner,
 * NOT the desktop WeChat app. Using "weixin (remote)" in model-facing text
 * reduces confusion with the desktop app the agent might see on screen.
 */
export declare function channelDisplayName(channel: string): string;
/**
 * Consistent one-line summary for an inbound command message.
 * Used in model-facing wake context, interrupt context, and activity summaries.
 */
export declare function formatMessageSummary(msg: CommandMessage): string;
/**
 * Consistent heading for model-facing wake and interrupt context blocks.
 */
export declare function formatMessageHeading(msg: CommandMessage): string;
/**
 * Compact, single-line preview of an inbound message's text body, suitable
 * for console logs. Large bodies (e.g. HTML emails) would otherwise flood the
 * terminal with many raw lines. The full text is still preserved in the
 * structured `data` field of the log entry (and therefore in the JSONL log
 * file) for later inspection.
 */
export declare function previewMessageText(text: string, maxLen?: number): string;
/**
 * Build the body portion (after the `[channel] sender:` prefix) of a console
 * log line for an inbound message. Channel-specific rules keep the console
 * readable:
 *   - gmail: only the subject. The HTML body has no human value in the
 *     terminal and would otherwise flood it.
 *   - others: a one-line, length-capped preview of `msg.text`.
 *
 * The full original `msg.text` is still captured in the log entry's `data`
 * field so the JSONL log file remains complete — except for gmail, where the
 * body is typically a large HTML blob with no diagnostic value; for gmail we
 * also keep the `data` minimal to avoid the default logger category appending
 * a 180-char JSON blob to the console line.
 */
export declare function previewIncomingForConsole(msg: CommandMessage): string;
/**
 * Structured `data` payload for an `incoming` log entry.
 *
 * Design rationale:
 *   - gmail: return `undefined` so the logger's default console formatter
 *     won't append a JSON blob. The message line already carries sender +
 *     subject, which is all we want in logs. The full HTML body has no
 *     diagnostic value and would otherwise flood both the terminal and JSONL.
 *   - others: keep the full structured fields so post-hoc analysis (JSONL
 *     log files) remains complete.
 */
export declare function buildIncomingLogData(msg: CommandMessage): Record<string, unknown> | undefined;
//# sourceMappingURL=message-format.d.ts.map