fengming 0.3.9 → 0.3.11

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

@@ -1,338 +0,0 @@
----
-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 FengMing 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 FengMing 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 FengMing
-  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, FengMing has already resolved:
-
-- provider and model
-- runtime auth state
-- thinking level and context budget
-- the FengMing 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 FengMing-owned
-policy bundle for runtime decisions that must stay shared across FengMing 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 FengMing 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:** `fengming/plugin-sdk/agent-harness`
-
-```typescript
-import type { AgentHarness } from "fengming/plugin-sdk/agent-harness";
-import { definePluginEntry } from "fengming/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
-
-FengMing 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, FengMing 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, FengMing 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 `FENGMING_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
-FengMing. 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: FengMing 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).
-
-FengMing 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
-FengMing 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 FengMing to the newer tested stable line.
-
-### Tool-result middleware
-
-Bundled plugins 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 FengMing 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
-`fengming/plugin-sdk/agent-harness-runtime` when a completed turn produced no
-visible assistant text. The helper returns `empty`, `reasoning-only`, or
-`planning-only` so FengMing'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 FengMing
-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 `openai-codex/*` routes should be repaired with
-`fengming 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. FengMing 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, FengMing 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: "fengming"`.
-
-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 FengMing session, and keep
-mirroring user-visible assistant/tool output into the FengMing transcript.
-
-The FengMing transcript remains the compatibility layer for:
-
-- channel-visible session history
-- transcript search and indexing
-- switching back to the built-in FengMing harness on a later turn
-- generic `/new`, `/reset`, and session deletion behavior
-
-If your harness stores a sidecar binding, implement `reset(...)` so FengMing can
-clear it when the owning FengMing session is reset.
-
-## Tool and media results
-
-Core constructs the FengMing 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 FengMing-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

@@ -1,70 +0,0 @@
----
-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 `fengming/plugin-sdk/channel-inbound` for inbound event normalization,
-formatting, roots, and orchestration. Use
-`fengming/plugin-sdk/channel-outbound` for native
-send, receipt, durable delivery, and live preview behavior.
-
-## Core Helpers
-
-```ts
-import {
-  buildChannelInboundEventContext,
-  runChannelInboundEvent,
-  dispatchChannelInboundReply,
-} from "fengming/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

@@ -1,137 +0,0 @@
----
-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 `fengming/plugin-sdk/channel-ingress-runtime` for receive paths.
-The older `fengming/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 "fengming/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

@@ -1,18 +0,0 @@
----
-summary: "Redirect to /plugins/sdk-channel-outbound"
-title: "Channel message API"
----
-
-This page moved to [Channel outbound API](/plugins/sdk-channel-outbound).
-
-`fengming/plugin-sdk/channel-message` and
-`fengming/plugin-sdk/channel-message-runtime` remain deprecated compatibility
-subpaths for older plugins. New channel plugins should use
-`fengming/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

@@ -1,113 +0,0 @@
----
-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
-`fengming/plugin-sdk/channel-outbound`. Use
-`fengming/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 "fengming/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 "fengming/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 `resolveChannelStreamingPreviewChunk(...)`
-
-`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.