/**
 * 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 function channelDisplayName(channel) {
    if (channel === "weixin")
        return "weixin (remote)";
    return channel;
}
/**
 * Consistent one-line summary for an inbound command message.
 * Used in model-facing wake context, interrupt context, and activity summaries.
 */
export function formatMessageSummary(msg) {
    return `[${channelDisplayName(msg.channel)}] ${msg.sender}: ${msg.text}`;
}
/**
 * Consistent heading for model-facing wake and interrupt context blocks.
 */
export function formatMessageHeading(msg) {
    if (msg.channel === "system" && msg.sender === "realtime") {
        return `[VisionClaw internal] Realtime voice follow-up at ${msg.timestamp}:`;
    }
    return `[${channelDisplayName(msg.channel)}] from ${msg.sender} at ${msg.timestamp}:`;
}
/**
 * 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 function previewMessageText(text, maxLen = 160) {
    const oneLine = text
        .replace(/\s+/g, " ") // collapse all whitespace (incl. newlines) to a single space
        .trim();
    if (oneLine.length <= maxLen)
        return oneLine;
    const truncated = oneLine.slice(0, maxLen).trimEnd();
    return `${truncated}… (+${oneLine.length - maxLen} chars)`;
}
/**
 * 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 function previewIncomingForConsole(msg) {
    if (msg.channel === "gmail") {
        const subjectRaw = msg.meta?.subject;
        const subject = typeof subjectRaw === "string" && subjectRaw.trim()
            ? subjectRaw.trim()
            : "(no subject)";
        return `[Subject: ${previewMessageText(subject, 120)}]`;
    }
    return previewMessageText(msg.text);
}
/**
 * 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 function buildIncomingLogData(msg) {
    if (msg.channel === "gmail")
        return undefined;
    return {
        channel: msg.channel,
        sender: msg.sender,
        text: msg.text,
        id: msg.id,
    };
}
//# sourceMappingURL=message-format.js.map