Рефакторинг життєвого циклу повідомлень

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.

• Основні примітиви мають бути receive і send, а не reply.
• Відповідь є лише відношенням у вихідному повідомленні.
• Turn є зручністю для обробки вхідних даних, а не власником доставки.
• Надсилання має базуватися на контексті: begin, render, preview або stream, final send, commit, fail.
• Отримання також має базуватися на контексті: normalize, dedupe, route, record, dispatch, platform ack, fail.
• Публічний plugin SDK має звестися до однієї невеликої поверхні channel-message.

​

Проблеми

• Прості вхідні адаптери використовують runtime.channel.turn.run.
• Розширені адаптери використовують runtime.channel.turn.runPrepared.
• Застарілі допоміжні засоби використовують dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, допоміжні засоби reply payload, reply chunking, reply references і outbound runtime helpers.
• Preview streaming живе в диспетчерах, специфічних для каналів.
• Надійність фінальної доставки додається навколо наявних шляхів reply payload.

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

​

Цілі

• Один життєвий цикл ядра для всіх шляхів отримання й надсилання channel message.
• Надійні фінальні надсилання за замовчуванням у новому життєвому циклі повідомлення після того, як адаптер оголосить replay-safe поведінку.
• Спільна семантика preview, edit, stream, finalization, retry, recovery і receipt.
• Невелика поверхня plugin SDK, яку сторонні plugins можуть вивчити й підтримувати.
• Сумісність для наявних викликів channel.turn під час міграції.
• Чіткі точки розширення для нових можливостей каналів.
• Без специфічних для платформи гілок у ядрі.
• Без token-delta повідомлень каналів. Channel streaming залишається доставкою message preview, edit, append або completed block.
• Структуровані метадані походження з OpenClaw для операційного/системного виводу, щоб видимі збої gateway не входили повторно в спільні кімнати з увімкненими ботами як нові prompts.

​

Нецілі

• Не видаляти runtime.channel.turn.* на першому етапі.
• Не змушувати кожен канал до однакової нативної транспортної поведінки.
• Не навчати ядро Telegram topics, Slack native streams, Matrix redactions, Feishu cards, QQ voice або Teams activities.
• Не публікувати всі внутрішні допоміжні засоби міграції як стабільний SDK API.
• Не робити так, щоб повторні спроби повторно відтворювали завершені неідемпотентні операції платформи.

​

Еталонна модель

• Chat
• Thread
• Channel
• Message
• методи адаптера, як-от postMessage, editMessage, deleteMessage, stream, startTyping і отримання історії
• адаптер стану для dedupe, locks, queues і persistence

• Надійні наміри вихідного надсилання перед прямими транспортними викликами.
• Явні контексти надсилання з begin, commit і fail.
• Контексти отримання, які знають політику platform ack.
• Квитанції, які переживають перезапуск і можуть керувати edits, deletes, recovery та duplicate suppression.
• Менший публічний SDK. Вбудовані plugins можуть використовувати внутрішні runtime helpers, але сторонні plugins мають бачити один узгоджений message API.
• Поведінка, специфічна для агента: sessions, transcripts, block streaming, tool progress, approvals, media directives, silent replies і group mention history.

​

Модель ядра

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

​

Терміни повідомлень

​

Повідомлення

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

​

Ціль

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

​

Відношення

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

​

Походження

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

​

Квитанція

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

​

Контекст отримання

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

• Transport ack: повідомляє platform webhook або socket, що OpenClaw прийняв event envelope. Деякі платформи вимагають цього до dispatch.
• Polling offset ack: просуває cursor, щоб ту саму подію не отримували знову. Це не має просуватися далі за роботу, яку неможливо відновити.
• Inbound record ack: підтверджує, що OpenClaw зберіг достатньо inbound metadata, щоб виконати dedupe і route для повторної доставки.
• User-visible receipt: необов’язкова read/status/typing поведінка; ніколи не є межею надійності.

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

​

Контекст надсилання

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

​

Живий контекст

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

• Telegram надсилання плюс редагований попередній перегляд, зі свіжим фінальним повідомленням після застаріння попереднього перегляду.
• Discord надсилання плюс редагований попередній перегляд, скасування на медіа/помилці/явній відповіді.
• Slack нативний stream або чорновий попередній перегляд залежно від форми треду.
• Mattermost фіналізація чорнового допису.
• Matrix фіналізація чорнової події або редагування у разі невідповідності.
• Teams нативний stream прогресу.
• QQ Bot stream або накопичений резервний варіант.

​

Поверхня адаптера

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

​

Скорочення публічного SDK

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• більшість публічних використань outbound-runtime
• ad hoc допоміжні засоби життєвого циклу draft stream

​

Зв’язок із channel turn

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

​

Запобіжники сумісності

• channel.turn.run і dispatchAssembledChannelTurn використовують callback доставки каналу, якщо цей канал явно не надає перевірений об’єкт довговічної політики/параметрів.
• channel.turn.runPrepared залишається у власності каналу, доки підготовлений диспетчер явно не викличе контекст надсилання.
• Публічні допоміжні засоби сумісності, як-от recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase і direct-DM helpers, ніколи не впроваджують універсальну довговічну доставку перед наданим викликачем callback deliver або reply.

• Стійка фінальна доставка повертає дискримінований статус. handled_visible і handled_no_send є термінальними; unsupported і not_applicable можуть повертатися до доставки, що належить каналу; failed поширює збій надсилання.
• Універсальна стійка фінальна доставка обмежується можливостями адаптера, як-от тиха доставка, збереження цілі відповіді, збереження нативної цитати та хуки надсилання повідомлень. За відсутності паритету слід обирати доставку, що належить каналу, а не універсальне надсилання, яке змінює поведінку, видиму користувачу.
• Стійкі надсилання на основі черги надають посилання на намір доставки. Наявні поля сеансу pendingFinalDelivery* можуть переносити ідентифікатор наміру під час переходу; кінцевий стан — сховище MessageSendIntent замість замороженого тексту відповіді плюс ad hoc поля контексту.

• Адаптер універсального надсилання виконує ту саму поведінку рендерингу й транспорту, що й старий прямий шлях.
• Локальні побічні ефекти після надсилання зберігаються через контекст надсилання.
• Адаптер повертає квитанції або результати доставки з усіма ідентифікаторами повідомлень платформи.
• Підготовлені шляхи диспетчеризації або викликають новий контекст надсилання, або залишаються задокументованими як такі, що перебувають поза стійкою гарантією.
• Резервна доставка обробляє кожне спроєктоване корисне навантаження, а не лише перше.
• Стійка резервна доставка записує весь масив спроєктованих корисних навантажень як один намір або пакетний план, який можна відтворити повторно.

• Доставка монітора iMessage записує надіслані повідомлення в кеш відлуння після успішного надсилання. Стійкі фінальні надсилання все одно мають заповнювати цей кеш, інакше OpenClaw може повторно приймати власні фінальні відповіді як вхідні повідомлення користувача.
• Tlon додає необов’язковий підпис моделі та записує потоки за участю після групових відповідей. Універсальна стійка доставка не повинна обходити ці ефекти; або перенесіть їх в адаптери рендерингу/надсилання/фіналізації Tlon, або залиште Tlon на шляху, що належить каналу.
• Discord та інші підготовлені диспетчери вже володіють прямою доставкою та поведінкою попереднього перегляду. На них не поширюється стійка гарантія зібраного ходу, доки їхні підготовлені диспетчери явно не маршрутизують фінальні повідомлення через контекст надсилання.
• Тиха резервна доставка Telegram має доставляти повний масив спроєктованих корисних навантажень. Скорочення до одного корисного навантаження може відкинути додаткові резервні корисні навантаження після проєкції.
• LINE, Zalo, Nostr та інші наявні зібрані/допоміжні шляхи можуть мати обробку токенів відповіді, проксіювання медіа, кеші надісланих повідомлень, очищення стану завантаження/статусу або цілі лише для callback. Вони залишаються на доставці, що належить каналу, доки ці семантики не будуть представлені адаптером надсилання й перевірені тестами.
• Допоміжні засоби прямих DM можуть мати callback відповіді, який є єдиною правильною ціллю транспорту. Універсальний вихідний потік не повинен вгадувати з OriginatingTo або To й пропускати цей callback.
• Вивід збоїв Gateway OpenClaw має залишатися видимим для людей, але позначені відлуння кімнати, створені ботом, потрібно відкидати до авторизації allowBots. Канали не повинні реалізовувати це за допомогою фільтрів префікса видимого тексту, окрім короткого аварійного запобіжника; стійкий контракт — це структуровані метадані походження.

​

Внутрішнє сховище

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

​

Класи збоїв

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

• Повторювати transient і rate_limit.
• Не повторювати invalid_payload, якщо немає резервного рендерингу.
• Не повторювати auth або permission, доки не зміниться конфігурація.
• Для not_found дозволити live-фіналізації повернутися з редагування до нового надсилання, коли канал оголошує це безпечним.
• Для conflict використовуйте правила квитанцій/idempotency, щоб вирішити, чи повідомлення вже існує.
• Будь-яка помилка після того, як адаптер міг завершити платформне I/O, але до фіксації квитанції, стає unknown_after_send, якщо адаптер не може довести, що платформна операція не відбулася.

​

Мапінг каналів

​

План міграції

​

Фаза 1: Внутрішній домен повідомлень

• Додайте типи src/channels/message/* для повідомлень, цілей, відношень, походжень, квитанцій, можливостей, стійких намірів, контексту отримання, контексту надсилання, live-контексту та класів збоїв.
• Додайте origin?: MessageOrigin до типу payload міграційного мосту, який використовується поточною доставкою відповідей, а потім перенесіть це поле до ChannelMessage і типів відрендерених повідомлень, коли рефакторинг замінить payload відповідей.
• Тримайте це внутрішнім, доки адаптери й тести не доведуть форму.
• Додайте чисті модульні тести для переходів стану та серіалізації.

​

Фаза 2: Ядро стійкого надсилання

• Перенесіть наявну вихідну чергу зі стійкості reply-payload до стійких намірів надсилання повідомлень.
• Дозвольте стійкому наміру надсилання переносити масив спроєктованих payload або план пакета, а не лише один reply payload.
• Збережіть поточну поведінку відновлення черги через конверсію сумісності.
• Зробіть так, щоб deliverOutboundPayloads викликав messages.send.
• Зробіть стійкість фінального надсилання типовою і відмовляйте закрито, коли стійкий намір не можна записати в новому життєвому циклі повідомлення, після того як адаптер оголосить безпечність повторного відтворення. Наявні шляхи сумісності channel-turn і SDK залишаються direct-send за замовчуванням протягом цієї фази.
• Послідовно записуйте квитанції.
• Повертайте квитанції та результати доставки початковому викликачеві диспетчера замість трактування стійкого надсилання як термінального побічного ефекту.
• Зберігайте походження повідомлення через стійкі наміри надсилання, щоб відновлення, повторне відтворення та фрагментовані надсилання зберігали операційне походження OpenClaw.

​

Фаза 3: Міст обороту каналу

• Повторно реалізуйте channel.turn.run і dispatchAssembledChannelTurn поверх messages.receive і messages.send.
• Збережіть поточні типи фактів стабільними.
• Збережіть за замовчуванням застарілу поведінку. Канал assembled-turn стає стійким лише тоді, коли його адаптер явно погоджується з replay-safe політикою стійкості.
• Збережіть durable: false як запасний шлях сумісності для шляхів, які фіналізують нативні редагування і ще не можуть безпечно відтворюватися повторно, але не покладайтеся на маркери false, щоб захищати немігрові канали.
• Умикайте типову стійкість assembled-turn лише в новому життєвому циклі повідомлень, після того як зіставлення каналу доведе, що загальний шлях надсилання зберігає стару семантику доставки каналу.

​

Фаза 4: Міст підготовленого диспетчера

• Замініть deliverDurableInboundReplyPayload мостом через контекст надсилання.
• Залиште старий допоміжний засіб як обгортку.
• Спершу перенесіть Telegram, WhatsApp, Slack, Signal, iMessage і Discord, тому що вони вже мають роботу зі стійким фіналом або простіші шляхи надсилання.
• Вважайте кожен підготовлений диспетчер непокритим, доки він явно не підключиться до контексту надсилання. Документація та записи журналу змін мають казати “зібрані оберти каналу” або називати перенесені шляхи каналів, а не заявляти про всі автоматичні фінальні відповіді.
• Збережіть поведінку recordInboundSessionAndDispatchReply, допоміжних засобів direct-DM та подібних публічних допоміжних засобів сумісності. Пізніше вони можуть надати явне підключення до контексту надсилання, але не повинні автоматично намагатися виконувати загальну стійку доставку перед callback доставки, яким володіє викликач.

​

Фаза 5: Уніфікований Життєвий Цикл Live

• Побудуйте messages.live з двома адаптерами доказу:
  • Telegram для надсилання плюс редагування плюс надсилання застарілого фіналу.
  • Matrix для фіналізації чернетки плюс резервне редагування.
• Потім перенесіть Discord, Slack, Mattermost, Teams, QQ Bot і Feishu.
• Видаляйте дубльований код фіналізації попереднього перегляду лише після того, як кожен канал матиме тести паритету.

​

Фаза 6: Публічний SDK

• Додайте openclaw/plugin-sdk/channel-message.
• Задокументуйте його як бажаний API Plugin каналу.
• Оновіть експорти пакета, інвентар entrypoint, згенеровані базові лінії API та документацію SDK Plugin.
• Включіть MessageOrigin, хуки кодування/декодування origin і спільний предикат shouldDropOpenClawEcho до поверхні SDK channel-message.
• Збережіть обгортки сумісності для старих підшляхів.
• Позначте допоміжні засоби SDK з назвами reply як застарілі в документації після перенесення вбудованих plugins.

​

Фаза 7: Усі Відправники

• сповіщення cron і Heartbeat
• завершення завдань
• результати hook
• запити на схвалення та результати схвалення
• надсилання через інструмент повідомлень
• оголошення про завершення subagent
• явні надсилання CLI або Control UI
• шляхи автоматизації/трансляції

​

Фаза 8: Виведення Turn з ужитку

• Залиште channel.turn як обгортку принаймні на одне вікно сумісності.
• Опублікуйте нотатки міграції.
• Запустіть тести сумісності SDK Plugin зі старими імпортами.
• Видаляйте або приховуйте старі внутрішні допоміжні засоби лише після того, як жоден вбудований plugin їх більше не потребуватиме, а сторонні контракти матимуть стабільну заміну.

​

План тестування

• Серіалізація та відновлення стійкого наміру надсилання.
• Повторне використання ключа ідемпотентності та придушення дублікатів.
• Commit квитанції та пропуск replay.
• Відновлення unknown_after_send, яке узгоджує перед replay, коли адаптер підтримує узгодження.
• Політика класифікації відмов.
• Послідовність політики ack приймання.
• Мапінг зв’язків для надсилань reply, followup, system і broadcast.
• Фабрика origin для відмов Gateway та предикат shouldDropOpenClawEcho.
• Збереження origin через нормалізацію payload, chunking, серіалізацію стійкої черги та відновлення.

• Простий адаптер channel.turn.run усе ще записує та надсилає.
• Доставка застарілого зібраного оберту не стає стійкою, якщо канал явно не підключився.
• Міст channel.turn.runPrepared усе ще записує та фіналізує.
• Публічні допоміжні засоби сумісності типово викликають callback доставки, яким володіє викликач, і не виконують загальне надсилання перед цими callback.
• Стійка резервна доставка відтворює весь спроєктований масив payload після перезапуску і не може залишити пізніші payload незаписаними після раннього збою.
• Стійка доставка зібраного оберту повертає ідентифікатори повідомлень платформи до буферизованого диспетчера.
• Користувацькі hook доставки все ще повертають ідентифікатори повідомлень платформи, коли стійку доставку вимкнено або вона недоступна.
• Фінальна відповідь переживає перезапуск між завершенням асистента та надсиланням на платформу.
• Чернетка попереднього перегляду фіналізується на місці, коли це дозволено.
• Чернетка попереднього перегляду скасовується або редагується, коли медіа/помилка/невідповідність цілі відповіді потребує звичайної доставки.
• Потокове передавання блоків і потокове передавання попереднього перегляду не доставляють той самий текст обидва.
• Медіа, передане потоково раніше, не дублюється у фінальній доставці.

• Відповідь у темі Telegram з ack polling, затриманим до безпечної завершеної watermark контексту приймання.
• Відновлення polling Telegram для прийнятих, але не доставлених оновлень, покрите збереженою моделлю safe-completed offset.
• Застарілий попередній перегляд Telegram надсилає свіжий фінал і прибирає попередній перегляд.
• Тихий резерв Telegram надсилає кожен спроєктований резервний payload.
• Стійкість тихого резерву Telegram атомарно записує повний спроєктований резервний масив, а не один стійкий намір з одиночним payload на кожну ітерацію циклу.
• Скасування попереднього перегляду Discord у разі медіа/помилки/явної відповіді.
• Фінали підготовленого диспетчера Discord маршрутизуються через контекст надсилання до того, як документація або журнал змін заявлять про стійкість фінальних відповідей Discord.
• Стійкі фінальні надсилання iMessage заповнюють кеш echo надісланих повідомлень монітора.
• Застарілі шляхи доставки LINE, Zalo і Nostr не обходяться загальним стійким надсиланням, доки не існують тести паритету їхнього адаптера.
• Доставка callback Direct-DM/Nostr лишається авторитетною, якщо її явно не перенесено на повну ціль повідомлення та replay-безпечний адаптер надсилання.
• Позначені Slack повідомлення про відмову Gateway OpenClaw лишаються видимими назовні, позначені echo bot-room відкидаються перед allowBots, а непозначені повідомлення bot з тим самим видимим текстом усе ще проходять звичайну авторизацію bot.
• Резервний варіант нативного потоку Slack до чернетки попереднього перегляду в DMs верхнього рівня.
• Фіналізація попереднього перегляду Matrix і резервне редагування.
• Позначені Matrix echo кімнати про gateway-failure OpenClaw від налаштованих облікових записів bot відкидаються перед обробкою allowBots.
• Аудити cascade gateway-failure у спільних кімнатах Discord і Google Chat покривають режими allowBots перед заявами про загальний захист там.
• Фіналізація чернетки Mattermost і резервне надсилання свіжого повідомлення.
• Фіналізація нативного прогресу Teams.
• Придушення дубльованого фіналу Feishu.
• Резерв accumulator timeout QQ Bot.
• Стійкі фінальні надсилання Tlon зберігають рендеринг model-signature і відстеження потоків, у яких була участь.
• Прості стійкі фінальні надсилання WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo і Zalo Personal.

• Цільові файли Vitest під час розробки.
• pnpm check:changed у Testbox для всієї зміненої поверхні.
• Ширший pnpm check у Testbox перед landing повного рефакторингу або після змін публічного SDK/export.
• Live або qa-channel smoke принаймні для одного каналу з можливістю редагування та одного простого каналу лише з надсиланням перед видаленням обгорток сумісності.

​

Відкриті питання

• Чи має Telegram зрештою замінити джерело runner grammY на повністю стійке джерело polling, яке може контролювати повторну доставку на рівні платформи, а не лише збережену watermark перезапуску OpenClaw.
• Чи слід зберігати стан стійкого live preview у тому самому записі черги, що й фінальний намір надсилання, або в сусідньому сховищі live-state.
• Як довго обгортки сумісності лишаються задокументованими після випуску plugin-sdk/channel-message.
• Чи повинні сторонні plugins реалізовувати адаптери приймання напряму, чи лише надавати hooks normalize/send/live через defineChannelMessageAdapter.
• Які поля квитанцій безпечно відкривати в публічному SDK, а які належать до внутрішнього runtime state.
• Чи слід моделювати побічні ефекти, як-от кеші self-echo і маркери participated-thread, як hook контексту надсилання, кроки finalize, якими володіє адаптер, або підписників на квитанції.
• Які канали мають нативні metadata origin, які потребують збережених вихідних реєстрів, а які не можуть забезпечити надійне придушення echo між bot.

​

Критерії прийняття

• Кожен вбудований канал повідомлень надсилає фінальний видимий вивід через messages.send.
• Кожен вхідний канал повідомлень входить через messages.receive або задокументовану обгортку сумісності.
• Кожен канал попереднього перегляду/редагування/потоку використовує messages.live для стану чернетки та фіналізації.
• channel.turn є лише обгорткою.
• Допоміжні засоби SDK з назвами reply є експортами сумісності, а не рекомендованим шляхом.
• Стійке відновлення може відтворювати очікувані фінальні надсилання після перезапуску без втрати фінальної відповіді або дублювання вже commit надсилань; надсилання, чий результат на платформі невідомий, узгоджуються перед replay або документуються як at-least-once для цього адаптера.
• Стійкі фінальні надсилання fail closed, коли стійкий намір неможливо записати, якщо тільки викликач явно не вибрав задокументований нестійкий режим.
• Застарілі channel-turn і допоміжні засоби сумісності SDK типово використовують пряму доставку, якою володіє канал; загальне стійке надсилання є лише явним opt-in.
• Квитанції зберігають усі ідентифікатори повідомлень платформи для багаточастинних доставок і первинний ідентифікатор для зручності threading/edit.
• Стійкі обгортки зберігають локальні для каналу побічні ефекти перед заміною прямих callback доставки.
• Підготовлені диспетчери не вважаються стійкими, доки їхній фінальний шлях доставки явно не використовує контекст надсилання.
• Резервна доставка обробляє кожен спроєктований payload.
• Стійка резервна доставка записує кожен спроєктований payload в один replay-able намір або пакетний план.
• Вивід про відмову Gateway, створений OpenClaw, видимий для людей, але позначені echo кімнати, автором яких є bot, відкидаються перед авторизацією bot на каналах, що оголошують підтримку контракту origin.
• Документація пояснює надсилання, приймання, live, state, квитанції, зв’язки, політику відмов, міграцію та тестове покриття.

​

Пов’язане

• Повідомлення
• Streaming і chunking
• Чернетки прогресу
• Політика повторних спроб
• Ядро оберту каналу