Refaktor siklus hidup pesan

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.

• Primitif inti harus berupa terima dan kirim, bukan balas.
• Balasan hanya merupakan relasi pada pesan keluar.
• Giliran adalah kemudahan pemrosesan masuk, bukan pemilik pengiriman.
• Pengiriman harus berbasis konteks: begin, render, pratinjau atau stream, kirim akhir, commit, gagal.
• Penerimaan juga harus berbasis konteks: normalisasi, dedupe, route, catat, dispatch, ack platform, gagal.
• SDK Plugin publik harus diringkas menjadi satu permukaan kecil untuk pesan channel.

​

Masalah

• Adapter masuk sederhana menggunakan runtime.channel.turn.run.
• Adapter kaya menggunakan runtime.channel.turn.runPrepared.
• Helper lama menggunakan dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, helper payload balasan, pemotongan balasan, referensi balasan, dan helper runtime keluar.
• Streaming pratinjau berada di dispatcher khusus channel.
• Durabilitas pengiriman akhir sedang ditambahkan di sekitar path payload balasan yang ada.

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

​

Tujuan

• Satu siklus hidup core untuk semua path terima dan kirim pesan channel.
• Pengiriman akhir yang tahan lama secara default dalam siklus hidup pesan baru setelah adapter mendeklarasikan perilaku yang aman untuk replay.
• Semantik pratinjau, edit, stream, finalisasi, retry, pemulihan, dan receipt bersama.
• Permukaan SDK Plugin kecil yang dapat dipelajari dan dipelihara oleh Plugin pihak ketiga.
• Kompatibilitas untuk pemanggil channel.turn yang ada selama migrasi.
• Titik ekstensi yang jelas untuk kapabilitas channel baru.
• Tidak ada cabang khusus platform di core.
• Tidak ada pesan channel token-delta. Streaming channel tetap berupa pratinjau pesan, edit, append, atau pengiriman blok selesai.
• Metadata asal OpenClaw terstruktur untuk output operasional/sistem agar kegagalan Gateway yang terlihat tidak masuk kembali ke ruang bersama yang mengaktifkan bot sebagai prompt baru.

​

Bukan tujuan

• Jangan hapus runtime.channel.turn.* pada fase pertama.
• Jangan paksa setiap channel ke perilaku transport native yang sama.
• Jangan ajarkan core topik Telegram, stream native Slack, redaksi Matrix, kartu Feishu, suara QQ, atau aktivitas Teams.
• Jangan publikasikan semua helper migrasi internal sebagai API SDK stabil.
• Jangan buat retry me-replay operasi platform non-idempoten yang sudah selesai.

​

Model referensi

• Chat
• Thread
• Channel
• Message
• metode adapter seperti postMessage, editMessage, deleteMessage, stream, startTyping, dan pengambilan riwayat
• adapter status untuk dedupe, lock, antrean, dan persistensi

• Intent pengiriman keluar yang tahan lama sebelum panggilan transport langsung.
• Konteks pengiriman eksplisit dengan begin, commit, dan fail.
• Konteks penerimaan yang mengetahui kebijakan ack platform.
• Receipt yang bertahan setelah restart dan dapat mendorong edit, hapus, pemulihan, dan penekanan duplikat.
• SDK publik yang lebih kecil. Plugin bawaan dapat menggunakan helper runtime internal, tetapi Plugin pihak ketiga harus melihat satu API pesan yang koheren.
• Perilaku khusus agen: sesi, transkrip, streaming blok, progres tool, approval, direktif media, balasan senyap, dan riwayat mention grup.

​

Model core

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

​

Istilah pesan

​

Pesan

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

​

Target

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

​

Relasi

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

​

Asal

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

​

Receipt

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

​

Konteks penerimaan

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

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

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

• Ack transport: memberi tahu webhook atau socket platform bahwa OpenClaw menerima envelope event. Beberapa platform mewajibkan ini sebelum dispatch.
• Ack offset polling: memajukan cursor agar event yang sama tidak diambil lagi. Ini tidak boleh melewati pekerjaan yang tidak dapat dipulihkan.
• Ack record masuk: mengonfirmasi OpenClaw telah mempersistensikan metadata masuk yang cukup untuk dedupe dan route redelivery.
• Receipt yang terlihat pengguna: perilaku baca/status/typing opsional; tidak pernah menjadi batas durabilitas.

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

​

Konteks pengiriman

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

​

Konteks live

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

• Pengiriman Telegram plus pratinjau edit, dengan final baru setelah usia pratinjau basi.
• Pengiriman Discord plus pratinjau edit, batal pada media/error/balasan eksplisit.
• Stream native Slack atau pratinjau draf bergantung pada bentuk thread.
• Finalisasi posting draf Mattermost.
• Finalisasi event draf Matrix atau redaksi saat tidak cocok.
• Stream progres native Teams.
• Stream QQ Bot atau fallback terakumulasi.

​

Permukaan adaptor

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

​

Pengurangan SDK publik

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• sebagian besar penggunaan publik outbound-runtime
• pembantu siklus hidup stream draf ad hoc

​

Hubungan dengan giliran kanal

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

​

Guardrail kompatibilitas

• channel.turn.run dan dispatchAssembledChannelTurn menggunakan callback pengiriman kanal kecuali kanal tersebut secara eksplisit menyediakan objek kebijakan/opsi tahan lama yang telah diaudit.
• channel.turn.runPrepared tetap dimiliki kanal sampai dispatcher yang disiapkan secara eksplisit memanggil konteks pengiriman.
• Pembantu kompatibilitas publik seperti recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase, dan pembantu direct-DM tidak pernah menyuntikkan pengiriman tahan lama generik sebelum callback deliver atau reply yang disediakan pemanggil.

• Pengiriman final persisten mengembalikan status terdiskriminasi. handled_visible dan handled_no_send bersifat terminal; unsupported dan not_applicable dapat fallback ke pengiriman yang dimiliki saluran; failed meneruskan kegagalan pengiriman.
• Pengiriman final persisten generik dibatasi oleh kapabilitas adaptor seperti pengiriman senyap, pelestarian target balasan, pelestarian kutipan native, dan hook pengiriman pesan. Paritas yang hilang harus memilih pengiriman yang dimiliki saluran, bukan pengiriman generik yang mengubah perilaku yang terlihat oleh pengguna.
• Pengiriman persisten berbasis antrean mengekspos referensi intent pengiriman. Kolom sesi pendingFinalDelivery* yang sudah ada dapat membawa id intent selama transisi; keadaan akhirnya adalah penyimpanan MessageSendIntent, bukan teks balasan beku plus kolom konteks ad hoc.

• Adaptor pengiriman generik menjalankan perilaku rendering dan transport yang sama seperti jalur langsung lama.
• Efek samping lokal pasca-pengiriman dipertahankan melalui konteks pengiriman.
• Adaptor mengembalikan tanda terima atau hasil pengiriman dengan semua id pesan platform.
• Jalur dispatcher yang disiapkan memanggil konteks pengiriman baru atau tetap didokumentasikan sebagai di luar jaminan persisten.
• Pengiriman fallback menangani setiap payload terproyeksi, bukan hanya yang pertama.
• Pengiriman fallback persisten mencatat seluruh array payload terproyeksi sebagai satu intent atau rencana batch yang dapat diputar ulang.

• Pengiriman monitor iMessage mencatat pesan terkirim dalam cache echo setelah pengiriman berhasil. Pengiriman final persisten tetap harus mengisi cache itu, jika tidak OpenClaw dapat menyerap ulang balasan finalnya sendiri sebagai pesan pengguna masuk.
• Tlon menambahkan tanda tangan model opsional dan mencatat thread yang diikuti setelah balasan grup. Pengiriman persisten generik tidak boleh melewati efek tersebut; pindahkan efek itu ke adaptor render/send/finalize Tlon atau pertahankan Tlon di jalur yang dimiliki saluran.
• Discord dan dispatcher lain yang disiapkan sudah memiliki perilaku pengiriman langsung dan pratinjau. Mereka tidak tercakup oleh jaminan persisten untuk giliran yang dirakit sampai dispatcher yang disiapkan secara eksplisit merutekan final melalui konteks pengiriman.
• Pengiriman fallback senyap Telegram harus mengirimkan seluruh array payload terproyeksi. Pintasan satu payload dapat menjatuhkan payload fallback tambahan setelah proyeksi.
• LINE, Zalo, Nostr, dan jalur rakitan/pembantu lain yang sudah ada mungkin memiliki penanganan token balasan, proxy media, cache pesan terkirim, pembersihan loading/status, atau target khusus callback. Semua itu tetap berada pada pengiriman yang dimiliki saluran sampai semantik tersebut direpresentasikan oleh adaptor pengiriman dan diverifikasi oleh pengujian.
• Pembantu DM langsung dapat memiliki callback balasan yang merupakan satu-satunya target transport yang benar. Outbound generik tidak boleh menebak dari OriginatingTo atau To dan melewati callback tersebut.
• Keluaran kegagalan Gateway OpenClaw harus tetap terlihat oleh manusia, tetapi echo ruang bertag yang dibuat bot harus dibuang sebelum otorisasi allowBots. Saluran tidak boleh mengimplementasikan ini dengan filter prefiks teks terlihat kecuali sebagai penghenti darurat singkat; kontrak persisten adalah metadata asal terstruktur.

​

Penyimpanan internal

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

​

Kelas kegagalan

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

• Coba ulang transient dan rate_limit.
• Jangan coba ulang invalid_payload kecuali ada fallback render.
• Jangan coba ulang auth atau permission sampai konfigurasi berubah.
• Untuk not_found, izinkan finalisasi langsung fallback dari edit ke pengiriman baru saat saluran menyatakan itu aman.
• Untuk conflict, gunakan aturan tanda terima/idempotensi untuk memutuskan apakah pesan sudah ada.
• Kesalahan apa pun setelah adaptor mungkin telah menyelesaikan I/O platform tetapi sebelum commit tanda terima menjadi unknown_after_send kecuali adaptor dapat membuktikan operasi platform tidak terjadi.

​

Pemetaan saluran

​

Rencana migrasi

​

Fase 1: Domain Pesan Internal

• Tambahkan tipe src/channels/message/* untuk pesan, target, relasi, asal, tanda terima, kapabilitas, intent tahan lama, konteks penerimaan, konteks pengiriman, konteks live, dan kelas kegagalan.
• Tambahkan origin?: MessageOrigin ke tipe payload bridge migrasi yang digunakan oleh pengiriman balasan saat ini, lalu pindahkan field itu ke ChannelMessage dan tipe pesan yang dirender saat refactor menggantikan payload balasan.
• Biarkan ini tetap internal sampai adapter dan pengujian membuktikan bentuknya.
• Tambahkan pengujian unit murni untuk transisi state dan serialisasi.

​

Fase 2: Core Pengiriman Tahan Lama

• Pindahkan antrean keluar yang ada dari durabilitas reply-payload ke intent pengiriman pesan tahan lama.
• Izinkan intent pengiriman tahan lama membawa array payload terproyeksi atau rencana batch, bukan hanya satu payload balasan.
• Pertahankan perilaku pemulihan antrean saat ini melalui konversi kompatibilitas.
• Buat deliverOutboundPayloads memanggil messages.send.
• Jadikan durabilitas pengiriman final sebagai default dan gagal tertutup saat intent tahan lama tidak dapat ditulis dalam siklus hidup pesan baru, setelah adapter mendeklarasikan keamanan replay. Jalur kompatibilitas channel-turn dan SDK yang sudah ada tetap direct-send secara default selama fase ini.
• Catat tanda terima secara konsisten.
• Kembalikan tanda terima dan hasil pengiriman ke pemanggil dispatcher asli, alih-alih memperlakukan pengiriman tahan lama sebagai efek samping terminal.
• Persistenkan asal pesan melalui intent pengiriman tahan lama agar pemulihan, replay, dan pengiriman terpotong mempertahankan provenance operasional OpenClaw.

​

Fase 3: Bridge Channel Turn

• Implementasikan ulang channel.turn.run dan dispatchAssembledChannelTurn di atas messages.receive dan messages.send.
• Pertahankan tipe fakta saat ini tetap stabil.
• Pertahankan perilaku legacy secara default. Channel assembled-turn menjadi tahan lama hanya saat adapternya secara eksplisit ikut serta dengan kebijakan durabilitas yang aman replay.
• Pertahankan durable: false sebagai escape hatch kompatibilitas untuk jalur yang memfinalisasi edit native dan belum dapat replay dengan aman, tetapi jangan mengandalkan marker false untuk melindungi channel yang belum dimigrasikan.
• Jadikan durabilitas assembled-turn default hanya dalam siklus hidup pesan baru, setelah pemetaan channel membuktikan bahwa jalur pengiriman generik mempertahankan semantik pengiriman channel lama.

​

Fase 4: Bridge Dispatcher yang Disiapkan

• Ganti deliverDurableInboundReplyPayload dengan jembatan konteks pengiriman.
• Pertahankan helper lama sebagai wrapper.
• Porting Telegram, WhatsApp, Slack, Signal, iMessage, dan Discord terlebih dahulu karena semuanya sudah memiliki pekerjaan final-tahan-lama atau jalur pengiriman yang lebih sederhana.
• Perlakukan setiap dispatcher yang disiapkan sebagai belum tercakup sampai secara eksplisit ikut serta dalam konteks pengiriman. Dokumentasi dan entri changelog harus mengatakan “turn saluran yang dirakit” atau menyebut jalur saluran yang dimigrasikan alih-alih mengklaim semua balasan final otomatis.
• Pertahankan perilaku recordInboundSessionAndDispatchReply, helper direct-DM, dan helper kompatibilitas publik serupa. Helper tersebut dapat mengekspos ikut serta konteks pengiriman secara eksplisit nanti, tetapi tidak boleh secara otomatis mencoba pengiriman tahan-lama generik sebelum callback pengiriman milik pemanggil.

​

Fase 5: Siklus Hidup Live Terpadu

• Bangun messages.live dengan dua adapter pembuktian:
  • Telegram untuk kirim plus edit plus kirim final basi.
  • Matrix untuk finalisasi draf plus fallback redaksi.
• Lalu migrasikan Discord, Slack, Mattermost, Teams, QQ Bot, dan Feishu.
• Hapus kode finalisasi pratinjau yang terduplikasi hanya setelah setiap saluran memiliki pengujian paritas.

​

Fase 6: SDK Publik

• Tambahkan openclaw/plugin-sdk/channel-message.
• Dokumentasikan sebagai API Plugin saluran yang disukai.
• Perbarui ekspor paket, inventaris entrypoint, baseline API yang dihasilkan, dan dokumentasi SDK Plugin.
• Sertakan MessageOrigin, hook encode/decode origin, dan predikat bersama shouldDropOpenClawEcho di permukaan SDK channel-message.
• Pertahankan wrapper kompatibilitas untuk subpath lama.
• Tandai helper SDK bernama reply sebagai usang dalam dokumentasi setelah Plugin bawaan dimigrasikan.

​

Fase 7: Semua Pengirim

• notifikasi Cron dan Heartbeat
• penyelesaian tugas
• hasil hook
• prompt persetujuan dan hasil persetujuan
• pengiriman message tool
• pengumuman penyelesaian subagent
• pengiriman CLI atau UI Kontrol eksplisit
• jalur otomatisasi/broadcast

​

Fase 8: Depresiasi Turn

• Pertahankan channel.turn sebagai wrapper untuk setidaknya satu jendela kompatibilitas.
• Publikasikan catatan migrasi.
• Jalankan pengujian kompatibilitas SDK Plugin terhadap impor lama.
• Hapus atau sembunyikan helper internal lama hanya setelah tidak ada Plugin bawaan yang membutuhkannya dan kontrak pihak ketiga memiliki pengganti yang stabil.

​

Rencana pengujian

• Serialisasi dan pemulihan intent pengiriman tahan-lama.
• Penggunaan ulang kunci idempotensi dan penekanan duplikat.
• Commit receipt dan lewati replay.
• Pemulihan unknown_after_send yang merekonsiliasi sebelum replay saat sebuah adapter mendukung rekonsiliasi.
• Kebijakan klasifikasi kegagalan.
• Urutan kebijakan ack terima.
• Pemetaan relasi untuk pengiriman reply, followup, system, dan broadcast.
• Factory origin kegagalan Gateway dan predikat shouldDropOpenClawEcho.
• Pelestarian origin melalui normalisasi payload, chunking, serialisasi antrean tahan-lama, dan pemulihan.

• Adapter sederhana channel.turn.run tetap mencatat dan mengirim.
• Pengiriman assembled-turn lama tidak menjadi tahan-lama kecuali saluran secara eksplisit ikut serta.
• Jembatan channel.turn.runPrepared tetap mencatat dan memfinalisasi.
• Helper kompatibilitas publik memanggil callback pengiriman milik pemanggil secara default dan tidak melakukan generic-send sebelum callback tersebut.
• Pengiriman fallback tahan-lama memutar ulang seluruh array payload yang diproyeksikan setelah restart dan tidak dapat membuat payload berikutnya tidak tercatat setelah crash awal.
• Pengiriman assembled-turn tahan-lama mengembalikan id pesan platform ke dispatcher buffered.
• Hook pengiriman kustom tetap mengembalikan id pesan platform saat pengiriman tahan-lama dinonaktifkan atau tidak tersedia.
• Balasan final bertahan dari restart antara penyelesaian asisten dan pengiriman platform.
• Draf pratinjau difinalisasi di tempat saat diizinkan.
• Draf pratinjau dibatalkan atau direduksi saat ketidakcocokan media/error/target-reply memerlukan pengiriman normal.
• Streaming blok dan streaming pratinjau tidak sama-sama mengirim teks yang sama.
• Media yang di-stream lebih awal tidak diduplikasi dalam pengiriman final.

• Reply topik Telegram dengan ack polling ditunda sampai watermark completed aman milik konteks penerimaan.
• Pemulihan polling Telegram untuk update yang diterima-tetapi-belum-terkirim tercakup oleh model offset safe-completed yang dipersistenkan.
• Pratinjau basi Telegram mengirim final baru dan membersihkan pratinjau.
• Fallback senyap Telegram mengirim setiap payload fallback yang diproyeksikan.
• Durabilitas fallback senyap Telegram mencatat seluruh array fallback yang diproyeksikan secara atomik, bukan satu intent tahan-lama payload-tunggal per iterasi loop.
• Pembatalan pratinjau Discord pada media/error/reply eksplisit.
• Final dispatcher siap pakai Discord dirutekan melalui konteks pengiriman sebelum dokumentasi atau changelog mengklaim durabilitas final-reply Discord.
• Pengiriman final tahan-lama iMessage mengisi cache echo pesan terkirim monitor.
• Jalur pengiriman lama LINE, Zalo, dan Nostr tidak dilewati oleh pengiriman tahan-lama generik sampai pengujian paritas adapternya ada.
• Pengiriman callback Direct-DM/Nostr tetap otoritatif kecuali dimigrasikan secara eksplisit ke target pesan lengkap dan adapter pengiriman yang aman untuk replay.
• Pesan kegagalan Gateway OpenClaw bertag Slack tetap terlihat outbound, echo ruang bot bertag turun sebelum allowBots, dan pesan bot tanpa tag dengan teks terlihat yang sama tetap mengikuti otorisasi bot normal.
• Fallback stream native Slack ke pratinjau draf dalam DM tingkat atas.
• Finalisasi pratinjau Matrix dan fallback redaksi.
• Echo ruang kegagalan Gateway OpenClaw bertag Matrix dari akun bot yang dikonfigurasi turun sebelum penanganan allowBots.
• Audit cascade kegagalan Gateway ruang bersama Discord dan Google Chat mencakup mode allowBots sebelum mengklaim perlindungan generik di sana.
• Finalisasi draf Mattermost dan fallback kirim-baru.
• Finalisasi progres native Teams.
• Penekanan final duplikat Feishu.
• Fallback timeout akumulator QQ Bot.
• Pengiriman final tahan-lama Tlon mempertahankan rendering tanda tangan model dan pelacakan thread yang diikuti.
• Pengiriman final tahan-lama sederhana WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo, dan Zalo Personal.

• File Vitest tertarget selama pengembangan.
• pnpm check:changed di Testbox untuk seluruh permukaan yang berubah.
• pnpm check yang lebih luas di Testbox sebelum mendaratkan refactor lengkap atau setelah perubahan SDK/ekspor publik.
• Smoke live atau qa-channel untuk setidaknya satu saluran berkemampuan edit dan satu saluran sederhana hanya-kirim sebelum menghapus wrapper kompatibilitas.

​

Pertanyaan terbuka

• Apakah Telegram pada akhirnya harus mengganti sumber runner grammY dengan sumber polling yang sepenuhnya tahan-lama yang dapat mengendalikan redelivery tingkat platform, bukan hanya watermark restart yang dipersistenkan milik OpenClaw.
• Apakah status pratinjau live tahan-lama harus disimpan dalam record antrean yang sama dengan intent pengiriman final atau dalam penyimpanan status live saudara.
• Berapa lama wrapper kompatibilitas tetap terdokumentasi setelah plugin-sdk/channel-message dirilis.
• Apakah Plugin pihak ketiga harus mengimplementasikan adapter receive secara langsung atau hanya menyediakan hook normalize/send/live melalui defineChannelMessageAdapter.
• Field receipt mana yang aman diekspos di SDK publik versus status runtime internal.
• Apakah efek samping seperti cache self-echo dan penanda participated-thread harus dimodelkan sebagai hook konteks pengiriman, langkah finalize milik adapter, atau subscriber receipt.
• Saluran mana yang memiliki metadata origin native, mana yang memerlukan registry outbound yang dipersistenkan, dan mana yang tidak dapat menawarkan penekanan echo lintas-bot yang andal.

​

Kriteria penerimaan

• Setiap saluran pesan bawaan mengirim output final yang terlihat melalui messages.send.
• Setiap saluran pesan inbound masuk melalui messages.receive atau wrapper kompatibilitas terdokumentasi.
• Setiap saluran pratinjau/edit/stream menggunakan messages.live untuk status draf dan finalisasi.
• channel.turn hanya sebuah wrapper.
• Helper SDK bernama reply adalah ekspor kompatibilitas, bukan jalur yang direkomendasikan.
• Pemulihan tahan-lama dapat memutar ulang pengiriman final tertunda setelah restart tanpa kehilangan respons final atau menduplikasi pengiriman yang sudah di-commit; pengiriman yang hasil platformnya tidak diketahui direkonsiliasi sebelum replay atau didokumentasikan sebagai at-least-once untuk adapter tersebut.
• Pengiriman final tahan-lama fail closed saat intent tahan-lama tidak dapat ditulis, kecuali pemanggil secara eksplisit memilih mode non-tahan-lama yang terdokumentasi.
• Helper kompatibilitas channel-turn dan SDK lama default ke pengiriman langsung milik saluran; pengiriman tahan-lama generik hanya ikut serta eksplisit.
• Receipt mempertahankan semua id pesan platform untuk pengiriman multi-bagian dan id utama untuk kemudahan threading/edit.
• Wrapper tahan-lama mempertahankan efek samping lokal saluran sebelum mengganti callback pengiriman langsung.
• Dispatcher siap pakai tidak dihitung tahan-lama sampai jalur pengiriman finalnya secara eksplisit menggunakan konteks pengiriman.
• Pengiriman fallback menangani setiap payload yang diproyeksikan.
• Pengiriman fallback tahan-lama mencatat setiap payload yang diproyeksikan dalam satu intent atau rencana batch yang dapat di-replay.
• Output kegagalan Gateway yang berasal dari OpenClaw terlihat oleh manusia tetapi echo ruang yang dibuat bot dan bertag dibuang sebelum otorisasi bot pada saluran yang menyatakan dukungan untuk kontrak origin.
• Dokumentasi menjelaskan pengiriman, penerimaan, live, status, receipt, relasi, kebijakan kegagalan, migrasi, dan cakupan pengujian.

​

Terkait

• Pesan
• Streaming dan chunking
• Draf progres
• Kebijakan retry
• Kernel turn saluran