Refactorisation du cycle de vie des messages

• Les primitives du cœur doivent être recevoir et envoyer, pas répondre.
• Une réponse n’est qu’une relation sur un message sortant.
• Un tour est une commodité de traitement entrant, pas le propriétaire de la livraison.
• L’envoi doit être fondé sur un contexte : begin, rendu, aperçu ou stream, envoi final, validation, échec.
• La réception doit aussi être fondée sur un contexte : normaliser, dédupliquer, router, enregistrer, distribuer, accuser réception côté plateforme, échouer.
• Le SDK Plugin public doit être réduit à une petite surface sortante de canal.

​

Problèmes

• Les adaptateurs entrants simples utilisent runtime.channel.inbound.run.
• Les adaptateurs riches utilisent runtime.channel.inbound.runPreparedReply.
• Les assistants historiques utilisent dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, les assistants de charge utile de réponse, le découpage des réponses, les références de réponse et les assistants d’exécution sortants.
• Le streaming d’aperçu vit dans des répartiteurs propres à chaque canal.
• La durabilité de la livraison finale est en cours d’ajout autour des chemins existants de charge utile de réponse.

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

​

Objectifs

• Un seul cycle de vie cœur pour tous les chemins de réception et d’envoi de messages de canal.
• Envois finaux durables par défaut dans le nouveau cycle de vie des messages après qu’un adaptateur a déclaré un comportement compatible avec la relecture.
• Sémantique partagée pour l’aperçu, l’édition, le stream, la finalisation, les nouvelles tentatives, la récupération et les reçus.
• Une petite surface de SDK Plugin que les plugins tiers peuvent apprendre et maintenir.
• Compatibilité pour les appelants existants de compatibilité des réponses entrantes pendant la migration.
• Points d’extension clairs pour les nouvelles capacités de canal.
• Aucune branche propre à une plateforme dans le cœur.
• Aucun message de canal par delta de jeton. Le streaming de canal reste une livraison d’aperçu de message, d’édition, d’ajout ou de bloc terminé.
• Métadonnées structurées d’origine OpenClaw pour les sorties opérationnelles/système afin que les échecs visibles du Gateway ne rentrent pas dans les salons partagés où les bots sont autorisés comme nouvelles invites.

​

Non-objectifs

• Ne pas forcer tous les canaux existants à adopter la livraison durable de messages dès la première phase.
• Ne pas forcer tous les canaux à adopter le même comportement de transport natif.
• Ne pas enseigner au cœur les sujets Telegram, les streams natifs Slack, les suppressions Matrix, les cartes Feishu, la voix QQ ou les activités Teams.
• Ne pas publier tous les assistants internes de migration comme API stable du SDK.
• Ne pas faire rejouer par les nouvelles tentatives des opérations de plateforme non idempotentes déjà terminées.

​

Modèle de référence

• Chat
• Thread
• Channel
• Message
• des méthodes d’adaptateur comme postMessage, editMessage, deleteMessage, stream, startTyping et des récupérations d’historique
• un adaptateur d’état pour la déduplication, les verrous, les files d’attente et la persistance

• Intentions d’envoi sortant durables avant les appels directs au transport.
• Contextes d’envoi explicites avec démarrage, validation et échec.
• Contextes de réception qui connaissent la politique d’accusé de réception de la plateforme.
• Reçus qui survivent à un redémarrage et peuvent piloter les éditions, suppressions, récupérations et suppressions de doublons.
• Un SDK public plus petit. Les plugins groupés peuvent utiliser des assistants d’exécution internes, mais les plugins tiers doivent voir une API de message cohérente.
• Comportement propre aux agents : sessions, transcriptions, streaming par blocs, progression des outils, approbations, directives média, réponses silencieuses et historique des mentions de groupe.

​

Modèle cœur

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

​

Termes de message

​

Message

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;
};

​

Cible

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

​

Relation

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";
    };

​

Origine

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";
    };

​

Reçu

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;
};

​

Contexte de réception

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

• Accusé de réception transport : indique au Webhook ou socket de la plateforme qu’OpenClaw a accepté l’enveloppe d’événement. Certaines plateformes l’exigent avant la distribution.
• Accusé de réception d’offset de polling : avance un curseur afin que le même événement ne soit pas récupéré à nouveau. Il ne doit pas avancer au-delà d’un travail qui ne peut pas être récupéré.
• Accusé d’enregistrement entrant : confirme qu’OpenClaw a persisté suffisamment de métadonnées entrantes pour dédupliquer et router une nouvelle livraison.
• Reçu visible par l’utilisateur : comportement optionnel de lecture/statut/saisie ; jamais une frontière de durabilité.

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" };

​

Contexte d’envoi

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;
};

​

Contexte en direct

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;
};

• Envoi Telegram plus édition de l’aperçu, avec final frais après l’âge de péremption de l’aperçu.
• Envoi Discord plus édition de l’aperçu, annulation sur média/erreur/réponse explicite.
• Flux natif Slack ou brouillon d’aperçu selon la forme du fil.
• Finalisation de publication brouillon Mattermost.
• Finalisation d’événement brouillon Matrix ou suppression en cas de non-correspondance.
• Flux de progression natif Teams.
• Flux QQ Bot ou secours accumulé.

​

Surface de l’adaptateur

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

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;
  };
};

​

Réduction du SDK public

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• la plupart des usages publics de outbound-runtime
• les assistants ad hoc de cycle de vie de flux brouillon

​

Relation avec l’entrant de canal

channel.inbound.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

​

Garde-fous de compatibilité

• channel.inbound.run et dispatchChannelInboundReply utilisent le rappel de livraison du canal, sauf si ce canal fournit explicitement un objet de politique/options durable audité.
• channel.inbound.runPreparedReply reste possédé par le canal jusqu’à ce que le répartiteur préparé appelle explicitement le contexte d’envoi.
• Les assistants publics de compatibilité tels que recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase et les assistants de DM direct n’injectent jamais de livraison générique durable avant le rappel deliver ou reply fourni par l’appelant.

• La livraison finale durable renvoie un état discriminé. handled_visible et handled_no_send sont terminaux ; unsupported et not_applicable peuvent revenir à une livraison gérée par le canal ; failed propage l’échec d’envoi.
• La livraison finale durable générique est conditionnée par les capacités de l’adaptateur, comme la livraison silencieuse, la préservation de la cible de réponse, la préservation des citations natives et les hooks d’envoi de messages. En cas de parité manquante, il faut choisir la livraison gérée par le canal, et non un envoi générique qui modifie le comportement visible par l’utilisateur.
• Les envois durables adossés à une file exposent une référence d’intention de livraison. Les champs de session pendingFinalDelivery* existants peuvent porter l’identifiant d’intention pendant la transition ; l’état final est un magasin MessageSendIntent au lieu d’un texte de réponse figé avec des champs de contexte ad hoc.

• L’adaptateur d’envoi générique exécute le même rendu et le même comportement de transport que l’ancien chemin direct.
• Les effets de bord locaux après envoi sont préservés via le contexte d’envoi.
• L’adaptateur renvoie des reçus ou des résultats de livraison avec tous les identifiants de messages de la plateforme.
• Les chemins de répartiteur préparés appellent soit le nouveau contexte d’envoi, soit restent documentés comme hors de la garantie durable.
• La livraison de secours gère chaque payload projeté, pas seulement le premier.
• La livraison de secours durable enregistre tout le tableau de payloads projetés comme une intention ou un plan de lot rejouable unique.

• La livraison du moniteur iMessage enregistre les messages envoyés dans un cache d’écho après un envoi réussi. Les envois finaux durables doivent toujours alimenter ce cache, sinon OpenClaw peut ré-ingérer ses propres réponses finales comme messages utilisateur entrants.
• Tlon ajoute une signature de modèle facultative et enregistre les fils participants après les réponses de groupe. La livraison durable générique ne doit pas contourner ces effets ; déplacez-les dans les adaptateurs de rendu/envoi/finalisation de Tlon ou gardez Tlon sur le chemin géré par le canal.
• Discord et les autres répartiteurs préparés possèdent déjà leur comportement de livraison directe et d’aperçu. Ils ne sont pas couverts par une garantie durable de tour assemblé tant que leurs répartiteurs préparés ne routent pas explicitement les finales via le contexte d’envoi.
• La livraison de secours silencieuse Telegram doit livrer tout le tableau de payloads projetés. Un raccourci limité à un seul payload peut supprimer les payloads de secours supplémentaires après projection.
• LINE, Zalo, Nostr et les autres chemins assemblés/assistants existants peuvent avoir une gestion de jeton de réponse, un proxy de médias, des caches de messages envoyés, un nettoyage de chargement/état ou des cibles uniquement par callback. Ils restent sur la livraison gérée par le canal jusqu’à ce que ces sémantiques soient représentées par l’adaptateur d’envoi et vérifiées par des tests.
• Les assistants de DM direct peuvent avoir un callback de réponse qui est la seule cible de transport correcte. La sortie générique ne doit pas deviner à partir de OriginatingTo ou To et ignorer ce callback.
• La sortie d’échec du Gateway OpenClaw doit rester visible pour les humains, mais les échos de salon marqués comme rédigés par un bot doivent être supprimés avant l’autorisation allowBots. Les canaux ne doivent pas implémenter cela avec des filtres de préfixe sur le texte visible, sauf comme mesure d’urgence temporaire ; le contrat durable est constitué de métadonnées d’origine structurées.

​

Stockage interne

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

​

Classes d’échec

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

• Réessayer transient et rate_limit.
• Ne pas réessayer invalid_payload sauf s’il existe un rendu de secours.
• Ne pas réessayer auth ou permission tant que la configuration n’a pas changé.
• Pour not_found, laissez la finalisation en direct revenir d’une modification à un nouvel envoi lorsque le canal déclare que c’est sûr.
• Pour conflict, utilisez les règles de reçu/idempotence pour décider si le message existe déjà.
• Toute erreur survenant après que l’adaptateur a pu terminer l’I/O de plateforme mais avant la validation du reçu devient unknown_after_send, sauf si l’adaptateur peut prouver que l’opération de plateforme n’a pas eu lieu.

​

Correspondance des canaux

​

Plan de migration

​

Phase 1 : Domaine de message interne

• Ajouter les types src/channels/message/* pour les messages, cibles, relations, origines, accusés de réception, capacités, intentions durables, contexte de réception, contexte d’envoi, contexte live et classes d’échec.
• Ajouter origin?: MessageOrigin au type de charge utile du pont de migration utilisé par la livraison de réponse actuelle, puis déplacer ce champ vers ChannelMessage et les types de message rendus à mesure que le refactor remplace les charges utiles de réponse.
• Garder cela interne jusqu’à ce que les adaptateurs et les tests prouvent la forme.
• Ajouter des tests unitaires purs pour les transitions d’état et la sérialisation.

​

Phase 2 : Noyau d’envoi durable

• Déplacer la file sortante existante de la durabilité des charges utiles de réponse vers les intentions durables d’envoi de message.
• Permettre à une intention d’envoi durable de porter un tableau de charges utiles projetées ou un plan de lot, et pas seulement une charge utile de réponse.
• Préserver le comportement actuel de récupération de file grâce à une conversion de compatibilité.
• Faire appeler messages.send par deliverOutboundPayloads.
• Faire de la durabilité de l’envoi final la valeur par défaut et échouer de manière fermée lorsque l’intention durable ne peut pas être écrite dans le nouveau cycle de vie des messages, après que l’adaptateur a déclaré la sûreté de relecture. Les chemins existants de runner entrant et de compatibilité SDK restent en envoi direct par défaut pendant cette phase.
• Enregistrer les accusés de réception de manière cohérente.
• Retourner les accusés de réception et les résultats de livraison à l’appelant répartiteur d’origine au lieu de traiter l’envoi durable comme un effet de bord terminal.
• Persister l’origine du message dans les intentions d’envoi durables afin que la récupération, la relecture et les envois fragmentés préservent la provenance opérationnelle OpenClaw.

​

Phase 3 : Pont entrant de canal

• Réimplémenter channel.inbound.run et dispatchChannelInboundReply au-dessus de messages.receive et messages.send.
• Garder les types de faits actuels stables.
• Conserver le comportement historique par défaut. Un canal de tour assemblé devient durable uniquement lorsque son adaptateur l’active explicitement avec une politique de durabilité sûre pour la relecture.
• Garder durable: false comme échappatoire de compatibilité pour les chemins qui finalisent des modifications natives et ne peuvent pas encore être relus de manière sûre, mais ne pas s’appuyer sur les marqueurs false pour protéger les canaux non migrés.
• Activer par défaut la durabilité des tours assemblés uniquement dans le nouveau cycle de vie des messages, après que le mappage de canal prouve que le chemin d’envoi générique préserve les anciennes sémantiques de livraison du canal.

​

Phase 4 : Pont de répartiteur préparé

• Remplacez deliverDurableInboundReplyPayload par un pont de contexte d’envoi.
• Conservez l’ancien assistant comme enveloppe.
• Portez Telegram, WhatsApp, Slack, Signal, iMessage et Discord en premier, car ils disposent déjà d’un travail final durable ou de chemins d’envoi plus simples.
• Considérez chaque répartiteur préparé comme non couvert jusqu’à ce qu’il opte explicitement pour le contexte d’envoi. La documentation et les entrées du changelog doivent indiquer « tours de canal assemblés » ou nommer les chemins de canal migrés, plutôt que de revendiquer toutes les réponses finales automatiques.
• Conservez le comportement de recordInboundSessionAndDispatchReply, des assistants de messages directs et des assistants de compatibilité publics similaires. Ils pourront exposer plus tard une option explicite de contexte d’envoi, mais ne doivent pas tenter automatiquement une livraison durable générique avant le rappel de livraison détenu par l’appelant.

​

Phase 5 : cycle de vie live unifié

• Construisez messages.live avec deux adaptateurs de preuve :
  • Telegram pour l’envoi, la modification et l’envoi final obsolète.
  • Matrix pour la finalisation de brouillon et le repli par caviardage.
• Migrez ensuite Discord, Slack, Mattermost, Teams, QQ Bot et Feishu.
• Supprimez le code de finalisation d’aperçu dupliqué uniquement après que chaque canal dispose de tests de parité.

​

Phase 6 : SDK public

• Ajoutez openclaw/plugin-sdk/channel-outbound.
• Documentez-le comme l’API recommandée pour les Plugins de canal.
• Mettez à jour les exports de paquet, l’inventaire des points d’entrée, les références d’API générées et la documentation du SDK de Plugin.
• Incluez MessageOrigin, les hooks d’encodage/décodage d’origine et le prédicat partagé shouldDropOpenClawEcho dans la surface SDK channel-outbound.
• Conservez les enveloppes de compatibilité pour les anciens sous-chemins.
• Marquez les assistants SDK nommés reply comme obsolètes dans la documentation après la migration des Plugins intégrés.

​

Phase 7 : tous les émetteurs

• notifications Cron et Heartbeat
• achèvements de tâches
• résultats de hooks
• invites d’approbation et résultats d’approbation
• envois de l’outil de message
• annonces d’achèvement de sous-agent
• envois explicites depuis la CLI ou Control UI
• chemins d’automatisation/diffusion

​

Phase 8 : supprimer la compatibilité nommée turn

• Conservez les enveloppes nommées inbound/message pendant la fenêtre de compatibilité.
• Publiez des notes de migration.
• Exécutez les tests de compatibilité du SDK de Plugin avec les anciens imports.
• Supprimez ou masquez les anciens assistants internes uniquement lorsqu’aucun Plugin intégré n’en a plus besoin et que les contrats tiers disposent d’un remplacement stable.

​

Plan de test

• Sérialisation et récupération de l’intention d’envoi durable.
• Réutilisation de la clé d’idempotence et suppression des doublons.
• Validation de reçu et saut de relecture.
• Récupération unknown_after_send qui réconcilie avant la relecture lorsqu’un adaptateur prend en charge la réconciliation.
• Politique de classification des échecs.
• Séquençage de la politique d’accusé de réception.
• Mappage des relations pour les envois de réponse, de suivi, système et de diffusion.
• Fabrique d’origine d’échec Gateway et prédicat shouldDropOpenClawEcho.
• Préservation de l’origine lors de la normalisation de charge utile, du découpage, de la sérialisation de file durable et de la récupération.

• L’adaptateur simple channel.inbound.run enregistre et envoie toujours.
• La livraison d’événement assemblé héritée ne devient pas durable sauf si le canal opte explicitement pour cela.
• Le pont channel.inbound.runPreparedReply enregistre et finalise toujours.
• Les assistants de compatibilité publics appellent par défaut les rappels de livraison détenus par l’appelant et n’effectuent pas d’envoi générique avant ces rappels.
• La livraison de repli durable relit tout le tableau de charges utiles projeté après redémarrage et ne peut pas laisser les charges utiles ultérieures non enregistrées après un plantage précoce.
• La livraison durable d’événement assemblé renvoie les ids de messages de plateforme au répartiteur tamponné.
• Les hooks de livraison personnalisés renvoient toujours les ids de messages de plateforme lorsque la livraison durable est désactivée ou indisponible.
• La réponse finale survit à un redémarrage entre l’achèvement de l’assistant et l’envoi à la plateforme.
• Le brouillon d’aperçu se finalise sur place lorsque c’est autorisé.
• Le brouillon d’aperçu est annulé ou caviardé lorsqu’une incompatibilité de média, d’erreur ou de cible de réponse impose une livraison normale.
• Le streaming par blocs et le streaming d’aperçu ne livrent pas tous deux le même texte.
• Les médias diffusés tôt ne sont pas dupliqués dans la livraison finale.

• Réponse de sujet Telegram avec accusé de réception par polling retardé jusqu’au filigrane sûr terminé du contexte de réception.
• Récupération du polling Telegram pour les mises à jour acceptées mais non livrées couverte par le modèle persistant d’offset sûr terminé.
• L’aperçu obsolète Telegram envoie un final frais et nettoie l’aperçu.
• Le repli silencieux Telegram envoie chaque charge utile de repli projetée.
• La durabilité du repli silencieux Telegram enregistre atomiquement tout le tableau de replis projetés, et non une seule intention durable à charge utile unique par itération de boucle.
• Annulation de l’aperçu Discord en cas de média, d’erreur ou de réponse explicite.
• Les finals du répartiteur préparé Discord passent par le contexte d’envoi avant que la documentation ou le changelog ne revendiquent la durabilité des réponses finales Discord.
• Les envois finaux durables iMessage alimentent le cache d’écho des messages envoyés du moniteur.
• Les chemins de livraison hérités LINE, Zalo et Nostr ne sont pas contournés par l’envoi durable générique tant que leurs tests de parité d’adaptateur n’existent pas.
• La livraison par rappel Direct-DM/Nostr reste l’autorité sauf si elle est explicitement migrée vers une cible de message complète et un adaptateur d’envoi sûr pour la relecture.
• Les messages d’échec Gateway OpenClaw étiquetés dans Slack restent visibles en sortie, les échos de salon de bot étiquetés sont supprimés avant allowBots, et les messages de bot non étiquetés ayant le même texte visible suivent toujours l’autorisation de bot normale.
• Repli de flux natif Slack vers un aperçu de brouillon dans les messages directs de premier niveau.
• Finalisation d’aperçu Matrix et repli par caviardage.
• Les échos de salon d’échec Gateway OpenClaw étiquetés Matrix provenant de comptes de bot configurés sont supprimés avant le traitement de allowBots.
• Les audits en cascade d’échec Gateway dans les salons partagés Discord et Google Chat couvrent les modes allowBots avant de revendiquer une protection générique à cet endroit.
• Finalisation de brouillon Mattermost et repli par nouvel envoi.
• Finalisation de progression native Teams.
• Suppression du final en doublon Feishu.
• Repli sur expiration de l’accumulateur QQ Bot.
• Les envois finaux durables Tlon préservent le rendu de signature du modèle et le suivi des fils participants.
• Envois finaux durables simples pour WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo et Zalo Personal.

• Fichiers Vitest ciblés pendant le développement.
• pnpm check:changed dans Testbox pour toute la surface modifiée.
• pnpm check plus large dans Testbox avant l’intégration du refactor complet ou après des changements de SDK public/export.
• Smoke live ou qa-channel pour au moins un canal capable de modification et un canal simple uniquement d’envoi avant de supprimer les enveloppes de compatibilité.

​

Questions ouvertes

• Savoir si Telegram devrait à terme remplacer la source du runner grammY par une source de polling entièrement durable capable de contrôler la relivraison au niveau de la plateforme, et pas seulement le filigrane de redémarrage persistant d’OpenClaw.
• Savoir si l’état durable d’aperçu live doit être stocké dans le même enregistrement de file que l’intention d’envoi finale ou dans un magasin d’état live adjacent.
• Combien de temps les enveloppes de compatibilité restent documentées après la livraison de plugin-sdk/channel-outbound.
• Savoir si les Plugins tiers doivent implémenter directement des adaptateurs de réception ou seulement fournir des hooks normalize/send/live via defineChannelMessageAdapter.
• Quels champs de reçu peuvent être exposés sans risque dans le SDK public plutôt que dans l’état interne du runtime.
• Savoir si les effets de bord tels que les caches d’écho de soi et les marqueurs de fils participants doivent être modélisés comme hooks de contexte d’envoi, étapes de finalisation détenues par l’adaptateur ou abonnés aux reçus.
• Quels canaux disposent de métadonnées d’origine natives, lesquels nécessitent des registres sortants persistants, et lesquels ne peuvent pas offrir de suppression fiable des échos inter-bots.

​

Critères d’acceptation

• Chaque canal de message intégré envoie la sortie finale visible via messages.send.
• Chaque canal de message entrant passe par messages.receive ou par une enveloppe de compatibilité documentée.
• Chaque canal d’aperçu/modification/flux utilise messages.live pour l’état de brouillon et la finalisation.
• channel.inbound n’est qu’une enveloppe.
• Les assistants SDK nommés reply sont des exports de compatibilité, pas le chemin recommandé.
• La récupération durable peut relire les envois finaux en attente après redémarrage sans perdre la réponse finale ni dupliquer les envois déjà validés ; les envois dont le résultat plateforme est inconnu sont réconciliés avant relecture ou documentés comme au moins une fois pour cet adaptateur.
• Les envois finaux durables échouent fermés lorsque l’intention durable ne peut pas être écrite, sauf si un appelant a explicitement sélectionné un mode non durable documenté.
• Les assistants de compatibilité SDK hérités utilisent par défaut une livraison directe détenue par le canal ; l’envoi durable générique est uniquement une option explicite.
• Les reçus préservent tous les ids de messages de plateforme pour les livraisons en plusieurs parties et un id principal pour faciliter les fils et les modifications.
• Les enveloppes durables préservent les effets de bord locaux au canal avant de remplacer les rappels de livraison directe.
• Les répartiteurs préparés ne sont pas comptés comme durables tant que leur chemin de livraison final n’utilise pas explicitement le contexte d’envoi.
• La livraison de repli gère chaque charge utile projetée.
• La livraison de repli durable enregistre chaque charge utile projetée dans une intention ou un plan de lot rejouable unique.
• La sortie d’échec Gateway émise par OpenClaw est visible pour les humains, mais les échos de salon étiquetés rédigés par des bots sont supprimés avant l’autorisation de bot sur les canaux qui déclarent prendre en charge le contrat d’origine.
• La documentation explique l’envoi, la réception, le live, l’état, les reçus, les relations, la politique d’échec, la migration et la couverture de tests.

​

Connexe

• Messages
• Streaming et découpage
• Brouillons de progression
• Politique de nouvelle tentative
• API entrante de canal