@open-everywhere/provider-discord 0.1.0

package/dist/agent/channels/discord-gateway.d.ts

@@ -0,0 +1,783 @@
+import { type RouteHandlerArgs } from "eve/channels";
+import { type OpenEverywhereDiscordAuth } from "./discord-identity.js";
+import { splitForDiscord } from "./discord-post.js";
+import { type DiscordFetchDeps } from "./discord-rest.js";
+import { type AttachSessionForCancel, contextLineIngestion, type IngestedChatMessage, type ExternalPolicy, type AuditInput, type FinalMessageAction, type NormalizedWake, type WakeEngagementTier, type WakeTrust, type AuthorTrustQuery, type SupervisorGrain, type SingleWindowMentionPolicy, type Partition, type ContextLine, type WakeMessageInput } from "@open-everywhere/core/agent/adapter-api.js";
+export { splitForDiscord };
+import { type ReactionSinkDeps, type ReactionIngestOutcome, type ReactionVerb } from "@open-everywhere/core/agent/adapter-api.js";
+export interface DiscordGatewayState {
+    channelId: string;
+    guildId?: string;
+    originalChannelId?: string;
+    originalMessageId?: string;
+}
+export interface DiscordRelayMessage {
+    readonly id: string;
+    readonly content: string;
+    readonly channelId: string;
+    /** Discord's numeric channel `type` as a STRING (relay sends the enum number). */
+    readonly channelType?: string;
+    readonly guildId?: string;
+    readonly author: {
+        readonly id: string;
+        readonly username?: string;
+        readonly bot: boolean;
+    };
+    readonly mentionsBot: boolean;
+    readonly referencedMessageId?: string;
+    /** The bot's own display name AS SEEN IN THIS GUILD (nickname, else global name) —
+     *  what a human actually types to address it. Sent by relay ≥ 5c67655; absent from an
+     *  older relay, which simply keeps the wake gate mention/engagement-only (fail-closed). */
+    readonly botName?: string;
+    /** The receiving bot's user id — multi-bot attribution (item 27): when N relay clients
+     *  share one process, each forwards every message, and botId is how dedupe and persona
+     *  routing tell the copies apart. Same relay payload as botName; optional for old relays. */
+    readonly botId?: string;
+    /** Whether the message author is a PENDING guild member (membership screening incomplete) —
+     *  the OPE-60 guest/unverified demotion signal. Discord stamps `member.pending` on gateway
+     *  member objects; forwarded by a relay that includes it (absent from older relays → the
+     *  binding keeps today's fail-closed/vouch behaviour). Undefined for DMs (no guild member). */
+    readonly memberPending?: boolean;
+    /**
+     * The guild ROLE ids this author holds (Discord stamps `member.roles` on the gateway member
+     * object — the SAME object `member.pending` rides on, so this costs no extra API call). The input
+     * to the author-trust register's membership patterns (OPE-516): a
+     * `{ membership: "discord/<guildId>/role:<roleId>" }` declaration matches an author whose roles
+     * include that id.
+     *
+     * Absent for a DM (no guild member) and from an older relay that omits the member object — both
+     * simply mean no membership evidence, which the register leg treats as "matched nothing".
+     */
+    readonly memberRoles?: readonly string[];
+}
+/**
+ * Defensively parse the relay envelope. Returns null for anything not recognizably a relay
+ * MESSAGE_CREATE with the identity facts we MUST have to dispatch + reply — a channel id (for
+ * the post-back + partition) and an author id (for identity). `content` may legitimately be
+ * empty (Message Content Intent disabled surfaces empty strings), so it isn't required here;
+ * the route drops empty-content turns separately. NEVER throws.
+ */
+export declare function parseRelayPayload(raw: unknown): DiscordRelayMessage | null;
+export interface DiscordRelayReaction {
+    readonly verb: ReactionVerb;
+    /** The reacted message's id + channel. */
+    readonly messageId: string;
+    readonly channelId: string;
+    readonly guildId?: string;
+    readonly channelType?: string;
+    /** The emoji: a unicode char (👍) or a custom emoji NAME. Bucketed by classifyEmoji. */
+    readonly emoji: string;
+    readonly reactorId: string;
+    /** The AUTHOR of the reacted message, when the relay could resolve it — drives onBotReply. */
+    readonly messageAuthorId?: string;
+    /** The receiving bot's own user id (relay-supplied) — onBotReply compares against it. */
+    readonly botId?: string;
+}
+/**
+ * Defensively parse a relay REACTION envelope, or null when it isn't one (wrong source/event,
+ * or missing the ids ingestion needs). NEVER throws. Distinguished from a message payload by
+ * the `event` discriminator + a `reaction` object (vs `message`).
+ */
+export declare function parseRelayReaction(raw: unknown): DiscordRelayReaction | null;
+export interface DiscordRelayHeartbeat {
+    /** Identifies the relay PROCESS (its own bot user id) — never a guild/channel/user fact. */
+    readonly relayId: string;
+    /** The relay's own clock, epoch milliseconds, at the moment it sent this beat. */
+    readonly ts: number;
+}
+/**
+ * Defensively parse a relay HEARTBEAT envelope, or null when it isn't one (wrong source/event, or
+ * missing a field). NEVER throws. Distinguished from a message/reaction envelope by the `event`
+ * discriminator + a `heartbeat` object (vs `message`/`reaction`) — mutually exclusive with both,
+ * pinned by scripts/discord-gateway-test.ts.
+ */
+export declare function parseRelayHeartbeat(raw: unknown): DiscordRelayHeartbeat | null;
+/** The audit row a heartbeat writes. Pure — no I/O — so the shape is testable without a live
+ *  store; the route below is the only caller that actually persists it via `appendAudit`. The
+ *  action name (`discord.heartbeat`) is what `agent/ops/census.ts`'s `CHANNEL_REPORTED_HEARTBEATS`
+ *  reads by. `workspace`/`surface` name the RELAY, never a guild — this signal is guild-agnostic
+ *  by design, which is exactly what lets it separate a dead relay from a quiet one. */
+export declare function discordHeartbeatAuditRow(heartbeat: DiscordRelayHeartbeat, org: string): AuditInput;
+/** Dependencies for {@link routeDiscordReaction} — injected so parse+route+record is unit-tested
+ *  without a live store. `attachSession` is eve's cancel door, present ONLY when the route was
+ *  built with it (the ✋ stop arm) — absent ⇒ a ✋ is ingested as an ordinary reaction. */
+export interface DiscordReactionRouteDeps {
+    readonly sink: ReactionSinkDeps;
+    readonly attachSession?: AttachSessionForCancel;
+}
+/**
+ * Route one parsed Discord reaction into the surface-neutral ingestion seam. The relay already
+ * dropped bot reactors, but we double-check against the relayed botId (defence in depth) so the
+ * bot's own reaction is never recorded as feedback. onBotReply = the reacted message was authored
+ * by the bot; fail-safe when either id is missing (telemetry only, never a false feedback row).
+ */
+export declare function routeDiscordReaction(rx: DiscordRelayReaction, deps: DiscordReactionRouteDeps): Promise<ReactionIngestOutcome>;
+export interface RelayRejection {
+    readonly status: number;
+    readonly reason: string;
+}
+/**
+ * Gate one relay delivery. Returns null when it may proceed, else the {@link RelayRejection}.
+ * `secret` defaults to the live env read but is injectable so the gate is unit-tested without
+ * touching process.env. Fail-closed: unset/empty secret → 401; missing/malformed/mismatched
+ * signature → 401 (verifyWebhookSignature returns false for a null or non-`sha256=` header).
+ */
+export declare function relayGate(signatureHeader: string | null, rawBody: string, secret?: string | undefined): RelayRejection | null;
+/**
+ * Reconstruct the dispatch auth from a relay message, or null to DROP. Reuses
+ * buildDiscordAuth verbatim (channels/discord.ts uses the same for the interaction path) so
+ * the identity seam (identity/binding.ts bindDiscord) resolves the real guild/channel/user →
+ * workspace/surface/mode/visibility. Drops bot authors: we never act on another bot (incl.
+ * ourselves) — mirrors discord.ts's authFromInteraction and the relay's own bot filter.
+ */
+export declare function authForRelayMessage(msg: DiscordRelayMessage): OpenEverywhereDiscordAuth | null;
+/**
+ * Is this bot-authored relay message's author id a KNOWN e2e-driver id (OPE-647) — pinned to
+ * SOME guild in `OE_TEST_DRIVER_IDS` — but NOT to this message's own guild? `authForRelayMessage`
+ * already refuses the message either way: `isAllowedDriver` is guild-pinned by format
+ * (`guildId:botUserId`), so a driver id posting outside its pinned guild never passes. This
+ * classifier exists only to tell that refusal APART from routine "some unrelated real bot
+ * posted" noise, so a driver credential surfacing in the wrong guild gets a NAMED audit row
+ * instead of vanishing into the ordinary bot-drop silence. Pure — no I/O — so every branch is
+ * unit-tested against a hand-built allowlist, with no live Discord and no store.
+ */
+export declare function isMisplacedDriver(guildId: string | undefined, botUserId: string, allowlist?: ReadonlySet<string>): boolean;
+/**
+ * The AUTHOR-TRUST question for this message (OPE-516) — the operator's own declaration of who is
+ * internal in this guild, which is the ONLY author-grain evidence Discord can produce. Discord has
+ * no organisation concept, so `discordTrust` can never refute an author; `member.pending` is a
+ * SCREENING verdict, not a membership one. The register fills that hole from reviewed config.
+ *
+ * Returns `{}` for a DM: a DM has no guild, so there is no tenant to arm and no roles to hold. The
+ * DM's trust question is about the PARTNER and is answered by the surface register instead — the
+ * same split `ChatWakeRoom.dm` makes on the room leg. A spread-able fragment rather than a
+ * `| undefined` value so the call sites stay one expression and an absent author is byte-identical
+ * to before this existed.
+ *
+ * The tenant key is built from the guild id and NOTHING ELSE. The platform and tenant halves of a
+ * principal key are surface facts, never properties of the id (identity/principal-key.ts) — and a
+ * snowflake is a bare digit string that would collide happily across vendors if it were sniffed.
+ */
+export declare function authorFacts(msg: DiscordRelayMessage): {
+    readonly authorTrust?: AuthorTrustQuery;
+};
+/**
+ * THE EXTERNAL-PARTICIPANT VERDICT for one Discord message (OPE-507 / OPE-504) — pure, so the four
+ * outcomes are tested without a REST call, a store or a live relay. `dispatchTurn` calls it once and
+ * switches on the answer.
+ *
+ * The four values name WHAT THE CALLER OWES, which is the only thing that differs between them:
+ *   `proceed`            — nothing suppressed. The shipped grains always return this.
+ *   `withheld-addressed` — an excluded author @mentioned or DM'd. Owed a PRIVATE notice, nothing else.
+ *   `withheld-ambient`   — an excluded author spoke ambiently. Owed NOTHING; suppress in silence.
+ *   `silent-room`        — the room is classified external and the operator asked for silence. Owed
+ *                          the once-ever suppressed-wake announcement.
+ *
+ * 🔴 THE AUTHOR GRAIN IS TESTED FIRST, AND THE ORDER MATTERS. An excluded author in a silenced room
+ * must get the AUTHOR outcome: they are owed a notice they can act on ("ask someone inside"), where
+ * the room announcement tells the whole room something about the room. Reversing this would answer
+ * the wrong question to the wrong audience.
+ */
+export type DiscordExternalVerdict = "proceed" | "withheld-addressed" | "withheld-ambient" | "silent-room";
+export declare function discordExternalVerdict(input: {
+    readonly policy: ExternalPolicy;
+    readonly author: IngestedChatMessage;
+    /** The message @mentions the bot, or arrived in a DM — an ADDRESSED message is owed an answer. */
+    readonly addressed: boolean;
+    readonly isDm: boolean;
+    /** The DOMAIN-grain surface key (a thread asks its parent channel), for the room classification. */
+    readonly roomKey: string;
+}): DiscordExternalVerdict;
+/**
+ * Is this channel type a THREAD? Discord 10 (announcement thread) / 11 (public thread) /
+ * 12 (private thread) — the surfaces whose channel id is NOT the id domains and spend
+ * caps are declared against (those name the PARENT channel). Pure; drives the
+ * parent-grain stamping in dispatchTurn (item 22).
+ */
+export declare function isThreadChannelType(channelType: string | undefined): boolean;
+/**
+ * Is this message a direct message to the bot? Discord channel type 1 (DM) / 3 (group DM).
+ * A DM is BY DEFINITION addressed to the bot — there is no one else it could be for — so it
+ * wakes without a mention and its text is a direct instruction (no judged preamble), exactly
+ * like a Slack DM. Pure.
+ */
+export declare function isDmChannel(channelType: string | undefined): boolean;
+/**
+ * Should this ambient message wake the agent? A DM always wakes (it's inherently addressed to
+ * the bot). An @mention is a direct address (guaranteed reply, like a Slack mention); otherwise
+ * the channel must already be ENGAGED — the agent was pulled in earlier and keeps following
+ * without re-tagging (engagement.ts, the same registry Slack uses). A non-mention message in a
+ * non-engaged guild channel is dropped, so the bot stays quiet in channels it wasn't invited
+ * into. Pure → unit-tested without the operational store.
+ */
+export declare function shouldDispatchDiscord(input: {
+    readonly mentionsBot: boolean;
+    readonly isEngaged: boolean;
+    readonly isDm: boolean;
+}): boolean;
+/**
+ * Is this message a NAME-DROP candidate — Slack's nameDropWake brought to Discord (item 25;
+ * live 2026-07-06 Tommy addressed the bot by display name and it only "worked" where the
+ * channel happened to be engaged)? Pure pre-filter, cheapest checks first; the caller still
+ * gates on the domain's `nameDropWake` flag (config, evaluated at DOMAIN grain — a thread
+ * checks its parent channel's domain). Disqualifiers:
+ *   - mention / DM / engaged — those wake paths own the message already;
+ *   - a bot author — never self/bot-trigger;
+ *   - anything but a guild conversation surface (text 0, announcement 5, threads 10/11/12).
+ *     DELIBERATE Slack DEVIATION: Slack excludes thread replies ("the engagement path owns
+ *     threads") but on Discord threads ARE the primary conversation surface and an
+ *     UN-engaged thread (TTL'd out, or human-created) that says the bot's name is a clear
+ *     address with no other wake path — the exact live gap. Forum containers (15) and
+ *     unknown types stay excluded, fail-safe;
+ *   - no relayed bot name (older relay) — fail-closed to mention/engagement-only, so
+ *     `identity.name`/`wake.nameDrop.include` alone never fires this without a live name too.
+ * Unlike Slack there is NO externally-shared-channel probe: Discord has no shared-channel
+ * concept — guild membership IS the boundary, so a guild surface is internal by construction.
+ * The text is matched against the UNIFIED wake token set (OPE-571): `input.botName` (the live
+ * Discord display name) UNION `identity.name`, extended by `wake.nameDrop.include` and narrowed
+ * by `wake.nameDrop.exclude` — see {@link wakeNameDropTokens}, the same builder Slack's
+ * `buildWakeTriggers` uses, so the two surfaces' wake set stays one rule.
+ */
+export declare function nameDropEligible(input: {
+    readonly mentionsBot: boolean;
+    readonly isDm: boolean;
+    readonly isEngaged: boolean;
+    readonly authorIsBot: boolean;
+    readonly channelType?: string;
+    readonly content: string;
+    readonly botName?: string;
+}): boolean;
+/**
+ * Low-level create-message: `POST /channels/{id}/messages` with the bot token. Returns the NEW
+ * message's id on success (needed by the holding-message flow so completion can edit it), or null
+ * on any failure — no token, non-ok status, network error, or a response missing an id. NEVER
+ * throws. postDiscordReply + postHoldingMessage are both built on this so the auth/error handling
+ * lives in one place (the bot token is a SECRET — never logged).
+ */
+export declare function discordCreateMessage(channelId: string, content: string, deps?: DiscordFetchDeps): Promise<string | null>;
+/**
+ * Post the agent's reply to a Discord channel via REST. Best-effort per chunk: a failed chunk is
+ * logged (with status, never the token) and the rest still attempt. No DISCORD_BOT_TOKEN → each
+ * chunk logs and no-ops (the turn already ran; silence is the only degradation). This is the plain
+ * post-back used when status UX is off, and the fail-open fallback when the holding-message flow
+ * couldn't run.
+ */
+/**
+ * Open (or re-open) the 1:1 DM channel with one user and return its id — `POST /users/@me/channels`.
+ * Idempotent on Discord's side: it returns the EXISTING DM channel when one is already open, so
+ * calling it repeatedly creates nothing.
+ *
+ * It exists for ONE caller: the external-sender notice (OPE-507 behaviour 1), which owes the sender a
+ * PRIVATE message. Fail-soft to `null` — see {@link postExternalSenderNotice} for why a failure here
+ * must stay silent rather than fall back to the channel.
+ */
+export declare function openDiscordDm(userId: string, deps?: DiscordFetchDeps): Promise<string | null>;
+/** Test hook: drop every recorded throttle timestamp. Production correctness needs this
+ *  map to live for the whole process (the throttle is meant to span turns), but the
+ *  golden-transcript scenario harness (discord-scenario-harness.ts) runs many scenarios in ONE
+ *  process and reuses small deterministic channel/thread ids ("TH1", …) across them — so
+ *  without a reset, whether a later scenario's typing throttle "holds" depends on the
+ *  REAL wall-clock gap since an earlier, unrelated scenario last wrote the same key: fast
+ *  test execution (<7s between scenarios) silently suppresses a typing re-trigger the
+ *  golden doesn't expect to be suppressed; a slow/loaded run (>7s) doesn't, and the extra
+ *  POST diverges the golden — a genuine flake pinned as OPE-69 (confirmed by forcing an
+ *  8s real delay between scenarios 01/02, which flipped the throttle and diverged
+ *  02-thread-followup-resume). Called by ScenarioRunner.scenario() before every scenario
+ *  so each starts cold, exactly like clearDiscordInfoCacheForTest(). */
+export declare function clearTypingThrottleForTest(): void;
+/** True when a typing re-trigger is due for this channel (and records it as fired). Pure
+ *  given an injected clock → unit-tested; the default clock is Date.now. */
+export declare function typingRefreshDue(channelId: string, nowMs?: number, state?: Map<string, number>): boolean;
+/** Close the gate for a judged wake: hold all typing until the reply is proven. */
+export declare function closeTypingGate(channelId: string, gates?: Set<string>): void;
+/** Open (clear) the gate — addressed dispatch, reply proven, or turn over. */
+export declare function openTypingGate(channelId: string, gates?: Set<string>): void;
+export declare function typingGateOpen(channelId: string, gates?: Set<string>): boolean;
+/**
+ * Feed the streamed assistant text into the gate; returns whether typing may fire. Mirrors
+ * slack-events.ts isNoReply EXACTLY (trimStart + case-sensitive startsWith): while the text
+ * is still a prefix of the sentinel the verdict is UNDECIDED (hold); once it starts with the
+ * full sentinel it IS a judged silence (hold — the final reply will be swallowed); any
+ * deviation proves a real reply, so the gate opens and stays open for the rest of the turn.
+ */
+export declare function typingGateFeed(channelId: string, messageSoFar: string, gates?: Set<string>): boolean;
+export declare function triggerDiscordTyping(channelId: string, deps?: DiscordFetchDeps): Promise<void>;
+/**
+ * Add or remove the bot's own reaction on a message: `{PUT|DELETE}
+ * /channels/{id}/messages/{messageId}/reactions/{emoji}/@me` with the emoji URL-encoded. Used to
+ * show 👀 the moment we decide to respond and swap to ✅ (or just clear 👀) on completion. Purely a
+ * status affordance — best-effort, any failure is logged and swallowed, NEVER throws, and a missing
+ * token no-ops. (The bot token is a SECRET — never logged.)
+ */
+export declare function setDiscordReaction(channelId: string, messageId: string, emoji: string, action: "PUT" | "DELETE", deps?: DiscordFetchDeps): Promise<void>;
+/** Strip ONE leading bot-mention token (`<@123>` / `<@!123>`) — shared by thread naming and
+ *  the stop-verb match, both of which care about the words AFTER the address. Pure. */
+export declare function stripLeadingMention(content: string): string;
+/**
+ * Should a mention here open a new thread? True ONLY for a base guild text (0) or announcement
+ * (5) channel when the toggle is on. False for threads (10/11/12 — already a thread surface),
+ * DMs / group DMs (1/3 — no threads), forum channels (15 — a forum post is itself a thread;
+ * don't nest), and any unknown type (fail-safe: keep today's inline behaviour). Pure.
+ */
+export declare function shouldAutoThread(channelType: string | undefined, enabled: boolean): boolean;
+/**
+ * Read the discord.autoThread toggle. Default ON — auto-thread is the on-brand behaviour;
+ * a deployer opts OUT of it. Only the explicit "false"/"0" disable; anything else (unset,
+ * "true", "1", …) leaves it on. `env` is injectable so the toggle is unit-tested without
+ * touching process.env. Pure.
+ */
+export declare function autoThreadEnabled(env?: string): boolean;
+/**
+ * Read the discord.statusUx toggle. Default ON — the "working" affordances (👀/✅ reaction + a
+ * holding message edited into the reply) are on-brand, so a deployer opts OUT. Only the explicit
+ * "false"/"0" disable; anything else (unset, "true", "1", …) leaves it on. When off, the surface
+ * behaves EXACTLY as before this feature: one plain reply post, no reaction, no holding message.
+ * `env` is injectable so the toggle is unit-tested without touching process.env. Pure. Mirrors
+ * autoThreadEnabled verbatim.
+ */
+export declare function statusUxEnabled(env?: string): boolean;
+/**
+ * Derive a Discord thread name from the triggering message. Strips a single leading bot
+ * mention token (`<@123>` or `<@!123>`), collapses whitespace, and truncates to Discord's
+ * 100-char cap (trimming back to a word boundary when one sits reasonably near the cut).
+ * Falls back to `Conversation with <botName>` when nothing usable remains (e.g. a bare
+ * mention with no text). Pure + deterministic — no model call (v1; a cheap-model title is a
+ * noted later enhancement).
+ */
+export declare function deriveThreadName(content: string, botName?: string): string;
+/**
+ * Create a Discord thread hanging off the triggering message:
+ * `POST /channels/{channelId}/messages/{messageId}/threads` with the bot token. Returns the
+ * new thread's channel id on success, or null on ANY failure (no token, non-ok status,
+ * network error, or a response missing an id). NEVER throws — threading is fail-OPEN: a null
+ * here degrades the turn to an inline reply, it never drops the turn. Mirrors postDiscordReply's
+ * auth + error handling exactly (including: the bot token is a SECRET — never logged).
+ */
+export declare function createDiscordThread(channelId: string, messageId: string, name: string, deps?: DiscordFetchDeps): Promise<string | null>;
+/**
+ * Compute the dispatch surface for a turn, given the thread-create outcome. This is the
+ * RE-KEY: when a thread was created (threadId non-null), the ENTIRE turn moves onto the thread
+ * channel id — identity/auth, continuation token, reply-target state, and engagement key all
+ * point at the thread, so the conversation lives there (its own memory silo + durable session)
+ * and the base channel is only where the mention landed. When no thread was created (threadId
+ * null — either not auto-threadable or a fail-open fallback), the turn stays on the base
+ * channel exactly as today. Pure → the fail-open contract is unit-tested by passing an id / null
+ * without any live Discord call.
+ */
+export declare function dispatchSurfaceFor(msg: DiscordRelayMessage, baseAuth: OpenEverywhereDiscordAuth, threadId: string | null): {
+    auth: OpenEverywhereDiscordAuth;
+    continuationToken: string;
+    state: DiscordGatewayState;
+    engagementKey: string;
+};
+/** How to reconcile the 👀 reaction on completion (auto-threaded mentions only). */
+export type ReactionResolution = "clear" | "none";
+/** How to deliver the final reply. Always a FRESH post — never an edit (no "(edited)" tag). */
+export type CompletionDelivery = {
+    readonly kind: "post";
+    readonly chunks: readonly string[];
+} | {
+    readonly kind: "none";
+};
+export interface CompletionPlan {
+    readonly reaction: ReactionResolution;
+    readonly delivery: CompletionDelivery;
+}
+/**
+ * Translate the shared finalMessageAction decision into the concrete completion operations. Pure —
+ * no I/O, no env, fully unit-tested.
+ *   - post   → POST the reply fresh (split to Discord's 2000-char cap); swap 👀→✅ when this turn
+ *              placed a swap-tracked reaction (auto-threaded mention).
+ *   - silent → post nothing; clear the 👀 if one was swap-tracked (don't leave "seen, working"
+ *              standing on a mention the agent decided not to answer).
+ *   - buffer-tool-status → interim tool turn, not the final reply → do nothing at all.
+ * `reactionActive` = this turn seeded original-message coords (status UX on + auto-threaded).
+ * The non-threaded 👀 (DMs, in-thread mentions) is a plain "seen" ack, deliberately NOT swapped
+ * or cleared — the answer lands right under the message, so the ack can simply stand.
+ */
+export declare function planCompletion(input: {
+    readonly action: FinalMessageAction;
+    readonly reactionActive: boolean;
+    /** An approval card was posted this turn (approvals/card-signal.ts) — the card IS the
+     *  reply, so the model's narration is suppressed (same rule as Slack: "the card should
+     *  suffice"). The turn still counts as answered → the 👀 still clears. */
+    readonly cardPostedThisTurn?: boolean;
+}): CompletionPlan;
+/**
+ * Assemble the session state SEEDED into `send` for a turn. This seed only takes effect when
+ * the send STARTS a session (eve drops it on the resume path — see the session-state comment
+ * up top), which is exactly why `original` is only ever passed on the auto-thread turn: a fresh
+ * thread id guarantees a fresh session, so the seeded reaction coords are guaranteed to belong
+ * to THIS turn's triggering message. The reply surface (`channelId`) follows the re-key (the
+ * thread when threaded); the reaction target stays pinned to the mention in the BASE channel so
+ * 👀/✅ land where the human is looking. No original coords → completion does no reaction swap.
+ */
+export declare function buildGatewayState(input: {
+    readonly replyChannelId: string;
+    /** The guild the reply surface is in — seeded so the completion handler can rebuild the
+     *  engagement partition (see DiscordGatewayState.guildId). Absent for DMs (no guild). */
+    readonly guildId?: string;
+    readonly original?: {
+        readonly channelId: string;
+        readonly messageId: string;
+    };
+}): DiscordGatewayState;
+/**
+ * Consume this turn's reaction-swap coordinates from the LIVE session state: return the
+ * original-message coords and CLEAR them (consume-once). The clearing is the correctness
+ * guarantee on resumed sessions — a later turn can never react on a PREVIOUS turn's message;
+ * the coords only ever exist on the session-creating auto-thread turn. Mutates the passed
+ * state in place (eve write-back persists it). Pure in/out mapping → unit-tested.
+ */
+export declare function takeTurnStatus(state: DiscordGatewayState): {
+    original?: {
+        channelId: string;
+        messageId: string;
+    };
+};
+/** The cross-channel dispatch primitive the route hands the dispatch (eve's public
+ *  `args.to` — the same primitive github.ts's fan-out + divert legs use; it was `args.receive`
+ *  before eve 0.31 split the call into `to(channel, target).send(message, options)`). */
+export type UnifiedReceive = RouteHandlerArgs["to"];
+/**
+ * THE DISCORD PRIVACY FLOOR (fail-closed): may this surface join a PRIVATE cross-surface window?
+ *
+ * Every single-window surface needs a POSITIVE privacy fact before its wakes may share a context
+ * window with the domain's private Slack/GitHub/Linear/Notion conversations (GitHub:
+ * `repository.private === true`; Slack: the channel positively confirmed internal; Notion: the
+ * operator-vouch register). Discord's honest answer is that NO reliable positive signal exists
+ * in what reaches this gateway:
+ *   - The guild is the tenant boundary (external people aren't guild members), but guilds are
+ *     routinely PUBLIC/community servers with open invites — guild membership alone proves
+ *     nothing about who can read or post.
+ *   - The relay's MESSAGE_CREATE payload carries NO channel-permission data. The identity
+ *     layer's `everyoneCanView` field (discord-identity.ts) is documented "absent today" — and
+ *     its `discordVisibility` default of `private` is the WRONG direction here: that default is
+ *     conservative for MEMORY (learnings stay surface-tier), but for window ADMISSION
+ *     "default-private" would be permissive — it would admit every guild channel, including
+ *     @everyone-viewable channels in public community guilds. A default is not a positive fact.
+ * So, exactly like Notion (whose public_url was similarly misleading), the floor is the
+ * OPERATOR-VOUCH register (identity/trust.ts isVouchedInternal — the deployer's out-of-band
+ * "this guild/channel is members-only internal" assertion, keyed on the workspaceKey
+ * `discord/<guild>` or a surfaceKey `discord/<guild>/<channel>`; a thread also honours a vouch
+ * on its PARENT channel via the domain-grain key), or the OE_TRUST=internal blanket switch for
+ * internal-only deploys. Code enforces, the operator vouches — never an inference from a payload
+ * field. Fail-CLOSED: un-vouched ⇒ false ⇒ the wake stays on the native per-channel path.
+ *
+ * DMs / group-DMs (no guildId) NEVER pass — unconditionally, even under OE_TRUST=internal
+ * (mirroring how the e2e driver allowlist excludes guildless surfaces): a DM is a PERSONAL
+ * surface with no tenant boundary at all, and its content must never enter a team-shared window.
+ *
+ * ATTACKER ANALYSIS (what goes wrong if this rule is too loose): if a public/@everyone-readable
+ * channel were admitted, anyone who can join the guild (open invite) could (a) READ private
+ * cross-surface context — an @mention here would recall, into a public channel, whatever the
+ * shared window absorbed from the domain's private repos/channels/docs — and (b) WRITE into the
+ * shared context: their message text enters the one window every surface's supervisor judges
+ * from, a persistent cross-surface prompt-injection foothold. The vouch register makes admission
+ * an explicit operator assertion with exactly that blast radius in view.
+ *
+ * Pure (vouch + env injectable) → the truth table is unit-tested without a live register
+ * (scripts/unified-window-test.ts). Mirrors notion.ts's floor + github.ts's positive-privacy gate.
+ */
+export declare function discordSingleWindowPrivacyOk(input: {
+    readonly guildId: string | undefined;
+    /** `discord/<guild>` — a workspace-level vouch covers every channel in the guild. */
+    readonly workspaceKey: string;
+    /** `discord/<guild>/<channel-or-thread>` — a surface-level vouch narrows to one. */
+    readonly surfaceKey: string;
+    /** The DOMAIN-grain key (a thread's parent channel — domainKeyOf); a vouch on the parent
+     *  channel covers its threads. Equal to surfaceKey for a non-thread. */
+    readonly domainKey?: string;
+}, deps?: {
+    readonly vouched?: (workspaceKey: string, surfaceKey: string) => boolean;
+    readonly trustEnv?: string | undefined;
+}): boolean;
+/**
+ * The Discord arm of the ONE single-window mention decision — a thin shim over the shared seam
+ * (unified-window.ts {@link singleWindowMentionPolicy}), exactly like github.ts's
+ * shouldSuppressNativeMention and slack-events.ts's slackSingleWindowMentionPolicy:
+ * `suppressNative` ⟺ the divert owns the @mention (this file's native dispatch — auto-thread,
+ * 👀, typing, per-channel session — stands down); `addressing` is the `direct-mention` stamp the
+ * diverted wake carries so the unified supervisor knows it is owed an answer — which it must give
+ * through the `reply` tool, since OPE-1982 deleted the prose route. Both derive from the SAME predicate (`singleWindow && privacyOk && isMention`), so
+ * suppress-and-keep stay perfectly complementary: never a double reply, never a gap. `privacyOk`
+ * is {@link discordSingleWindowPrivacyOk}'s verdict (fail-closed). Pure → unit-tested truth table.
+ */
+export declare function discordSingleWindowMentionPolicy(singleWindow: boolean, isMention: boolean, privacyOk: boolean): SingleWindowMentionPolicy;
+/** Everything {@link buildDiscordUnifiedWake} needs — extracted by the divert wiring, built
+ *  directly by tests. */
+export interface DiscordUnifiedWakeInput {
+    readonly guildId: string;
+    /** The conversation the trigger arrived in (a thread's OWN channel id when in a thread). */
+    readonly channelId: string;
+    /** The thread's parent channel, when known (auth enrichment) — the locus CONTAINER. */
+    readonly parentChannelId?: string;
+    readonly isThread: boolean;
+    readonly addressing: "direct-mention" | "channel-watch" | "name-drop";
+    /** This conversation carries an ENGAGED registry row — an @mention (or an earned reply) invited
+     *  the agent and the invitation still stands — so a JUDGED wake states `follow-up="thread-engaged"`
+     *  (channels/engaged-wake.ts). Unset/false ⇒ no attribute, byte-identical. */
+    readonly threadEngaged?: boolean;
+    readonly wakeId: string;
+    readonly engagementTier?: WakeEngagementTier;
+    /** The OUTGOING generation's recorded TAIL (OPE-794), rendered as this first wake's backscroll.
+     *  Only a FRESH generation's first wake carries one. */
+    readonly tail?: readonly WakeMessageInput[];
+    /** The hydrated surrounding conversation, STRUCTURED — `renderWake` renders it through core's own
+     *  road, which de-duplicates it against {@link tail} and caps BELOW that (OPE-1749). This road used
+     *  to hand a pre-rendered string down beside the wake, which bypassed both. */
+    readonly contextLines?: readonly ContextLine[];
+    /** `renderContext`'s provenance label for {@link contextLines}. */
+    readonly contextSource?: string;
+    /** The bot's display name — name-drop wakes only (what the human actually said). */
+    readonly botName?: string;
+    /** This surface could not read its own history since the seat's last wake (core
+     *  channels/seat-catch-up.ts). Rendered as a trusted `<system-note>`; unset ⇒ no note. */
+    readonly catchUpUnavailable?: string;
+    readonly trigger: {
+        readonly id: string;
+        readonly author: string;
+        readonly authorId: string;
+        readonly sentAt: string;
+        readonly text: string;
+        /**
+         * Resolved per-wake trust tier (identity/wake-trust.ts).
+         *
+         * 🔴 REQUIRED, NOT OPTIONAL (OPE-596) — see LinearSupervisorWakeInput.trigger.trust. The field
+         * used to default UPWARD (`?? (direct ? "principal" : "peer")`), which is fail-OPEN, and since
+         * OPE-577 the tier decides the `<untrusted_external_data>` fence. A caller that cannot resolve
+         * a tier states the fail-closed one itself: `relay` for a machine author, `unauth` for an
+         * unvouchable human.
+         */
+        readonly trust: WakeTrust;
+    };
+}
+/**
+ * Build the NormalizedWake for one DIVERTED Discord wake — the exact shape
+ * buildGitHubSupervisorWake produces for GitHub, with Discord's locus mapping: container =
+ * the (parent) channel, conversation = the thread when the trigger was in one. Always stamps
+ * the platform address + P5 disclosure + wake-id (this builder exists ONLY for the
+ * single-window path — the native dispatch renders via renderTurn/renderNameDropTurn,
+ * untouched). renderWake then emits the `{message, context}` every OE dispatch sends — the
+ * SAME renderer Slack/GitHub/Linear/Notion use, with NO platform branch. Pure → unit-testable.
+ */
+export declare function buildDiscordUnifiedWake(input: DiscordUnifiedWakeInput): NormalizedWake;
+/** Everything {@link discordNativeWake} needs — extracted by the native dispatch, built directly
+ *  by tests. The NON-unified sibling of {@link DiscordUnifiedWakeInput}: no wake-id (per-channel
+ *  session; the reply posts back via message.completed, not a routed reply tool) and no P5
+ *  disclosure (single-surface, not a cross-surface window). */
+export interface DiscordNativeWakeInput {
+    /** The conversation the trigger arrived in (a thread's OWN channel id when in a thread). */
+    readonly channelId: string;
+    /** The thread's parent channel, when known — the locus CONTAINER (domain/spend grain). */
+    readonly parentChannelId?: string;
+    readonly isThread: boolean;
+    /** A DM (channel type 1/3) — an inherently-addressed `direct` wake whose reason is `dm`. */
+    readonly isDm: boolean;
+    readonly addressing: "direct" | "thread-follow" | "name-drop";
+    /** This conversation carries a PARTICIPATING, un-stopped engagement row — see
+     *  {@link DiscordUnifiedWakeInput.threadEngaged}. 🔴 NOT derivable from `thread-follow`: that tier
+     *  is reached past an `isEngaged` gate a name-drop's WARM latch (`participating: false`) also
+     *  satisfies, and a seat nobody invited must not be told it is enrolled. */
+    readonly threadEngaged?: boolean;
+    /** The bot's display name — name-drop wakes only (what the human actually said). */
+    readonly botName?: string;
+    /** RAW side-channel backscroll (mention/name-drop hydration) — renderWake wraps it (W3). */
+    readonly contextLines?: readonly ContextLine[];
+    readonly contextSource?: string;
+    readonly trigger: {
+        readonly id: string;
+        readonly author: string;
+        readonly authorId: string;
+        readonly sentAt: string;
+        readonly text: string;
+        /** Resolved per-wake trust tier (identity/wake-trust.ts). 🔴 REQUIRED (OPE-596) — see
+         *  {@link DiscordUnifiedWakeInput}'s trigger tier for the whole reason. */
+        readonly trust: WakeTrust;
+    };
+}
+/**
+ * Build the NormalizedWake for one NATIVE (non-diverted) Discord wake — the per-channel-session
+ * path that renderTurn/renderNameDropTurn used to hand-render. It maps into the SAME shared type
+ * every other surface uses, so renderWake emits the one canonical dialect with NO platform branch:
+ *  - `direct` (DM / @mention): the conversation driver — renderWake returns the body VERBATIM (no
+ *    preamble, no envelope, unwrapped — W4), byte-identical to the old renderTurn(true).
+ *  - `thread-follow` (engaged non-mention) / `name-drop`: JUDGED — the canonical Slack-parity
+ *    preamble + the full wake envelope (the migration's deliberate convergence; the old Discord
+ *    prose stub had DRIFTED away from the social-chatter / never-re-answer / PREFER_NO_REPLY_TOOL
+ *    sentences, each of which encodes an observed judge failure).
+ * Locus: container = the (parent) channel; conversation = the thread when the trigger was in one.
+ * No wakeId is minted (a native wake answers through the base `reply`, which names no wake). Pure →
+ * unit-testable without a live Discord call.
+ */
+export declare function discordNativeWake(input: DiscordNativeWakeInput): NormalizedWake;
+/** Everything {@link buildDiscordDmWake} needs — extracted by the DM divert, built directly by
+ *  tests. Deliberately NARROWER than {@link DiscordUnifiedWakeInput}: a DM has no guild, no thread,
+ *  no engagement tier and no name-drop, and every one of those absences is a property of the
+ *  surface rather than a field a caller might or might not fill in. */
+export interface DiscordDmWakeInput {
+    /** The DM (or group-DM) channel id — a DM's whole locus. */
+    readonly channelId: string;
+    readonly wakeId: string;
+    /** The OUTGOING generation's recorded TAIL (OPE-794), rendered as this first wake's backscroll.
+     *  Only a FRESH generation's first wake carries one. */
+    readonly tail?: readonly WakeMessageInput[];
+    readonly trigger: {
+        readonly id: string;
+        readonly author: string;
+        readonly authorId: string;
+        readonly sentAt: string;
+        readonly text: string;
+        /** Resolved per-wake trust tier (identity/wake-trust.ts). 🔴 REQUIRED (OPE-596) — the field
+         *  used to default to `principal`, the highest tier, on the reasoning that a DM partner IS the
+         *  seat's principal. That reasoning is about the ROOM, and the tier is about the AUTHOR. See
+         *  {@link DiscordUnifiedWakeInput}'s trigger tier. */
+        readonly trust: WakeTrust;
+    };
+}
+/**
+ * THE 1:1 (and group) DM WAKE for a first-classed Discord DM window (OPE-356) — the Discord twin of
+ * slack-events.ts's `slackDmWake`, and it renders through the SAME core renderer with no platform
+ * branch, so the two surfaces' DM envelopes are one dialect.
+ *
+ * ADDRESSING IS `direct-mention`, ALWAYS, doing the same two jobs it does on Slack. Semantically it
+ * is simply TRUE: everything said in a DM is said to the agent, which is why this path bypasses the
+ * engagement gate, the name-drop judge and the channel-watch silence bias entirely — a DM IS ALWAYS
+ * ANSWERED. Mechanically it is LOAD-BEARING: `direct-mention` is what stamps `oe_addressing` through
+ * the divert, which marks the wake as OWED a reply and selects the `[direct]` preamble's reply
+ * mandate. 🔴 IT IS NOT A DELIVERY PATH (OPE-1982): the addressed-prose bridge it used to arm is
+ * deleted, so a DM answer written as prose rather than a `reply` call is DROPPED on that channel
+ * like any other, and re-driven once towards the tool.
+ *
+ * `reason` is `dm`, not `mention`: the envelope's reason describes the SURFACE SHAPE. It is also the
+ * one reason that survives the OPE-744 collapse of `mention` into `channel-activity`, because no
+ * other attribute states "this is a direct-message room".
+ *
+ * NO `engagementTier`: that dial raises the bar for AMBIENT watching, and a DM is always answered.
+ *
+ * The `wakeId` is present because the unified channel is the delivery route: it is the id the model
+ * must echo to `reply`, and the only way a DM answer gets out. Pure → unit-testable.
+ */
+export declare function buildDiscordDmWake(input: DiscordDmWakeInput): NormalizedWake;
+/**
+ * THE DOMAIN'S ADMISSION POLICY over a mention/name-drop hydration, for BOTH of this surface's wake roads (OPE-1800).
+ * 🔴 THE DOMAIN'S POLICY, ON THIS READ TOO. A seated Discord wake takes TWO reads of the room: the since-last-wake catch-up, which has passed `seatAdmissionFor` since OPE-1726, and this hydration, which did not. So a `members-only` domain dropped a guest's message from the catch-up and then handed the seat the SAME message inside the context block. The policy is resolved by NAME from the caller's own domain key and applied by the shared core seam (channels/seat-admission.ts `admitContextLines`), which is the one mapping Slack's hydration takes — never a per-bundle copy.
+ * 🔴 THE SEAT DECIDES, AND THE SEAT IS `grainUsesUnifiedWindow(grain)` ALONE — never "which road this wake took". That is the exact predicate Slack resolves `seated` from ({@link slackDomainUsesUnifiedWindow}, "the SAME fact … without the async privacy floor"), and matching it is what gives one domain ONE admission answer. A wake whose room HAS a seat but which falls through to `dispatchTurn`'s native road — the guild vouch absent, or no `receive` — is a seat STOOD DOWN, not an unseated room: access/window-routing.ts calls that state `native-degraded` and hooks/window-routing.ts audits it `window.routing_degraded`. Reading it as "no seat" would hand that domain a second admission answer, selected by a runtime vouch.
+ * 🔴 A TRULY UNSEATED DEPLOYMENT KEEPS ITS WHOLE HYDRATION: `window.topology` unarmed, or no seat domain reaches the room, so `grainUsesUnifiedWindow` is false. There is no seat for a seat policy to govern, that hydration is the only context such a wake carries, and the shipped `wide` default would strip the attributable-bot lines it keeps for coherence.
+ * 🔴 GRADE FIRST, THEN ADMIT. `lines` must already carry the per-author regrade ({@link gradeDiscordContextLines}): the policy judges the RESOLVED tier, and an ungraded person floors at `unauth`, so admitting first would make `members-only` refuse every human line in the room.
+ * Nothing admitted ⇒ `undefined`, the same shape an absent fetch produces — never an empty slot, which renders as a quiet room.
+ */
+export declare function admitDiscordSeatLines(lines: readonly ContextLine[] | undefined, grain: SupervisorGrain, domainKey: string, isThread: boolean): readonly ContextLine[] | undefined;
+/**
+ * The WINDOW road's use of {@link admitDiscordSeatLines}: admit, then derive the taint-join facts — both over ONE set.
+ * 🔴 IT NO LONGER RENDERS (OPE-1749). It used to hand `divertDiscordWakeToUnifiedWindow` a PRE-RENDERED string, which took this road OUT of the core render — and with it out of the envelope de-duplication and the cap ORDER that `renderWake` applies through `hydrationSlices`. A seat whose carried TAIL overlapped this hydration then rendered each overlapping message TWICE and spent the ten-line cap doing it. The road now hands the structured lines down to the builder, exactly as every other surface does, and core decides what renders.
+ * 🔴 ONE SET FEEDS BOTH OUTPUTS, so the join can never carry a line the policy REFUSED — which is the property that matters, because a refused line's bytes never reach the model. It is not an equality of counts: the core render applies its own bounds and the de-duplication drops the envelope's own copies, so FEWER lines render than the join marks. That direction over-taints, which is the safe one (OPE-475) — and a de-duplicated line's bytes did enter, through the envelope sibling that replaced it.
+ * Nothing admitted ⇒ EMPTY on both, the same shape an absent or empty fetch produces, never an empty context block.
+ */
+export declare function discordSeatContextForWindow(lines: readonly ContextLine[] | undefined, source: string | undefined, grain: SupervisorGrain, domainKey: string, isThread: boolean): {
+    readonly lines: readonly ContextLine[];
+    readonly source?: string;
+    readonly ingestion: ReadonlyArray<ReturnType<typeof contextLineIngestion>>;
+};
+/**
+ * Divert one Discord wake into the unified window: get-or-create the DOMAIN session (the SAME
+ * registry row + rotation policy every other surface's live deps drive — github.ts
+ * liveGitHubSupervisorDeps — so a Discord wake lands in whatever generation the domain is on),
+ * build + render the wake with a host-minted wake-id, and hand it to the shared
+ * divertToUnifiedWindow (which stamps the auth and registers the durable wakeId→origin map
+ * entry BEFORE the send, inside unified.ts's fail-closed receive).
+ *
+ * 🔴 NOTHING HERE REACTS TO A SESSION THAT DIES AT TURN TIME, and nothing can: the dispatch awaits
+ * only the ENQUEUE, so a turn-time throw cannot reject it, and eve emits no userland event for the
+ * unreadable-World class (channels/session-resume.ts holds the measurement). This comment used to
+ * promise a force-rotate-and-re-deliver arm; OPE-174 removed that arm as provably inert. The
+ * remedy that does work is PRE-DISPATCH — the OPE-599 runtime-change claim below, which rotates
+ * BEFORE the wake goes out so the trigger lands in a session the running eve build can read.
+ */
+/**
+ * EXPORTED FOR THE INGRESS CONTRACT TEST (OPE-1719), not for another caller. `dispatchTurn` is the
+ * only production caller and it is one file away. `scripts/owned-thread-ingress-wiring-test.ts`
+ * drives THIS function — the real Discord ingress divert, over the real store — because a test that
+ * reimplemented the wake dep would stay green after somebody moved this leg back to the raw divert,
+ * which is the exact regression the ticket closes.
+ */
+export declare function divertDiscordWakeToUnifiedWindow(input: {
+    readonly msg: DiscordRelayMessage;
+    readonly auth: OpenEverywhereDiscordAuth;
+    readonly partition: Partition;
+    /** Guaranteed `unified` + `singleWindow` + `domainName` by the caller's gate. */
+    readonly grain: SupervisorGrain;
+    readonly addressing: "direct-mention" | "channel-watch" | "name-drop";
+    /**
+     * The caller's OWN `discordSingleWindowPrivacyOk` verdict — an operator-VOUCHED guild surface. It
+     * is the same fact the trigger's trust tier is resolved from, and the catch-up's per-author trust
+     * resolver reads it rather than hardcoding one (channels/seat-catch-up.ts `surfaceInternal` says
+     * why). Today the only production caller gates this whole divert on it, so it is always `true`
+     * there; passing it keeps that a STRUCTURAL fact rather than a convention a second caller could
+     * break, since this function is exported.
+     */
+    readonly privacyOk: boolean;
+    /** The ENROLMENT fact for a judged wake — see {@link DiscordUnifiedWakeInput.threadEngaged}. The
+     *  caller reads it off the engagement row it already fetched for the dispatch gate. */
+    readonly threadEngaged?: boolean;
+    readonly receive: UnifiedReceive;
+    /** The ADMITTED backscroll lines, STRUCTURED, possibly empty (OPE-1749). */
+    readonly contextLines: readonly ContextLine[];
+    /** `renderContext`'s provenance label for {@link contextLines}. */
+    readonly contextSource?: string;
+    /** OPE-475: the taint join's per-line facts for the SAME backscroll lines `contextLines` holds
+     *  ({@link gradeDiscordContextLines} output, mapped via `contextLineIngestion`) — carried
+     *  alongside them because the join is the CALLER's to build: the render drops the envelope's own
+     *  copies, whose bytes still entered through those siblings. Possibly empty. */
+    readonly contextIngestion: ReadonlyArray<ReturnType<typeof contextLineIngestion>>;
+}): Promise<void>;
+/** The `send` shape this channel dispatches with (SendFn parametrized by our state). The first
+ *  arg is a plain string OR eve's SendPayload `{ message, context }` — `context` strings are
+ *  appended as user messages before the delivery turn (used for the wake/mention backscroll). */
+export type DiscordGatewaySend = (message: string | {
+    readonly message: string;
+    readonly context?: readonly string[];
+}, options: {
+    auth: OpenEverywhereDiscordAuth;
+    continuationToken: string;
+    state: DiscordGatewayState;
+}) => Promise<unknown>;
+/**
+ * Resolve the wake decision (consulting the engagement registry only when needed) and, if it
+ * passes, start/resume the durable session. A mention also ENGAGES the channel so later
+ * non-mention replies keep waking it (reply-without-re-tagging, exactly like Slack). Runs in
+ * the background (handed to waitUntil) so the route acks fast.
+ */
+export declare function dispatchTurn(msg: DiscordRelayMessage, auth: OpenEverywhereDiscordAuth, send: DiscordGatewaySend, createThread?: (channelId: string, messageId: string, name: string) => Promise<string | null>, resolveParent?: (channelId: string) => Promise<string | undefined>, receive?: UnifiedReceive): Promise<void>;
+export declare function engagementCoordsFor(state: DiscordGatewayState): {
+    p: Partition;
+    key: string;
+} | null;
+/**
+ * Promote the surface to PARTICIPATING on a POSTED reply (incl. a card-only reply — the card IS
+ * the reply), mirroring slack.ts's post branch: a warm (name-drop) surface the agent actually
+ * answered goes sticky, its silent streak resets, and its failures go loud.
+ *
+ * THE DISCORD DIVERGENCE (why this reads-then-promotes instead of blindly engaging): Slack promotes
+ * unconditionally because its engagement grain is the THREAD, so a name-drop reply merely
+ * establishing THREAD engagement is harmless. Discord's BASE-channel engagement grain is the WHOLE
+ * CHANNEL, and a base-channel name-drop DELIBERATELY does not engage (dispatchTurn — else every
+ * subsequent channel message becomes a judged model turn, the "engaged-channel surprise" from live
+ * testing). So a base-channel name-drop reply must NOT create whole-channel engagement. We only
+ * PROMOTE an EXISTING warm record (a thread name-drop engaged at dispatch, or a mention/engaged
+ * surface); no record ⇒ a base-channel name-drop ⇒ leave it un-engaged. Best-effort: engagement
+ * must never fail a delivered reply.
+ */
+export declare function promoteParticipatingOnReply(state: DiscordGatewayState): Promise<void>;
+/**
+ * Warm auto-disengage on a JUDGED-SILENT turn (mirrors slack.ts's silent branch): a WARM
+ * (participating:false) surface that keeps judging NO_REPLY is shed after WARM_SILENT_LIMIT turns,
+ * so a one-off name-drop that never earns a reply doesn't leave the bot quietly following forever.
+ * PARTICIPATING surfaces are EXEMPT — they're sticky, only an explicit stop disengages them — so a
+ * missing record OR participating:true is a no-op. Best-effort; engagement bookkeeping never throws
+ * out of the completion handler.
+ */
+export declare function maybeShedWarmSurface(state: DiscordGatewayState): Promise<void>;
+declare const _default: import("eve/channels").Channel<DiscordGatewayState, Record<string, unknown>, Record<string, unknown>>;
+export default _default;
+//# sourceMappingURL=discord-gateway.d.ts.map