Refactorización del ciclo de vida de los mensajes

Documentation Index

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

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

• Las primitivas del núcleo deben ser recibir y enviar, no responder.
• Una respuesta es solo una relación en un mensaje saliente.
• Un turno es una conveniencia de procesamiento entrante, no el propietario de la entrega.
• El envío debe basarse en contexto: begin, renderizar, vista previa o stream, envío final, confirmar, fallar.
• La recepción también debe basarse en contexto: normalizar, deduplicar, enrutar, registrar, despachar, ack de plataforma, fallar.
• La SDK pública de plugins debe condensarse en una pequeña superficie de mensajes de canal.

​

Problemas

• Los adaptadores entrantes simples usan runtime.channel.turn.run.
• Los adaptadores enriquecidos usan runtime.channel.turn.runPrepared.
• Los helpers heredados usan dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, helpers de payload de respuesta, fragmentación de respuestas, referencias de respuesta y helpers 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 existentes de payload de respuesta.

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

​

Objetivos

• Un ciclo de vida de núcleo 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 comportamiento seguro para reproducción.
• Semánticas compartidas de vista previa, edición, stream, finalización, reintento, recuperación y recibo.
• Una pequeña superficie de SDK de plugins que los plugins de terceros puedan aprender y mantener.
• Compatibilidad para 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, anexado o entrega de bloque completado.
• Metadatos estructurados originados en OpenClaw para salida operativa o del sistema, de modo que los fallos visibles del Gateway no vuelvan a entrar en salas compartidas con bots habilitados 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 helpers internos de migración como API estable de la 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 deduplicación, locks, 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 conozcan la política de ack de plataforma.
• Recibos que sobrevivan a reinicios y puedan impulsar ediciones, eliminaciones, recuperación y supresión de duplicados.
• Una SDK pública más pequeña. Los plugins incluidos pueden usar helpers internos de runtime, pero los plugins de terceros deben ver una API de mensajes coherente.
• Comportamiento específico de agentes: sesiones, transcripciones, streaming de bloques, progreso de herramientas, aprobaciones, directivas de medios, respuestas silenciosas e historial de menciones en grupos.

​

Modelo del núcleo

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

• Ack de transporte: indica al webhook o socket de la plataforma que OpenClaw aceptó el sobre del evento. Algunas plataformas lo requieren antes del despacho.
• Ack de offset de polling: avanza un cursor para que el mismo evento no se obtenga de nuevo. Esto no debe avanzar más allá de trabajo que no pueda recuperarse.
• Ack de registro entrante: confirma que OpenClaw persistió suficientes metadatos entrantes para deduplicar y enrutar una reentrega.
• Recibo visible para el usuario: comportamiento opcional de lectura, estado o escritura; nunca 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 vista previa editada, con final nuevo después de una antigüedad obsoleta de la vista previa.
• Envío de Discord más vista previa editada, cancelación en medios/error/respuesta explícita.
• Transmisión nativa de Slack o vista previa de borrador según la forma del hilo.
• Finalización de publicación de borrador de Mattermost.
• Finalización de evento de borrador de Matrix o redacción en caso de discrepancia.
• Transmisión de progreso nativa de Teams.
• Transmisión de QQ Bot o respaldo acumulado.

​

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 de ciclo de vida de transmisión de borradores

​

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

​

Medidas de protección de compatibilidad

• channel.turn.run y dispatchAssembledChannelTurn usan el callback de entrega del canal a menos que ese canal proporcione explícitamente un objeto de política/opciones durables auditado.
• channel.turn.runPrepared sigue siendo propiedad del canal hasta que el despachador preparado llame explícitamente al contexto de envío.
• Los helpers de compatibilidad públicos como recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase y los helpers de DM directos nunca inyectan entrega durable genérica antes del callback deliver o reply proporcionado 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á controlada 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 ruta directa anterior.
• 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 permanecen documentadas como fuera de la garantía duradera.
• La entrega alternativa maneja cada carga útil proyectada, no solo la primera.
• La entrega alternativa duradera registra todo el arreglo de cargas útiles proyectadas como una sola intención reproducible o plan por lotes.

• La entrega del monitor de iMessage registra los mensajes enviados en una caché de eco después de un envío exitoso. Los envíos finales duraderos todavía deben poblar esa caché; de lo contrario, OpenClaw puede reingerir sus propias respuestas finales como mensajes entrantes de usuario.
• Tlon agrega una firma opcional del modelo y registra los hilos participados 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 del 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 mediante el contexto de envío.
• La entrega alternativa silenciosa de Telegram debe entregar todo el arreglo de cargas útiles proyectadas. Un atajo de una sola carga útil puede descartar cargas útiles alternativas adicionales después de la proyección.
• LINE, BlueBubbles, Zalo, Nostr y otras rutas ensambladas/de ayuda existentes pueden tener manejo de tokens de respuesta, proxy de medios, cachés de mensajes enviados, limpieza de carga/estado o destinos 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 ayudantes de DM directo pueden tener un callback de respuesta que es el único destino de transporte correcto. La salida genérica no debe adivinar a partir de OriginatingTo o To y omitir ese callback.
• La salida de fallos del Gateway de OpenClaw debe seguir 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 una medida provisional 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, permitir que la finalización en vivo pase de edición a envío nuevo cuando el canal declare que es seguro.
• Para conflict, usar reglas de recibo/idempotencia para decidir si el mensaje ya existe.
• Cualquier error posterior a que el adaptador pueda haber completado E/S de la plataforma, pero anterior a confirmar el recibo, pasa a ser unknown_after_send, salvo que el adaptador pueda demostrar que la operación de la plataforma no ocurrió.

​

Mapeo de canales

​

Plan de migración

​

Fase 1: Dominio interno de mensajes

• Agregar 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.
• Agregar origin?: MessageOrigin al tipo de carga útil del puente de migración usado por la entrega de respuestas actual; luego mover ese campo a ChannelMessage y a los tipos de mensaje renderizado a medida que la refactorización reemplace las cargas útiles de respuesta.
• Mantener esto interno hasta que los adaptadores y las pruebas demuestren la forma.
• Agregar pruebas unitarias puras para transiciones de estado y serialización.

​

Fase 2: Núcleo de envío duradero

• Mover la cola saliente existente desde la durabilidad de cargas útiles de respuesta a intenciones de envío de mensajes duraderas.
• Permitir que una intención de envío duradera transporte un arreglo de cargas útiles proyectadas o un plan de lote, no solo una carga útil de respuesta.
• Preservar el comportamiento actual de recuperación de cola mediante conversión de compatibilidad.
• Hacer que deliverOutboundPayloads llame a messages.send.
• Hacer que la durabilidad del envío final sea el valor predeterminado y 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 SDK siguen siendo de envío directo de forma predeterminada durante esta fase.
• Registrar recibos de forma coherente.
• Devolver recibos y resultados de entrega al llamador del despachador original en lugar de tratar el envío duradero como un efecto secundario terminal.
• Persistir 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

• Reimplementar channel.turn.run y dispatchAssembledChannelTurn sobre messages.receive y messages.send.
• Mantener estables los tipos de hechos actuales.
• Mantener 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.
• Mantener durable: false como una vía de escape de compatibilidad para rutas que finalizan ediciones nativas y aún no pueden reproducirse de forma segura, pero no depender de marcadores false para proteger canales no migrados.
• Aplicar la durabilidad predeterminada de turnos ensamblados 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 del despachador preparado

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

​

Fase 5: Ciclo de vida en vivo unificado

• Crea messages.live con dos adaptadores de prueba:
  • Telegram para envío, edición y envío final obsoleto.
  • Matrix para finalización de borrador y fallback de redacción.
• Luego migra Discord, Slack, Mattermost, Teams, QQ Bot y Feishu.
• Elimina 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

• Agrega openclaw/plugin-sdk/channel-message.
• Documéntalo como la API preferida para plugins de canal.
• Actualiza las exportaciones del paquete, el inventario de puntos de entrada, las líneas base de API generadas y la documentación del SDK de plugins.
• Incluye MessageOrigin, hooks de codificación/decodificación de origen y el predicado compartido shouldDropOpenClawEcho en la superficie del SDK channel-message.
• Mantén wrappers de compatibilidad para las subrutas antiguas.
• Marca los helpers del SDK con nombre de respuesta como obsoletos en la documentación después de migrar los plugins incluidos.

​

Fase 7: Todos los remitentes

• notificaciones de cron y heartbeat
• finalizaciones de tareas
• resultados de hooks
• solicitudes y resultados de aprobación
• envíos de la herramienta de mensajes
• anuncios de finalización de subagentes
• envíos explícitos desde CLI o Control UI
• rutas de automatización/difusión

​

Fase 8: Obsolecer Turn

• Mantén channel.turn como wrapper durante al menos una ventana de compatibilidad.
• Publica notas de migración.
• Ejecuta pruebas de compatibilidad del SDK de plugins contra importaciones antiguas.
• Elimina u oculta los 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 intenciones de envío durables.
• Reutilización de claves de idempotencia y supresión de duplicados.
• Confirmación de recibos y omisión de 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 acuse de recepción.
• Asignación 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 durable y recuperación.

• El adaptador simple de channel.turn.run aún registra y envía.
• La entrega heredada de turnos ensamblados no se vuelve durable a menos que el canal opte explícitamente por ello.
• El puente channel.turn.runPrepared aún registra y finaliza.
• Los helpers públicos de compatibilidad llaman por defecto a los callbacks de entrega propiedad del llamador y no hacen un envío genérico antes de esos callbacks.
• La entrega de fallback durable reproduce todo el arreglo de payload proyectado después de reiniciar y no puede dejar los payloads posteriores sin registrar tras un fallo temprano.
• La entrega durable de turnos ensamblados devuelve ids de mensajes de la plataforma al dispatcher con búfer.
• Los hooks de entrega personalizados aún devuelven ids de mensajes de la plataforma cuando la entrega durable está deshabilitada o no está 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 un desajuste de medio/error/destino de respuesta requiere entrega normal.
• La transmisión por 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 de tema de Telegram con acuse de sondeo retrasado hasta la marca de agua completada segura del contexto de recepción.
• Recuperación de sondeo de Telegram para actualizaciones aceptadas pero no entregadas cubierta por el modelo persistido de offset completado seguro.
• La vista previa obsoleta de Telegram envía un final nuevo y limpia la vista previa.
• El fallback silencioso de Telegram envía cada payload de fallback proyectado.
• La durabilidad del fallback silencioso de Telegram registra atómicamente todo el arreglo de fallback proyectado, no una intención durable de un solo payload por cada iteración del bucle.
• Cancelación de vista previa de Discord en medio/error/respuesta explícita.
• Los finales del dispatcher preparado de Discord se enrutan a través del contexto de envío antes de que la documentación o el registro de cambios afirmen durabilidad de respuesta final de Discord.
• Los envíos finales durables de iMessage rellenan la caché de ecos de mensajes enviados del monitor.
• Las rutas de entrega heredadas de LINE, BlueBubbles, Zalo y Nostr no se omiten por envío durable genérico hasta que existan sus pruebas de paridad de adaptador.
• La entrega por callback de Direct-DM/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 como salientes, los ecos etiquetados de sala de bot se descartan antes de allowBots, y los mensajes de bot sin etiqueta con el mismo texto visible siguen la autorización normal de bot.
• Fallback de transmisión nativa de Slack a borrador de vista previa en DM de nivel superior.
• Finalización de vista previa y fallback de redacción de Matrix.
• Los ecos de sala etiquetados como fallo de Gateway de OpenClaw desde cuentas de bot configuradas de Matrix se descartan antes del manejo de allowBots.
• Las auditorías en cascada de fallo de Gateway en salas compartidas de Discord y Google Chat cubren los modos de allowBots antes de afirmar protección genérica allí.
• Finalización de borrador y fallback de envío nuevo de Mattermost.
• Finalización de progreso nativo de Teams.
• Supresión de final duplicado de Feishu.
• Fallback por timeout del acumulador de QQ Bot.
• Los envíos finales durables de Tlon preservan el renderizado de firma del modelo y el seguimiento de hilos participados.
• Envíos finales durables simples de WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo y Zalo Personal.

• Archivos Vitest dirigidos durante el desarrollo.
• pnpm check:changed en Testbox para toda la superficie modificada.
• pnpm check más amplio en Testbox antes de integrar el refactor completo o después de cambios públicos de SDK/exportación.
• 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 reemplazar eventualmente la fuente del runner de grammY por una fuente de sondeo completamente durable que pueda controlar la reentrega a nivel de plataforma, no solo la marca de agua persistida de reinicio de OpenClaw.
• Si el estado durable de vista previa en vivo 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.
• Cuánto tiempo permanecen documentados los wrappers de compatibilidad 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 normalize/send/live 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 eco propio 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 confiable 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/transmisión usa messages.live para el estado de borrador y la finalización.
• channel.turn es solo un wrapper.
• Los helpers del SDK con nombre de respuesta son exportaciones de compatibilidad, no la ruta recomendada.
• La recuperación durable 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 durables fallan de forma cerrada cuando no se puede escribir la intención durable, a menos que un llamador haya seleccionado explícitamente un modo no durable documentado.
• Los helpers heredados de channel-turn y de compatibilidad del SDK usan por defecto entrega directa propiedad del canal; el envío durable genérico requiere opción explícita.
• Los recibos preservan todos los ids de mensajes de la plataforma para entregas multipartes y un id primario para comodidad de hilos/edición.
• Los wrappers durables preservan los efectos secundarios locales del canal antes de reemplazar callbacks de entrega directa.
• Los dispatchers preparados no se cuentan como durables hasta que su ruta de entrega final use explícitamente el contexto de envío.
• La entrega de fallback maneja cada payload proyectado.
• La entrega de fallback durable registra cada payload proyectado en una intención reproducible o plan de lote.
• La salida de fallo de Gateway originada por OpenClaw es visible para humanos, pero los ecos de sala etiquetados y escritos 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
• Transmisión y fragmentación
• Borradores de progreso
• Política de reintentos
• Kernel de turno de canal