vilvona 1.0.0

package/docs/plugins/sdk-agent-harness.md

@@ -0,0 +1,339 @@
+---
+summary: "Experimental SDK surface for plugins that replace the low level embedded agent executor"
+title: "Agent harness plugins"
+sidebarTitle: "Agent Harness"
+read_when:
+  - You are changing the embedded agent runtime or harness registry
+  - You are registering an agent harness from a bundled or trusted plugin
+  - You need to understand how the Codex plugin relates to model providers
+---
+
+An **agent harness** is the low level executor for one prepared OpenClaw agent
+turn. It is not a model provider, not a channel, and not a tool registry.
+For the user-facing mental model, see [Agent runtimes](/concepts/agent-runtimes).
+
+Use this surface only for bundled or trusted native plugins. The contract is
+still experimental because the parameter types intentionally mirror the current
+embedded runner.
+
+## When to use a harness
+
+Register an agent harness when a model family has its own native session
+runtime and the normal OpenClaw provider transport is the wrong abstraction.
+
+Examples:
+
+- a native coding-agent server that owns threads and compaction
+- a local CLI or daemon that must stream native plan/reasoning/tool events
+- a model runtime that needs its own resume id in addition to the OpenClaw
+  session transcript
+
+Do **not** register a harness just to add a new LLM API. For normal HTTP or
+WebSocket model APIs, build a [provider plugin](/plugins/sdk-provider-plugins).
+
+## What core still owns
+
+Before a harness is selected, OpenClaw has already resolved:
+
+- provider and model
+- runtime auth state
+- thinking level and context budget
+- the OpenClaw transcript/session file
+- workspace, sandbox, and tool policy
+- channel reply callbacks and streaming callbacks
+- model fallback and live model switching policy
+
+That split is intentional. A harness runs a prepared attempt; it does not pick
+providers, replace channel delivery, or silently switch models.
+
+The prepared attempt also includes `params.runtimePlan`, an OpenClaw-owned
+policy bundle for runtime decisions that must stay shared across OpenClaw and native
+harnesses:
+
+- `runtimePlan.tools.normalize(...)` and
+  `runtimePlan.tools.logDiagnostics(...)` for provider-aware tool schema policy
+- `runtimePlan.transcript.resolvePolicy(...)` for transcript sanitization and
+  tool-call repair policy
+- `runtimePlan.delivery.isSilentPayload(...)` for shared `NO_REPLY` and media
+  delivery suppression
+- `runtimePlan.outcome.classifyRunResult(...)` for model fallback classification
+- `runtimePlan.observability` for resolved provider/model/harness metadata
+
+Harnesses may use the plan for decisions that need to match OpenClaw behavior, but
+should still treat it as host-owned attempt state. Do not mutate it or use it to
+switch providers/models inside a turn.
+
+## Register a harness
+
+**Import:** `openclaw/plugin-sdk/agent-harness`
+
+```typescript
+import type { AgentHarness } from "openclaw/plugin-sdk/agent-harness";
+import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
+
+const myHarness: AgentHarness = {
+  id: "my-harness",
+  label: "My native agent harness",
+
+  supports(ctx) {
+    return ctx.provider === "my-provider"
+      ? { supported: true, priority: 100 }
+      : { supported: false };
+  },
+
+  async runAttempt(params) {
+    // Start or resume your native thread.
+    // Use params.prompt, params.tools, params.images, params.onPartialReply,
+    // params.onAgentEvent, and the other prepared attempt fields.
+    return await runMyNativeTurn(params);
+  },
+};
+
+export default definePluginEntry({
+  id: "my-native-agent",
+  name: "My Native Agent",
+  description: "Runs selected models through a native agent daemon.",
+  register(api) {
+    api.registerAgentHarness(myHarness);
+  },
+});
+```
+
+## Selection policy
+
+OpenClaw chooses a harness after provider/model resolution:
+
+1. Model-scoped runtime policy wins.
+2. Provider-scoped runtime policy comes next.
+3. `auto` asks registered harnesses if they support the resolved
+   provider/model.
+4. If no registered harness matches, OpenClaw uses its embedded runtime.
+
+Plugin harness failures surface as run failures. In `auto` mode, embedded fallback is
+only used when no registered plugin harness supports the resolved
+provider/model. Once a plugin harness has claimed a run, OpenClaw does not
+replay that same turn through another runtime because that can change
+auth/runtime semantics or duplicate side effects.
+
+Whole-session and whole-agent runtime pins are ignored by selection. That
+includes stale session `agentHarnessId` values, `agents.defaults.agentRuntime`,
+`agents.list[].agentRuntime`, and `OPENCLAW_AGENT_RUNTIME`. `/status` shows the
+effective runtime selected from the provider/model route.
+If the selected harness is surprising, enable `agents/harness` debug logging and
+inspect the gateway's structured `agent harness selected` record. It includes
+the selected harness id, selection reason, runtime/fallback policy, and, in
+`auto` mode, each plugin candidate's support result.
+
+The bundled Codex plugin registers `codex` as its harness id. Core treats that
+as an ordinary plugin harness id; Codex-specific aliases belong in the plugin
+or operator config, not in the shared runtime selector.
+
+## Provider plus harness pairing
+
+Most harnesses should also register a provider. The provider makes model refs,
+auth status, model metadata, and `/model` selection visible to the rest of
+OpenClaw. The harness then claims that provider in `supports(...)`.
+
+The bundled Codex plugin follows this pattern:
+
+- preferred user model refs: `openai/gpt-5.5`
+- compatibility refs: legacy `codex/gpt-*` refs remain accepted, but new
+  configs should not use them as normal provider/model refs
+- harness id: `codex`
+- auth: synthetic provider availability, because the Codex harness owns the
+  native Codex login/session
+- app-server request: OpenClaw sends the bare model id to Codex and lets the
+  harness talk to the native app-server protocol
+
+The Codex plugin is additive. Plain `openai/gpt-*` agent refs on the official
+OpenAI provider select the Codex harness by default. Older `codex/gpt-*` refs
+still select the Codex provider and harness for compatibility.
+
+For operator setup, model prefix examples, and Codex-only configs, see
+[Codex Harness](/plugins/codex-harness).
+
+OpenClaw requires Codex app-server `0.125.0` or newer. The Codex plugin checks
+the app-server initialize handshake and blocks older or unversioned servers so
+OpenClaw only runs against the protocol surface it has been tested with. The
+`0.125.0` floor includes the native MCP hook payload support that landed in
+Codex `0.124.0`, while pinning OpenClaw to the newer tested stable line.
+
+### Tool-result middleware
+
+Bundled plugins and explicitly enabled installed plugins with matching manifest
+contracts can attach runtime-neutral tool-result middleware through
+`api.registerAgentToolResultMiddleware(...)` when their manifest declares the
+targeted runtime ids in `contracts.agentToolResultMiddleware`. This trusted
+seam is for async tool-result transforms that must run before OpenClaw or Codex
+feeds tool output back into the model.
+
+Legacy bundled plugins can still use
+`api.registerCodexAppServerExtensionFactory(...)` for Codex app-server-only
+middleware, but new result transforms should use the runtime-neutral API.
+The embedded-runner-only `api.registerEmbeddedExtensionFactory(...)` hook has been removed;
+embedded tool-result transforms must use runtime-neutral middleware.
+
+### Terminal outcome classification
+
+Native harnesses that own their own protocol projection can use
+`classifyAgentHarnessTerminalOutcome(...)` from
+`openclaw/plugin-sdk/agent-harness-runtime` when a completed turn produced no
+visible assistant text. The helper returns `empty`, `reasoning-only`, or
+`planning-only` so OpenClaw's fallback policy can decide whether to retry on a
+different model. It intentionally leaves prompt errors, in-flight turns, and
+intentional silent replies such as `NO_REPLY` unclassified.
+
+### Native Codex harness mode
+
+The bundled `codex` harness is the native Codex mode for embedded OpenClaw
+agent turns. Enable the bundled `codex` plugin first, and include `codex` in
+`plugins.allow` if your config uses a restrictive allowlist. Native app-server
+configs should use `openai/gpt-*`; OpenAI agent turns select the Codex harness
+by default. Legacy Codex model refs routes should be repaired with
+`openclaw doctor --fix`, and legacy `codex/*` model refs remain compatibility
+aliases for the native harness.
+
+When this mode runs, Codex owns the native thread id, resume behavior,
+compaction, and app-server execution. OpenClaw still owns the chat channel,
+visible transcript mirror, tool policy, approvals, media delivery, and session
+selection. Use provider/model `agentRuntime.id: "codex"` when you need to prove
+that only the Codex app-server path can claim the run. Explicit plugin runtimes
+fail closed; Codex app-server selection failures and runtime failures are not
+retried through another runtime.
+
+## Runtime strictness
+
+By default, OpenClaw uses `auto` provider/model runtime policy: registered
+plugin harnesses can claim a provider/model pair, and the embedded runtime
+handles the turn when none match. OpenAI agent refs on the official OpenAI provider default to Codex.
+Use an explicit provider/model plugin runtime such as
+`agentRuntime.id: "codex"` when missing harness selection should fail instead
+of routing through the embedded runtime. Selected plugin harness failures always
+fail hard. This does not block an explicit provider/model `agentRuntime.id: "openclaw"`.
+
+For Codex-only embedded runs:
+
+```json
+{
+  "models": {
+    "providers": {
+      "openai": {
+        "agentRuntime": {
+          "id": "codex"
+        }
+      }
+    }
+  },
+  "agents": {
+    "defaults": {
+      "model": "openai/gpt-5.5"
+    }
+  }
+}
+```
+
+If you want a CLI backend for one canonical model, put the runtime on that
+model entry:
+
+```json
+{
+  "agents": {
+    "defaults": {
+      "model": "anthropic/claude-opus-4-8",
+      "models": {
+        "anthropic/claude-opus-4-8": {
+          "agentRuntime": {
+            "id": "claude-cli"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+Per-agent overrides use the same model-scoped shape:
+
+```json
+{
+  "agents": {
+    "list": [
+      {
+        "id": "codex-only",
+        "model": "openai/gpt-5.5",
+        "models": {
+          "openai/gpt-5.5": {
+            "agentRuntime": { "id": "codex" }
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+Legacy whole-agent runtime examples like this are ignored:
+
+```json
+{
+  "agents": {
+    "defaults": {
+      "agentRuntime": {
+        "id": "codex"
+      }
+    }
+  }
+}
+```
+
+With an explicit plugin runtime, a session fails early when the requested
+harness is not registered, does not support the resolved provider/model, or
+fails before producing turn side effects. That is intentional for Codex-only
+deployments and for live tests that must prove the Codex app-server path is
+actually in use.
+
+This setting only controls the embedded agent harness. It does not disable
+image, video, music, TTS, PDF, or other provider-specific model routing.
+
+## Native sessions and transcript mirror
+
+A harness may keep a native session id, thread id, or daemon-side resume token.
+Keep that binding explicitly associated with the OpenClaw session, and keep
+mirroring user-visible assistant/tool output into the OpenClaw transcript.
+
+The OpenClaw transcript remains the compatibility layer for:
+
+- channel-visible session history
+- transcript search and indexing
+- switching back to the built-in OpenClaw harness on a later turn
+- generic `/new`, `/reset`, and session deletion behavior
+
+If your harness stores a sidecar binding, implement `reset(...)` so OpenClaw can
+clear it when the owning OpenClaw session is reset.
+
+## Tool and media results
+
+Core constructs the OpenClaw tool list and passes it into the prepared attempt.
+When a harness executes a dynamic tool call, return the tool result back through
+the harness result shape instead of sending channel media yourself.
+
+This keeps text, image, video, music, TTS, approval, and messaging-tool outputs
+on the same delivery path as OpenClaw-backed runs.
+
+## Current limitations
+
+- The public import path is generic, but some attempt/result type aliases still
+  carry legacy names for compatibility.
+- Third-party harness installation is experimental. Prefer provider plugins
+  until you need a native session runtime.
+- Harness switching is supported across turns. Do not switch harnesses in the
+  middle of a turn after native tools, approvals, assistant text, or message
+  sends have started.
+
+## Related
+
+- [SDK Overview](/plugins/sdk-overview)
+- [Runtime Helpers](/plugins/sdk-runtime)
+- [Provider Plugins](/plugins/sdk-provider-plugins)
+- [Codex Harness](/plugins/codex-harness)
+- [Model Providers](/concepts/model-providers)

package/docs/plugins/sdk-channel-inbound.md

@@ -0,0 +1,70 @@
+---
+summary: "Inbound event helpers for channel plugins: context building, shared runner orchestration, session record, and prepared reply dispatch"
+title: "Channel inbound API"
+read_when:
+  - You are building or refactoring a messaging channel plugin receive path
+  - You need shared inbound context construction, session recording, or prepared reply dispatch
+  - You are migrating old channel turn helpers to inbound/message APIs
+---
+
+Channel plugins should model receive paths with inbound and message nouns:
+
+```text
+platform event -> inbound facts/context -> agent reply -> message delivery
+```
+
+Use `openclaw/plugin-sdk/channel-inbound` for inbound event normalization,
+formatting, roots, and orchestration. Use
+`openclaw/plugin-sdk/channel-outbound` for native
+send, receipt, durable delivery, and live preview behavior.
+
+## Core Helpers
+
+```ts
+import {
+  buildChannelInboundEventContext,
+  runChannelInboundEvent,
+  dispatchChannelInboundReply,
+} from "openclaw/plugin-sdk/channel-inbound";
+```
+
+- `buildChannelInboundEventContext(...)`: project normalized channel facts into
+  the prompt/session context.
+- `runChannelInboundEvent(...)`: run ingest, classify, preflight, resolve,
+  record, dispatch, and finalize for one inbound platform event.
+- `dispatchChannelInboundReply(...)`: record and dispatch an already assembled
+  inbound reply with a delivery adapter.
+
+The injected plugin runtime exposes the same high-level helpers under
+`runtime.channel.inbound.*` for bundled/native channels that already receive the
+runtime object.
+
+```ts
+await runtime.channel.inbound.run({
+  channel: "demo",
+  accountId,
+  raw: platformEvent,
+  adapter: {
+    ingest: normalizePlatformEvent,
+    resolveTurn: resolveInboundReply,
+  },
+});
+```
+
+Compatibility dispatchers should assemble `dispatchChannelInboundReply(...)`
+inputs and keep platform delivery in the delivery adapter. New send paths should
+prefer message adapters and durable message helpers.
+
+## Migration
+
+The old `runtime.channel.turn.*` runtime aliases were removed. Use:
+
+- `runtime.channel.inbound.run(...)` for raw inbound events.
+- `runtime.channel.inbound.dispatchReply(...)` for assembled reply contexts.
+- `runtime.channel.inbound.buildContext(...)` for inbound context payloads.
+- `runtime.channel.inbound.runPreparedReply(...)` only for channel-owned prepared
+  dispatch paths that already assemble their own dispatch closure.
+
+New plugin code should not introduce `turn`-named channel APIs. Keep model or
+agent turn vocabulary inside agent/provider code; channel plugins use inbound,
+message, delivery, and reply terms.

package/docs/plugins/sdk-channel-ingress.md

@@ -0,0 +1,137 @@
+---
+summary: "Experimental channel ingress API for inbound message authorization"
+read_when:
+  - Building or migrating a messaging channel plugin
+  - Changing DM or group allowlists, route gates, command auth, event auth, or mention activation
+  - Reviewing channel ingress redaction or SDK compatibility boundaries
+title: "Channel ingress API"
+sidebarTitle: "Channel Ingress"
+---
+
+# Channel ingress API
+
+Channel ingress is the experimental access-control boundary for inbound channel
+events. Use `openclaw/plugin-sdk/channel-ingress-runtime` for receive paths.
+The older `openclaw/plugin-sdk/channel-ingress` subpath stays exported as a
+deprecated compatibility facade for third-party plugins.
+
+Plugins own platform facts and side effects. Core owns generic policy: DM/group
+allowlists, pairing-store DM entries, route gates, command gates, event auth,
+mention activation, redacted diagnostics, and admission.
+
+## Runtime Resolver
+
+```ts
+import {
+  defineStableChannelIngressIdentity,
+  resolveChannelMessageIngress,
+} from "openclaw/plugin-sdk/channel-ingress-runtime";
+
+const identity = defineStableChannelIngressIdentity({
+  key: "platform-user-id",
+  normalize: normalizePlatformUserId,
+  sensitivity: "pii",
+});
+
+const result = await resolveChannelMessageIngress({
+  channelId: "my-channel",
+  accountId,
+  identity,
+  subject: { stableId: platformUserId },
+  conversation: { kind: isGroup ? "group" : "direct", id: conversationId },
+  event: { kind: "message", authMode: "inbound", mayPair: !isGroup },
+  policy: {
+    dmPolicy: config.dmPolicy,
+    groupPolicy: config.groupPolicy,
+    groupAllowFromFallbackToAllowFrom: true,
+  },
+  allowFrom: config.allowFrom,
+  groupAllowFrom: config.groupAllowFrom,
+  accessGroups: cfg.accessGroups,
+  route,
+  readStoreAllowFrom,
+  command: hasControlCommand ? { allowTextCommands: true, hasControlCommand } : undefined,
+});
+```
+
+Do not precompute effective allowlists, command owners, or command groups. The
+resolver derives them from raw allowlists, store callbacks, route descriptors,
+access groups, policy, and conversation kind.
+
+## Result
+
+Bundled plugins should consume modern projections directly:
+
+- `ingress`: ordered gate decision and admission
+- `senderAccess`: sender/conversation authorization only
+- `routeAccess`: route and route-sender projection
+- `commandAccess`: command authorization; false when no command gate ran
+- `activationAccess`: mention/activation result
+
+Event authorization remains available on the ordered `ingress.graph` and the
+decisive `ingress.reasonCode`; no separate event projection is emitted.
+
+Deprecated third-party SDK helpers may rebuild older shapes internally. New
+bundled receive paths should not translate modern results back into local DTOs.
+
+## Access Groups
+
+`accessGroup:<name>` entries stay redacted. Core resolves static
+`message.senders` groups itself and calls `resolveAccessGroupMembership` only
+for dynamic groups that require a platform lookup. Missing, unsupported, and
+failed groups fail closed.
+
+## Event Modes
+
+| `authMode`       | Meaning                                          |
+| ---------------- | ------------------------------------------------ |
+| `inbound`        | normal inbound sender gates                      |
+| `command`        | command gates for callbacks or scoped buttons    |
+| `origin-subject` | actor must match the original message subject    |
+| `route-only`     | route gates only for route-scoped trusted events |
+| `none`           | plugin-owned internal events bypass shared auth  |
+
+Use `mayPair: false` for reactions, buttons, callbacks, and native commands.
+
+## Routes And Activation
+
+Use route descriptors for room, topic, guild, thread, or nested route policy:
+
+```ts
+route: {
+  id: "room",
+  allowed: roomAllowed,
+  enabled: roomEnabled,
+  senderPolicy: "replace",
+  senderAllowFrom: roomAllowFrom,
+  blockReason: "room_sender_not_allowlisted",
+}
+```
+
+Use `channelIngressRoutes(...)` when a plugin has several optional route
+descriptors; it filters disabled branches while keeping route facts generic and
+ordered by each descriptor's `precedence`.
+
+Mention gating is an activation gate. A mention miss returns
+`admission: "skip"` so the turn kernel does not process an observe-only turn.
+Most channels should leave activation after sender and command gates. Public
+chat surfaces that must quiet non-mentioned traffic before sender allowlist
+noise can opt into `activation.order: "before-sender"` when text-command
+bypass is disabled. Channels with implicit activation, such as replies in bot
+threads, can pass `activation.allowedImplicitMentionKinds`; the projected
+`activationAccess.shouldBypassMention` then reports when command or implicit
+activation bypassed an explicit mention.
+
+## Redaction
+
+Raw sender values and raw allowlist entries are resolver input only. They must
+not appear in resolved state, decisions, diagnostics, snapshots, or
+compatibility facts. Use opaque subject ids, entry ids, route ids, and
+diagnostic ids.
+
+## Verification
+
+```bash
+pnpm test src/channels/message-access/message-access.test.ts src/plugin-sdk/channel-ingress-runtime.test.ts
+pnpm plugin-sdk:api:check
+```

package/docs/plugins/sdk-channel-message.md

@@ -0,0 +1,18 @@
+---
+summary: "Redirect to /plugins/sdk-channel-outbound"
+title: "Channel message API"
+---
+
+This page moved to [Channel outbound API](/plugins/sdk-channel-outbound).
+
+`openclaw/plugin-sdk/channel-message` and
+`openclaw/plugin-sdk/channel-message-runtime` remain deprecated compatibility
+subpaths for older plugins. New channel plugins should use
+`openclaw/plugin-sdk/channel-outbound` for message lifecycle, receipt, durable
+send, and live preview helpers. The deprecated subpaths are thin aliases over
+the shared channel message core and the focused inbound/outbound SDK surfaces;
+do not add new helpers there.
+
+Removal plan: keep these aliases through the external plugin migration window,
+then remove them in the next major SDK cleanup after callers have moved to
+`channel-outbound`.

package/docs/plugins/sdk-channel-outbound.md

@@ -0,0 +1,113 @@
+---
+summary: "Outbound message lifecycle API for channel plugins: adapters, receipts, durable sends, live preview, and reply pipeline helpers"
+title: "Channel outbound API"
+read_when:
+  - You are building or refactoring a messaging channel plugin send path
+  - You need durable final reply delivery, receipts, live preview finalization, or receive acknowledgement policy
+  - You are migrating from channel-message, channel-message-runtime, or legacy reply dispatch helpers
+---
+
+Channel plugins should expose outbound message behavior from
+`openclaw/plugin-sdk/channel-outbound`. Use
+`openclaw/plugin-sdk/channel-inbound` for receive/context/dispatch orchestration.
+
+Core owns queueing, durability, generic retry policy, hooks, receipts, and the
+shared `message` tool. The plugin owns native send/edit/delete calls, target
+normalization, platform threading, selected quotes, notification flags, account
+state, and platform-specific side effects.
+
+## Adapter
+
+Most plugins define one `message` adapter:
+
+```ts
+import {
+  defineChannelMessageAdapter,
+  createMessageReceiptFromOutboundResults,
+} from "openclaw/plugin-sdk/channel-outbound";
+
+export const demoMessageAdapter = defineChannelMessageAdapter({
+  id: "demo",
+  durableFinal: {
+    capabilities: {
+      text: true,
+      replyTo: true,
+      thread: true,
+      messageSendingHooks: true,
+    },
+  },
+  send: {
+    text: async ({ cfg, to, text, accountId, replyToId, threadId, signal }) => {
+      const sent = await sendDemoMessage({
+        cfg,
+        to,
+        text,
+        accountId: accountId ?? undefined,
+        replyToId: replyToId ?? undefined,
+        threadId: threadId == null ? undefined : String(threadId),
+        signal,
+      });
+
+      return {
+        receipt: createMessageReceiptFromOutboundResults({
+          results: [{ channel: "demo", messageId: sent.id, conversationId: to }],
+          kind: "text",
+          threadId: threadId == null ? undefined : String(threadId),
+          replyToId: replyToId ?? undefined,
+        }),
+      };
+    },
+  },
+});
+```
+
+Only declare capabilities the native transport actually preserves. Cover each
+declared send, receipt, live-preview, and receive-ack capability with the
+contract helpers exported from this subpath.
+
+## Existing Outbound Adapters
+
+If the channel already has a compatible `outbound` adapter, derive the message
+adapter instead of duplicating send code:
+
+```ts
+import { createChannelMessageAdapterFromOutbound } from "openclaw/plugin-sdk/channel-outbound";
+
+export const messageAdapter = createChannelMessageAdapterFromOutbound({
+  id: "demo",
+  outbound,
+  durableFinal: {
+    capabilities: {
+      text: true,
+      media: true,
+    },
+  },
+});
+```
+
+## Durable Sends
+
+Runtime send helpers also live on `channel-outbound`:
+
+- `sendDurableMessageBatch(...)`
+- `withDurableMessageSendContext(...)`
+- `deliverInboundReplyWithMessageSendContext(...)`
+- draft streaming/progress helpers such as `resolveChannelDraftStreamingChunking(...)`
+
+`sendDurableMessageBatch(...)` returns one explicit outcome:
+
+- `sent`: at least one visible platform message was delivered.
+- `suppressed`: no platform message should be treated as missing.
+- `partial_failed`: at least one platform message was delivered before a later
+  payload or side effect failed.
+- `failed`: no platform receipt was produced.
+
+Use `payloadOutcomes` when a batch mixes sent, suppressed, and failed payloads.
+Do not infer hook cancellation from an empty legacy direct-delivery result.
+
+## Compatibility Dispatch
+
+Inbound reply dispatch should be assembled through
+`dispatchChannelInboundReply(...)` from `channel-inbound`. Keep platform
+delivery in the delivery adapter; use `channel-outbound` for message adapters,
+durable sends, receipts, live preview, and reply pipeline options.