Refaktor siklus hidup pesan

Documentation Index

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

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

• Primitif inti seharusnya terima dan kirim, bukan balas.
• Balasan hanyalah relasi pada pesan outbound.
• Turn adalah kemudahan pemrosesan inbound, bukan pemilik pengiriman.
• Pengiriman harus berbasis konteks: begin, render, pratinjau atau stream, kirim final, commit, gagal.
• Penerimaan juga harus berbasis konteks: normalisasi, dedupe, route, catat, dispatch, ack platform, gagal.
• SDK Plugin publik seharusnya diringkas menjadi satu permukaan channel-message kecil.

​

Masalah

• Adapter inbound sederhana menggunakan runtime.channel.turn.run.
• Adapter kaya menggunakan runtime.channel.turn.runPrepared.
• Helper lama menggunakan dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, helper payload balasan, chunking balasan, referensi balasan, dan helper runtime outbound.
• Streaming pratinjau berada di dispatcher khusus channel.
• Ketahanan pengiriman final 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 lifecycle inti untuk semua path terima dan kirim pesan channel.
• Pengiriman final durable secara default di lifecycle pesan baru setelah adapter menyatakan perilaku replay-safe.
• Semantik pratinjau, edit, stream, finalisasi, retry, pemulihan, dan receipt bersama.
• Permukaan SDK Plugin kecil yang dapat dipelajari dan dipelihara Plugin pihak ketiga.
• Kompatibilitas untuk pemanggil channel.turn yang ada selama migrasi.
• Titik ekstensi yang jelas untuk kemampuan 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 yang terstruktur untuk output operasional/sistem agar kegagalan gateway yang terlihat tidak masuk kembali ke room 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 ajari 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 memutar ulang operasi platform non-idempotent yang sudah selesai.

​

Model referensi

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

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

​

Model inti

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 maju melewati pekerjaan yang tidak dapat dipulihkan.
• Ack catatan inbound: mengonfirmasi OpenClaw telah mempersistensikan metadata inbound yang cukup untuk dedupe dan route redelivery.
• Receipt terlihat pengguna: perilaku baca/status/typing opsional; tidak pernah menjadi batas durability.

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

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

​

Permukaan adapter

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
• helper siklus hidup stream draf ad hoc

​

Hubungan dengan 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

​

Guardrail kompatibilitas

• channel.turn.run dan dispatchAssembledChannelTurn menggunakan callback pengiriman channel kecuali channel tersebut secara eksplisit menyediakan objek kebijakan/opsi durable yang telah diaudit.
• channel.turn.runPrepared tetap dimiliki channel sampai dispatcher prepared secara eksplisit memanggil konteks pengiriman.
• Helper kompatibilitas publik seperti recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase, dan helper direct-DM tidak pernah menyuntikkan pengiriman generik durable 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 digerbangi 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 pengguna.
• Pengiriman persisten yang didukung antrean mengekspos referensi intensi pengiriman. Field sesi pendingFinalDelivery* yang ada dapat membawa id intensi selama transisi; keadaan akhirnya adalah penyimpanan MessageSendIntent, bukan teks balasan beku ditambah field konteks ad hoc.

• Adaptor pengiriman generik menjalankan perilaku rendering dan transport yang sama dengan jalur langsung lama.
• Efek samping lokal setelah 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 terdokumentasi sebagai berada di luar jaminan persisten.
• Pengiriman fallback menangani setiap payload terproyeksi, bukan hanya yang pertama.
• Pengiriman fallback persisten merekam seluruh array payload terproyeksi sebagai satu intensi atau rencana batch yang dapat diputar ulang.

• Pengiriman monitor iMessage merekam pesan terkirim dalam cache gema setelah pengiriman berhasil. Pengiriman final persisten tetap harus mengisi cache itu, jika tidak OpenClaw dapat menelan ulang balasan finalnya sendiri sebagai pesan pengguna masuk.
• Tlon menambahkan tanda tangan model opsional dan merekam thread yang diikuti setelah balasan grup. Pengiriman persisten generik tidak boleh melewati efek tersebut; pindahkan efek itu ke adaptor render/kirim/finalisasi Tlon atau pertahankan Tlon pada jalur yang dimiliki saluran.
• Discord dan dispatcher lain yang disiapkan sudah memiliki perilaku pengiriman langsung dan pratinjau sendiri. Mereka tidak tercakup oleh jaminan persisten giliran-terakit 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 membuang payload fallback tambahan setelah proyeksi.
• LINE, BlueBubbles, Zalo, Nostr, dan jalur terakit/helper lain yang ada mungkin memiliki penanganan token balasan, proxy media, cache pesan terkirim, pembersihan pemuatan/status, atau target hanya-callback. Jalur-jalur itu tetap pada pengiriman yang dimiliki saluran sampai semantik tersebut direpresentasikan oleh adaptor pengiriman dan diverifikasi oleh pengujian.
• Helper 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.
• Output kegagalan Gateway OpenClaw harus tetap terlihat oleh manusia, tetapi gema ruang yang ditandai sebagai dibuat oleh 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 fallback render tersedia.
• Jangan coba ulang auth atau permission sampai konfigurasi berubah.
• Untuk not_found, biarkan finalisasi live fallback dari edit ke pengiriman baru ketika saluran menyatakan bahwa itu aman.
• Untuk conflict, gunakan aturan tanda terima/idempotensi untuk memutuskan apakah pesan sudah ada.
• Setiap error setelah adaptor mungkin telah menyelesaikan I/O platform tetapi sebelum commit tanda terima menjadi unknown_after_send kecuali adaptor dapat membuktikan bahwa 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, intensi persisten, konteks penerimaan, konteks pengiriman, konteks waktu nyata, dan kelas kegagalan.
• Tambahkan origin?: MessageOrigin ke tipe payload bridge migrasi yang digunakan oleh pengiriman balasan saat ini, lalu pindahkan field tersebut ke ChannelMessage dan tipe pesan yang dirender saat refactor menggantikan payload balasan.
• Pertahankan ini tetap internal sampai adapter dan pengujian membuktikan bentuknya.
• Tambahkan pengujian unit murni untuk transisi status dan serialisasi.

​

Fase 2: Core Pengiriman Persisten

• Pindahkan antrean keluar yang ada dari persistensi payload balasan ke intensi pengiriman pesan persisten.
• Biarkan intensi pengiriman persisten 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 persistensi pengiriman final sebagai default dan gagal tertutup saat intensi persisten tidak dapat ditulis dalam siklus hidup pesan baru, setelah adapter menyatakan keamanan replay. Jalur kompatibilitas channel-turn dan SDK yang ada tetap menggunakan pengiriman langsung secara default selama fase ini.
• Catat tanda terima secara konsisten.
• Kembalikan tanda terima dan hasil pengiriman ke pemanggil dispatcher asli, bukan memperlakukan pengiriman persisten sebagai efek samping terminal.
• Persistensikan asal pesan melalui intensi pengiriman persisten sehingga pemulihan, replay, dan pengiriman berpotongan mempertahankan provenance operasional OpenClaw.

​

Fase 3: Bridge Giliran Saluran

• Implementasikan ulang channel.turn.run dan dispatchAssembledChannelTurn di atas messages.receive dan messages.send.
• Pertahankan tipe fact saat ini tetap stabil.
• Pertahankan perilaku legacy secara default. Saluran assembled-turn menjadi persisten hanya ketika adapternya secara eksplisit ikut serta dengan kebijakan persistensi yang aman untuk replay.
• Pertahankan durable: false sebagai hatch escape kompatibilitas untuk jalur yang memfinalisasi edit native dan belum dapat di-replay dengan aman, tetapi jangan mengandalkan penanda false untuk melindungi saluran yang belum dimigrasikan.
• Default-kan persistensi assembled-turn hanya dalam siklus hidup pesan baru, setelah pemetaan saluran membuktikan jalur pengiriman generik mempertahankan semantik pengiriman saluran 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 durable-final 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 “assembled channel turns” atau menyebut jalur channel yang dimigrasikan, bukan mengklaim semua balasan final otomatis.
• Pertahankan perilaku recordInboundSessionAndDispatchReply, helper direct-DM, dan helper kompatibilitas publik serupa. Semuanya boleh mengekspos opt-in konteks pengiriman eksplisit nanti, tetapi tidak boleh otomatis mencoba pengiriman durable generik sebelum callback pengiriman yang dimiliki pemanggil.

​

Fase 5: Siklus Hidup Live Terpadu

• Bangun messages.live dengan dua adaptor pembuktian:
  • Telegram untuk pengiriman plus edit plus pengiriman 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 channel memiliki pengujian paritas.

​

Fase 6: SDK Publik

• Tambahkan openclaw/plugin-sdk/channel-message.
• Dokumentasikan sebagai API Plugin channel yang direkomendasikan.
• Perbarui ekspor paket, inventaris entrypoint, baseline API yang dihasilkan, dan dokumentasi SDK Plugin.
• Sertakan MessageOrigin, hook encode/decode asal, 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 alat pesan
• pengumuman penyelesaian subagent
• pengiriman CLI atau Control UI eksplisit
• jalur otomatisasi/broadcast

​

Fase 8: Usangkan 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 durable.
• Penggunaan ulang kunci idempotensi dan penekanan duplikat.
• Commit receipt dan lewati replay.
• Pemulihan unknown_after_send yang melakukan rekonsiliasi sebelum replay saat adaptor mendukung rekonsiliasi.
• Kebijakan klasifikasi kegagalan.
• Pengurutan kebijakan ack penerimaan.
• Pemetaan relasi untuk pengiriman reply, followup, system, dan broadcast.
• Factory asal kegagalan Gateway dan predikat shouldDropOpenClawEcho.
• Pelestarian asal melalui normalisasi payload, chunking, serialisasi antrean durable, dan pemulihan.

• Adaptor sederhana channel.turn.run tetap mencatat dan mengirim.
• Pengiriman assembled-turn lama tidak menjadi durable kecuali channel secara eksplisit ikut serta.
• Jembatan channel.turn.runPrepared tetap mencatat dan memfinalisasi.
• Helper kompatibilitas publik memanggil callback pengiriman yang dimiliki pemanggil secara default dan tidak melakukan generic-send sebelum callback tersebut.
• Pengiriman fallback durable memutar ulang seluruh array payload yang diproyeksikan setelah restart dan tidak dapat membiarkan payload berikutnya tidak tercatat setelah crash awal.
• Pengiriman assembled-turn durable mengembalikan id pesan platform ke dispatcher yang dibuffer.
• Hook pengiriman kustom tetap mengembalikan id pesan platform saat pengiriman durable 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 membutuhkan 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.

• Balasan topik Telegram dengan ack polling ditunda sampai watermark selesai aman milik konteks penerimaan.
• Pemulihan polling Telegram untuk pembaruan yang diterima-tetapi-belum-terkirim dicakup 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 durable payload tunggal per iterasi loop.
• Pembatalan pratinjau Discord pada media/error/reply eksplisit.
• Final dispatcher Discord yang disiapkan dirutekan melalui konteks pengiriman sebelum dokumentasi atau changelog mengklaim durabilitas final-reply Discord.
• Pengiriman final durable iMessage mengisi cache echo pesan-terkirim monitor.
• Jalur pengiriman lama LINE, BlueBubbles, Zalo, dan Nostr tidak dilewati oleh pengiriman durable generik sampai pengujian paritas adaptornya ada.
• Pengiriman callback Direct-DM/Nostr tetap otoritatif kecuali secara eksplisit dimigrasikan ke target pesan lengkap dan adaptor pengiriman replay-safe.
• Pesan kegagalan Gateway OpenClaw bertag Slack tetap terlihat outbound, echo bot-room 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 di 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 fresh-send.
• Finalisasi progres native Teams.
• Penekanan final duplikat Feishu.
• Fallback timeout akumulator QQ Bot.
• Pengiriman final durable Tlon mempertahankan rendering model-signature dan pelacakan thread yang diikuti.
• Pengiriman final durable 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 perubahan.
• 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 channel yang mendukung edit dan satu channel pengiriman-saja sederhana sebelum menghapus wrapper kompatibilitas.

​

Pertanyaan terbuka

• Apakah Telegram pada akhirnya harus mengganti sumber runner grammY dengan sumber polling yang sepenuhnya durable dan dapat mengontrol redelivery tingkat platform, bukan hanya watermark restart yang dipersistenkan OpenClaw.
• Apakah status pratinjau live durable harus disimpan dalam record antrean yang sama dengan intent pengiriman final atau dalam store live-state saudara.
• Berapa lama wrapper kompatibilitas tetap didokumentasikan setelah plugin-sdk/channel-message dirilis.
• Apakah Plugin pihak ketiga harus mengimplementasikan adaptor penerimaan secara langsung atau hanya menyediakan hook normalize/send/live melalui defineChannelMessageAdapter.
• Field receipt mana yang aman diekspos di SDK publik dibandingkan status runtime internal.
• Apakah efek samping seperti cache self-echo dan marker thread yang diikuti harus dimodelkan sebagai hook konteks pengiriman, langkah finalize milik adaptor, atau subscriber receipt.
• Channel mana yang memiliki metadata asal native, mana yang membutuhkan registry outbound persisten, dan mana yang tidak dapat menawarkan penekanan echo lintas-bot yang andal.

​

Kriteria penerimaan

• Setiap channel pesan bawaan mengirim output terlihat final melalui messages.send.
• Setiap channel pesan inbound masuk melalui messages.receive atau wrapper kompatibilitas terdokumentasi.
• Setiap channel pratinjau/edit/stream menggunakan messages.live untuk status draf dan finalisasi.
• channel.turn hanya wrapper.
• Helper SDK bernama reply adalah ekspor kompatibilitas, bukan jalur yang direkomendasikan.
• Pemulihan durable 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 adaptor tersebut.
• Pengiriman final durable gagal tertutup saat intent durable tidak dapat ditulis, kecuali pemanggil secara eksplisit memilih mode non-durable terdokumentasi.
• Helper kompatibilitas channel-turn dan SDK lama default ke pengiriman langsung milik channel; pengiriman durable generik hanya opt-in eksplisit.
• Receipt mempertahankan semua id pesan platform untuk pengiriman multi-bagian dan id primer untuk kemudahan threading/edit.
• Wrapper durable mempertahankan efek samping lokal channel sebelum mengganti callback pengiriman langsung.
• Dispatcher yang disiapkan tidak dihitung sebagai durable sampai jalur pengiriman finalnya secara eksplisit menggunakan konteks pengiriman.
• Pengiriman fallback menangani setiap payload yang diproyeksikan.
• Pengiriman fallback durable 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 buatan bot yang bertag dijatuhkan sebelum otorisasi bot pada channel yang mendeklarasikan dukungan untuk kontrak asal.
• 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 channel