Refactorisation du cycle de vie des messages

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.

• 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 basé sur un contexte : begin, rendu, aperçu ou stream, envoi final, commit, échec.
• La réception doit aussi être basée sur un contexte : normaliser, dédupliquer, router, enregistrer, distribuer, acquitter la plateforme, échouer.
• Le SDK public de Plugin doit se réduire à une petite surface de messages de canal unique.

​

Problèmes

• Les adaptateurs entrants simples utilisent runtime.channel.turn.run.
• Les adaptateurs riches utilisent runtime.channel.turn.runPrepared.
• Les helpers hérités utilisent dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, les helpers de payload de réponse, le découpage de réponse, les références de réponse et les helpers d’exécution sortante.
• Le streaming d’aperçu vit dans des dispatchers propres à chaque canal.
• La durabilité de la livraison finale est ajoutée autour des chemins de payload de réponse existants.

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

​

Objectifs

• Un cycle de vie cœur unique pour tous les chemins de réception et d’envoi des messages de canal.
• Envois finaux durables par défaut dans le nouveau cycle de vie des messages après qu’un adaptateur déclare un comportement sûr au rejeu.
• Sémantiques partagées d’aperçu, modification, stream, finalisation, nouvelle tentative, récupération et reçu.
• Une petite surface de SDK de Plugin que les plugins tiers peuvent apprendre et maintenir.
• Compatibilité pour les appelants channel.turn existants pendant la migration.
• Points d’extension clairs pour les nouvelles capacités de canal.
• Aucune branche spécifique à une plateforme dans le cœur.
• Pas de messages de canal à delta de tokens. Le streaming de canal reste une livraison d’aperçu de message, de modification, 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 réentrent pas dans les salons partagés où les bots sont activés comme de nouvelles invites.

​

Non-objectifs

• Ne pas supprimer runtime.channel.turn.* dans la première phase.
• Ne pas forcer chaque canal à adopter le même comportement de transport natif.
• Ne pas enseigner au cœur les sujets Telegram, les streams natifs Slack, les redactions Matrix, les cartes Feishu, la voix QQ ou les activités Teams.
• Ne pas publier tous les helpers internes de migration comme API SDK stable.
• 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 les 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 begin, commit et échec.
• Contextes de réception qui connaissent la politique d’acquittement de la plateforme.
• Reçus qui survivent au redémarrage et peuvent piloter les modifications, suppressions, récupérations et la suppression des doublons.
• Un SDK public plus petit. Les plugins groupés peuvent utiliser des helpers d’exécution internes, mais les plugins tiers devraient voir une API de message cohérente unique.
• Comportement propre à l’agent : sessions, transcriptions, streaming de blocs, progression d’outils, approbations, directives média, réponses silencieuses et historique de 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

• Acquittement de transport : indique au Webhook ou au socket de la plateforme qu’OpenClaw a accepté l’enveloppe d’événement. Certaines plateformes l’exigent avant la distribution.
• Acquittement 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à du travail qui ne peut pas être récupéré.
• Acquittement d’enregistrement entrant : confirme qu’OpenClaw a persisté assez de métadonnées entrantes pour dédupliquer et router une nouvelle livraison.
• Reçu visible par l’utilisateur : comportement facultatif 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 avec édition d’aperçu, avec un final frais après le vieillissement de l’aperçu périmé.
• Envoi Discord avec édition d’aperçu, annulation en cas de média, d’erreur ou de 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 discordance.
• Flux de progression natif Teams.
• Flux QQ Bot ou repli accumulé.

​

Surface de l’adaptateur

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

​

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 de brouillon

​

Relation avec le tour 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

​

Garde-fous de compatibilité

• channel.turn.run et dispatchAssembledChannelTurn utilisent le rappel de livraison du canal sauf si ce canal fournit explicitement un objet de politique/options durable audité.
• channel.turn.runPrepared reste possédé par le canal jusqu’à ce que le répartiteur préparé appelle explicitement le contexte d’envoi.
• Les assistants de compatibilité publics tels que recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase et les assistants de DM directs n’injectent jamais de livraison durable générique 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 se rabattre sur 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 des capacités d’adaptateur telles que 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 une 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’id d’intention pendant la transition ; l’état final est un stockage MessageSendIntent au lieu d’un texte de réponse figé plus des champs de contexte ad hoc.

• L’adaptateur d’envoi générique exécute le même comportement de rendu et de transport que l’ancien chemin direct.
• Les effets de bord locaux post-envoi sont préservés via le contexte d’envoi.
• L’adaptateur renvoie des accusés de réception ou des résultats de livraison avec tous les ids 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 étant hors de la garantie durable.
• La livraison de repli gère chaque charge utile projetée, pas seulement la première.
• La livraison de repli durable enregistre tout le tableau de charges utiles projetées comme une intention rejouable unique ou un plan de lot.

• 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à le 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 finals via le contexte d’envoi.
• La livraison de repli silencieuse de Telegram doit livrer tout le tableau de charges utiles projetées. Un raccourci à charge utile unique peut supprimer des charges utiles de repli supplémentaires après projection.
• LINE, Zalo, Nostr et les autres chemins assemblés/d’assistance existants peuvent avoir une gestion des jetons de réponse, une médiation de médias, des caches de messages envoyés, un nettoyage de chargement/état ou des cibles réservées aux callbacks. Ils restent sur la livraison gérée par le canal tant que ces sémantiques ne sont pas représentées par l’adaptateur d’envoi et vérifiées par des tests.
• Les assistants de DM directs peuvent avoir un callback de réponse qui est la seule cible de transport correcte. Le sortant 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 par les humains, mais les échos de salon étiquetés et 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 de texte visible, sauf comme court palliatif d’urgence ; le contrat durable repose sur des 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 repli de rendu.
• Ne pas réessayer auth ou permission tant que la configuration n’a pas changé.
• Pour not_found, laisser la finalisation en direct se rabattre d’une modification vers un nouvel envoi lorsque le canal déclare que c’est sûr.
• Pour conflict, utiliser les règles d’accusé de réception/idempotence pour décider si le message existe déjà.
• Toute erreur survenant après que l’adaptateur a pu terminer les E/S de plateforme mais avant la validation de l’accusé de réception devient unknown_after_send, sauf si l’adaptateur peut prouver que l’opération de plateforme n’a pas eu lieu.

​

Mappage des canaux

​

Plan de migration

​

Phase 1 : domaine de message interne

• Ajouter des types src/channels/message/* pour les messages, cibles, relations, origines, reçus, capacités, intentions durables, contexte de réception, contexte d’envoi, contexte en direct et classes d’échec.
• Ajouter origin?: MessageOrigin au type de charge utile du pont de migration utilisé par la livraison de réponses actuelle, puis déplacer ce champ vers ChannelMessage et les types de message rendu à mesure que le remaniement 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 d’envoi de message durables.
• Permettre à une intention d’envoi durable de transporter un tableau de charges utiles projetées ou un plan de lot, pas seulement une seule 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 tour de canal et de compatibilité SDK restent en envoi direct par défaut pendant cette phase.
• Enregistrer les reçus de manière cohérente.
• Renvoyer les reçus et les résultats de livraison à l’appelant du répartiteur d’origine au lieu de traiter l’envoi durable comme un effet de bord terminal.
• Persister l’origine du message via les intentions d’envoi durables afin que la récupération, la relecture et les envois fragmentés préservent la provenance opérationnelle d’OpenClaw.

​

Phase 3 : pont de tour de canal

• Réimplémenter channel.turn.run et dispatchAssembledChannelTurn par-dessus messages.receive et messages.send.
• Garder les types de faits actuels stables.
• Garder le comportement hérité par défaut. Un canal de tour assemblé ne devient durable que lorsque son adaptateur opte explicitement pour une politique de durabilité sûre à rejouer.
• Garder durable: false comme issue de compatibilité pour les chemins qui finalisent les modifications natives et ne peuvent pas encore être rejoués en toute sûreté, 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 du canal a prouvé 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é

• Remplacer deliverDurableInboundReplyPayload par un pont de contexte d’envoi.
• Conserver l’ancien assistant comme wrapper.
• Porter d’abord Telegram, WhatsApp, Slack, Signal, iMessage et Discord, car ils disposent déjà d’un travail final durable ou de chemins d’envoi plus simples.
• Considérer 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 d’affirmer que toutes les réponses finales automatiques sont couvertes.
• Conserver le comportement de recordInboundSessionAndDispatchReply, des assistants de MP directs et des assistants de compatibilité publics similaires. Ils pourront exposer plus tard une adhésion explicite au contexte d’envoi, mais ne doivent pas tenter automatiquement une livraison durable générique avant le callback de livraison détenu par l’appelant.

​

Phase 5 : Cycle de vie unifié en direct

• Construire 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 rédaction.
• Migrer ensuite Discord, Slack, Mattermost, Teams, QQ Bot et Feishu.
• Supprimer le code de finalisation d’aperçu dupliqué seulement après que chaque canal dispose de tests de parité.

​

Phase 6 : SDK public

• Ajouter openclaw/plugin-sdk/channel-message.
• Le documenter comme l’API de Plugin de canal recommandée.
• Mettre à jour les exports de package, l’inventaire des points d’entrée, les références d’API générées et la documentation du SDK de Plugin.
• Inclure MessageOrigin, les hooks d’encodage/décodage d’origine et le prédicat partagé shouldDropOpenClawEcho dans la surface SDK channel-message.
• Conserver les wrappers de compatibilité pour les anciens sous-chemins.
• Marquer les assistants SDK nommés reply comme obsolètes dans la documentation après la migration des plugins fournis.

​

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 CLI ou Control UI
• chemins d’automatisation/diffusion

​

Phase 8 : Déprécier Turn

• Conserver channel.turn comme wrapper pendant au moins une fenêtre de compatibilité.
• Publier des notes de migration.
• Exécuter les tests de compatibilité du SDK de Plugin avec les anciens imports.
• Supprimer ou masquer les anciens assistants internes seulement après qu’aucun plugin fourni n’en ait 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 clé d’idempotence et suppression des doublons.
• Commit 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équencement de la politique d’acquittement de réception.
• Mappage des relations pour les envois reply, followup, system et broadcast.
• Fabrique d’origine d’échec de Gateway et prédicat shouldDropOpenClawEcho.
• Préservation de l’origine à travers la normalisation de charge utile, le découpage, la sérialisation de file durable et la récupération.

• L’adaptateur simple channel.turn.run enregistre et envoie toujours.
• La livraison héritée de tour assemblé ne devient pas durable sauf si le canal opte explicitement pour cela.
• Le pont channel.turn.runPrepared enregistre et finalise toujours.
• Les assistants de compatibilité publics appellent par défaut les callbacks de livraison détenus par l’appelant et n’effectuent pas d’envoi générique avant ces callbacks.
• La livraison de repli durable rejoue l’ensemble du tableau de charges utiles projetées après redémarrage et ne peut pas laisser les charges utiles suivantes non enregistrées après un crash précoce.
• La livraison durable de tour assemblé renvoie les identifiants de messages de plateforme au répartiteur tamponné.
• Les hooks de livraison personnalisés renvoient toujours les identifiants 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 rédigé lorsqu’un média, une erreur ou une incompatibilité de cible de réponse exige une livraison normale.
• Le streaming par blocs et le streaming d’aperçu ne livrent pas tous deux le même texte.
• Le média diffusé tôt n’est pas dupliqué dans la livraison finale.

• Réponse à un sujet Telegram avec acquittement de polling retardé jusqu’au watermark terminé sûr 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 d’offset terminé sûr persistant.
• L’aperçu Telegram obsolète 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 repli projeté, et non une 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 finales 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 callback Direct-DM/Nostr reste l’autorité sauf migration explicite vers une cible de message complète et un adaptateur d’envoi sûr pour la relecture.
• Les messages Slack d’échec de Gateway OpenClaw balisés restent visibles en sortie, les échos de salle de bot balisés sont supprimés avant allowBots, et les messages de bot non balisés avec le même texte visible suivent toujours l’autorisation normale des bots.
• Repli du flux natif Slack vers un aperçu de brouillon dans les MP de premier niveau.
• Finalisation d’aperçu Matrix et repli par rédaction.
• Les échos de salle Matrix balisés comme échec de Gateway OpenClaw provenant de comptes de bot configurés sont supprimés avant le traitement allowBots.
• Les audits en cascade des échecs de Gateway en salle partagée 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 des finales dupliquées Feishu.
• Repli sur expiration du délai de l’accumulateur QQ Bot.
• Les envois finaux durables Tlon préservent le rendu de signature de modèle et le suivi des fils de discussion participants.
• Envois finaux durables simples 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 de livrer le refactor complet ou après des changements d’exports/SDK publics.
• Smoke live ou qa-channel pour au moins un canal capable de modifier et un canal simple à envoi seul avant de supprimer les wrappers de compatibilité.

​

Questions ouvertes

• Déterminer si Telegram doit à terme remplacer la source du runner grammY par une source de polling entièrement durable pouvant contrôler la relivraison au niveau de la plateforme, et non seulement le watermark de redémarrage persistant d’OpenClaw.
• Déterminer si l’état d’aperçu live durable doit être stocké dans le même enregistrement de file que l’intention d’envoi final ou dans un magasin d’état live frère.
• Durée pendant laquelle les wrappers de compatibilité restent documentés après la livraison de plugin-sdk/channel-message.
• Déterminer si les plugins tiers doivent implémenter directement des adaptateurs de réception ou seulement fournir des hooks normalize/send/live via defineChannelMessageAdapter.
• Champs de reçu pouvant être exposés sans risque dans le SDK public plutôt que dans l’état d’exécution interne.
• Déterminer si les effets de bord tels que les caches d’auto-écho 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.
• Canaux disposant de métadonnées d’origine natives, ceux qui nécessitent des registres sortants persistants et ceux qui ne peuvent pas offrir une suppression fiable des échos entre bots.

​

Critères d’acceptation

• Chaque canal de messages fourni envoie la sortie finale visible via messages.send.
• Chaque canal de messages entrant passe par messages.receive ou par un wrapper de compatibilité documenté.
• Chaque canal d’aperçu/modification/stream utilise messages.live pour l’état de brouillon et la finalisation.
• channel.turn est seulement un wrapper.
• Les assistants SDK nommés reply sont des exports de compatibilité, pas le chemin recommandé.
• La récupération durable peut rejouer les envois finaux en attente après redémarrage sans perdre la réponse finale ni dupliquer les envois déjà commités ; les envois dont le résultat de 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é legacy channel-turn et SDK utilisent par défaut la livraison directe détenue par le canal ; l’envoi durable générique est une adhésion explicite seulement.
• Les reçus préservent tous les identifiants de messages de plateforme pour les livraisons en plusieurs parties et un identifiant principal pour faciliter les fils et les modifications.
• Les wrappers durables préservent les effets de bord locaux au canal avant de remplacer les callbacks de livraison directe.
• Les répartiteurs préparés ne sont pas comptés comme durables tant que leur chemin de livraison finale 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.
• La sortie d’échec de Gateway émise par OpenClaw est visible pour les humains, mais les échos de salle balisés et rédigés par un bot 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
• Noyau de tour de canal