Refactorización del ciclo de vida de los mensajes

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• Las primitivas centrales deben ser recibir y enviar, no responder.
• Una respuesta es solo una relación en un mensaje saliente.
• Un turno es una comodidad de procesamiento entrante, no el propietario de la entrega.
• El envío debe basarse en contexto: begin, renderizar, previsualizar o transmitir, envío final, confirmar, fallar.
• La recepción también debe basarse en contexto: normalizar, desduplicar, enrutar, registrar, despachar, confirmación de plataforma, fallar.
• El SDK público de Plugin debe reducirse a una sola superficie pequeña de mensajes de canal.

​

Problemas

• Los adaptadores entrantes simples usan runtime.channel.turn.run.
• Los adaptadores enriquecidos usan runtime.channel.turn.runPrepared.
• Los ayudantes heredados usan dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, ayudantes de payload de respuesta, fragmentación de respuestas, referencias de respuesta y ayudantes de runtime saliente.
• El streaming de vista previa vive en despachadores específicos de canal.
• La durabilidad de la entrega final se está agregando alrededor de las rutas de payload de respuesta existentes.

Telegram polling update acked
  -> assistant final text exists
  -> process restarts before sendMessage succeeds
  -> final response is lost

​

Objetivos

• Un ciclo de vida central para todas las rutas de recepción y envío de mensajes de canal.
• Envíos finales duraderos de forma predeterminada en el nuevo ciclo de vida de mensajes después de que un adaptador declare un comportamiento seguro para reproducción.
• Semántica compartida de vista previa, edición, streaming, finalización, reintento, recuperación y recibo.
• Una superficie pequeña de SDK de Plugin que los plugins de terceros puedan aprender y mantener.
• Compatibilidad para los llamadores existentes de channel.turn durante la migración.
• Puntos de extensión claros para nuevas capacidades de canal.
• Sin ramas específicas de plataforma en el núcleo.
• Sin mensajes de canal de delta de tokens. El streaming de canal sigue siendo vista previa de mensaje, edición, adición o entrega de bloque completado.
• Metadatos estructurados de origen OpenClaw para salida operativa/de sistema, de modo que las fallas visibles del Gateway no vuelvan a entrar en salas compartidas habilitadas para bots como prompts nuevos.

​

No objetivos

• No eliminar runtime.channel.turn.* en la primera fase.
• No forzar a todos los canales al mismo comportamiento de transporte nativo.
• No enseñar al núcleo temas de Telegram, streams nativos de Slack, redacciones de Matrix, tarjetas de Feishu, voz de QQ ni actividades de Teams.
• No publicar todos los ayudantes internos de migración como API estable del SDK.
• No hacer que los reintentos reproduzcan operaciones de plataforma no idempotentes ya completadas.

​

Modelo de referencia

• Chat
• Thread
• Channel
• Message
• métodos de adaptador como postMessage, editMessage, deleteMessage, stream, startTyping y obtenciones de historial
• un adaptador de estado para desduplicación, bloqueos, colas y persistencia

• Intenciones de envío saliente duraderas antes de llamadas directas de transporte.
• Contextos de envío explícitos con inicio, confirmación y fallo.
• Contextos de recepción que conocen la política de confirmación de plataforma.
• Recibos que sobreviven a reinicios y pueden impulsar ediciones, eliminaciones, recuperación y supresión de duplicados.
• Un SDK público más pequeño. Los plugins incluidos pueden usar ayudantes internos de runtime, pero los plugins de terceros deben ver una API coherente de mensajes.
• Comportamiento específico de agente: sesiones, transcripciones, streaming de bloques, progreso de herramientas, aprobaciones, directivas de medios, respuestas silenciosas e historial de menciones de grupo.

​

Modelo central

core.messages.receive(...)
core.messages.send(...)
core.messages.live(...)
core.messages.state(...)

​

Términos de mensaje

​

Mensaje

type ChannelMessage = {
  id: string;
  channel: string;
  accountId?: string;
  direction: "inbound" | "outbound";
  target: MessageTarget;
  sender?: MessageActor;
  body?: MessageBody;
  attachments?: MessageAttachment[];
  relation?: MessageRelation;
  origin?: MessageOrigin;
  timestamp?: number;
  raw?: unknown;
};

​

Destino

type MessageTarget = {
  kind: "direct" | "group" | "channel" | "thread";
  id: string;
  label?: string;
  spaceId?: string;
  parentId?: string;
  threadId?: string;
  nativeChannelId?: string;
};

​

Relación

type MessageRelation =
  | {
      kind: "reply";
      inboundMessageId?: string;
      replyToId?: string;
      threadId?: string;
      quote?: MessageQuote;
    }
  | {
      kind: "followup";
      sessionKey?: string;
      previousMessageId?: string;
    }
  | {
      kind: "broadcast";
      reason?: string;
    }
  | {
      kind: "system";
      reason:
        | "approval"
        | "task"
        | "hook"
        | "cron"
        | "subagent"
        | "message_tool"
        | "cli"
        | "control_ui"
        | "automation"
        | "error";
    };

​

Origen

type MessageOrigin =
  | {
      source: "openclaw";
      schemaVersion: 1;
      kind: "gateway_failure";
      code: "agent_failed_before_reply" | "missing_api_key" | "model_login_expired";
      echoPolicy: "drop_bot_room_echo";
    }
  | {
      source: "user" | "external_bot" | "platform" | "unknown";
    };

​

Recibo

type MessageReceipt = {
  primaryPlatformMessageId?: string;
  platformMessageIds: string[];
  parts: MessageReceiptPart[];
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  sentAt: number;
  raw?: unknown;
};

type MessageReceiptPart = {
  platformMessageId: string;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  index: number;
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  raw?: unknown;
};

​

Contexto de recepción

type MessageReceiveContext = {
  id: string;
  channel: string;
  accountId?: string;
  input: ChannelMessage;
  ack: ReceiveAckController;
  route: MessageRouteController;
  session: MessageSessionController;
  log: MessageLifecycleLogger;

  dedupe(): Promise<ReceiveDedupeResult>;
  resolve(): Promise<ResolvedInboundMessage>;
  record(resolved: ResolvedInboundMessage): Promise<RecordResult>;
  dispatch(recorded: RecordResult): Promise<DispatchResult>;
  commit(result: DispatchResult): Promise<void>;
  fail(error: unknown): Promise<void>;
};

platform event
  -> begin receive context
  -> normalize
  -> classify
  -> dedupe and self-echo gate
  -> route and authorize
  -> record inbound session metadata
  -> dispatch agent run
  -> durable outbound sends happen through send context
  -> commit receive
  -> ack platform when policy allows

• Confirmación de transporte: le indica al webhook o socket de la plataforma que OpenClaw aceptó el sobre del evento. Algunas plataformas requieren esto antes del despacho.
• Confirmación de offset de sondeo: avanza un cursor para que no se vuelva a obtener el mismo evento. Esto no debe avanzar más allá de trabajo que no puede recuperarse.
• Confirmación de registro entrante: confirma que OpenClaw persistió suficientes metadatos entrantes para desduplicar y enrutar una reentrega.
• Recibo visible para el usuario: comportamiento opcional de lectura/estado/escritura; nunca es un límite de durabilidad.

function shouldDropOpenClawEcho(params: {
  origin?: MessageOrigin;
  isBotAuthor: boolean;
  isRoomish: boolean;
}): boolean {
  return (
    params.isBotAuthor &&
    params.isRoomish &&
    params.origin?.source === "openclaw" &&
    params.origin.kind === "gateway_failure" &&
    params.origin.echoPolicy === "drop_bot_room_echo"
  );
}

type ReceiveAckPolicy =
  | { kind: "immediate"; reason: "webhook-timeout" | "platform-contract" }
  | { kind: "after-record" }
  | { kind: "after-durable-send" }
  | { kind: "manual" };

​

Contexto de envío

type MessageSendContext = {
  id: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  intent: DurableSendIntent;
  attempt: number;
  signal: AbortSignal;
  previousReceipt?: MessageReceipt;
  preview?: LiveMessageState;
  log: MessageLifecycleLogger;

  render(): Promise<RenderedMessageBatch>;
  previewUpdate(rendered: RenderedMessageBatch): Promise<LiveMessageState>;
  send(rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit(receipt: MessageReceipt, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  delete(receipt: MessageReceipt): Promise<void>;
  commit(receipt: MessageReceipt): Promise<void>;
  fail(error: unknown): Promise<void>;
};

await core.messages.withSendContext(message, async (ctx) => {
  const rendered = await ctx.render();

  if (ctx.preview?.canFinalizeInPlace) {
    return await ctx.edit(ctx.preview.receipt, rendered);
  }

  return await ctx.send(rendered);
});

begin durable intent
  -> render
  -> optional preview/edit/stream work
  -> mark sending
  -> final platform send or final edit
  -> mark committing with raw receipt
  -> commit receipt
  -> ack durable intent
  -> fail durable intent on classified failure

type MessageDurabilityPolicy = "required" | "best_effort" | "disabled";

type RenderedMessageBatch = {
  units: RenderedMessageUnit[];
  atomicity: "all_or_retry_remaining" | "best_effort_parts";
  idempotencyKey: string;
};

type RenderedMessageUnit = {
  index: number;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  payload: unknown;
  required: boolean;
};

​

Contexto en vivo

type MessageLiveAdapter = {
  begin?(ctx: MessageSendContext): Promise<LiveMessageState>;
  update?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    update: LiveMessageUpdate,
  ): Promise<LiveMessageState>;
  finalize?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    final: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  cancel?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    reason: LiveCancelReason,
  ): Promise<void>;
};

type LiveMessageState = {
  mode: "partial" | "block" | "progress" | "native";
  receipt?: MessageReceipt;
  visibleSince?: number;
  canFinalizeInPlace: boolean;
  lastRenderedHash?: string;
  staleAfterMs?: number;
};

• Envío de Telegram más edición de vista previa, con final nuevo tras una antigüedad obsoleta de la vista previa.
• Envío de Discord más edición de vista previa, cancelación en medios/error/respuesta explícita.
• Stream nativo de Slack o vista previa de borrador según la forma del hilo.
• Finalización de publicación en borrador de Mattermost.
• Finalización de evento en borrador de Matrix o redacción en caso de discrepancia.
• Stream de progreso nativo de Teams.
• Stream de QQ Bot o reserva acumulada.

​

Superficie del adaptador

import { defineChannelMessageAdapter } from "openclaw/plugin-sdk/channel-message";

type ChannelMessageAdapter = {
  receive?: MessageReceiveAdapter;
  send: MessageSendAdapter;
  live?: MessageLiveAdapter;
  origin?: MessageOriginAdapter;
  render?: MessageRenderAdapter;
  capabilities: MessageCapabilities;
};

type MessageSendAdapter = {
  send(ctx: MessageSendContext, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit?(
    ctx: MessageSendContext,
    receipt: MessageReceipt,
    rendered: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  delete?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  classifyError?(ctx: MessageSendContext, error: unknown): DeliveryFailureKind;
  reconcileUnknownSend?(ctx: MessageSendContext): Promise<MessageReceipt | null>;
  afterSendSuccess?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  afterCommit?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
};

type MessageReceiveAdapter<TRaw = unknown> = {
  normalize(raw: TRaw, ctx: MessageNormalizeContext): Promise<ChannelMessage>;
  classify?(message: ChannelMessage): Promise<MessageEventClass>;
  preflight?(message: ChannelMessage, event: MessageEventClass): Promise<MessagePreflightResult>;
  ackPolicy?(message: ChannelMessage, event: MessageEventClass): ReceiveAckPolicy;
};

type MessageOriginAdapter<TRaw = unknown, TNative = unknown> = {
  encode?(origin: MessageOrigin): TNative | undefined;
  decode?(raw: TRaw): MessageOrigin | undefined;
};

type MessageCapabilities = {
  text: { maxLength?: number; chunking?: boolean };
  attachments?: {
    upload: boolean;
    remoteUrl: boolean;
    voice?: boolean;
  };
  threads?: {
    reply: boolean;
    topic?: boolean;
    nativeThread?: boolean;
  };
  live?: {
    edit: boolean;
    delete: boolean;
    nativeStream?: boolean;
    progress?: boolean;
  };
  delivery?: {
    idempotencyKey?: boolean;
    retryAfter?: boolean;
    receiptRequired?: boolean;
  };
};

​

Reducción del SDK público

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• la mayoría de los usos públicos de outbound-runtime
• helpers ad hoc del ciclo de vida de stream de borrador

​

Relación con el turno de canal

channel.turn.run
  -> messages.receive context
  -> session dispatch
  -> messages.send context for visible output

channel-owned dispatcher
  -> messages.receive record/finalize bridge
  -> messages.live for preview/progress
  -> messages.send for final delivery

​

Guardarraíles de compatibilidad

• channel.turn.run y dispatchAssembledChannelTurn usan la callback de entrega del canal, a menos que ese canal proporcione explícitamente un objeto de política/opciones duraderas auditado.
• channel.turn.runPrepared permanece bajo propiedad del canal hasta que el despachador preparado llama explícitamente al contexto de envío.
• Los helpers públicos de compatibilidad como recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase y los helpers de MD directo nunca inyectan entrega genérica duradera antes de la callback deliver o reply proporcionada por el llamador.

• La entrega final duradera devuelve un estado discriminado. handled_visible y handled_no_send son terminales; unsupported y not_applicable pueden recurrir a la entrega propiedad del canal; failed propaga el fallo de envío.
• La entrega final duradera genérica está condicionada por capacidades del adaptador como la entrega silenciosa, la preservación del destino de respuesta, la preservación de citas nativas y los hooks de envío de mensajes. Si falta paridad, debe elegirse la entrega propiedad del canal, no un envío genérico que cambie el comportamiento visible para el usuario.
• Los envíos duraderos respaldados por cola exponen una referencia de intención de entrega. Los campos de sesión pendingFinalDelivery* existentes pueden transportar el id de la intención durante la transición; el estado final es un almacén MessageSendIntent en lugar de texto de respuesta congelado más campos de contexto ad hoc.

• El adaptador de envío genérico ejecuta el mismo comportamiento de renderizado y transporte que la antigua ruta directa.
• Los efectos secundarios locales posteriores al envío se preservan mediante el contexto de envío.
• El adaptador devuelve recibos o resultados de entrega con todos los ids de mensajes de la plataforma.
• Las rutas de despachador preparadas llaman al nuevo contexto de envío o quedan documentadas como fuera de la garantía duradera.
• La entrega alternativa maneja cada payload proyectado, no solo el primero.
• La entrega alternativa duradera registra todo el array de payload proyectado como una intención o plan de lote reproducible.

• La entrega del monitor de iMessage registra los mensajes enviados en una caché de eco después de un envío correcto. Los envíos finales duraderos aún deben rellenar esa caché; de lo contrario, OpenClaw puede volver a ingerir sus propias respuestas finales como mensajes entrantes de usuario.
• Tlon añade una firma de modelo opcional y registra los hilos participantes después de respuestas de grupo. La entrega duradera genérica no debe omitir esos efectos; muévelos a los adaptadores de renderizado/envío/finalización de Tlon o mantén Tlon en la ruta propiedad del canal.
• Discord y otros despachadores preparados ya son propietarios de la entrega directa y el comportamiento de vista previa. No están cubiertos por una garantía duradera de turno ensamblado hasta que sus despachadores preparados enruten explícitamente los finales a través del contexto de envío.
• La entrega alternativa silenciosa de Telegram debe entregar el array completo de payload proyectado. Un atajo de payload único puede descartar payloads alternativos adicionales después de la proyección.
• LINE, Zalo, Nostr y otras rutas ensambladas/de helper existentes pueden tener manejo de tokens de respuesta, proxy de medios, cachés de mensajes enviados, limpieza de carga/estado u objetivos solo de callback. Permanecen en la entrega propiedad del canal hasta que esas semánticas estén representadas por el adaptador de envío y verificadas mediante pruebas.
• Los helpers de DM directo pueden tener un callback de respuesta que es el único destino de transporte correcto. La salida genérica no debe inferir a partir de OriginatingTo o To y omitir ese callback.
• La salida de fallo del Gateway de OpenClaw debe seguir siendo visible para humanos, pero los ecos de sala etiquetados como escritos por bots deben descartarse antes de la autorización allowBots. Los canales no deben implementar esto con filtros de prefijo de texto visible salvo como medida temporal breve de emergencia; el contrato duradero es metadatos de origen estructurados.

​

Almacenamiento interno

type DurableSendIntent = {
  id: string;
  idempotencyKey: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  batch?: RenderedMessageBatch;
  liveState?: LiveMessageState;
  status:
    | "pending"
    | "sending"
    | "committing"
    | "unknown_after_send"
    | "sent"
    | "failed"
    | "cancelled";
  attempt: number;
  nextAttemptAt?: number;
  receipt?: MessageReceipt;
  partialReceipt?: MessageReceipt;
  failure?: DeliveryFailure;
  createdAt: number;
  updatedAt: number;
};

load pending or sending intents
  -> acquire idempotency lock
  -> skip if receipt already committed
  -> reconstruct send context
  -> render if needed
  -> reconcile unknown_after_send if needed
  -> call adapter send/edit/finalize
  -> commit receipt, mark unknown_after_send, or schedule retry

​

Clases de fallo

type DeliveryFailureKind =
  | "transient"
  | "rate_limit"
  | "auth"
  | "permission"
  | "not_found"
  | "invalid_payload"
  | "conflict"
  | "cancelled"
  | "unknown";

• Reintentar transient y rate_limit.
• No reintentar invalid_payload salvo que exista una alternativa de renderizado.
• No reintentar auth ni permission hasta que cambie la configuración.
• Para not_found, permite que la finalización en vivo recurra de edición a un envío nuevo cuando el canal declare que eso es seguro.
• Para conflict, usa reglas de recibo/idempotencia para decidir si el mensaje ya existe.
• Cualquier error posterior al momento en que el adaptador puede haber completado E/S de plataforma pero anterior al commit del recibo se convierte en unknown_after_send, salvo que el adaptador pueda probar que la operación de plataforma no ocurrió.

​

Mapeo de canales

​

Plan de migración

​

Fase 1: Dominio interno de mensajes

• Añade tipos src/channels/message/* para mensajes, destinos, relaciones, orígenes, recibos, capacidades, intenciones duraderas, contexto de recepción, contexto de envío, contexto en vivo y clases de fallo.
• Añade origin?: MessageOrigin al tipo de carga útil del puente de migración usado por la entrega actual de respuestas; luego mueve ese campo a ChannelMessage y a los tipos de mensajes renderizados a medida que la refactorización reemplace las cargas útiles de respuesta.
• Mantén esto interno hasta que los adaptadores y las pruebas demuestren la forma.
• Añade pruebas unitarias puras para transiciones de estado y serialización.

​

Fase 2: Núcleo de envío duradero

• Mueve la cola saliente existente desde la durabilidad de cargas útiles de respuesta a intenciones duraderas de envío de mensajes.
• Permite que una intención de envío duradera lleve un arreglo de cargas útiles proyectadas o un plan de lote, no solo una carga útil de respuesta.
• Preserva el comportamiento actual de recuperación de cola mediante conversión de compatibilidad.
• Haz que deliverOutboundPayloads llame a messages.send.
• Haz que la durabilidad del envío final sea el valor predeterminado y que falle de forma cerrada cuando la intención duradera no pueda escribirse en el nuevo ciclo de vida de mensajes, después de que el adaptador declare seguridad de reproducción. Las rutas existentes de turno de canal y compatibilidad del SDK permanecen como envío directo de forma predeterminada durante esta fase.
• Registra recibos de forma coherente.
• Devuelve recibos y resultados de entrega al llamador original del dispatcher en lugar de tratar el envío duradero como un efecto secundario terminal.
• Persiste el origen del mensaje mediante intenciones de envío duraderas para que la recuperación, la reproducción y los envíos fragmentados preserven la procedencia operativa de OpenClaw.

​

Fase 3: Puente de turno de canal

• Reimplementa channel.turn.run y dispatchAssembledChannelTurn sobre messages.receive y messages.send.
• Mantén estables los tipos de hechos actuales.
• Mantén el comportamiento heredado de forma predeterminada. Un canal de turno ensamblado se vuelve duradero solo cuando su adaptador opta explícitamente por una política de durabilidad segura para reproducción.
• Mantén durable: false como vía de escape de compatibilidad para rutas que finalizan ediciones nativas y aún no pueden reproducirse con seguridad, pero no dependas de marcadores false para proteger canales no migrados.
• Predetermina la durabilidad del turno ensamblado solo en el nuevo ciclo de vida de mensajes, después de que la asignación del canal demuestre que la ruta de envío genérica preserva la semántica antigua de entrega del canal.

​

Fase 4: Puente de dispatcher preparado

• Reemplace deliverDurableInboundReplyPayload por un puente de contexto de envío.
• Mantenga el helper antiguo como un wrapper.
• Migre primero Telegram, WhatsApp, Slack, Signal, iMessage y Discord porque ya tienen trabajo final duradero o rutas de envío más simples.
• Trate cada despachador preparado como no cubierto hasta que opte explícitamente por el contexto de envío. Las entradas de documentación y changelog deben decir “turnos de canal ensamblados” o nombrar las rutas de canal migradas en lugar de afirmar todas las respuestas finales automáticas.
• Mantenga recordInboundSessionAndDispatchReply, los helpers de DM directo y helpers de compatibilidad públicos similares preservando el comportamiento. Pueden exponer una opción explícita de contexto de envío más adelante, pero no deben intentar automáticamente una entrega duradera genérica antes del callback de entrega propiedad del llamador.

​

Fase 5: Ciclo de vida en vivo unificado

• Construya messages.live con dos adaptadores de prueba:
  • Telegram para envío más edición más envío final obsoleto.
  • Matrix para finalización de borrador más alternativa de redacción.
• Luego migre Discord, Slack, Mattermost, Teams, QQ Bot y Feishu.
• Elimine el código duplicado de finalización de vista previa solo después de que cada canal tenga pruebas de paridad.

​

Fase 6: SDK público

• Agregue openclaw/plugin-sdk/channel-message.
• Documéntelo como la API preferida de plugins de canal.
• Actualice las exportaciones de paquetes, el inventario de puntos de entrada, las bases de API generadas y la documentación del SDK de plugins.
• Incluya MessageOrigin, hooks de codificación/decodificación de origen y el predicado compartido shouldDropOpenClawEcho en la superficie del SDK de channel-message.
• Mantenga wrappers de compatibilidad para subrutas antiguas.
• Marque los helpers del SDK con nombres de respuesta como obsoletos en la documentación después de que los plugins incluidos se hayan migrado.

​

Fase 7: Todos los emisores

• notificaciones de Cron y Heartbeat
• finalizaciones de tareas
• resultados de hooks
• solicitudes de aprobación y resultados de aprobación
• envíos de la herramienta de mensajes
• anuncios de finalización de subagentes
• envíos explícitos de CLI o interfaz de control
• rutas de automatización/difusión

​

Fase 8: Desaprobar Turn

• Mantenga channel.turn como wrapper durante al menos una ventana de compatibilidad.
• Publique notas de migración.
• Ejecute pruebas de compatibilidad del SDK de plugins contra importaciones antiguas.
• Elimine u oculte helpers internos antiguos solo después de que ningún plugin incluido los necesite y los contratos de terceros tengan un reemplazo estable.

​

Plan de pruebas

• Serialización y recuperación de intención de envío duradero.
• Reutilización de claves de idempotencia y supresión de duplicados.
• Confirmación de recibo y omisión en reproducción.
• Recuperación de unknown_after_send que reconcilia antes de reproducir cuando un adaptador admite reconciliación.
• Política de clasificación de fallos.
• Secuenciación de la política de confirmación de recepción.
• Mapeo de relaciones para envíos de respuesta, seguimiento, sistema y difusión.
• Fábrica de origen de fallo de Gateway y predicado shouldDropOpenClawEcho.
• Preservación del origen mediante normalización de payload, fragmentación, serialización de cola duradera y recuperación.

• El adaptador simple de channel.turn.run todavía registra y envía.
• La entrega heredada de turnos ensamblados no se vuelve duradera a menos que el canal opte explícitamente por ello.
• El puente channel.turn.runPrepared todavía registra y finaliza.
• Los helpers públicos de compatibilidad llaman por defecto a callbacks de entrega propiedad del llamador y no realizan un envío genérico antes de esos callbacks.
• La entrega de alternativa duradera reproduce todo el arreglo de payloads proyectado después de reiniciar y no puede dejar los payloads posteriores sin registrar tras un fallo temprano.
• La entrega duradera de turnos ensamblados devuelve ids de mensajes de plataforma al despachador almacenado en búfer.
• Los hooks de entrega personalizados todavía devuelven ids de mensajes de plataforma cuando la entrega duradera está deshabilitada o no disponible.
• La respuesta final sobrevive a un reinicio entre la finalización del asistente y el envío a la plataforma.
• El borrador de vista previa se finaliza en el mismo lugar cuando está permitido.
• El borrador de vista previa se cancela o redacta cuando una discrepancia de media/error/destino de respuesta requiere entrega normal.
• La transmisión de bloques y la transmisión de vista previa no entregan ambas el mismo texto.
• Los medios transmitidos temprano no se duplican en la entrega final.

• Respuesta a tema de Telegram con confirmación por sondeo retrasada hasta la marca de agua segura completada del contexto de recepción.
• Recuperación de sondeo de Telegram para actualizaciones aceptadas pero no entregadas cubierta por el modelo persistido de desplazamiento seguro completado.
• La vista previa obsoleta de Telegram envía un final nuevo y limpia la vista previa.
• La alternativa silenciosa de Telegram envía cada payload alternativo proyectado.
• La durabilidad de la alternativa silenciosa de Telegram registra atómicamente todo el arreglo alternativo proyectado, no una intención duradera de un solo payload por iteración del bucle.
• Cancelación de vista previa de Discord por media/error/respuesta explícita.
• Las finales de despachadores preparados de Discord se enrutan por el contexto de envío antes de que la documentación o el changelog afirmen durabilidad de respuesta final de Discord.
• Los envíos finales duraderos de iMessage rellenan la caché de eco de mensajes enviados del monitor.
• Las rutas de entrega heredadas de LINE, Zalo y Nostr no se omiten mediante envío duradero genérico hasta que existan sus pruebas de paridad de adaptador.
• La entrega por callback de DM directo/Nostr sigue siendo autoritativa a menos que se migre explícitamente a un destino de mensaje completo y un adaptador de envío seguro para reproducción.
• Los mensajes etiquetados de fallo de Gateway de OpenClaw en Slack permanecen visibles salientes, los ecos de sala de bot etiquetados se descartan antes de allowBots, y los mensajes de bot sin etiquetar con el mismo texto visible siguen la autorización normal de bots.
• Alternativa de stream nativo de Slack a vista previa de borrador en DM de nivel superior.
• Finalización de vista previa y alternativa de redacción de Matrix.
• Los ecos de sala de fallo de Gateway de OpenClaw etiquetados de Matrix desde cuentas de bot configuradas se descartan antes del manejo de allowBots.
• Las auditorías de cascada de fallo de Gateway en salas compartidas de Discord y Google Chat cubren modos de allowBots antes de afirmar protección genérica allí.
• Finalización de borrador y alternativa de envío nuevo de Mattermost.
• Finalización de progreso nativo de Teams.
• Supresión de final duplicado de Feishu.
• Alternativa por timeout del acumulador de QQ Bot.
• Los envíos finales duraderos de Tlon preservan el renderizado de firma de modelo y el seguimiento de hilos participados.
• Envíos finales duraderos simples de WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo y Zalo Personal.

• Archivos de Vitest dirigidos durante el desarrollo.
• pnpm check:changed en Testbox para toda la superficie modificada.
• pnpm check más amplio en Testbox antes de aterrizar la refactorización completa o después de cambios en SDK público/exportaciones.
• Smoke en vivo o qa-channel para al menos un canal con capacidad de edición y un canal simple de solo envío antes de eliminar wrappers de compatibilidad.

​

Preguntas abiertas

• Si Telegram debería eventualmente reemplazar la fuente del runner de grammY por una fuente de sondeo completamente duradera que pueda controlar la reentrega a nivel de plataforma, no solo la marca de agua de reinicio persistida de OpenClaw.
• Si el estado de vista previa en vivo duradero debería almacenarse en el mismo registro de cola que la intención de envío final o en un almacén hermano de estado en vivo.
• Durante cuánto tiempo los wrappers de compatibilidad siguen documentados después de que plugin-sdk/channel-message se publique.
• Si los plugins de terceros deberían implementar adaptadores de recepción directamente o solo proporcionar hooks de normalización/envío/en vivo mediante defineChannelMessageAdapter.
• Qué campos de recibo es seguro exponer en el SDK público frente al estado interno de runtime.
• Si los efectos secundarios como cachés de autoeco y marcadores de hilos participados deberían modelarse como hooks de contexto de envío, pasos de finalización propiedad del adaptador o suscriptores de recibos.
• Qué canales tienen metadatos de origen nativos, cuáles necesitan registros salientes persistidos y cuáles no pueden ofrecer supresión fiable de eco entre bots.

​

Criterios de aceptación

• Cada canal de mensajes incluido envía la salida visible final mediante messages.send.
• Cada canal de mensajes entrantes entra mediante messages.receive o un wrapper de compatibilidad documentado.
• Cada canal de vista previa/edición/stream usa messages.live para estado de borrador y finalización.
• channel.turn es solo un wrapper.
• Los helpers del SDK con nombres de respuesta son exportaciones de compatibilidad, no la ruta recomendada.
• La recuperación duradera puede reproducir envíos finales pendientes después de reiniciar sin perder la respuesta final ni duplicar envíos ya confirmados; los envíos cuyo resultado de plataforma es desconocido se reconcilian antes de reproducir o se documentan como al menos una vez para ese adaptador.
• Los envíos finales duraderos fallan cerrados cuando la intención duradera no puede escribirse, a menos que un llamador haya seleccionado explícitamente un modo no duradero documentado.
• Los helpers de compatibilidad heredados de channel-turn y SDK usan por defecto entrega directa propiedad del canal; el envío duradero genérico solo es opt-in explícito.
• Los recibos preservan todos los ids de mensajes de plataforma para entregas multiparte y un id principal para conveniencia de hilos/edición.
• Los wrappers duraderos preservan los efectos secundarios locales del canal antes de reemplazar callbacks de entrega directa.
• Los despachadores preparados no se cuentan como duraderos hasta que su ruta de entrega final use explícitamente el contexto de envío.
• La entrega alternativa maneja cada payload proyectado.
• La entrega alternativa duradera registra cada payload proyectado en una intención o plan por lotes reproducible.
• La salida de fallo de Gateway originada por OpenClaw es visible para humanos, pero los ecos de sala etiquetados y creados por bots se descartan antes de la autorización de bots en canales que declaran soporte para el contrato de origen.
• La documentación explica envío, recepción, en vivo, estado, recibos, relaciones, política de fallos, migración y cobertura de pruebas.

​

Relacionado

• Mensajes
• Streaming y fragmentación
• Borradores de progreso
• Política de reintentos
• Kernel de turnos de canal