Refaktoryzacja cyklu życia wiadomości

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.

• Podstawowymi prymitywami rdzenia powinny być odbieranie i wysyłanie, a nie odpowiadanie.
• Odpowiedź jest tylko relacją w wiadomości wychodzącej.
• Tura to udogodnienie przetwarzania przychodzącego, a nie właściciel dostarczania.
• Wysyłanie musi być oparte na kontekście: begin, renderowanie, podgląd lub strumieniowanie, wysłanie końcowe, zatwierdzenie, niepowodzenie.
• Odbieranie także musi być oparte na kontekście: normalizacja, deduplikacja, routing, zapis, wysłanie do obsługi, potwierdzenie platformy, niepowodzenie.
• Publiczny SDK pluginów powinien zostać sprowadzony do jednej małej powierzchni wiadomości kanału.

​

Problemy

• Proste adaptery przychodzące używają runtime.channel.turn.run.
• Rozbudowane adaptery używają runtime.channel.turn.runPrepared.
• Starsze pomocniki używają dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, pomocników ładunku odpowiedzi, dzielenia odpowiedzi na fragmenty, odwołań odpowiedzi oraz pomocników środowiska uruchomieniowego dla wiadomości wychodzących.
• Strumieniowanie podglądu znajduje się w dyspozytorach specyficznych dla kanałów.
• Trwałość końcowego dostarczania jest dodawana wokół istniejących ścieżek ładunku odpowiedzi.

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

​

Cele

• Jeden cykl życia rdzenia dla wszystkich ścieżek odbierania i wysyłania wiadomości kanału.
• Trwałe końcowe wysyłki domyślnie w nowym cyklu życia wiadomości po tym, jak adapter zadeklaruje zachowanie bezpieczne do ponownego odtwarzania.
• Wspólna semantyka podglądu, edycji, strumienia, finalizacji, ponowień, odzyskiwania i potwierdzeń.
• Mała powierzchnia SDK pluginów, którą pluginy firm trzecich mogą poznać i utrzymywać.
• Zgodność dla istniejących wywołań channel.turn podczas migracji.
• Jasne punkty rozszerzeń dla nowych możliwości kanałów.
• Brak gałęzi specyficznych dla platform w rdzeniu.
• Brak wiadomości kanału typu token-delta. Strumieniowanie kanału pozostaje podglądem wiadomości, edycją, dopisaniem albo dostarczeniem ukończonego bloku.
• Ustrukturyzowane metadane pochodzenia OpenClaw dla wyjścia operacyjnego/systemowego, aby widoczne awarie Gateway nie wracały do współdzielonych pokoi z włączonym botem jako nowe prompty.

​

Poza zakresem

• Nie usuwać runtime.channel.turn.* w pierwszej fazie.
• Nie wymuszać na każdym kanale tego samego natywnego zachowania transportu.
• Nie uczyć rdzenia tematów Telegram, natywnych strumieni Slack, redakcji Matrix, kart Feishu, głosu QQ ani aktywności Teams.
• Nie publikować wszystkich wewnętrznych pomocników migracji jako stabilnego API SDK.
• Nie sprawiać, by ponowienia odtwarzały zakończone nieidempotentne operacje platformy.

​

Model referencyjny

• Chat
• Thread
• Channel
• Message
• metody adaptera, takie jak postMessage, editMessage, deleteMessage, stream, startTyping i pobieranie historii
• adapter stanu dla deduplikacji, blokad, kolejek i utrwalania

• Trwałe intencje wysyłania wychodzącego przed bezpośrednimi wywołaniami transportu.
• Jawne konteksty wysyłania z rozpoczęciem, zatwierdzeniem i niepowodzeniem.
• Konteksty odbierania, które znają politykę potwierdzania platformy.
• Potwierdzenia, które przetrwają restart i mogą sterować edycjami, usunięciami, odzyskiwaniem oraz tłumieniem duplikatów.
• Mniejszy publiczny SDK. Dołączone pluginy mogą używać wewnętrznych pomocników środowiska uruchomieniowego, ale pluginy firm trzecich powinny widzieć jedno spójne API wiadomości.
• Zachowanie specyficzne dla agentów: sesje, transkrypty, strumieniowanie bloków, postęp narzędzi, zatwierdzenia, dyrektywy mediów, ciche odpowiedzi i historia wzmianek grupowych.

​

Model rdzenia

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

​

Terminy wiadomości

​

Wiadomość

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

​

Cel

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

​

Relacja

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

​

Pochodzenie

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

​

Potwierdzenie

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

​

Kontekst odbierania

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

• Potwierdzenie transportu: informuje Webhook lub gniazdo platformy, że OpenClaw zaakceptował kopertę zdarzenia. Niektóre platformy wymagają tego przed wysłaniem do obsługi.
• Potwierdzenie offsetu odpytywania: przesuwa kursor, aby to samo zdarzenie nie zostało pobrane ponownie. Nie może to przesunąć się za pracę, której nie da się odzyskać.
• Potwierdzenie zapisu przychodzącego: potwierdza, że OpenClaw utrwalił wystarczająco dużo metadanych przychodzących, aby deduplikować i trasować ponowne dostarczenie.
• Potwierdzenie widoczne dla użytkownika: opcjonalne zachowanie odczytu/statusu/pisania; nigdy nie jest granicą trwałości.

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

​

Kontekst wysyłania

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

​

Kontekst na żywo

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 wysyła i edytuje podgląd, ze świeżą wersją końcową po przekroczeniu wieku nieaktualności podglądu.
• Discord wysyła i edytuje podgląd, anuluje przy multimediach, błędzie albo jawnej odpowiedzi.
• Slack używa natywnego strumienia albo roboczego podglądu zależnie od kształtu wątku.
• Finalizacja roboczego wpisu Mattermost.
• Finalizacja roboczego zdarzenia Matrix albo redakcja przy niezgodności.
• Natywny strumień postępu Teams.
• Strumień QQ Bot albo zebrana ścieżka awaryjna.

​

Powierzchnia adaptera

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

​

Redukcja publicznego SDK

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• większość publicznych użyć outbound-runtime
• doraźne helpery cyklu życia roboczego strumienia

​

Relacja z turą kanału

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

​

Bariery zgodności

• channel.turn.run i dispatchAssembledChannelTurn używają wywołania zwrotnego dostarczania kanału, chyba że ten kanał jawnie dostarczy zweryfikowany trwały obiekt polityki/opcji.
• channel.turn.runPrepared pozostaje własnością kanału, dopóki przygotowany dyspozytor jawnie nie wywoła kontekstu wysyłki.
• Publiczne helpery zgodności, takie jak recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase i helpery bezpośrednich wiadomości prywatnych nigdy nie wstrzykują ogólnego trwałego dostarczania przed dostarczonym przez wywołującego wywołaniem zwrotnym deliver albo reply.

• Trwałe dostarczanie odpowiedzi końcowej zwraca dyskryminowany status. handled_visible i handled_no_send są terminalne; unsupported i not_applicable mogą przejść awaryjnie do dostarczania obsługiwanego przez kanał; failed propaguje błąd wysyłki.
• Ogólne trwałe dostarczanie odpowiedzi końcowej jest ograniczane przez możliwości adaptera, takie jak ciche dostarczanie, zachowanie celu odpowiedzi, zachowanie natywnego cytatu oraz haki wysyłania wiadomości. Brak parytetu powinien wybierać dostarczanie obsługiwane przez kanał, a nie ogólną wysyłkę zmieniającą zachowanie widoczne dla użytkownika.
• Trwałe wysyłki oparte na kolejce ujawniają referencję intencji dostarczenia. Istniejące pola sesji pendingFinalDelivery* mogą przenosić identyfikator intencji w trakcie przejścia; stanem docelowym jest magazyn MessageSendIntent zamiast zamrożonego tekstu odpowiedzi oraz doraźnych pól kontekstu.

• Ogólny adapter wysyłki wykonuje takie samo renderowanie i zachowanie transportowe jak stara ścieżka bezpośrednia.
• Lokalne skutki uboczne po wysyłce są zachowane przez kontekst wysyłki.
• Adapter zwraca potwierdzenia lub wyniki dostarczenia ze wszystkimi identyfikatorami wiadomości platformy.
• Przygotowane ścieżki dyspozytora albo wywołują nowy kontekst wysyłki, albo pozostają udokumentowane jako poza trwałą gwarancją.
• Dostarczanie awaryjne obsługuje każdy rzutowany ładunek, a nie tylko pierwszy.
• Trwałe dostarczanie awaryjne zapisuje całą tablicę rzutowanych ładunków jako jedną odtwarzalną intencję albo plan wsadowy.

• Dostarczanie monitora iMessage zapisuje wysłane wiadomości w pamięci podręcznej echa po udanej wysyłce. Trwałe wysyłki końcowe nadal muszą wypełniać tę pamięć podręczną, w przeciwnym razie OpenClaw może ponownie pobrać własne odpowiedzi końcowe jako przychodzące wiadomości użytkownika.
• Tlon dołącza opcjonalny podpis modelu i zapisuje wątki z udziałem po odpowiedziach grupowych. Ogólne trwałe dostarczanie nie może pomijać tych efektów; albo przenieś je do adapterów renderowania/wysyłania/finalizacji Tlon, albo pozostaw Tlon na ścieżce obsługiwanej przez kanał.
• Discord i inne przygotowane dyspozytory już posiadają bezpośrednie dostarczanie i zachowanie podglądu. Nie są objęte trwałą gwarancją złożonej tury, dopóki ich przygotowane dyspozytory jawnie nie skierują odpowiedzi końcowych przez kontekst wysyłki.
• Ciche dostarczanie awaryjne Telegram musi dostarczyć pełną tablicę rzutowanych ładunków. Skrót dla pojedynczego ładunku może porzucić dodatkowe ładunki awaryjne po rzutowaniu.
• LINE, BlueBubbles, Zalo, Nostr i inne istniejące ścieżki złożone/pomocnicze mogą mieć obsługę tokenów odpowiedzi, pośredniczenie mediów, pamięci podręczne wysłanych wiadomości, czyszczenie ładowania/statusu albo cele wyłącznie callbackowe. Pozostają na dostarczaniu obsługiwanym przez kanał, dopóki te semantyki nie zostaną odzwierciedlone przez adapter wysyłki i zweryfikowane testami.
• Pomocniki bezpośrednich DM mogą mieć callback odpowiedzi, który jest jedynym poprawnym celem transportu. Ogólne wysyłanie wychodzące nie może zgadywać na podstawie OriginatingTo albo To i pomijać tego callbacku.
• Dane wyjściowe awarii OpenClaw Gateway muszą pozostać widoczne dla ludzi, ale oznaczone echa pokojów autorstwa bota muszą zostać odrzucone przed autoryzacją allowBots. Kanały nie mogą implementować tego przy użyciu filtrów prefiksów widocznego tekstu poza krótkim awaryjnym obejściem; trwały kontrakt to ustrukturyzowane metadane pochodzenia.

​

Wewnętrzna pamięć

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

​

Klasy awarii

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

• Ponawiaj transient i rate_limit.
• Nie ponawiaj invalid_payload, chyba że istnieje awaryjna ścieżka renderowania.
• Nie ponawiaj auth ani permission, dopóki konfiguracja się nie zmieni.
• Dla not_found pozwól finalizacji na żywo przejść awaryjnie z edycji na świeżą wysyłkę, gdy kanał deklaruje, że jest to bezpieczne.
• Dla conflict użyj reguł potwierdzeń/idempotencji, aby zdecydować, czy wiadomość już istnieje.
• Każdy błąd po tym, jak adapter mógł ukończyć wejście/wyjście platformy, ale przed zatwierdzeniem potwierdzenia, staje się unknown_after_send, chyba że adapter potrafi udowodnić, że operacja platformy nie nastąpiła.

​

Mapowanie kanałów

​

Plan migracji

​

Faza 1: Wewnętrzna domena wiadomości

• Dodaj typy src/channels/message/* dla wiadomości, celów, relacji, źródeł, potwierdzeń, możliwości, trwałych intencji, kontekstu odbierania, kontekstu wysyłania, kontekstu live i klas awarii.
• Dodaj origin?: MessageOrigin do typu ładunku mostu migracyjnego używanego przez bieżące dostarczanie odpowiedzi, a następnie przenieś to pole do ChannelMessage i renderowanych typów wiadomości, gdy refaktoryzacja zastąpi ładunki odpowiedzi.
• Utrzymaj to jako wewnętrzne, dopóki adaptery i testy nie potwierdzą kształtu.
• Dodaj czyste testy jednostkowe dla przejść stanów i serializacji.

​

Faza 2: Rdzeń trwałego wysyłania

• Przenieś istniejącą kolejkę wychodzącą z trwałości ładunków odpowiedzi do trwałych intencji wysyłania wiadomości.
• Pozwól trwałej intencji wysyłania przenosić projektowaną tablicę ładunków lub plan partii, a nie tylko jeden ładunek odpowiedzi.
• Zachowaj obecne zachowanie odzyskiwania kolejki przez konwersję zgodności.
• Spraw, aby deliverOutboundPayloads wywoływało messages.send.
• Uczyń trwałość wysyłania końcowego domyślną i zamykaj z błędem, gdy trwałej intencji nie da się zapisać w nowym cyklu życia wiadomości, po tym jak adapter zadeklaruje bezpieczeństwo odtwarzania. Istniejące ścieżki zgodności channel-turn i SDK pozostają domyślnie bezpośrednim wysyłaniem w tej fazie.
• Rejestruj potwierdzenia spójnie.
• Zwracaj potwierdzenia i wyniki dostarczania do pierwotnego wywołującego dyspozytor zamiast traktować trwałe wysyłanie jako końcowy efekt uboczny.
• Utrwalaj pochodzenie wiadomości przez trwałe intencje wysyłania, aby odzyskiwanie, odtwarzanie i wysyłanie w częściach zachowywały operacyjne pochodzenie OpenClaw.

​

Faza 3: Most obrotu kanału

• Zaimplementuj ponownie channel.turn.run i dispatchAssembledChannelTurn na bazie messages.receive i messages.send.
• Utrzymaj stabilność bieżących typów faktów.
• Domyślnie zachowaj dotychczasowe zachowanie. Kanał złożonego obrotu staje się trwały tylko wtedy, gdy jego adapter jawnie wybierze politykę trwałości bezpieczną dla odtwarzania.
• Zachowaj durable: false jako furtkę zgodności dla ścieżek, które finalizują natywne edycje i nie mogą jeszcze bezpiecznie odtwarzać, ale nie polegaj na znacznikach false, aby chronić niezmodernizowane kanały.
• Domyślnie włącz trwałość złożonego obrotu tylko w nowym cyklu życia wiadomości, po tym jak mapowanie kanału potwierdzi, że ogólna ścieżka wysyłania zachowuje stare semantyki dostarczania kanału.

​

Faza 4: Most przygotowanego dyspozytora

• Zastąp deliverDurableInboundReplyPayload mostem kontekstu wysyłania.
• Zachowaj stary helper jako wrapper.
• Najpierw przenieś Telegram, WhatsApp, Slack, Signal, iMessage i Discord, ponieważ mają już pracę nad trwałym finalnym wysyłaniem albo prostsze ścieżki wysyłania.
• Traktuj każdy przygotowany dispatcher jako nieobjęty pokryciem, dopóki wyraźnie nie zdecyduje się na kontekst wysyłania. Dokumentacja i wpisy changeloga muszą mówić „złożone przebiegi kanału” albo nazywać zmigrowane ścieżki kanałów, zamiast twierdzić, że obejmują wszystkie automatyczne odpowiedzi finalne.
• Zachowaj recordInboundSessionAndDispatchReply, helpery bezpośrednich DM i podobne publiczne helpery zgodności w sposób zachowujący dotychczasowe zachowanie. Mogą później udostępnić jawne włączenie kontekstu wysyłania, ale nie mogą automatycznie próbować ogólnego trwałego dostarczania przed callbackiem dostarczania należącym do wywołującego.

​

Faza 5: Ujednolicony Cykl Życia Na Żywo

• Zbuduj messages.live z dwoma adapterami dowodowymi:
  • Telegram dla wysyłania, edycji oraz wysyłania przedawnionego finalnego komunikatu.
  • Matrix dla finalizacji wersji roboczej oraz zapasowej redakcji.
• Następnie zmigruj Discord, Slack, Mattermost, Teams, QQ Bot i Feishu.
• Usuń zduplikowany kod finalizacji podglądu dopiero wtedy, gdy każdy kanał będzie mieć testy parytetu.

​

Faza 6: Publiczny SDK

• Dodaj openclaw/plugin-sdk/channel-message.
• Udokumentuj go jako preferowane API Plugin kanału.
• Zaktualizuj eksporty pakietu, spis punktów wejścia, wygenerowane baseline API oraz dokumentację SDK pluginów.
• Uwzględnij MessageOrigin, haki kodowania/dekodowania origin oraz współdzielony predykat shouldDropOpenClawEcho w powierzchni SDK channel-message.
• Zachowaj wrappery zgodności dla starych podścieżek.
• Oznacz helpery SDK nazwane od odpowiedzi jako przestarzałe w dokumentacji po migracji bundled pluginów.

​

Faza 7: Wszyscy Nadawcy

• powiadomienia Cron i Heartbeat
• ukończenia zadań
• wyniki hooków
• prośby o zatwierdzenie i wyniki zatwierdzeń
• wysyłki narzędzia wiadomości
• ogłoszenia ukończenia subagenta
• jawne wysyłki CLI lub Control UI
• ścieżki automatyzacji/broadcastu

​

Faza 8: Wycofanie Turn

• Zachowaj channel.turn jako wrapper przez co najmniej jedno okno zgodności.
• Opublikuj notatki migracyjne.
• Uruchom testy zgodności SDK pluginów względem starych importów.
• Usuń albo ukryj stare wewnętrzne helpery dopiero wtedy, gdy żaden bundled plugin ich nie potrzebuje, a kontrakty zewnętrznych pluginów mają stabilny zamiennik.

​

Plan testów

• Serializacja i odzyskiwanie trwałej intencji wysyłania.
• Ponowne użycie klucza idempotencji i tłumienie duplikatów.
• Commit potwierdzenia i pominięcie odtworzenia.
• Odzyskiwanie unknown_after_send, które uzgadnia stan przed odtworzeniem, gdy adapter obsługuje uzgadnianie.
• Polityka klasyfikacji awarii.
• Sekwencjonowanie polityki potwierdzania odbioru.
• Mapowanie relacji dla odpowiedzi, kontynuacji, wysyłek systemowych i broadcastowych.
• Fabryka origin dla awarii Gateway oraz predykat shouldDropOpenClawEcho.
• Zachowanie origin przez normalizację payloadu, dzielenie na części, serializację trwałej kolejki i odzyskiwanie.

• Prosty adapter channel.turn.run nadal rejestruje i wysyła.
• Starsze dostarczanie złożonego przebiegu nie staje się trwałe, chyba że kanał wyraźnie się na to zdecyduje.
• Most channel.turn.runPrepared nadal rejestruje i finalizuje.
• Publiczne helpery zgodności domyślnie wywołują callbacki dostarczania należące do wywołującego i nie wykonują ogólnego wysłania przed tymi callbackami.
• Trwałe dostarczanie zapasowe odtwarza całą przewidywaną tablicę payloadów po restarcie i nie może pozostawić późniejszych payloadów niezarejestrowanych po wczesnej awarii.
• Trwałe dostarczanie złożonego przebiegu zwraca identyfikatory wiadomości platformy do buforowanego dispatchera.
• Niestandardowe haki dostarczania nadal zwracają identyfikatory wiadomości platformy, gdy trwałe dostarczanie jest wyłączone lub niedostępne.
• Odpowiedź finalna przetrwa restart między ukończeniem asystenta a wysłaniem na platformę.
• Wersja robocza podglądu finalizuje się w miejscu, gdy jest to dozwolone.
• Wersja robocza podglądu jest anulowana albo zredagowana, gdy media/błąd/niezgodność celu odpowiedzi wymaga normalnego dostarczania.
• Strumieniowanie bloków i strumieniowanie podglądu nie dostarczają tego samego tekstu jednocześnie.
• Media przesłane strumieniowo wcześnie nie są duplikowane w finalnym dostarczaniu.

• Odpowiedź tematu Telegram z opóźnionym potwierdzeniem pollingu do bezpiecznego ukończonego znacznika wodnego kontekstu odbioru.
• Odzyskiwanie pollingu Telegram dla zaakceptowanych, ale niedostarczonych aktualizacji objęte utrwalonym modelem bezpiecznego ukończonego offsetu.
• Przedawniony podgląd Telegram wysyła świeży finalny komunikat i czyści podgląd.
• Cicha ścieżka zapasowa Telegram wysyła każdy przewidywany payload zapasowy.
• Trwałość cichej ścieżki zapasowej Telegram rejestruje pełną przewidywaną tablicę zapasową atomowo, a nie jedną trwałą intencję z pojedynczym payloadem na iterację pętli.
• Discord anuluje podgląd przy mediach/błędzie/jawnej odpowiedzi.
• Finalne komunikaty przygotowanego dispatchera Discord przechodzą przez kontekst wysyłania, zanim dokumentacja lub changelog ogłosi trwałość finalnych odpowiedzi Discord.
• Trwałe finalne wysyłki iMessage zasilają cache echa wysłanych wiadomości monitora.
• Starsze ścieżki dostarczania LINE, BlueBubbles, Zalo i Nostr nie są omijane przez ogólne trwałe wysyłanie, dopóki nie istnieją testy parytetu ich adapterów.
• Dostarczanie callbackiem Direct-DM/Nostr pozostaje autorytatywne, chyba że zostanie wyraźnie zmigrowane do kompletnego celu wiadomości i odpornego na odtwarzanie adaptera wysyłania.
• Otagowane komunikaty awarii Slack OpenClaw Gateway pozostają widoczne wychodząco, otagowane echa pokoju bota są odrzucane przed allowBots, a nieotagowane wiadomości bota z tym samym widocznym tekstem nadal przechodzą normalną autoryzację botów.
• Natywna zapasowa ścieżka strumienia Slack do wersji roboczej podglądu w DM najwyższego poziomu.
• Finalizacja podglądu Matrix i zapasowa redakcja.
• Otagowane echa pokojowe awarii OpenClaw Gateway w Matrix z skonfigurowanych kont botów są odrzucane przed obsługą allowBots.
• Audyty kaskady awarii Gateway w pokojach współdzielonych Discord i Google Chat obejmują tryby allowBots przed deklarowaniem ogólnej ochrony w tych miejscach.
• Finalizacja wersji roboczej Mattermost i zapasowe świeże wysłanie.
• Finalizacja natywnego postępu Teams.
• Feishu tłumi zduplikowany finalny komunikat.
• Zapasowa ścieżka timeoutu akumulatora QQ Bot.
• Trwałe finalne wysyłki Tlon zachowują renderowanie sygnatury modelu i śledzenie uczestniczących wątków.
• Proste trwałe finalne wysyłki WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo i Zalo Personal.

• Docelowe pliki Vitest podczas rozwoju.
• pnpm check:changed w Testbox dla pełnej zmienionej powierzchni.
• Szersze pnpm check w Testbox przed landowaniem kompletnego refaktoru albo po zmianach publicznego SDK/eksportów.
• Smoke live albo qa-channel dla co najmniej jednego kanału obsługującego edycję i jednego prostego kanału tylko do wysyłania przed usunięciem wrapperów zgodności.

​

Otwarte pytania

• Czy Telegram powinien docelowo zastąpić źródło runnera grammY w pełni trwałym źródłem pollingu, które może kontrolować ponowne dostarczanie na poziomie platformy, a nie tylko utrwalony znacznik wodny restartu OpenClaw.
• Czy trwały stan podglądu live powinien być przechowywany w tym samym rekordzie kolejki co finalna intencja wysyłania, czy w sąsiednim magazynie stanu live.
• Jak długo wrappery zgodności pozostają udokumentowane po wydaniu plugin-sdk/channel-message.
• Czy zewnętrzne pluginy powinny implementować adaptery odbioru bezpośrednio, czy tylko dostarczać haki normalize/send/live przez defineChannelMessageAdapter.
• Które pola potwierdzeń można bezpiecznie udostępnić w publicznym SDK względem wewnętrznego stanu runtime.
• Czy efekty uboczne, takie jak cache self-echo i znaczniki uczestniczących wątków, powinny być modelowane jako haki kontekstu wysyłania, kroki finalizacji należące do adaptera albo subskrybenci potwierdzeń.
• Które kanały mają natywne metadane origin, które potrzebują utrwalonych rejestrów wychodzących, a które nie mogą zaoferować niezawodnego tłumienia echa między botami.

​

Kryteria akceptacji

• Każdy bundled kanał wiadomości wysyła finalne widoczne wyjście przez messages.send.
• Każdy przychodzący kanał wiadomości wchodzi przez messages.receive albo udokumentowany wrapper zgodności.
• Każdy kanał podglądu/edycji/strumienia używa messages.live dla stanu wersji roboczej i finalizacji.
• channel.turn jest tylko wrapperem.
• Helpery SDK nazwane od odpowiedzi są eksportami zgodności, a nie zalecaną ścieżką.
• Trwałe odzyskiwanie może odtworzyć oczekujące finalne wysyłki po restarcie bez utraty finalnej odpowiedzi ani duplikowania już zatwierdzonych wysyłek; wysyłki, których wynik platformy jest nieznany, są uzgadniane przed odtworzeniem albo udokumentowane jako co najmniej jednokrotne dla danego adaptera.
• Trwałe finalne wysyłki zamykają się bezpiecznie przy awarii, gdy trwała intencja nie może zostać zapisana, chyba że wywołujący wyraźnie wybrał udokumentowany tryb nietrwały.
• Starsze helpery channel-turn i zgodności SDK domyślnie używają bezpośredniego dostarczania należącego do kanału; ogólne trwałe wysyłanie jest tylko jawnym włączeniem.
• Potwierdzenia zachowują wszystkie identyfikatory wiadomości platformy dla dostarczeń wieloczęściowych oraz identyfikator główny dla wygody wątkowania/edycji.
• Trwałe wrappery zachowują lokalne dla kanału efekty uboczne przed zastąpieniem bezpośrednich callbacków dostarczania.
• Przygotowane dispatchery nie są liczone jako trwałe, dopóki ich finalna ścieżka dostarczania wyraźnie nie używa kontekstu wysyłania.
• Dostarczanie zapasowe obsługuje każdy przewidywany payload.
• Trwałe dostarczanie zapasowe rejestruje każdy przewidywany payload w jednej odtwarzalnej intencji albo planie batcha.
• Wyjście awarii Gateway pochodzące z OpenClaw jest widoczne dla ludzi, ale otagowane echa pokojowe autorstwa bota są odrzucane przed autoryzacją bota na kanałach, które deklarują obsługę kontraktu origin.
• Dokumentacja wyjaśnia wysyłanie, odbiór, live, stan, potwierdzenia, relacje, politykę awarii, migrację i pokrycie testami.

​

Powiązane

• Wiadomości
• Strumieniowanie i dzielenie na części
• Wersje robocze postępu
• Polityka ponawiania
• Jądro przebiegu kanału