メッセージライフサイクルのリファクタリング

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.

• コアプリミティブは reply ではなく receive と send にする。
• 返信は送信メッセージ上の関係にすぎない。
• ターンはインバウンド処理の便宜であり、配送の所有者ではない。
• 送信はコンテキストベースである必要がある: begin、レンダリング、プレビューまたはストリーム、最終送信、コミット、失敗。
• 受信もコンテキストベースである必要がある: 正規化、重複排除、ルーティング、記録、ディスパッチ、プラットフォーム ack、失敗。
• 公開 Plugin SDK は、小さなチャネルメッセージサーフェス1つに統合するべきである。

​

問題

• シンプルなインバウンドアダプターは runtime.channel.turn.run を使用する。
• 高機能なアダプターは runtime.channel.turn.runPrepared を使用する。
• レガシーヘルパーは dispatchInboundReplyWithBase、recordInboundSessionAndDispatchReply、返信ペイロードヘルパー、返信チャンク化、返信参照、送信ランタイムヘルパーを使用する。
• プレビュー ストリーミングはチャネル固有のディスパッチャー内にある。
• 最終配送の耐久性は、既存の返信ペイロード経路の周辺に追加されつつある。

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

​

目標

• すべてのチャネルメッセージの受信および送信経路に対する1つのコアライフサイクル。
• アダプターが再生安全な動作を宣言した後、新しいメッセージライフサイクルでは耐久化された最終送信をデフォルトにする。
• 共有されたプレビュー、編集、ストリーム、最終化、リトライ、リカバリー、受領セマンティクス。
• サードパーティ Plugin が習得し保守できる小さな Plugin SDK サーフェス。
• 移行中の既存 channel.turn 呼び出し元との互換性。
• 新しいチャネル機能のための明確な拡張ポイント。
• コア内にプラットフォーム固有の分岐を置かない。
• トークンデルタのチャネルメッセージを置かない。チャネル ストリーミングは、メッセージのプレビュー、編集、追加、または完了済みブロック配送のままにする。
• 可視の Gateway 障害が、bot が有効な共有ルームに新しいプロンプトとして再投入されないようにする、OpenClaw 起源の運用/システム出力向けの構造化メタデータ。

​

非目標

• 第1フェーズでは runtime.channel.turn.* を削除しない。
• すべてのチャネルに同じネイティブ転送動作を強制しない。
• コアに Telegram トピック、Slack ネイティブストリーム、Matrix リダクション、Feishu カード、QQ 音声、Teams アクティビティを教えない。
• すべての内部移行ヘルパーを安定した SDK API として公開しない。
• 完了済みの非冪等なプラットフォーム操作をリトライで再生しない。

​

参照モデル

• Chat
• Thread
• Channel
• Message
• postMessage、editMessage、deleteMessage、stream、startTyping、履歴取得などのアダプターメソッド
• 重複排除、ロック、キュー、永続化のための状態アダプター

• 直接転送呼び出しの前に、耐久化された送信意図を置く。
• begin、commit、fail を持つ明示的な送信コンテキスト。
• プラットフォーム ack ポリシーを知っている受信コンテキスト。
• 再起動後も残り、編集、削除、リカバリー、重複抑制を駆動できる受領。
• より小さな公開 SDK。バンドルされた Plugin は内部ランタイムヘルパーを使用できるが、サードパーティ Plugin には1つの一貫したメッセージ API を見せるべきである。
• エージェント固有の動作: セッション、トランスクリプト、ブロック ストリーミング、ツール進捗、承認、メディアディレクティブ、サイレント返信、グループメンション履歴。

​

コアモデル

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

​

メッセージ用語

​

メッセージ

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

​

ターゲット

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

​

関係

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

​

起源

type MessageOrigin =
  | {
      source: "openclaw";
      schemaVersion: 1;
      kind: "gateway_failure";
      code: "agent_failed_before_reply" | "missing_api_key" | "model_login_expired";
      echoPolicy: "drop_bot_room_echo";
    }
  | {
      source: "user" | "external_bot" | "platform" | "unknown";
    };

​

受領

type MessageReceipt = {
  primaryPlatformMessageId?: string;
  platformMessageIds: string[];
  parts: MessageReceiptPart[];
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  sentAt: number;
  raw?: unknown;
};

type MessageReceiptPart = {
  platformMessageId: string;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  index: number;
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  raw?: unknown;
};

​

受信コンテキスト

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

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

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

• 転送 ack: OpenClaw がイベントエンベロープを受け入れたことをプラットフォーム Webhook またはソケットに伝える。一部のプラットフォームでは、ディスパッチ前にこれが必要である。
• ポーリングオフセット ack: 同じイベントが再取得されないようにカーソルを進める。リカバリーできない作業を越えて進めてはならない。
• インバウンド記録 ack: OpenClaw が再配送を重複排除およびルーティングするのに十分なインバウンドメタデータを永続化したことを確認する。
• ユーザー可視の受領: 任意の既読/ステータス/入力中動作。耐久性境界にはならない。

function shouldDropOpenClawEcho(params: {
  origin?: MessageOrigin;
  isBotAuthor: boolean;
  isRoomish: boolean;
}): boolean {
  return (
    params.isBotAuthor &&
    params.isRoomish &&
    params.origin?.source === "openclaw" &&
    params.origin.kind === "gateway_failure" &&
    params.origin.echoPolicy === "drop_bot_room_echo"
  );
}

type ReceiveAckPolicy =
  | { kind: "immediate"; reason: "webhook-timeout" | "platform-contract" }
  | { kind: "after-record" }
  | { kind: "after-durable-send" }
  | { kind: "manual" };

​

送信コンテキスト

type MessageSendContext = {
  id: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  intent: DurableSendIntent;
  attempt: number;
  signal: AbortSignal;
  previousReceipt?: MessageReceipt;
  preview?: LiveMessageState;
  log: MessageLifecycleLogger;

  render(): Promise<RenderedMessageBatch>;
  previewUpdate(rendered: RenderedMessageBatch): Promise<LiveMessageState>;
  send(rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit(receipt: MessageReceipt, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  delete(receipt: MessageReceipt): Promise<void>;
  commit(receipt: MessageReceipt): Promise<void>;
  fail(error: unknown): Promise<void>;
};

await core.messages.withSendContext(message, async (ctx) => {
  const rendered = await ctx.render();

  if (ctx.preview?.canFinalizeInPlace) {
    return await ctx.edit(ctx.preview.receipt, rendered);
  }

  return await ctx.send(rendered);
});

begin durable intent
  -> render
  -> optional preview/edit/stream work
  -> mark sending
  -> final platform send or final edit
  -> mark committing with raw receipt
  -> commit receipt
  -> ack durable intent
  -> fail durable intent on classified failure

type MessageDurabilityPolicy = "required" | "best_effort" | "disabled";

type RenderedMessageBatch = {
  units: RenderedMessageUnit[];
  atomicity: "all_or_retry_remaining" | "best_effort_parts";
  idempotencyKey: string;
};

type RenderedMessageUnit = {
  index: number;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  payload: unknown;
  required: boolean;
};

​

ライブコンテキスト

type MessageLiveAdapter = {
  begin?(ctx: MessageSendContext): Promise<LiveMessageState>;
  update?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    update: LiveMessageUpdate,
  ): Promise<LiveMessageState>;
  finalize?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    final: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  cancel?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    reason: LiveCancelReason,
  ): Promise<void>;
};

type LiveMessageState = {
  mode: "partial" | "block" | "progress" | "native";
  receipt?: MessageReceipt;
  visibleSince?: number;
  canFinalizeInPlace: boolean;
  lastRenderedHash?: string;
  staleAfterMs?: number;
};

• Telegram の送信と編集プレビュー。古いプレビュー age の後は新しい final を送る。
• Discord の送信と編集プレビュー。メディア、エラー、明示的な返信ではキャンセルする。
• Slack のネイティブストリームまたはドラフトプレビュー。スレッド形状に応じて使い分ける。
• Mattermost のドラフト投稿 finalization。
• Matrix のドラフトイベント finalization、または不一致時の redaction。
• Teams のネイティブ進捗ストリーム。
• QQ Bot のストリームまたは蓄積フォールバック。

​

アダプターサーフェス

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

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

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

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

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

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

​

公開 SDK の縮小

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• outbound-runtime の公開利用の大半
• ad hoc なドラフトストリームライフサイクルヘルパー

​

チャネルターンとの関係

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

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

​

互換性のガードレール

• channel.turn.run と dispatchAssembledChannelTurn は、そのチャネルが監査済みの durable policy/options オブジェクトを明示的に提供しない限り、チャネルの配送コールバックを使用する。
• channel.turn.runPrepared は、prepared dispatcher が send context を明示的に呼び出すまでチャネル所有のままにする。
• recordInboundSessionAndDispatchReply、dispatchInboundReplyWithBase、direct-DM ヘルパーなどの公開互換ヘルパーは、呼び出し元が提供する deliver または reply コールバックの前に、汎用 durable delivery を注入しない。

• 耐久性のある最終配信は判別可能なステータスを返します。handled_visible と handled_no_send は終端です。unsupported と not_applicable は チャンネル所有の配信にフォールバックする場合があります。failed は送信失敗を伝播します。
• 汎用の耐久性のある最終配信は、サイレント配信、返信先の保持、ネイティブ引用の保持、 メッセージ送信フックなどのアダプター能力によって制御されます。同等性が欠けている場合は、 ユーザーに見える動作を変える汎用送信ではなく、チャンネル所有の配信を選ぶ必要があります。
• キューを基盤とする耐久性のある送信は、配信インテント参照を公開します。既存の pendingFinalDelivery* セッションフィールドは、移行中にインテント ID を保持できます。 最終状態は、凍結された返信テキストと場当たり的なコンテキストフィールドではなく、 MessageSendIntent ストアです。

• 汎用送信アダプターが、古い直接パスと同じレンダリングおよびトランスポート動作を実行する。
• ローカルの送信後副作用が送信コンテキストを通じて保持される。
• アダプターが、すべてのプラットフォームメッセージ ID を含む受領情報または配信結果を返す。
• 準備済みディスパッチャーパスが、新しい送信コンテキストを呼び出すか、耐久性保証の対象外として文書化されたままである。
• フォールバック配信が、最初の 1 件だけでなく、射影されたすべてのペイロードを処理する。
• 耐久性のあるフォールバック配信が、射影されたペイロード配列全体を、1 つの再生可能なインテントまたはバッチ計画として記録する。

• iMessage モニター配信は、送信成功後に送信済みメッセージをエコーキャッシュに記録します。耐久性のある最終送信でもそのキャッシュを必ず埋める必要があります。そうしないと、 OpenClaw が自身の最終返信を、受信ユーザーメッセージとして再取り込みする可能性があります。
• Tlon は任意のモデル署名を付加し、グループ返信後に参加済みスレッドを記録します。汎用の耐久性のある配信は、これらの効果を迂回してはなりません。それらを Tlon のレンダリング、送信、最終化アダプターへ移すか、Tlon をチャンネル所有パスに留めてください。
• Discord やその他の準備済みディスパッチャーは、直接配信とプレビュー動作をすでに所有しています。それらの準備済みディスパッチャーが最終メッセージを送信コンテキストへ明示的にルーティングするまで、組み立て済みターンの耐久性保証の対象にはなりません。
• Telegram のサイレントフォールバック配信は、射影されたペイロード配列全体を配信する必要があります。単一ペイロードのショートカットは、射影後の追加フォールバックペイロードを落とす可能性があります。
• LINE、Zalo、Nostr、およびその他の既存の組み立て済みパスやヘルパーパスには、 返信トークン処理、メディアプロキシ、送信済みメッセージキャッシュ、読み込み/ステータスのクリーンアップ、またはコールバック専用ターゲットがある場合があります。それらのセマンティクスが送信アダプターで表現され、テストで検証されるまで、チャンネル所有の配信に留めます。
• Direct-DM ヘルパーには、唯一の正しいトランスポートターゲットである返信コールバックがある場合があります。汎用アウトバウンドは、OriginatingTo や To から推測してそのコールバックをスキップしてはなりません。
• OpenClaw Gateway の失敗出力は人間に見える状態を保つ必要がありますが、タグ付けされたボット作成のルームエコーは、allowBots 認可の前に破棄する必要があります。短期の緊急停止策を除き、チャンネルは可視テキストの接頭辞フィルターでこれを実装してはなりません。耐久性契約は構造化された発信元メタデータです。

​

内部ストレージ

type DurableSendIntent = {
  id: string;
  idempotencyKey: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  batch?: RenderedMessageBatch;
  liveState?: LiveMessageState;
  status:
    | "pending"
    | "sending"
    | "committing"
    | "unknown_after_send"
    | "sent"
    | "failed"
    | "cancelled";
  attempt: number;
  nextAttemptAt?: number;
  receipt?: MessageReceipt;
  partialReceipt?: MessageReceipt;
  failure?: DeliveryFailure;
  createdAt: number;
  updatedAt: number;
};

load pending or sending intents
  -> acquire idempotency lock
  -> skip if receipt already committed
  -> reconstruct send context
  -> render if needed
  -> reconcile unknown_after_send if needed
  -> call adapter send/edit/finalize
  -> commit receipt, mark unknown_after_send, or schedule retry

​

失敗クラス

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

• transient と rate_limit は再試行する。
• レンダリングフォールバックが存在しない限り、invalid_payload は再試行しない。
• 設定が変更されるまで、auth または permission は再試行しない。
• not_found では、チャンネルが安全であると宣言している場合、ライブ最終化で編集から新規送信へフォールバックできるようにする。
• conflict では、受領情報/冪等性ルールを使ってメッセージがすでに存在するかどうかを判断する。
• アダプターがプラットフォーム I/O を完了した可能性がある後、受領情報のコミット前に発生したエラーは、プラットフォーム操作が発生しなかったことをアダプターが証明できる場合を除き、すべて unknown_after_send になります。

​

チャンネルマッピング

​

移行計画

​

フェーズ 1: 内部メッセージドメイン

• メッセージ、ターゲット、関係、 origin、受領、capability、耐久性のある intent、受信コンテキスト、送信 コンテキスト、ライブコンテキスト、失敗クラス用の src/channels/message/* 型を追加します。
• 現在の返信配信で使われる移行ブリッジペイロード型に origin?: MessageOrigin を追加し、その後、リファクタリングで返信ペイロードが置き換えられるにつれて、そのフィールドを ChannelMessage とレンダリング済み メッセージ型へ移動します。
• アダプターとテストで形が証明されるまで、これは内部に保ちます。
• 状態遷移とシリアライズの純粋なユニットテストを追加します。

​

フェーズ 2: 耐久性のある送信コア

• 既存のアウトバウンドキューを、返信ペイロードの耐久性から、耐久性のある メッセージ送信 intent に移動します。
• 耐久性のある送信 intent は、1 つの返信ペイロードだけでなく、 投影済みペイロード配列またはバッチ計画を保持できるようにします。
• 互換変換を通じて、現在のキュー復旧動作を保持します。
• deliverOutboundPayloads が messages.send を呼び出すようにします。
• アダプターがリプレイ安全性を宣言した後、新しいメッセージライフサイクルで耐久性のある intent を書き込めない場合は、最終送信の耐久性をデフォルトにし、fail closed します。既存の channel-turn と SDK 互換パスは、このフェーズ中はデフォルトで direct-send のままにします。
• 受領を一貫して記録します。
• 耐久性のある送信を終端の副作用として扱うのではなく、受領と配信結果を元の dispatcher 呼び出し元へ返します。
• 復旧、リプレイ、チャンク化送信で OpenClaw の運用上の由来を保持できるよう、耐久性のある送信 intent を通じてメッセージ origin を永続化します。

​

フェーズ 3: Channel Turn ブリッジ

• messages.receive と messages.send の上に channel.turn.run と dispatchAssembledChannelTurn を再実装します。
• 現在の fact 型を安定したまま保ちます。
• デフォルトではレガシー動作を維持します。assembled-turn チャネルは、そのアダプターがリプレイ安全な耐久性ポリシーで明示的に opt in した場合にのみ耐久性を持ちます。
• ネイティブ編集を最終化してまだ安全にリプレイできないパス向けの互換エスケープハッチとして、durable: false を維持します。ただし、未移行チャネルを保護するために false マーカーへ依存しないでください。
• チャネルマッピングによって汎用送信パスが古いチャネル配信セマンティクスを保持することが証明された後、新しいメッセージライフサイクルでのみ assembled-turn の耐久性をデフォルトにします。

​

フェーズ 4: Prepared Dispatcher ブリッジ

• deliverDurableInboundReplyPayload を送信コンテキストブリッジに置き換える。
• 古いヘルパーはラッパーとして維持する。
• Telegram、WhatsApp、Slack、Signal、iMessage、Discord を先に移植する。これらはすでに durable-final 作業があるか、送信パスがより単純なため。
• prepared dispatcher は、送信コンテキストに明示的にオプトインするまで未対応として扱う。ドキュメントと changelog エントリでは、すべての自動最終返信を主張するのではなく、「assembled channel turns」と書くか、移行済みのチャネルパス名を挙げる必要がある。
• recordInboundSessionAndDispatchReply、direct-DM ヘルパー、および同様の公開互換ヘルパーは、挙動を維持する。後で明示的な送信コンテキストへのオプトインを公開してもよいが、呼び出し元が所有する配送コールバックより前に、汎用の durable 配送を自動で試みてはならない。

​

フェーズ 5: 統一されたライブライフサイクル

• 2 つの proof adapter で messages.live を構築する:
  • Telegram は送信、編集、stale final send 用。
  • Matrix は draft finalization と redaction fallback 用。
• その後、Discord、Slack、Mattermost、Teams、QQ Bot、Feishu を移行する。
• 各チャネルに parity tests が揃ってから、重複した preview finalization コードを削除する。

​

フェーズ 6: 公開 SDK

• openclaw/plugin-sdk/channel-message を追加する。
• これを推奨されるチャネル Plugin API として文書化する。
• package exports、entrypoint inventory、生成された API baselines、Plugin SDK ドキュメントを更新する。
• MessageOrigin、origin encode/decode hooks、共有 shouldDropOpenClawEcho predicate を channel-message SDK surface に含める。
• 古い subpaths の互換ラッパーを維持する。
• bundled plugins の移行後、reply-named SDK helpers をドキュメント上で deprecated としてマークする。

​

フェーズ 7: すべての送信元

• cron と heartbeat 通知
• task completions
• hook results
• approval prompts と approval results
• message tool sends
• subagent completion announcements
• 明示的な CLI または Control UI sends
• automation/broadcast paths

​

フェーズ 8: Turn の非推奨化

• channel.turn は少なくとも 1 つの互換期間ではラッパーとして維持する。
• migration notes を公開する。
• 古い imports に対して Plugin SDK compatibility tests を実行する。
• bundled plugin が不要になり、third-party contracts に安定した代替ができた後でのみ、古い内部ヘルパーを削除または非表示にする。

​

テスト計画

• durable send intent serialization と recovery。
• idempotency key reuse と duplicate suppression。
• receipt commit と replay skip。
• adapter が reconciliation をサポートする場合に、replay 前に reconciles する unknown_after_send recovery。
• 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.turn.run の simple adapter が引き続き record と send を行う。
• Legacy assembled-turn delivery は、チャネルが明示的に opt in しない限り durable にならない。
• channel.turn.runPrepared bridge が引き続き record と finalize を行う。
• Public compatibility helpers はデフォルトで caller-owned delivery callbacks を呼び出し、それらの callbacks より前に generic-send しない。
• Durable fallback delivery は restart 後に projected payload array 全体を replay し、early crash 後に後続 payloads が unrecorded のまま残らない。
• Durable assembled-turn delivery は platform message ids を buffered dispatcher に返す。
• durable delivery が disabled または unavailable の場合でも、custom delivery hooks は platform message ids を返す。
• assistant completion と platform send の間で restart しても final reply が残る。
• Preview draft は許可される場合にその場で finalize される。
• media/error/reply-target mismatch により normal delivery が必要な場合、Preview draft は cancel または redact される。
• Block streaming と preview streaming が同じテキストを両方配送しない。
• 早期に streamed された media が final delivery で重複しない。

• Telegram topic reply で polling ack が receive context の safe completed watermark まで遅延される。
• Telegram polling recovery で、persisted safe-completed offset model により accepted-but-not-delivered updates がカバーされる。
• Telegram stale preview が fresh final を送信し、preview をクリーンアップする。
• Telegram silent fallback が projected fallback payload をすべて送信する。
• Telegram silent fallback durability は、ループ反復ごとの単一 payload durable intent ではなく、projected fallback array 全体を atomic に記録する。
• Discord preview cancel on media/error/explicit reply。
• Discord prepared dispatcher finals は、ドキュメントまたは changelog が Discord final-reply durability を主張する前に、send context 経由で route される。
• iMessage durable final sends は monitor sent-message echo cache を populate する。
• LINE、Zalo、Nostr の legacy delivery paths は、adapter parity tests が存在するまで generic durable send によって bypass されない。
• Direct-DM/Nostr callback delivery は、complete message target と replay-safe send adapter に明示的に移行されない限り authoritative のまま。
• Slack tagged OpenClaw gateway failure messages は outbound で visible のままになり、tagged bot-room echoes は allowBots の前に drop され、同じ visible text を持つ untagged bot messages は通常の bot authorization に従う。
• Slack native stream fallback to draft preview in top-level DMs。
• Matrix preview finalization と redaction fallback。
• Matrix tagged OpenClaw gateway-failure room echoes from configured bot accounts は allowBots handling の前に drop される。
• Discord と Google Chat の shared-room gateway-failure cascade audits は、そこで generic protection を主張する前に allowBots modes をカバーする。
• 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 を保持する。
• WhatsApp、Signal、iMessage、Google Chat、LINE、IRC、Nostr、Nextcloud Talk、Synology Chat、Tlon、Twitch、Zalo、Zalo Personal の simple durable final sends。

• 開発中は対象を絞った Vitest files。
• full changed surface について Testbox で pnpm check:changed。
• complete refactor を landing する前、または public SDK/export changes の後に、Testbox でより広範な pnpm check。
• compatibility wrappers を削除する前に、少なくとも 1 つの edit-capable channel と 1 つの simple send-only channel で live または qa-channel smoke。

​

未解決の質問

• Telegram が最終的に grammY runner source を、OpenClaw の persisted restart watermark だけでなく platform-level redelivery を制御できる fully durable polling source に置き換えるべきか。
• durable live preview state を final send intent と同じ queue record に保存すべきか、sibling live-state store に保存すべきか。
• plugin-sdk/channel-message の出荷後、compatibility wrappers をどのくらいの期間文書化しておくか。
• third-party plugins は receive adapters を直接実装すべきか、それとも defineChannelMessageAdapter を通じて normalize/send/live hooks のみを提供すべきか。
• public SDK に公開して安全な receipt fields と、internal runtime state に留めるべきものはどれか。
• self-echo caches や participated-thread markers などの side effects を、send-context hooks、adapter-owned finalize steps、receipt subscribers のどれとしてモデル化すべきか。
• どのチャネルが native origin metadata を持ち、どのチャネルが persisted outbound registries を必要とし、どのチャネルが reliable cross-bot echo suppression を提供できないか。

​

受け入れ基準

• すべての bundled message channel が final visible output を messages.send 経由で送信する。
• すべての inbound message channel が messages.receive または文書化された compatibility wrapper 経由で入る。
• すべての preview/edit/stream channel が draft state と finalization に messages.live を使用する。
• channel.turn はラッパーのみである。
• Reply-named SDK helpers は compatibility exports であり、推奨パスではない。
• Durable recovery は restart 後に pending final sends を replay でき、final response を失わず、すでに committed sends を重複させない。platform outcome が unknown の sends は replay 前に reconciled されるか、その adapter について at-least-once として文書化される。
• Durable final sends は durable intent を書き込めない場合に fail closed する。ただし caller が文書化された non-durable mode を明示的に選択した場合を除く。
• Legacy channel-turn と SDK compatibility helpers は、デフォルトで direct channel-owned delivery を使用する。generic durable send は明示的な opt-in のみ。
• Receipts は multi-part deliveries のすべての platform message ids と、threading/edit convenience 用の primary id を保持する。
• Durable wrappers は direct delivery callbacks を置き換える前に channel-local side effects を保持する。
• Prepared dispatchers は、その final delivery path が明示的に send context を使用するまで durable として数えない。
• Fallback delivery はすべての projected payload を処理する。
• Durable fallback delivery はすべての projected payload を 1 つの replayable intent または batch plan に記録する。
• OpenClaw-originated gateway failure output は humans に visible だが、origin contract のサポートを宣言するチャネルでは tagged bot-authored room echoes が bot authorization の前に drop される。
• ドキュメントは send、receive、live、state、receipts、relations、failure policy、migration、test coverage を説明する。

​

関連

• メッセージ
• ストリーミングとチャンク化
• 進行状況ドラフト
• リトライポリシー
• Channel turn kernel