संदेश जीवनचक्र रिफैक्टर

• मुख्य primitives प्राप्त करना और भेजना होने चाहिए, जवाब देना नहीं।
• reply केवल outbound message पर एक relation है।
• turn inbound-processing की सुविधा है, delivery का मालिक नहीं।
• भेजना context आधारित होना चाहिए: begin, render, preview या stream, final send, commit, fail.
• प्राप्त करना भी context आधारित होना चाहिए: normalize, dedupe, route, record, dispatch, platform ack, fail.
• public plugin SDK को एक छोटे channel-outbound surface में सिमट जाना चाहिए।

​

समस्याएं

• Simple inbound adapters runtime.channel.inbound.run का उपयोग करते हैं।
• Rich adapters runtime.channel.inbound.runPreparedReply का उपयोग करते हैं।
• Legacy helpers dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, reply payload helpers, reply chunking, reply references, और outbound runtime helpers का उपयोग करते हैं।
• Preview streaming channel-specific dispatchers में रहती है।
• Final delivery durability मौजूदा reply payload paths के आसपास जोड़ी जा रही है।

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

​

लक्ष्य

• सभी channel message receive और send paths के लिए एक core lifecycle।
• नए message lifecycle में adapter द्वारा replay-safe behavior घोषित करने के बाद default रूप से durable final sends।
• साझा preview, edit, stream, finalization, retry, recovery, और receipt semantics।
• एक छोटा plugin SDK surface जिसे third-party plugins सीख और maintain कर सकें।
• Migration के दौरान existing inbound reply compatibility callers के लिए compatibility।
• नई channel capabilities के लिए साफ extension points।
• core में कोई platform-specific branches नहीं।
• कोई token-delta channel messages नहीं। Channel streaming message preview, edit, append, या completed block delivery बनी रहती है।
• operational/system output के लिए structured OpenClaw-origin metadata ताकि visible gateway failures shared bot-enabled rooms में fresh prompts की तरह फिर से enter न करें।

​

गैर-लक्ष्य

• पहले phase में हर existing channel को durable message delivery पर force न करें।
• हर channel को समान native transport behavior में force न करें।
• core को Telegram topics, Slack native streams, Matrix redactions, Feishu cards, QQ voice, या Teams activities न सिखाएं।
• सभी internal migration helpers को stable SDK API के रूप में publish न करें।
• retries को completed non-idempotent platform operations replay न करने दें।

​

संदर्भ मॉडल

• Chat
• Thread
• Channel
• Message
• adapter methods जैसे postMessage, editMessage, deleteMessage, stream, startTyping, और history fetches
• dedupe, locks, queues, और persistence के लिए state adapter

• Direct transport calls से पहले durable outbound send intents।
• begin, commit, और fail के साथ explicit send contexts।
• Receive contexts जिन्हें platform ack policy पता हो।
• Receipts जो restart के बाद भी survive करें और edits, deletes, recovery, और duplicate suppression चला सकें।
• एक छोटा public SDK। Bundled plugins internal runtime helpers का उपयोग कर सकते हैं, लेकिन third-party plugins को एक coherent message API दिखना चाहिए।
• Agent-specific behavior: sessions, transcripts, block streaming, tool progress, approvals, media directives, silent replies, और group mention history।

​

Core model

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

​

Message terms

​

Message

type ChannelMessage = {
  id: string;
  channel: string;
  accountId?: string;
  direction: "inbound" | "outbound";
  target: MessageTarget;
  sender?: MessageActor;
  body?: MessageBody;
  attachments?: MessageAttachment[];
  relation?: MessageRelation;
  origin?: MessageOrigin;
  timestamp?: number;
  raw?: unknown;
};

​

Target

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

​

Relation

type MessageRelation =
  | {
      kind: "reply";
      inboundMessageId?: string;
      replyToId?: string;
      threadId?: string;
      quote?: MessageQuote;
    }
  | {
      kind: "followup";
      sessionKey?: string;
      previousMessageId?: string;
    }
  | {
      kind: "broadcast";
      reason?: string;
    }
  | {
      kind: "system";
      reason:
        | "approval"
        | "task"
        | "hook"
        | "cron"
        | "subagent"
        | "message_tool"
        | "cli"
        | "control_ui"
        | "automation"
        | "error";
    };

​

Origin

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

​

Receive context

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 accept कर लिया। कुछ platforms को dispatch से पहले इसकी जरूरत होती है।
• Polling offset ack: cursor को advance करता है ताकि वही event फिर से fetch न हो। यह ऐसे work से आगे advance नहीं होना चाहिए जिसे recover नहीं किया जा सकता।
• Inbound record ack: पुष्टि करता है कि OpenClaw ने redelivery को dedupe और route करने के लिए पर्याप्त inbound metadata persist कर लिया है।
• User-visible receipt: optional read/status/typing behavior; durability boundary कभी नहीं।

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

​

Send context

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 send plus edit preview, stale preview age के बाद fresh final के साथ।
• Discord send plus edit preview, media/error/explicit reply पर cancel।
• Slack native stream या draft preview, thread shape पर निर्भर।
• Mattermost draft post finalization।
• Matrix draft event finalization या mismatch पर redaction।
• Teams native progress stream।
• QQ Bot stream या accumulated fallback।

​

Adapter सतह

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

type ChannelMessageAdapter = {
  receive?: MessageReceiveAdapter;
  send: MessageSendAdapter;
  live?: MessageLiveAdapter;
  origin?: MessageOriginAdapter;
  render?: MessageRenderAdapter;
  capabilities: MessageCapabilities;
};

type MessageSendAdapter = {
  send(ctx: MessageSendContext, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit?(
    ctx: MessageSendContext,
    receipt: MessageReceipt,
    rendered: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  delete?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  classifyError?(ctx: MessageSendContext, error: unknown): DeliveryFailureKind;
  reconcileUnknownSend?(ctx: MessageSendContext): Promise<MessageReceipt | null>;
  afterSendSuccess?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  afterCommit?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
};

type MessageReceiveAdapter<TRaw = unknown> = {
  normalize(raw: TRaw, ctx: MessageNormalizeContext): Promise<ChannelMessage>;
  classify?(message: ChannelMessage): Promise<MessageEventClass>;
  preflight?(message: ChannelMessage, event: MessageEventClass): Promise<MessagePreflightResult>;
  ackPolicy?(message: ChannelMessage, event: MessageEventClass): ReceiveAckPolicy;
};

type MessageOriginAdapter<TRaw = unknown, TNative = unknown> = {
  encode?(origin: MessageOrigin): TNative | undefined;
  decode?(raw: TRaw): MessageOrigin | undefined;
};

type MessageCapabilities = {
  text: { maxLength?: number; chunking?: boolean };
  attachments?: {
    upload: boolean;
    remoteUrl: boolean;
    voice?: boolean;
  };
  threads?: {
    reply: boolean;
    topic?: boolean;
    nativeThread?: boolean;
  };
  live?: {
    edit: boolean;
    delete: boolean;
    nativeStream?: boolean;
    progress?: boolean;
  };
  delivery?: {
    idempotencyKey?: boolean;
    retryAfter?: boolean;
    receiptRequired?: boolean;
  };
};

​

Public SDK कटौती

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• outbound-runtime के अधिकांश public uses
• ad hoc draft stream lifecycle helpers

​

channel inbound से संबंध

channel.inbound.run
  -> messages.receive context
  -> session dispatch
  -> messages.send context for visible output

channel-owned dispatcher
  -> messages.receive record/finalize bridge
  -> messages.live for preview/progress
  -> messages.send for final delivery

​

Compatibility guardrails

• channel.inbound.run और dispatchChannelInboundReply channel की delivery callback का उपयोग करते हैं, जब तक वह channel स्पष्ट रूप से audited durable policy/options object उपलब्ध न कराए।
• channel.inbound.runPreparedReply channel-owned रहता है, जब तक prepared dispatcher स्पष्ट रूप से send context को call नहीं करता।
• Public compatibility helpers जैसे recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase, और direct-DM helpers caller-provided deliver या reply callback से पहले कभी generic durable delivery inject नहीं करते।

• टिकाऊ अंतिम डिलीवरी एक discriminated स्थिति लौटाती है। handled_visible और handled_no_send अंतिम हैं; unsupported और not_applicable channel-स्वामित्व वाली डिलीवरी पर वापस जा सकते हैं; failed भेजने की विफलता को आगे प्रसारित करता है।
• सामान्य टिकाऊ अंतिम डिलीवरी adapter क्षमताओं द्वारा नियंत्रित होती है, जैसे मौन डिलीवरी, reply target संरक्षण, native quote संरक्षण, और message-sending hooks। अनुपस्थित समानता को channel-स्वामित्व वाली डिलीवरी चुननी चाहिए, ऐसा सामान्य send नहीं जो उपयोगकर्ता-दृश्य व्यवहार बदल दे।
• Queue-समर्थित टिकाऊ sends एक delivery intent reference उजागर करते हैं। मौजूदा pendingFinalDelivery* session fields transition के दौरान intent id रख सकते हैं; अंतिम स्थिति frozen reply text और ad hoc context fields के बजाय एक MessageSendIntent store है।

• generic send adapter पुराने direct path जैसा ही rendering और transport व्यवहार निष्पादित करता है।
• स्थानीय post-send side effects send context के माध्यम से संरक्षित हैं।
• adapter सभी platform message ids के साथ receipts या delivery results लौटाता है।
• Prepared dispatcher paths या तो नए send context को call करते हैं या durable guarantee से बाहर के रूप में documented रहते हैं।
• Fallback delivery हर projected payload को संभालती है, केवल पहले वाले को नहीं।
• Durable fallback delivery पूरे projected payload array को एक replayable intent या batch plan के रूप में रिकॉर्ड करती है।

• iMessage monitor delivery सफल send के बाद sent messages को echo cache में रिकॉर्ड करती है। Durable final sends को अभी भी वह cache populate करना होगा, अन्यथा OpenClaw अपनी ही final replies को inbound user messages के रूप में फिर से ingest कर सकता है।
• Tlon optional model signature जोड़ता है और group replies के बाद participated threads रिकॉर्ड करता है। Generic durable delivery को उन effects को bypass नहीं करना चाहिए; या तो उन्हें Tlon render/send/finalize adapters में move करें या Tlon को channel-owned path पर रखें।
• Discord और अन्य prepared dispatchers पहले से direct delivery और preview behavior के स्वामी हैं। वे assembled-turn durable guarantee द्वारा covered नहीं हैं जब तक उनके prepared dispatchers स्पष्ट रूप से finals को send context के माध्यम से route नहीं करते।
• Telegram silent fallback delivery को पूरा projected payload array deliver करना होगा। single-payload shortcut projection के बाद अतिरिक्त fallback payloads को drop कर सकता है।
• LINE, Zalo, Nostr, और अन्य मौजूदा assembled/helper paths में reply-token handling, media proxying, sent-message caches, loading/status cleanup, या callback-only targets हो सकते हैं। वे channel-owned delivery पर रहते हैं जब तक वे semantics send adapter द्वारा represented और tests द्वारा verified न हों।
• Direct-DM helpers में ऐसा reply callback हो सकता है जो ही एकमात्र सही transport target है। Generic outbound को OriginatingTo या To से guess करके उस callback को skip नहीं करना चाहिए।
• OpenClaw gateway failure output मनुष्यों को visible रहना चाहिए, लेकिन tagged bot-authored room echoes को allowBots authorization से पहले drop करना होगा। Channels को इसे visible-text prefix filters से implement नहीं करना चाहिए, सिवाय छोटे emergency stopgap के; durable contract structured origin metadata है।

​

Internal storage

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

​

Failure classes

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

• transient और rate_limit को retry करें।
• render fallback मौजूद न हो तो invalid_payload को retry न करें।
• configuration बदलने तक auth या permission को retry न करें।
• not_found के लिए, channel द्वारा safe घोषित किए जाने पर live finalization को edit से fresh send पर fall back करने दें।
• conflict के लिए, message पहले से मौजूद है या नहीं यह तय करने के लिए receipt/idempotency rules का उपयोग करें।
• adapter द्वारा platform I/O पूरा कर लेने के बाद लेकिन receipt commit से पहले कोई भी error unknown_after_send बन जाती है, जब तक adapter prove न कर सके कि platform operation नहीं हुआ।

​

Channel mapping

​

माइग्रेशन योजना

​

चरण 1: आंतरिक संदेश डोमेन

• संदेशों, लक्ष्यों, संबंधों, उद्गमों, रसीदों, क्षमताओं, टिकाऊ intents, receive context, send context, live context, और failure classes के लिए src/channels/message/* प्रकार जोड़ें।
• मौजूदा reply delivery द्वारा उपयोग किए जाने वाले migration bridge payload type में origin?: MessageOrigin जोड़ें, फिर जैसे-जैसे refactor reply payloads को बदलता है, उस field को ChannelMessage और rendered message types में ले जाएं।
• इसे तब तक आंतरिक रखें जब तक अडैप्टर और tests shape को सिद्ध न कर दें।
• state transitions और serialization के लिए pure unit tests जोड़ें।

​

चरण 2: टिकाऊ भेजने वाला Core

• मौजूदा outbound queue को reply-payload durability से टिकाऊ message send intents पर ले जाएं।
• टिकाऊ send intent को केवल एक reply payload नहीं, बल्कि projected payload array या batch plan ले जाने दें।
• compatibility conversion के जरिए मौजूदा queue recovery behavior को संरक्षित रखें।
• deliverOutboundPayloads से messages.send call कराएं।
• adapter द्वारा replay safety घोषित करने के बाद, नए message lifecycle में durable intent नहीं लिखे जा सकने पर final-send durability को default बनाएं और fail closed करें। मौजूदा inbound runner और SDK compatibility paths इस चरण के दौरान default रूप से direct-send बने रहते हैं।
• रसीदें लगातार record करें।
• टिकाऊ send को terminal side effect मानने के बजाय original dispatcher caller को receipts और delivery results लौटाएं।
• durable send intents के जरिए message origin persist करें ताकि recovery, replay, और chunked sends OpenClaw operational provenance संरक्षित रखें।

​

चरण 3: Channel Inbound Bridge

• channel.inbound.run और dispatchChannelInboundReply को messages.receive और messages.send के ऊपर दोबारा लागू करें।
• मौजूदा fact types स्थिर रखें।
• legacy behavior को default रूप से रखें। assembled-turn channel केवल तब durable बनता है जब उसका adapter replay-safe durability policy के साथ स्पष्ट रूप से opt in करता है।
• उन paths के लिए compatibility escape hatch के रूप में durable: false रखें जो native edits finalize करते हैं और अभी सुरक्षित रूप से replay नहीं कर सकते, लेकिन unmigrated channels की सुरक्षा के लिए false markers पर निर्भर न रहें।
• नए message lifecycle में ही assembled-turn durability को default करें, उसके बाद जब channel mapping सिद्ध कर दे कि generic send path पुराने channel delivery semantics को संरक्षित रखता है।

​

चरण 4: Prepared Dispatcher Bridge

• deliverDurableInboundReplyPayload को send-context bridge से बदलें.
• पुराने helper को wrapper के रूप में रखें.
• पहले Telegram, WhatsApp, Slack, Signal, iMessage, और Discord को पोर्ट करें क्योंकि उनके पास पहले से durable-final काम या सरल send paths हैं.
• हर prepared dispatcher को uncovered मानें जब तक वह स्पष्ट रूप से send context में opt in न करे. दस्तावेज़ीकरण और changelog प्रविष्टियों में “असेंबल किए गए channel turns” कहना चाहिए या migrated channel paths का नाम लेना चाहिए, बजाय सभी automatic final replies का दावा करने के.
• recordInboundSessionAndDispatchReply, direct-DM helpers, और इसी तरह के public compatibility helpers को behavior-preserving रखें. वे बाद में स्पष्ट send-context opt-in उजागर कर सकते हैं, लेकिन caller-owned delivery callback से पहले अपने आप generic durable delivery का प्रयास नहीं करना चाहिए.

​

चरण 5: एकीकृत लाइव Lifecycle

• दो proof adapters के साथ messages.live बनाएँ:
  • Telegram, send plus edit plus stale final send के लिए.
  • Matrix, draft finalization plus redaction fallback के लिए.
• फिर Discord, Slack, Mattermost, Teams, QQ Bot, और Feishu को migrate करें.
• duplicated preview finalization code को केवल तब हटाएँ जब हर channel के पास parity tests हों.

​

चरण 6: Public SDK

• openclaw/plugin-sdk/channel-outbound जोड़ें.
• इसे preferred channel Plugin API के रूप में document करें.
• package exports, entrypoint inventory, generated API baselines, और Plugin SDK docs अपडेट करें.
• channel-outbound SDK surface में MessageOrigin, origin encode/decode hooks, और shared shouldDropOpenClawEcho predicate शामिल करें.
• पुराने subpaths के लिए compatibility wrappers रखें.
• bundled plugins migrate होने के बाद docs में reply-named SDK helpers को deprecated के रूप में mark करें.

​

चरण 7: सभी Senders

• Cron और Heartbeat notifications
• task completions
• hook results
• approval prompts और approval results
• message tool sends
• subagent completion announcements
• explicit CLI या Control UI sends
• automation/broadcast paths

​

चरण 8: Turn-Named Compatibility हटाएँ

• inbound/message-named wrappers को compatibility window के रूप में रखें.
• migration notes publish करें.
• पुराने imports के विरुद्ध Plugin SDK compatibility tests चलाएँ.
• पुराने internal helpers को केवल तब हटाएँ या छिपाएँ जब किसी bundled Plugin को उनकी ज़रूरत न हो और third-party contracts के पास stable replacement हो.

​

Test plan

• Durable send intent serialization और recovery.
• Idempotency key reuse और duplicate suppression.
• Receipt commit और replay skip.
• unknown_after_send recovery जो replay से पहले reconcile करती है जब कोई adapter reconciliation support करता है.
• Failure classification policy.
• Receive ack policy sequencing.
• reply, followup, system, और broadcast sends के लिए relation mapping.
• Gateway-failure origin factory और shouldDropOpenClawEcho predicate.
• payload normalization, chunking, durable queue serialization, और recovery के दौरान origin preservation.

• channel.inbound.run simple adapter अभी भी records और sends करता है.
• Legacy assembled-event delivery durable नहीं बनती जब तक channel स्पष्ट रूप से opt in न करे.
• channel.inbound.runPreparedReply bridge अभी भी records और finalizes करता है.
• Public compatibility helpers default रूप से caller-owned delivery callbacks call करते हैं और उन callbacks से पहले generic-send नहीं करते.
• Durable fallback delivery restart के बाद पूरे projected payload array को replay करती है और early crash के बाद बाद के payloads को unrecorded नहीं छोड़ सकती.
• Durable assembled-event delivery buffered dispatcher को platform message ids लौटाती है.
• durable delivery disabled या unavailable होने पर भी custom delivery hooks platform message ids लौटाते हैं.
• Final reply assistant completion और platform send के बीच restart से बची रहती है.
• Preview draft अनुमति होने पर उसी जगह finalize होता है.
• media/error/reply-target mismatch के कारण normal delivery आवश्यक होने पर Preview draft cancel या redact होता है.
• Block streaming और preview streaming दोनों एक ही text deliver नहीं करते.
• जल्दी stream हुआ media final delivery में duplicate नहीं होता.

• Telegram topic reply जिसमें polling ack receive context के safe completed watermark तक delayed रहता है.
• accepted-but-not-delivered updates के लिए Telegram polling recovery, persisted safe-completed offset model से covered है.
• Telegram stale preview fresh final भेजता है और preview clean up करता है.
• Telegram silent fallback हर projected fallback payload भेजता है.
• Telegram silent fallback durability पूरे projected fallback array को atomically record करती है, loop iteration के प्रति एक single-payload durable intent नहीं.
• media/error/explicit reply पर Discord preview cancel.
• Discord prepared dispatcher finals docs या changelog द्वारा Discord final-reply durability claim करने से पहले send context से route होते हैं.
• iMessage durable final sends monitor sent-message echo cache populate करते हैं.
• LINE, Zalo, और Nostr legacy delivery paths को generic durable send द्वारा bypass नहीं किया जाता जब तक उनके adapter parity tests मौजूद न हों.
• Direct-DM/Nostr callback delivery authoritative रहती है जब तक स्पष्ट रूप से complete message target और replay-safe send adapter में migrate न किया जाए.
• Slack tagged OpenClaw gateway failure messages visible outbound रहते हैं, tagged bot-room echoes allowBots से पहले drop होते हैं, और उसी visible text वाले untagged bot messages अभी भी normal bot authorization follow करते हैं.
• top-level DMs में Slack native stream fallback to draft preview.
• Matrix preview finalization और redaction fallback.
• configured bot accounts से Matrix tagged OpenClaw gateway-failure room echoes allowBots handling से पहले drop होते हैं.
• Discord और Google Chat shared-room gateway-failure cascade audits वहाँ generic protection claim करने से पहले allowBots modes cover करते हैं.
• Mattermost draft finalization और fresh-send fallback.
• Teams native progress finalization.
• Feishu duplicate final suppression.
• QQ Bot accumulator timeout fallback.
• Tlon durable final sends model-signature rendering और participated thread tracking preserve करते हैं.
• WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo, और Zalo Personal simple durable final sends.

• development के दौरान targeted Vitest files.
• पूरी changed surface के लिए Testbox में pnpm check:changed.
• complete refactor land करने से पहले या public SDK/export changes के बाद Testbox में broader pnpm check.
• compatibility wrappers हटाने से पहले कम से कम एक edit-capable channel और एक simple send-only channel के लिए live या qa-channel smoke.

​

खुले प्रश्न

• क्या Telegram को अंततः grammY runner source को ऐसे fully durable polling source से बदलना चाहिए जो platform-level redelivery control कर सके, न कि केवल OpenClaw का persisted restart watermark.
• क्या durable live preview state को final send intent जैसी ही queue record में store किया जाना चाहिए या sibling live-state store में.
• plugin-sdk/channel-outbound ship होने के बाद compatibility wrappers कितने समय तक documented रहें.
• क्या third-party plugins को receive adapters directly implement करने चाहिए या केवल defineChannelMessageAdapter के माध्यम से normalize/send/live hooks provide करने चाहिए.
• कौन से receipt fields public SDK में expose करने के लिए safe हैं बनाम internal runtime state.
• self-echo caches और participated-thread markers जैसे side effects को send-context hooks, adapter-owned finalize steps, या receipt subscribers के रूप में model किया जाना चाहिए.
• किन channels के पास native origin metadata है, किन्हें persisted outbound registries चाहिए, और कौन reliable cross-bot echo suppression नहीं दे सकते.

​

Acceptance criteria

• हर bundled message channel final visible output को messages.send के माध्यम से भेजता है.
• हर inbound message channel messages.receive या documented compatibility wrapper के माध्यम से enter करता है.
• हर preview/edit/stream channel draft state और finalization के लिए messages.live का उपयोग करता है.
• channel.inbound केवल wrapper है.
• Reply-named SDK helpers compatibility exports हैं, recommended path नहीं.
• Durable recovery restart के बाद pending final sends replay कर सकती है बिना final response खोए या already committed sends duplicate किए; जिन sends का platform outcome unknown है वे replay से पहले reconciled होते हैं या उस adapter के लिए at-least-once के रूप में documented होते हैं.
• Durable final sends तब fail closed करते हैं जब durable intent नहीं लिखा जा सकता, जब तक caller ने स्पष्ट रूप से documented non-durable mode select न किया हो.
• Legacy SDK compatibility helpers default रूप से direct channel-owned delivery करते हैं; generic durable send केवल explicit opt-in है.
• Receipts multi-part deliveries के लिए सभी platform message ids और threading/edit सुविधा के लिए primary id preserve करते हैं.
• Durable wrappers direct delivery callbacks बदलने से पहले channel-local side effects preserve करते हैं.
• Prepared dispatchers को durable नहीं गिना जाता जब तक उनका final delivery path स्पष्ट रूप से send context का उपयोग न करे.
• Fallback delivery हर projected payload handle करती है.
• Durable fallback delivery हर projected payload को एक replayable intent या batch plan में record करती है.
• OpenClaw-originated gateway failure output humans को visible होता है लेकिन tagged bot-authored room echoes उन channels पर bot authorization से पहले drop होते हैं जो origin contract के लिए support declare करते हैं.
• docs send, receive, live, state, receipts, relations, failure policy, migration, और test coverage समझाते हैं.

​

संबंधित

• Messages
• Streaming और chunking
• Progress drafts
• Retry policy
• Channel inbound API