@open-everywhere/provider-discord 0.1.0

package/dist/agent/channels/discord-gateway.js

@@ -0,0 +1,2591 @@
+// The Discord GATEWAY ingestion surface — Milestone 2 of the Discord Gateway feature.
+//
+// Discord delivers ambient channel/DM messages (MESSAGE_CREATE) ONLY over a persistent
+// Gateway WebSocket, never to an HTTP endpoint — so a serverless deploy can't receive them
+// directly. Milestone 1 (deploy/discord-relay/) is a tiny always-on process that holds that
+// socket and forwards each message here as a signed HTTP POST. THIS file is the receiving
+// end: it verifies the relay's HMAC, reconstructs the real Discord identity, wake-gates like
+// every other surface, dispatches an agent turn on a durable-resume session, and posts the
+// reply back to Discord via REST.
+//
+// MOUNTING CHOICE mirrors channels/webhooks.ts: a plain `defineChannel` with one POST route
+// (`/eve/v1/discord-gateway`), not a front-route over an existing channel (slack-front.ts).
+// The relay POSTs to a BRAND-NEW public surface with no existing owner, so the least-invasive
+// mount is the first-class route primitive — exactly the shape webhooks.ts uses. Unlike the
+// interaction-based channels/discord.ts (Discord's HTTP Interactions → slash commands only),
+// this path carries ambient messages, so it does its OWN identity capture + dispatch and posts
+// replies with the bot token over REST (there is no interaction token to edit/followup).
+//
+// DISPATCH + RESUME. A route handler starts/continues a session via `args.send` (the same
+// primitive eve's own channel wrappers use internally): the continuation token keys the
+// durable session on the Discord channel id, so subsequent messages RESUME it → real
+// multi-turn conversation. The turn runs async (waitUntil); its final reply is posted from
+// the `message.completed` event handler, NOT synchronously in the route. The target channel
+// id is threaded to that handler via the session `state` /
+// `context`, the way eve's discordChannel threads its own channelId.
+//
+// 🔴 A DM DOES NOT TAKE THAT PATH ANY MORE (OPE-356). A `channelType` 1 (DM) or 3 (group DM) is
+// DIVERTED into the DM's own first-class standing window — `divertDiscordDmToWindow` below — so it
+// gets a rotatable, WAKEABLE address instead of a per-channel session eve alone can address, and its
+// reply comes back through the unified channel's arm rather than this file's `message.completed`.
+// The paragraph above still describes every GUILD wake; since OPE-368 removed the
+// `OE_DM_SEAT_ROTATION` escape hatch it no longer describes any DM at all.
+//
+// FAIL-CLOSED. No OE_RELAY_SECRET, or a missing/malformed/mismatched signature → 401, never
+// dispatch. The payload is untrusted JSON: every field is probed defensively, bot authors are
+// dropped, and unresolvable payloads are rejected rather than guessed at.
+//
+// Env this surface reads at runtime:
+//   OE_DM_SEAT_ROTATE_*    (optional) the DM window's rotation thresholds (core channels/dm-seat.ts),
+//                          never the supervisor's. A DM window itself is unconditional since OPE-368
+//                          retired the OE_DM_SEAT_ROTATION master switch.
+//   OE_RELAY_SECRET        (required) HMAC-SHA256 key shared with the relay; unset → all 401.
+//   DISCORD_BOT_TOKEN      (required to reply) bot token for the REST create-message/thread calls.
+//   discord.autoThread (optional, default ON) a mention in a base channel opens a thread and
+//                          the conversation re-keys onto it; set "false"/"0" for inline replies.
+//   discord.statusUx   (optional, default ON) show "working" affordances during a turn — a
+//                          👀 "seen/working" reaction on direct addresses (mention/DM; on
+//                          auto-threaded mentions it is REMOVED when the answer lands — absence
+//                          = done, ✅ stays reserved for humans) and Discord's NATIVE typing
+//                          indicator while the turn runs (re-triggered on turn/tool events; it
+//                          expires by itself, so there is nothing to track or clean up across
+//                          turns); set "false"/"0" off.
+import { defineChannel, POST } from "eve/channels";
+import { buildDiscordAuth } from "./discord-identity.js";
+import { threadParentChannelId } from "./discord-channel-info.js";
+import { splitForDiscord } from "./discord-post.js";
+import { discordFetch } from "./discord-rest.js";
+import { RateLimitExhaustedError } from "@open-everywhere/core/agent/adapter-api.js";
+import { finalMessageAction, nameDropPattern, wakeNameDropTokens, NO_REPLY_SENTINEL, shouldRotate, renderWake, mkMessageTrigger, supervisorGrainFor, unifiedSupervisorToken, grainUsesUnifiedWindow, mintRotationToken, claimRuntimeRotation, stampMintedRuntime, mintWakeId, discordVendorEventTime, spreadVendorTs, singleWindowMentionPolicy, divertToUnifiedWindow, divertInboundToUnifiedWindow, verifyWebhookSignature, cancelAnchoredTurn, turnAnchorKey, STOP_HAND_UNICODE, STOP_HAND_SLACK_NAME, domainKeyOf, resolvePartition, nameDropWakeEnabled, seatCatchUp, seatCatchUpSinceMs, seatAdmissionFor, admitContextLines, backscrollTrustResolver, engagementTierFor, getConfig, deploymentOrg, isVouchedInternal, resolveWakeTrustFromContext, stampNonMemberChatAuth, contextLineIngestion, resolveExternalPolicy, externalPolicyOverrideFor, withholdsBody, roomIsSilenced, silentRoomNotice, silentNoticeKey, EXTERNAL_SENDER_NOTICE, EXTERNAL_MENTION_ACK, owesSuppressedMentionAck, suppressionRendering, getOperationalStore, appendAudit, carryTailForward, recordWakeTail, tailAuthorGrain, dmWindowRegistryKey, auditSupervisorFailure, healPrunedDeploymentStrand, engagedFollowUpContract, dispatchNativeWakeWithRetry, } from "@open-everywhere/core/agent/adapter-api.js";
+// Re-exported so every existing importer (scripts/discord-gateway-test.ts, the completion
+// post-back below) keeps compiling — the implementation moved to discord-post.ts so the
+// unified reply arm (unified-reply.ts) can split without importing this whole channel module.
+export { splitForDiscord };
+import { bumpThreadSilentStreak, disengageThread, getThreadEngagement, markThreadEngaged, auditNameDropWoke, auditNameDropSilent, WARM_SILENT_LIMIT, ingressSpendGate, consumeCardPostedThisTurn, peekCardPostedThisTurn, consumeRepliedThisTurn, dropClosingProse, isAllowedDriver, parseDriverAllowlist, 
+// THE DM SEAT (OPE-356) — the same core mint/touch/flag every first-classed DM window uses; the
+// Slack front route reaches for exactly these three.
+getOrCreateDmSeat, touchDmSeat, buildIngestedReaction, ingestReaction, liveReactionSink, consumeNoReplyThisTurn, consumeStandDownSilenceThisTurn, STAND_DOWN_SILENCE_REASON, NO_REPLY_SENTINEL_REASON, auditNoReplySentinelObserved, getSettings, authPrincipalId, } from "@open-everywhere/core/agent/adapter-api.js";
+import { fetchDiscordBackscrollLines, gradeDiscordContextLines, DISCORD_RAW_FETCH_REACHBACK_HOURS } from "./discord-backscroll.js";
+function log(msg) {
+    console.log(`[open-everywhere:discord-gateway] ${msg}`);
+}
+function isObject(v) {
+    return typeof v === "object" && v !== null;
+}
+function str(v) {
+    return typeof v === "string" && v.length > 0 ? v : undefined;
+}
+/** Coerce a string OR a number (Discord's numeric channel type) to a non-empty string. */
+function strOrNum(v) {
+    if (typeof v === "string")
+        return v.length > 0 ? v : undefined;
+    if (typeof v === "number" && Number.isFinite(v))
+        return String(v);
+    return undefined;
+}
+/**
+ * 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 function parseRelayPayload(raw) {
+    if (!isObject(raw))
+        return null;
+    if (raw["source"] !== "discord-gateway-relay")
+        return null; // not our relay's shape
+    const m = raw["message"];
+    if (!isObject(m))
+        return null;
+    const channelId = str(m["channelId"]);
+    const author = isObject(m["author"]) ? m["author"] : undefined;
+    const authorId = author ? str(author["id"]) : undefined;
+    if (!channelId || !authorId)
+        return null; // no post-back target / no identity → unusable
+    const bot = isObject(m["bot"]) ? m["bot"] : undefined;
+    const member = isObject(m["member"]) ? m["member"] : undefined;
+    return {
+        id: str(m["id"]) ?? "",
+        content: typeof m["content"] === "string" ? m["content"] : "",
+        channelId,
+        channelType: strOrNum(m["channelType"]),
+        guildId: str(m["guildId"]),
+        author: { id: authorId, username: str(author["username"]), bot: author["bot"] === true },
+        mentionsBot: m["mentionsBot"] === true,
+        referencedMessageId: str(m["referencedMessageId"]),
+        // OPE-60 guest/unverified signal — forwarded by a relay that includes the member object;
+        // absent from older relays → undefined → today's fail-closed/vouch behaviour is unchanged.
+        memberPending: member && typeof member["pending"] === "boolean" ? member["pending"] : undefined,
+        // OPE-516 author-trust membership evidence, off the SAME member object. Defensive: only a real
+        // array of non-empty strings counts, and an empty result stays `undefined` so "the relay sent no
+        // member object" and "this member holds no roles" are not conflated in the shape (they resolve
+        // the same way, but the absence is honest).
+        memberRoles: Array.isArray(member?.["roles"])
+            ? member["roles"].filter((r) => typeof r === "string" && r.length > 0)
+            : undefined,
+        botName: bot ? str(bot["name"]) : undefined,
+        // WHICH bot this delivery came through — the multi-bot attribution field (item 27:
+        // N relay clients in one process each forward every message; botId is how dedupe and
+        // persona routing tell the copies apart). Carried from the relay since 5c67655.
+        botId: bot ? str(bot["id"]) : undefined,
+    };
+}
+/**
+ * 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 function parseRelayReaction(raw) {
+    if (!isObject(raw))
+        return null;
+    if (raw["source"] !== "discord-gateway-relay")
+        return null;
+    const ev = raw["event"];
+    if (ev !== "MESSAGE_REACTION_ADD" && ev !== "MESSAGE_REACTION_REMOVE")
+        return null;
+    const r = raw["reaction"];
+    if (!isObject(r))
+        return null;
+    const messageId = str(r["messageId"]);
+    const channelId = str(r["channelId"]);
+    const reactorId = str(r["reactorId"]);
+    const emoji = str(r["emoji"]);
+    if (!messageId || !channelId || !reactorId || !emoji)
+        return null;
+    return {
+        verb: ev === "MESSAGE_REACTION_ADD" ? "added" : "removed",
+        messageId,
+        channelId,
+        guildId: str(r["guildId"]),
+        channelType: strOrNum(r["channelType"]),
+        emoji,
+        reactorId,
+        messageAuthorId: str(r["messageAuthorId"]),
+        botId: str(r["botId"]),
+    };
+}
+/**
+ * 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 function parseRelayHeartbeat(raw) {
+    if (!isObject(raw))
+        return null;
+    if (raw["source"] !== "discord-gateway-relay")
+        return null;
+    if (raw["event"] !== "HEARTBEAT")
+        return null;
+    const hb = raw["heartbeat"];
+    if (!isObject(hb))
+        return null;
+    const relayId = str(hb["relayId"]);
+    const ts = typeof hb["ts"] === "number" && Number.isFinite(hb["ts"]) ? hb["ts"] : undefined;
+    if (!relayId || ts === undefined)
+        return null;
+    return { relayId, ts };
+}
+/** 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 function discordHeartbeatAuditRow(heartbeat, org) {
+    return {
+        org,
+        platform: "discord",
+        workspace: "relay",
+        surface: "heartbeat",
+        principalId: heartbeat.relayId,
+        action: "discord.heartbeat",
+        detail: { relayId: heartbeat.relayId, sentAtIso: new Date(heartbeat.ts).toISOString() },
+    };
+}
+/** Is this reaction the ✋ stop affordance? Discord delivers a unicode emoji as the char itself, but
+ *  a relay (or a custom emoji of the same name) may deliver the NAME — accept both spellings rather
+ *  than making the stop button depend on which one arrived. */
+function isStopHand(emoji) {
+    const bare = emoji.trim();
+    return bare === STOP_HAND_UNICODE || bare === STOP_HAND_SLACK_NAME;
+}
+/**
+ * The ✋ STOP arm (OPE-418) — cancel the turn anchored on the reacted message.
+ *
+ * 🔴 THE REACTOR GUARD HERE FAILS CLOSED, and that is a DIFFERENT posture from the feedback path
+ * below on purpose. The ingest path skips its bot-reactor drop when `botId` is unresolved, which
+ * costs a spurious telemetry row — harmless. Behind `cancel()` the same fail-OPEN would be a
+ * SELF-CANCEL: the bot's own ✋ (it places one on every delegating turn) would cancel the very turn
+ * that placed it. So a stop requires a POSITIVELY RESOLVED, non-bot reactor: no `botId` ⇒ no stop.
+ */
+async function routeStopHandReaction(rx, attachSession) {
+    if (!rx.botId) {
+        return { recorded: false, onBotReply: false, reason: "stop: bot identity unresolved — refusing to cancel (fail-closed)" };
+    }
+    if (rx.reactorId === rx.botId) {
+        return { recorded: false, onBotReply: false, reason: "stop: the reactor is the bot itself — never a self-cancel" };
+    }
+    const auth = buildDiscordAuth({ userId: rx.reactorId, guildId: rx.guildId, channelId: rx.channelId, channelType: rx.channelType });
+    const p = resolvePartition(ctxFromAuth(auth));
+    const result = await cancelAnchoredTurn({
+        org: p.org,
+        platform: "discord",
+        workspace: p.workspace,
+        requestedBy: rx.reactorId,
+        via: "reaction",
+        // The reaction knows EXACTLY which message it landed on, so it resolves by the sharp key and
+        // never falls through to the channel's newest-turn guess.
+        query: { anchorKey: turnAnchorKey("discord", rx.channelId, rx.messageId) },
+        attachSession,
+    });
+    return { recorded: false, onBotReply: false, reason: `stop: ${result.outcome}` };
+}
+/**
+ * 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 async function routeDiscordReaction(rx, deps) {
+    // ✋ FIRST, and only on ADD. ✋ is a MECHANISM, not feedback: it means "stop this", so it must
+    // never also be recorded as a sentiment signal about the message it sits on. Its REMOVAL is
+    // meaningless (the host removes it at turn end) and must never trigger anything.
+    if (rx.verb === "added" && isStopHand(rx.emoji) && deps.attachSession) {
+        return routeStopHandReaction(rx, deps.attachSession);
+    }
+    if (rx.botId && rx.reactorId === rx.botId) {
+        return { recorded: false, onBotReply: false, reason: "reactor is the bot itself — ignored (not feedback)" };
+    }
+    const onBotReply = Boolean(rx.botId) && rx.messageAuthorId === rx.botId;
+    // Reuse the identity/partition seam (no channelType needed for surfaceKey resolution).
+    const auth = buildDiscordAuth({ userId: rx.reactorId, guildId: rx.guildId, channelId: rx.channelId, channelType: rx.channelType });
+    const p = resolvePartition(ctxFromAuth(auth));
+    const reaction = buildIngestedReaction({
+        surface: "discord",
+        verb: rx.verb,
+        reactorId: rx.reactorId,
+        emoji: rx.emoji,
+        target: { channelId: rx.channelId, messageId: rx.messageId },
+        onBotReply,
+        partition: p,
+    });
+    return ingestReaction(reaction, deps.sink);
+}
+/** Production deps for the Discord reaction route: the live audit/telemetry sink, plus eve's cancel
+ *  door when the route has one (it is only reachable as `args.attachSession`). */
+function liveDiscordReactionDeps(attachSession) {
+    return { sink: liveReactionSink(), ...(attachSession ? { attachSession } : {}) };
+}
+/**
+ * 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 function relayGate(signatureHeader, rawBody, secret = process.env.OE_RELAY_SECRET) {
+    if (!secret) {
+        return { status: 401, reason: "OE_RELAY_SECRET is not set — rejecting unverified relay delivery" };
+    }
+    if (!verifyWebhookSignature(secret, rawBody, signatureHeader)) {
+        return { status: 401, reason: "invalid relay signature" };
+    }
+    return 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 function authForRelayMessage(msg) {
+    if (msg.author.bot) {
+        // The ONE narrow exception (item 29, e2e driver bot): a guild-pinned, env-allowlisted
+        // driver bot is treated as a user so full-path integration scenarios can drive the
+        // real agent. Fail-closed default-off (no env → unconditional drop, exactly as
+        // before); every acceptance is logged so an armed seam is never invisible.
+        if (!isAllowedDriver(msg.guildId, msg.author.id))
+            return null;
+        log(`e2e driver accepted as user: bot ${msg.author.id} in guild ${msg.guildId} (OE_TEST_DRIVER_IDS)`);
+    }
+    return buildDiscordAuth({
+        userId: msg.author.id,
+        guildId: msg.guildId,
+        channelId: msg.channelId,
+        channelType: msg.channelType,
+        // OPE-60: demote a pending (membership-screening-incomplete) member to external. Only set
+        // when the relay forwarded the member object; undefined otherwise (unchanged behaviour).
+        memberPending: msg.memberPending,
+        // OPE-671: the ✋ stop-hand anchor — see DiscordIdentityInput.messageId's doc.
+        messageId: msg.id,
+    });
+}
+/**
+ * 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 function isMisplacedDriver(guildId, botUserId, allowlist = parseDriverAllowlist(process.env.OE_TEST_DRIVER_IDS)) {
+    if (!botUserId)
+        return false;
+    if (guildId !== undefined && allowlist.has(`${guildId}:${botUserId}`))
+        return false; // pinned HERE — ordinary admission, not a misplacement
+    for (const entry of allowlist) {
+        if (entry.endsWith(`:${botUserId}`))
+            return true; // pinned to a DIFFERENT guild
+    }
+    return false;
+}
+/**
+ * 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 function authorFacts(msg) {
+    if (!msg.guildId)
+        return {};
+    return {
+        authorTrust: {
+            tenantKey: `discord/${msg.guildId}`,
+            authorId: msg.author.id,
+            // The membership keys this author holds, in the group-rung grammar the register's patterns
+            // are written in (identity/surface-key-grammar.ts). Empty when the relay sent no member
+            // object — no evidence, which the register reads as "matched nothing".
+            memberships: (msg.memberRoles ?? []).map((roleId) => `discord/${msg.guildId}/role:${roleId}`),
+        },
+    };
+}
+/**
+ * The resolved external-participant policy for one room: the ORG DEFAULT, with the DOMAIN OVERRIDE
+ * applied when the domain registry can be read.
+ *
+ * 🔴 AN UNREADABLE DOMAIN REGISTRY DEGRADES TO THE ORG DEFAULT, IT DOES NOT THROW. Every other
+ * `getConfig()` call on this path sits BELOW the DM early-return, so a DM never touched the config
+ * registry before this feature existed; making the policy the first thing that does would let an
+ * unregistered config take DMs off the air. "Could not read the domain registry" means "no domain
+ * override", which resolves to the shipped org default — today's behaviour, which is the only safe
+ * answer. A genuinely broken config is still loud everywhere else it is read.
+ */
+function externalPolicyForRoom(roomKey) {
+    try {
+        return resolveExternalPolicy(externalPolicyOverrideFor(roomKey, getConfig().loadDomains()));
+    }
+    catch {
+        return resolveExternalPolicy();
+    }
+}
+export function discordExternalVerdict(input) {
+    if (withholdsBody(input.author, input.policy))
+        return input.addressed ? "withheld-addressed" : "withheld-ambient";
+    // A DM contributes NO room leg — on a DM the trust plane asks about the PARTNER, not the room.
+    const room = input.isDm ? { dm: true } : { surfaceKey: input.roomKey };
+    return roomIsSilenced({ room, ingested: [input.author] }, input.policy) ? "silent-room" : "proceed";
+}
+/** Build the BindableContext the identity/partition seam expects from a dispatch auth. */
+function ctxFromAuth(auth) {
+    return { channel: { kind: "discord" }, session: { auth: { current: auth } } };
+}
+/**
+ * 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 function isThreadChannelType(channelType) {
+    return channelType === "10" || channelType === "11" || channelType === "12";
+}
+/**
+ * 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 function isDmChannel(channelType) {
+    return channelType === "1" || channelType === "3";
+}
+/**
+ * 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 function shouldDispatchDiscord(input) {
+    return input.isDm || input.mentionsBot || input.isEngaged;
+}
+// Engagement is per-conversation. A Discord thread is its OWN channel id, so the channel id is
+// the right engagement key: the partition surfaceKey already includes it, and using it as the
+// registry's per-thread key keeps threads and their parent channel independently engaged.
+function engagementKey(msg) {
+    return msg.channelId;
+}
+/**
+ * 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 function nameDropEligible(input) {
+    if (input.mentionsBot || input.isDm || input.isEngaged)
+        return false;
+    if (input.authorIsBot)
+        return false;
+    const t = input.channelType;
+    if (t !== "0" && t !== "5" && t !== "10" && t !== "11" && t !== "12")
+        return false;
+    if (!input.botName)
+        return false;
+    return wakeNameDropTokens(input.botName).some((token) => nameDropPattern(token).test(input.content));
+}
+/**
+ * The name-drop road's audit key for one Discord message (OPE-1899) — the partition every other
+ * Discord row is keyed by, plus the two ids a reader joins on. Built here rather than at the two
+ * call sites so the ADMIT row and the SILENT row can never key differently.
+ * 🔴 `surface` IS THE WHOLE `surfaceKey`, NOT THE BARE CHANNEL ID, because that is what every other
+ * audit row this file writes carries (`discord.external_policy_suppressed`, the spend gate, the
+ * dispatch row). An operator answering "is this road dead in that room" filters by that value, so a
+ * row keyed any other way is a row their query cannot see.
+ * Discord's messages carry no separate timestamp on these facts, so the message's own id IS its
+ * surface locator — the same value the ✋ anchor and the reaction swap address a message by.
+ */
+function nameDropAuditKey(partition, msg) {
+    return {
+        org: partition.org,
+        platform: partition.platform,
+        workspace: partition.workspace,
+        surface: partition.surfaceKey,
+        principalId: msg.author.id,
+        container: msg.channelId,
+        ts: msg.id,
+    };
+}
+// --- turn message -----------------------------------------------------------
+//
+// (The old renderTurn / renderNameDropTurn hand-rolled prose renderers were RETIRED in the
+// NormalizedWake migration — a design note commit 3. The native dispatch
+// now builds a {@link discordNativeWake} and renders it through the ONE shared renderWake, so
+// Discord's judged/name-drop wakes carry the canonical Slack-parity preamble + the full wake
+// envelope instead of a drifted prose stub. Direct DM/@mention bodies still pass through verbatim,
+// via renderWake's `direct` addressing — W4.)
+// Bot-auth header shared by every REST call below. `Bot <token>` is Discord's scheme; the token
+// is a SECRET — it rides in the header, NEVER in a log line or error string. Returns null when
+// there is no token, so each caller degrades to today's behaviour (silence) rather than throwing.
+function botAuthHeaders(token) {
+    return { authorization: `Bot ${token}`, "content-type": "application/json" };
+}
+// --- the gateway's 429 backoff (OPE-1311) -----------------------------------
+//
+// Every REST write below goes through `discordFetch` (discord-rest.ts), the ONE Discord write funnel,
+// so a rate-limited gateway write honours the delay Discord names — in the JSON `retry_after` body
+// field, which wins over the header. OPE-1236 put that funnel over the reply seam and the message
+// ops; this file was out of that ticket's scope and failed on Discord's FIRST refusal.
+//
+// 🔴 EXHAUSTION IS LOGGED BY NAME, THEN SWALLOWED. Every write here is fail-silent by design: the
+// turn already ran, and no failure arm may throw into the caller. So a `RateLimitExhaustedError`
+// would leave NO trace at all — the silent drop the backoff exists to prevent. Each catch below
+// therefore names it before swallowing it, the posture `slackForm` and the wake-backscroll fetcher
+// take (OPE-1211). Every field on that error is token-free and id-free, so the line is safe to log.
+/**
+ * The tighter policy the two EPHEMERAL status affordances use — typing and the 👀 reaction.
+ *
+ * 🔴 THE SHARED DEFAULTS ARE WRONG FOR THESE TWO, AND THE REASON IS LATENCY, NOT CORRECTNESS. Both
+ * are awaited INLINE on the turn's own path: `triggerDiscordTyping` runs inside the streaming loop
+ * and the reaction is set before the turn starts. The shared 4-attempt / 30 s-per-wait / 60 s-budget
+ * policy would stall a live turn for up to a minute to deliver a typing indicator that Discord
+ * expires after 10 seconds — a worse outcome than dropping the affordance, which is exactly what the
+ * code did before this backoff existed. So they get one retry and a 2 s ceiling, and give up.
+ *
+ * This mirrors `slack-web-api.ts`, which passes the same shape for the `auth.test` identity probe on
+ * Slack's 3-second event-ack path, and the reason `RetryPolicy` exists as a caller-settable shape.
+ * The writes that must LAND — the completion post-back, the open-DM, the thread open — keep the
+ * shared defaults.
+ *
+ * 🔴 IT IS SPREAD LAST, SO A CALLER CANNOT WIDEN IT. The two functions merge it OVER `deps.retry`, not
+ * under it. A test may still inject a `sleep` or a clock — this policy names neither — but nothing can
+ * hand the typing indicator the 60 s budget, which is the whole point of it having its own policy.
+ */
+const AFFORDANCE_RETRY = { maxAttempts: 2, capMs: 2_000, totalBudgetMs: 2_000 };
+/**
+ * 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 async function discordCreateMessage(channelId, content, deps = {}) {
+    const token = process.env.DISCORD_BOT_TOKEN;
+    if (!token) {
+        log(`DISCORD_BOT_TOKEN is not set — cannot post to channel ${channelId}`);
+        return null;
+    }
+    if (!channelId) {
+        log("no channel id — nothing to post to");
+        return null;
+    }
+    try {
+        const res = await discordFetch("POST /channels/{id}/messages", `https://discord.com/api/v10/channels/${channelId}/messages`, {
+            method: "POST",
+            headers: botAuthHeaders(token),
+            body: JSON.stringify({ content }),
+        }, deps);
+        if (!res.ok) {
+            log(`Discord create-message failed (${res.status}) for channel ${channelId}`);
+            return null;
+        }
+        const body = (await res.json());
+        return isObject(body) ? (str(body["id"]) ?? null) : null;
+    }
+    catch (err) {
+        // The post-back is fail-silent, so an exhausted 429 retry must still leave a trace — see the
+        // backoff note above. The error's own message names the attempts and the total wait.
+        if (err instanceof RateLimitExhaustedError) {
+            log(`Discord create-message rate limited for channel ${channelId}: gave up after ${err.attempts} attempts (waited ${err.waitedMs} ms)`);
+            return null;
+        }
+        log(`Discord create-message error for channel ${channelId}: ${err?.message ?? String(err)}`);
+        return 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 async function openDiscordDm(userId, deps = {}) {
+    const token = process.env.DISCORD_BOT_TOKEN;
+    if (!token)
+        return null;
+    try {
+        const res = await discordFetch("POST /users/@me/channels", "https://discord.com/api/v10/users/@me/channels", {
+            method: "POST",
+            headers: { ...botAuthHeaders(token), "content-type": "application/json" },
+            body: JSON.stringify({ recipient_id: userId }),
+        }, deps);
+        if (!res.ok)
+            return null;
+        const body = (await res.json());
+        return typeof body.id === "string" ? body.id : null;
+    }
+    catch (err) {
+        // 🔴 THIS CATCH USED TO BE BARE, AND THAT IS WHY THE NAME MATTERS MOST HERE. Every other failure
+        // arm on this path already logs; a swallowed `RateLimitExhaustedError` here would be the ONE
+        // Discord write whose rate-limit give-up left no trace anywhere. The notice this DM carries is
+        // never said elsewhere (see `postExternalSenderNotice`), so the drop is otherwise invisible.
+        // `userId` is a Discord snowflake, not personal data, and the error carries no token.
+        if (err instanceof RateLimitExhaustedError) {
+            log(`Discord open-DM rate limited for user ${userId}: gave up after ${err.attempts} attempts (waited ${err.waitedMs} ms)`);
+        }
+        return null;
+    }
+}
+/**
+ * Tell an EXCLUDED sender, PRIVATELY, that the agent will not act on their message (OPE-507
+ * behaviour 1). Best-effort and silent on failure.
+ *
+ * 🔴 THIS NOTICE NEVER GOES TO THE GUILD CHANNEL, AND THAT RULING STANDS. Its text names the
+ * organisation, so posting it where the room can read it would announce that this person is
+ * classified as an outsider — a disclosure about a member of the room, not a notice to the sender.
+ * If the DM cannot be opened (the sender blocks bot DMs, the token is absent, Discord refuses),
+ * THIS notice is not said anywhere.
+ *
+ * 🔴 THE `false` RETURN IS LOAD-BEARING (OPE-885). An EXPLICITLY ADDRESSED wake this notice could
+ * not reach falls back to the channel's fixed `EXTERNAL_MENTION_ACK` — a different string precisely
+ * because it discloses nothing. So the caller needs the truth about delivery, and every failure arm
+ * answers `false`.
+ */
+async function postExternalSenderNotice(userId) {
+    const dmId = await openDiscordDm(userId);
+    if (!dmId)
+        return false;
+    return (await discordCreateMessage(dmId, EXTERNAL_SENDER_NOTICE)) !== null;
+}
+/**
+ * Post the suppressed-wake half of the silent-room announcement pair (OPE-504) — AT MOST ONCE PER
+ * ROOM, EVER.
+ *
+ * 🔴 DISCORD POSTS THIS HALF AND NOT THE JOIN HALF, AND THAT IS SETTLED (OPE-525). The relay forwards
+ * MESSAGES, not guild/channel join events, so there is no trigger the join notice could hang on. A
+ * Discord room is therefore announced ONCE — at the first wake the classification silences — rather
+ * than twice. The ruling the pair encodes is "at most twice, never periodic"; one is inside it.
+ *
+ * 🔴 THE CLAIM IS DURABLE, NOT PER-PROCESS. `claimNotice` writes a permanent row; an in-memory
+ * marker would re-announce on every cold start, and a cold start happens per serverless invocation.
+ * That would be the periodic announcement the design explicitly rejects, wearing a "once" label.
+ *
+ * FAIL-CLOSED on the claim, which is the inverse of `postOnce`'s posture and deliberate: if the store
+ * cannot answer, the agent stays QUIET. A duplicate here is not a lost message, it is the exact
+ * repetition this pair exists to avoid, so the safe direction is silence.
+ */
+async function announceSilentRoom(surfaceKey, channelId) {
+    const org = deploymentOrg();
+    if (!org)
+        return false;
+    try {
+        const won = await getOperationalStore().claimNotice(org, silentNoticeKey(surfaceKey, "suppressed-wake"), new Date().toISOString());
+        if (!won)
+            return false; // already said, once, forever
+    }
+    catch {
+        return false; // cannot prove it is unsaid ⇒ stay quiet
+    }
+    await discordCreateMessage(channelId, silentRoomNotice("suppressed-wake"));
+    return true;
+}
+async function postDiscordReply(channelId, text) {
+    for (const chunk of splitForDiscord(text)) {
+        if (!chunk.trim())
+            continue; // belt-and-braces: never post an invisible empty message
+        await discordCreateMessage(channelId, chunk);
+    }
+}
+/**
+ * Fire Discord's NATIVE typing indicator: `POST /channels/{id}/typing` → "<bot> is typing…"
+ * shown to everyone in the channel for ~10s. This is the working signal while a turn runs —
+ * chosen over a posted "holding" message because it's the idiom Discord users already read
+ * as "working", it involves NO message (so no "(edited)" tag on the final reply and no
+ * delete-and-repost dance), and it EXPIRES BY ITSELF — nothing to track across turns, which
+ * is what makes it immune to the resumed-session staleness class (see the state comment).
+ * Re-triggered from turn/tool event handlers to cover long turns. Purely an affordance:
+ * best-effort, every failure swallowed, missing token no-ops, NEVER throws.
+ */
+// Throttle for the HIGH-FREQUENCY typing triggers (the streamed *.appended events, which can
+// fire many times a second): re-POST only when the previous trigger is old enough that the
+// ~10s indicator is nearing expiry. In-process state — if an event handler lands in a fresh
+// invocation the map is cold and we simply POST again (an extra cheap call, never a miss).
+const lastTypingAt = new Map();
+const TYPING_REFRESH_MS = 7_000;
+/** 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 function clearTypingThrottleForTest() {
+    lastTypingAt.clear();
+}
+/** 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 function typingRefreshDue(channelId, nowMs = Date.now(), state = lastTypingAt) {
+    const last = state.get(channelId);
+    if (last !== undefined && nowMs - last < TYPING_REFRESH_MS)
+        return false;
+    state.set(channelId, nowMs);
+    return true;
+}
+// Judged-wake typing gate (live 2026-07-07): engaged and name-drop wakes run a JUDGED turn
+// that may end in the NO_REPLY sentinel — nothing gets posted. Firing typing at dispatch for
+// those turns produced "typing… for ~10s, then nothing" (Tommy's "test" in an engaged
+// channel), indistinguishable from a crash. Discord typing can only be triggered, never
+// cancelled — so the only lever is to NOT start it until the model has proven it's replying:
+// the streamed message text deviating from the sentinel. Addressed wakes (mention/DM) always
+// answer → they keep dispatch-time typing. In-process, keyed by reply channel id, fail-OPEN:
+// a cold map (event handler in a fresh invocation) just behaves like today — typing during
+// judgment — never a lost reply or a stuck indicator (the indicator expires by itself).
+const closedTypingGates = new Set();
+/** Close the gate for a judged wake: hold all typing until the reply is proven. */
+export function closeTypingGate(channelId, gates = closedTypingGates) {
+    gates.add(channelId);
+}
+/** Open (clear) the gate — addressed dispatch, reply proven, or turn over. */
+export function openTypingGate(channelId, gates = closedTypingGates) {
+    gates.delete(channelId);
+}
+export function typingGateOpen(channelId, gates = closedTypingGates) {
+    return !gates.has(channelId);
+}
+/**
+ * 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 function typingGateFeed(channelId, messageSoFar, gates = closedTypingGates) {
+    if (!gates.has(channelId))
+        return true;
+    const t = messageSoFar.trimStart();
+    if (t.startsWith(NO_REPLY_SENTINEL) || NO_REPLY_SENTINEL.startsWith(t))
+        return false;
+    gates.delete(channelId);
+    return true;
+}
+export async function triggerDiscordTyping(channelId, deps = {}) {
+    const token = process.env.DISCORD_BOT_TOKEN;
+    if (!token || !channelId)
+        return;
+    try {
+        const res = await discordFetch("POST /channels/{id}/typing", `https://discord.com/api/v10/channels/${channelId}/typing`, { method: "POST", headers: { authorization: `Bot ${token}` } }, { ...deps, retry: { ...deps.retry, ...AFFORDANCE_RETRY } });
+        if (!res.ok) {
+            log(`Discord typing trigger failed (${res.status}) for channel ${channelId}`);
+        }
+    }
+    catch (err) {
+        // The typing indicator is an affordance on the turn's own latency path — it gives up fast (see
+        // AFFORDANCE_RETRY) and the give-up is logged, never thrown.
+        if (err instanceof RateLimitExhaustedError) {
+            log(`Discord typing trigger rate limited for channel ${channelId}: gave up after ${err.attempts} attempts (waited ${err.waitedMs} ms)`);
+            return;
+        }
+        log(`Discord typing trigger error for channel ${channelId}: ${err?.message ?? String(err)}`);
+    }
+}
+// The status emoji. encodeURIComponent yields exactly Discord's expected percent-encoding
+// (👀 → %F0%9F%91%80). There is deliberately NO ✅: the convention (established on Slack —
+// see status/status.ts) is 👀 = seen/working, REMOVAL = done, and ✅ stays reserved for
+// humans to mark things themselves. The bot never plants a tick.
+const EYES_EMOJI = "👀";
+/**
+ * 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 async function setDiscordReaction(channelId, messageId, emoji, action, deps = {}) {
+    const token = process.env.DISCORD_BOT_TOKEN;
+    if (!token)
+        return; // no token → silently skip the affordance (degrades to no reaction)
+    if (!channelId || !messageId)
+        return;
+    const encoded = encodeURIComponent(emoji);
+    try {
+        const res = await discordFetch(
+        // The route SHAPE, id-free and emoji-free, so the named failure carries no ids — the same
+        // operation string discord-post.ts uses for its own reaction write.
+        `${action} /channels/{id}/messages/{id}/reactions/{emoji}/@me`, `https://discord.com/api/v10/channels/${channelId}/messages/${messageId}/reactions/${encoded}/@me`, { method: action, headers: { authorization: `Bot ${token}` } }, { ...deps, retry: { ...deps.retry, ...AFFORDANCE_RETRY } });
+        // A DELETE of a reaction that was never added 404s — harmless, so we don't treat it as notable.
+        if (!res.ok && !(action === "DELETE" && res.status === 404)) {
+            log(`Discord reaction ${action} failed (${res.status}) for message ${messageId} in channel ${channelId}`);
+        }
+    }
+    catch (err) {
+        // The 👀 reaction is an affordance on the turn's own latency path — it gives up fast (see
+        // AFFORDANCE_RETRY) and the give-up is logged, never thrown.
+        if (err instanceof RateLimitExhaustedError) {
+            log(`Discord reaction ${action} rate limited for channel ${channelId}: gave up after ${err.attempts} attempts (waited ${err.waitedMs} ms)`);
+            return;
+        }
+        log(`Discord reaction ${action} error for channel ${channelId}: ${err?.message ?? String(err)}`);
+    }
+}
+// --- auto-thread (one task = one thread) ------------------------------------
+// The signature Slack pattern is "mention starts a thread; the work happens in it." Discord
+// threads are first-class channel objects (a thread IS its own channel id), so we map the
+// same model: a mention in a base guild text/announcement channel spins up a thread and the
+// WHOLE conversation re-keys onto it (its own surface silo + durable session + engagement).
+// Everything below is pure/deterministic (unit-tested) except createDiscordThread's REST call.
+/** 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 function stripLeadingMention(content) {
+    return content.replace(/^\s*<@!?[^>]+>\s*/, "");
+}
+/**
+ * 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 function shouldAutoThread(channelType, enabled) {
+    if (!enabled)
+        return false;
+    return channelType === "0" || channelType === "5";
+}
+/**
+ * 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 function autoThreadEnabled(env) {
+    return env === undefined ? getSettings().discord.autoThread : env !== "false" && env !== "0";
+}
+/**
+ * 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 function statusUxEnabled(env) {
+    return env === undefined ? getSettings().discord.statusUx : env !== "false" && env !== "0";
+}
+/**
+ * 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 function deriveThreadName(content, botName) {
+    const fallback = `Conversation with ${botName ?? "the agent"}`;
+    // Strip ONE leading mention token, then collapse all runs of whitespace to single spaces.
+    const cleaned = stripLeadingMention(content).replace(/\s+/g, " ").trim();
+    if (cleaned.length === 0)
+        return fallback; // empty / mention-only → fallback
+    if (cleaned.length <= 100)
+        return cleaned;
+    // Over the cap: hard-slice to 100, then prefer a word boundary if one is close to the end
+    // (≥80) so we don't cut mid-word; otherwise keep the hard slice.
+    const hard = cleaned.slice(0, 100);
+    const lastSpace = hard.lastIndexOf(" ");
+    return (lastSpace >= 80 ? hard.slice(0, lastSpace) : hard).trim();
+}
+/**
+ * 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 async function createDiscordThread(channelId, messageId, name, deps = {}) {
+    const token = process.env.DISCORD_BOT_TOKEN;
+    if (!token) {
+        log(`DISCORD_BOT_TOKEN is not set — cannot create thread on channel ${channelId}`);
+        return null;
+    }
+    if (!channelId || !messageId) {
+        log("createDiscordThread: missing channel/message id — cannot create thread");
+        return null;
+    }
+    try {
+        const res = await discordFetch("POST /channels/{id}/messages/{id}/threads", `https://discord.com/api/v10/channels/${channelId}/messages/${messageId}/threads`, {
+            method: "POST",
+            headers: {
+                // `Bot <token>` is Discord's bot-auth scheme. The token is a SECRET — never log it.
+                authorization: `Bot ${token}`,
+                "content-type": "application/json",
+            },
+            body: JSON.stringify({ name, auto_archive_duration: 1440 }),
+        }, deps);
+        if (!res.ok) {
+            // 403 = missing Create Public Threads / Send Messages in Threads; 429 = rate limit; etc.
+            log(`Discord create-thread failed (${res.status}) for channel ${channelId} — falling back to inline`);
+            return null;
+        }
+        const body = (await res.json());
+        const id = isObject(body) ? str(body["id"]) : undefined;
+        if (!id) {
+            log(`Discord create-thread returned no thread id for channel ${channelId} — falling back to inline`);
+            return null;
+        }
+        return id;
+    }
+    catch (err) {
+        // Threading is fail-OPEN: a null degrades the turn to an inline reply. An exhausted 429 is still
+        // named, so the degradation is never a silent drop.
+        if (err instanceof RateLimitExhaustedError) {
+            log(`Discord create-thread rate limited for channel ${channelId}: gave up after ${err.attempts} attempts (waited ${err.waitedMs} ms) — falling back to inline`);
+            return null;
+        }
+        log(`Discord create-thread error for channel ${channelId}: ${err?.message ?? String(err)}`);
+        return 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 function dispatchSurfaceFor(msg, baseAuth, threadId) {
+    if (threadId) {
+        // Re-key onto the thread. channelType "11" = PUBLIC_THREAD, so the identity seam derives a
+        // guild `channel` surface with its own surfaceKey (discord/<guild>/<threadId>).
+        // parentChannelId is FREE here — the thread hangs off the mention's own base channel
+        // (msg.channelId), no REST needed — and it keeps the session's DOMAIN/SPEND grain on
+        // that channel (binding.domainSurface → partition.domainKey) while the surfaceKey /
+        // session / engagement stay on the thread (item 22).
+        // NO `messageId` here, deliberately (OPE-671): this REKEYS `channelId` onto the newly-created
+        // thread, but `msg.id` still lives in the BASE channel (the mention that spawned the thread) —
+        // pairing them would address a reaction at a message the thread channel doesn't own. The 👀
+        // swap-tracked reaction has the identical constraint (see `original: {channelId: msg.channelId,
+        // messageId: msg.id}` below, which stays on the BASE channel for the same reason). A turn
+        // re-keyed onto a fresh auto-thread therefore gets no ✋ — a narrower, PRE-EXISTING gap (today
+        // NO Discord turn gets one), not a regression.
+        const auth = buildDiscordAuth({
+            userId: msg.author.id,
+            guildId: msg.guildId,
+            channelId: threadId,
+            channelType: "11",
+            parentChannelId: msg.channelId,
+        });
+        return { auth, continuationToken: `discord:${threadId}`, state: { channelId: threadId }, engagementKey: threadId };
+    }
+    // No thread → base channel, identical to the pre-auto-thread behaviour.
+    return {
+        auth: baseAuth,
+        continuationToken: `discord:${msg.channelId}`,
+        state: { channelId: msg.channelId },
+        engagementKey: msg.channelId,
+    };
+}
+/**
+ * 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 function planCompletion(input) {
+    const { action, reactionActive, cardPostedThisTurn } = input;
+    if (action.kind === "buffer-tool-status") {
+        // Not the final message — an interim tool-call turn. Touch nothing; the real reply comes later.
+        return { reaction: "none", delivery: { kind: "none" } };
+    }
+    if (action.kind === "post") {
+        return {
+            reaction: reactionActive ? "clear" : "none",
+            delivery: cardPostedThisTurn ? { kind: "none" } : { kind: "post", chunks: splitForDiscord(action.text) },
+        };
+    }
+    // action.kind === "silent" (empty final message OR the NO_REPLY sentinel — judged not warranted).
+    return {
+        reaction: reactionActive ? "clear" : "none",
+        delivery: { kind: "none" },
+    };
+}
+/**
+ * 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 function buildGatewayState(input) {
+    return {
+        channelId: input.replyChannelId,
+        guildId: input.guildId,
+        originalChannelId: input.original?.channelId,
+        originalMessageId: input.original?.messageId,
+    };
+}
+/**
+ * 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 function takeTurnStatus(state) {
+    const original = state.originalChannelId && state.originalMessageId
+        ? { channelId: state.originalChannelId, messageId: state.originalMessageId }
+        : undefined;
+    state.originalChannelId = undefined;
+    state.originalMessageId = undefined;
+    return { original };
+}
+// UNIFIED grain for a Discord surface's DOMAIN-grain key (a thread asks its parent channel's
+// domain — domainKeyOf, the same grain the nameDropWake and spend gates use). FAIL-SOFT to the
+// per-container grain (the byte-identical path): a config-load error must degrade to today's
+// behaviour, never take the channel down or mis-key a session. Mirrors github.ts githubGrainFor.
+function discordGrainFor(domainKey) {
+    try {
+        return supervisorGrainFor(domainKey, getConfig().loadDomains());
+    }
+    catch {
+        return { unified: false, registryKey: domainKey };
+    }
+}
+// The ambient-calibration dial for a diverted watch wake (memory/domain.ts engagementTierFor,
+// resolved at the DOMAIN grain). Fail-soft: neutral. Mirrors github.ts githubEngagementTier.
+function discordEngagementTier(domainKey) {
+    try {
+        return engagementTierFor(domainKey, getConfig().loadDomains());
+    }
+    catch {
+        return undefined;
+    }
+}
+/**
+ * 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 function discordSingleWindowPrivacyOk(input, deps = {}) {
+    if (!input.guildId)
+        return false; // DM/group-DM: NEVER, unconditionally (no tenant boundary)
+    const vouched = deps.vouched ?? isVouchedInternal;
+    const trustEnv = "trustEnv" in deps ? deps.trustEnv : process.env.OE_TRUST;
+    if (trustEnv === "internal")
+        return true; // the blanket internal-only-deploy switch
+    if (vouched(input.workspaceKey, input.surfaceKey))
+        return true;
+    // A thread inherits its parent channel's vouch (the domain-grain key — same widening the
+    // nameDropWake/spend gates apply; a vouch names channels, threads come and go under them).
+    return input.domainKey !== undefined && input.domainKey !== input.surfaceKey && vouched(input.workspaceKey, input.domainKey);
+}
+/**
+ * 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 function discordSingleWindowMentionPolicy(singleWindow, isMention, privacyOk) {
+    return singleWindowMentionPolicy(singleWindow, isMention, privacyOk);
+}
+/**
+ * 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 function buildDiscordUnifiedWake(input) {
+    const direct = input.addressing === "direct-mention";
+    return {
+        platform: "discord",
+        // An addressed @mention is reason "mention" (honest, rides the envelope); engaged/name-drop
+        // chatter is "channel-activity". Every addressing here keeps the full envelope, so the
+        // wake-id survives for the reply tool (the ONLY reply route on the unified channel).
+        reason: direct ? "mention" : "channel-activity",
+        addressing: input.addressing,
+        // The ambient calibration dial applies only to the watch wake (an addressed mention is owed
+        // an answer; a name-drop has its own higher-bar preamble) — mirrors the GitHub builder.
+        engagementTier: input.addressing === "channel-watch" ? input.engagementTier : undefined,
+        // The ENROLMENT fact, through the ONE shared helper every enveloped surface calls
+        // (channels/engaged-wake.ts, OPE-1740). `nameDrop` below still wins in renderWake, so a
+        // name-drop wake's own mechanic is unchanged.
+        followUp: engagedFollowUpContract({ addressing: input.addressing, threadEngaged: input.threadEngaged }),
+        wakeId: input.wakeId,
+        locus: {
+            // Container = the channel (a thread's PARENT when known — the grain domains/spend use).
+            channel: { id: input.parentChannelId ?? input.channelId },
+            // Conversation = the thread (its own channel id) when the trigger was in one.
+            ...(input.isThread ? { thread: { ts: input.channelId } } : {}),
+        },
+        // The `botName` guard is a FIDELITY guard, not a data dependency (OPE-770 removed the field the
+        // block used to carry): a relay that reported no bot name never matched one, so it gets no
+        // `follow-up` attribute — exactly the bytes it rendered before.
+        ...(input.addressing === "name-drop" && input.botName
+            ? {
+                nameDrop: {
+                    // The honest follow-up contract, mirroring the native path's engagement mechanics
+                    // (dispatchTurn): a THREAD name-drop engaged the thread at dispatch; a base-channel
+                    // name-drop deliberately does not follow (the engaged-channel surprise).
+                    followUp: input.isThread ? "thread-engaged" : "channel-not-following",
+                },
+            }
+            : {}),
+        backscroll: input.tail && input.tail.length > 0 ? input.tail : undefined,
+        // The hydration's own slot (OPE-1749): `renderWake` de-duplicates it against `backscroll` above
+        // and caps below that, so this road renders through the same core ordering as every other surface.
+        ...(input.contextLines && input.contextLines.length > 0
+            ? { contextLines: input.contextLines, ...(input.contextSource === undefined ? {} : { contextSource: input.contextSource }) }
+            : {}),
+        ...(input.catchUpUnavailable !== undefined ? { catchUpUnavailable: input.catchUpUnavailable } : {}),
+        trigger: mkMessageTrigger({
+            from: "human", // bot authors were dropped at ingress (authForRelayMessage)
+            author: input.trigger.author,
+            authorId: input.trigger.authorId,
+            id: input.trigger.id,
+            sentAt: input.trigger.sentAt,
+            // The caller's stated per-person tier — no default (OPE-596).
+            trust: input.trigger.trust,
+            // The @mention response-obligation flag (rendered `mention="true"`).
+            mention: direct ? true : undefined,
+            body: input.trigger.text,
+        }),
+    };
+}
+/**
+ * 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 function discordNativeWake(input) {
+    const direct = input.addressing === "direct";
+    return {
+        platform: "discord",
+        // Direct is DM or @mention (reason is cosmetic — the direct render carries no envelope); a
+        // judged wake's reason honestly reflects thread vs base-channel activity.
+        reason: direct ? (input.isDm ? "dm" : "mention") : input.isThread ? "thread-activity" : "channel-activity",
+        addressing: input.addressing,
+        // The ENROLMENT fact, through the ONE shared helper (channels/engaged-wake.ts, OPE-1740), off the
+        // engagement row the dispatch already read — never off the `thread-follow` tier, which a warm
+        // name-drop latch also reaches. `direct` renders no envelope and `nameDrop` wins in renderWake,
+        // so both are unchanged.
+        followUp: engagedFollowUpContract({ addressing: input.addressing, threadEngaged: input.threadEngaged }),
+        locus: {
+            // Container = the channel (a thread's PARENT when known — the grain domains/spend use).
+            channel: { id: input.parentChannelId ?? input.channelId },
+            // Conversation = the thread (its own channel id) when the trigger was in one.
+            ...(input.isThread ? { thread: { ts: input.channelId } } : {}),
+        },
+        // The `botName` guard is a FIDELITY guard, not a data dependency (OPE-770 removed the field the
+        // block used to carry): a relay that reported no bot name never matched one, so it gets no
+        // `follow-up` attribute — exactly the bytes it rendered before.
+        ...(input.addressing === "name-drop" && input.botName
+            ? {
+                nameDrop: {
+                    // The honest follow-up contract, matching the native engagement mechanics dispatchTurn
+                    // applied: a THREAD name-drop engaged the thread at dispatch (follow-ups flow); a
+                    // base-channel name-drop deliberately does NOT follow (the engaged-channel surprise).
+                    followUp: input.isThread ? "thread-engaged" : "channel-not-following",
+                },
+            }
+            : {}),
+        ...(input.contextLines ? { contextLines: input.contextLines, contextSource: input.contextSource } : {}),
+        trigger: mkMessageTrigger({
+            from: "human", // bot authors were dropped at ingress (authForRelayMessage / the wake gate)
+            author: input.trigger.author,
+            authorId: input.trigger.authorId,
+            id: input.trigger.id,
+            sentAt: input.trigger.sentAt,
+            // The caller's stated per-person tier — no default (OPE-596).
+            trust: input.trigger.trust,
+            // The @mention response-obligation flag renders only on the enveloped judged paths; a raw
+            // `direct` body carries no envelope so the flag never surfaces (left unset there).
+            mention: undefined,
+            body: input.trigger.text,
+        }),
+    };
+}
+/**
+ * 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 function buildDiscordDmWake(input) {
+    return {
+        platform: "discord",
+        reason: "dm",
+        addressing: "direct-mention",
+        wakeId: input.wakeId,
+        // A DM's container IS the DM channel: no parent, no thread, and — unlike the cross-surface
+        // builder — no `platform` address stamp, because this window sees exactly one surface.
+        locus: { channel: { id: input.channelId } },
+        backscroll: input.tail && input.tail.length > 0 ? input.tail : undefined,
+        trigger: mkMessageTrigger({
+            from: "human", // bot authors are dropped at ingress (authForRelayMessage)
+            author: input.trigger.author,
+            authorId: input.trigger.authorId,
+            id: input.trigger.id,
+            sentAt: input.trigger.sentAt,
+            // The caller's stated per-person tier — no default (OPE-596).
+            trust: input.trigger.trust,
+            // The response-obligation flag, exactly as the Slack DM wake carries it.
+            mention: true,
+            body: input.trigger.text,
+        }),
+    };
+}
+/**
+ * THE DM WINDOW DIVERT (OPE-356) — a Discord DM lands in its OWN first-class standing window
+ * (channels/dm-seat.ts), the Discord parity of slack-front.ts's `scheduleDmWake`.
+ *
+ * WHAT IT FIXES. Until now a Discord DM ran on eve's per-channel continuation token: a session with
+ * no window row, and therefore NO DISPATCHABLE ADDRESS. A DM that delegated could not be told the
+ * answer had arrived — `resolveCallerSeat` took the OPE-306 ANCHOR arm, both completion-wake sites
+ * skipped the wake fail-closed, and the workaround was the worker posting its own report into the
+ * DM. A window token is an address, so the DM seat now gets the whole standing-seat apparatus for
+ * free: woken, redriven, rotated (on the DM thresholds — `OE_DM_SEAT_ROTATE_*`, never the
+ * supervisor's), spend-counted and audited through the seams every other seat already used. The
+ * worker's direct report-back drops with it, deliberately: it compensated for a seat that could not
+ * be woken, and keeping it would put two voices in one DM per delegated turn.
+ *
+ * 🔴 IT BYPASSES THE ENGAGEMENT GATE AND THE NAME-DROP JUDGE — see {@link buildDiscordDmWake}. The
+ * SPEND gate is NOT bypassed: `dispatchTurn` has already run `ingressSpendGate` (door `mention`)
+ * before reaching here, and `divertToUnifiedWindow` runs its own attended-arrival gate on top.
+ *
+ * THE ENVELOPE CARRIES NO BACKSCROLL, on purpose and unchanged from the native path (`!isDm && …`
+ * in dispatchTurn): the 1:1 history IS the conversation and the seat's own long-lived session
+ * already holds it. The one thing a FRESH generation carries is the recorded tail of the
+ * generation it replaced (OPE-794).
+ *
+ * FAIL-CLOSED: a seat-resolution or dispatch failure PROPAGATES to the route's `waitUntil` catch.
+ * There is deliberately no fall-back to the native send — that would answer the human from a second
+ * session with no window row behind it, which is the very topology this replaces.
+ */
+async function divertDiscordDmToWindow(input) {
+    const { msg } = input;
+    const org = deploymentOrg();
+    const atIso = new Date().toISOString();
+    const surfaceKey = input.partition.surfaceKey;
+    // The seat: create / rotate / resume the DM's own standing window row, keyed on the SURFACE KEY
+    // (what the token and the row are both keyed on, and what both admission gates match byte-exactly
+    // to fence a DM window to its own DM). NO `legacyChannelId`: the OPE-90 `oe-dm-seat::<id>` rows
+    // only ever existed on Slack, so there is nothing for the adopt-from-legacy probe to find here —
+    const seat = await getOrCreateDmSeat(org, { surfaceKey }, atIso);
+    // PER-WAKE TRUST off the SAME auth the session binds with; `principalFallback` because a DM
+    // partner is the seat's principal (the native DM path's `direct` default, preserved).
+    const trust = resolveWakeTrustFromContext(ctxFromAuth(input.auth), { id: msg.author.id, isBot: msg.author.bot }, { principalFallback: true });
+    const wakeId = mintWakeId();
+    // The frozen reply target: the DM channel itself, host-extracted from the verified relay payload.
+    // `dm: true` is the POSITIVE discriminant OPE-315 added — never a guildless guild-shape — so this
+    // is precisely the origin the registered Discord codec's DM branch admits, and there is no path
+    // from it to guild authority (no guildId, no autoThreadName: the codec forbids both, and the
+    // reply leg's auto-thread branch writes guild-keyed engagement rows).
+    //
+    // 🔴 NO `messageId`, DELIBERATELY. It is codec-legal (cosmetic `message_reference` anchoring with
+    // no guild-shaped consequence), but the native DM path replied with a PLAIN post, and anchoring
+    // every answer to the question it answers is a visible change to a 1:1 conversation that this
+    // ticket is not the place to make. Same reasoning as the Slack DM divert setting no
+    // `replyAnchorTs`: behaviour preserved across the re-seat, not quietly improved.
+    const origin = { platform: "discord", channelId: msg.channelId, dm: true };
+    const rendered = renderWake(buildDiscordDmWake({
+        channelId: msg.channelId,
+        wakeId,
+        ...(seat.freshGeneration && seat.tail.length > 0 ? { tail: seat.tail } : {}),
+        trigger: {
+            id: msg.id || "unknown",
+            author: msg.author.username ?? msg.author.id,
+            authorId: msg.author.id,
+            sentAt: atIso,
+            text: msg.content,
+            trust,
+        },
+    }));
+    try {
+        await divertToUnifiedWindow(input.receive, {
+            message: rendered.message,
+            ...(rendered.context && rendered.context.length > 0 ? { context: rendered.context } : {}),
+            token: seat.token,
+            // `vendorTs` (OPE-1716): the message snowflake's embedded creation time — Discord's own
+            // clock to the millisecond, and the first latency anchor. Absent id ⇒ no reading.
+            window: { wakeId, origin, addressing: "direct-mention", ...spreadVendorTs(discordVendorEventTime(msg.id)) },
+            // Byte-exactly the surface named inside the token — the self-consistency both admission gates
+            // match on, and the whole privacy fence (a DM window is deliverable to ITS OWN DM and nowhere
+            // else). NOT domainKeyOf: a DM has no parent container to widen to.
+            surfaceKey,
+            // OPE-466 CARRIAGE: one ingested message, so the join runs over the trigger's own tier.
+            // OPE-489: the author leg now reads the POSITIVE refutation, and a DM has no room leg at all
+            // (`dm: true` — on a DM the trust plane asks about the PARTNER, not about the room). Discord
+            // cannot refute a DM partner: `member.pending` is a GUILD screening fact and a DM has no guild.
+            auth: stampNonMemberChatAuth(input.auth, [{ trust }], { dm: true }),
+        });
+    }
+    catch (err) {
+        // OPE-970: this DM divert has NO re-delivery leg (unlike slack-front.ts's DM route) and, until
+        // now, NO audit row either — the outer `dispatchTurn(...).catch` at the route only logged the
+        // error to the console. `auditSupervisorFailure` (the same generic writer github.ts/linear.ts
+        // already use for their own lifecycle failures) gives it the SAME `surface.wake_failed` row
+        // Slack/Teams already write for their own wake failures, then rethrows unchanged.
+        // `surface: surfaceKey` (the compound `discord/user/channel`), matching this file's own
+        // dominant convention for a wake-shaped audit row (line ~2112/2259/2330 below), not the raw
+        // `partition.surface` channel id.
+        await auditSupervisorFailure({ org, platform: input.partition.platform, workspace: input.partition.workspace, surface: surfaceKey }, "surface.wake_failed", {
+            message: String(err instanceof Error ? err.message : err).slice(0, 500),
+            wakeId,
+            addressing: "direct-mention",
+        });
+        throw err;
+    }
+    // Record the wake on the seat's own row (turnCount/lastWakeAt feed the rotation thresholds),
+    // best-effort — a touch failure must never affect the reply. Through the seat's OWN seam, so the
+    // row it touches cannot drift from the row the mint wrote.
+    await touchDmSeat(org, surfaceKey, atIso).catch(() => undefined);
+    // OPE-794 — file this DM wake on the live seat generation's tail ring, AFTER it landed, and only
+    // the TRIGGER. The registry key is the DM window key, the same row the seat itself lives in.
+    await recordWakeTail(org, dmWindowRegistryKey(surfaceKey), seat.token, {
+        kind: "wake",
+        at: atIso,
+        from: "human", // bot authors are dropped at ingress (authForRelayMessage)
+        trust,
+        // THE AUTHOR GRAIN (OPE-1747) — the same two facts this surface's taint join reads: Discord has
+        // no membership verdict of its own beyond `member.pending`, so the OPERATOR's register query
+        // (`authorFacts`) is the leg that carries the refutation, and it must ride the row.
+        ...tailAuthorGrain({ trust, refuted: msg.memberPending === true, ...authorFacts(msg) }),
+        author: msg.author.username ?? msg.author.id,
+        authorId: msg.author.id,
+        id: msg.id || "unknown",
+        platform: "discord",
+        container: surfaceKey,
+        text: msg.content,
+    });
+}
+/**
+ * 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 function admitDiscordSeatLines(lines, grain, domainKey, isThread) {
+    if (!lines || lines.length === 0)
+        return undefined;
+    // The unseated arm hands the SAME array back, never a copy: this road was byte-identical before
+    // OPE-1800 and must stay so.
+    if (!grainUsesUnifiedWindow(grain))
+        return lines;
+    const admitted = admitContextLines(lines, seatAdmissionFor(domainKey), isThread ? "thread" : "channel");
+    return admitted.length > 0 ? admitted : 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 function discordSeatContextForWindow(lines, source, grain, domainKey, isThread) {
+    const admitted = admitDiscordSeatLines(lines, grain, domainKey, isThread);
+    if (!admitted)
+        return { lines: [], ingestion: [] };
+    return { lines: admitted, ...(source === undefined ? {} : { source }), ingestion: admitted.map(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 async function divertDiscordWakeToUnifiedWindow(input) {
+    const { msg, grain } = input;
+    const org = deploymentOrg();
+    const store = getOperationalStore();
+    const atIso = new Date().toISOString();
+    // ENGAGE an addressed THREAD wake at dispatch — the native path's exact affordance (its
+    // dispatch marks the arriving surface engaged) that the divert otherwise skips, so a mention
+    // inside an existing thread (incl. a post-stop revive) keeps its non-mention follow-ups
+    // flowing. Base channels deliberately excluded: one mention must not turn a whole channel
+    // into a followed surface — a base-channel mention's follow surface is the auto-thread the
+    // reply leg opens (engaged there, unified-reply.ts). Best-effort, never blocks the wake.
+    if (input.addressing === "direct-mention" && isThreadChannelType(msg.channelType)) {
+        await markThreadEngaged(input.partition, msg.channelId, atIso, { participating: true });
+    }
+    const domainName = grain.domainName ?? "unknown"; // caller-guaranteed present; belt-and-braces
+    const tokenFor = (gen) => mintRotationToken(grain, gen, () => unifiedSupervisorToken(domainName, gen));
+    // OPE-599: claim the runtime-change rotation BEFORE the row read, and unconditionally (the mint
+    // arm must consume it too). Why, and why here: channels/runtime-rotation.ts.
+    const runtimeChanged = await claimRuntimeRotation({ org, registryKey: grain.registryKey, surfaceKey: input.partition.surfaceKey, domainName: grain.domainName, atIso });
+    // Get-or-create the domain session (H7c self-heal semantics mirrored from github.ts: a resume
+    // whose first wake never delivered is still "fresh", so the next wake re-carries context).
+    const existing = await store.getChannelSession(org, grain.registryKey);
+    let session;
+    if (!existing) {
+        const row = await store.rotateChannelSession(org, grain.registryKey, tokenFor(1), atIso);
+        // OPE-1821: stamp the pair onto the row this build just minted. Without it the seat's next
+        // wake reads NULL, takes the ADOPTED arm and never rotates for the deploy it crossed.
+        await stampMintedRuntime({ org, registryKey: grain.registryKey, surfaceKey: input.partition.surfaceKey, domainName: grain.domainName, atIso });
+        session = { token: row.token, generation: row.generation, fresh: true, tail: [] };
+    }
+    else if (shouldRotate(existing, atIso, { runtimeChanged })) {
+        // OPE-794: read the OUTGOING generation's recorded tail BEFORE minting its successor.
+        const tail = await carryTailForward(org, grain.registryKey, existing.token);
+        const row = await store.rotateChannelSession(org, grain.registryKey, tokenFor(existing.generation + 1), atIso);
+        session = { token: row.token, generation: row.generation, fresh: true, tail };
+    }
+    else {
+        // The tail is empty on a resume: it was carried and cleared at the rotation that minted this row.
+        session = { token: existing.token, generation: existing.generation, fresh: existing.firstWakeAt == null, tail: [] };
+    }
+    // PER-WAKE TRUST (identity/wake-trust.ts — audit-wedge F3), off the SAME auth capture the
+    // session binds with. TRIGGER: the message author IS the bound principal.
+    const trust = resolveWakeTrustFromContext(ctxFromAuth(input.auth), { id: msg.author.id, isBot: msg.author.bot }, { principalFallback: true });
+    const doWake = async (token, generation, tail, catchUpUnavailable) => {
+        const wakeId = mintWakeId();
+        // The frozen reply target: the EXACT conversation the message arrived in (a thread is its
+        // own channel id, so a threaded trigger's reply threads for free). Host-extracted from the
+        // verified relay payload, never model-authored. guildId is caller-guaranteed by the privacy
+        // floor (DMs never divert) — and re-validated fail-closed by isUnifiedWakeOrigin on both
+        // the register and the resolve side.
+        const origin = {
+            platform: "discord",
+            channelId: msg.channelId,
+            guildId: msg.guildId ?? "",
+            ...(msg.id ? { messageId: msg.id } : {}),
+            // ADDRESSED mention in a base channel ⇒ carry the auto-thread name so the reply leg
+            // opens a thread off the mention and answers there (the native path's auto-thread UX;
+            // the divert skips that block, so without this the answer lands bare in the channel).
+            ...(msg.id && input.addressing === "direct-mention" && shouldAutoThread(msg.channelType, autoThreadEnabled())
+                ? { autoThreadName: deriveThreadName(msg.content) }
+                : {}),
+            // OPE-1719 — THE POSITIVE THREAD SIGNAL the owned-thread ingress router reads. A Discord
+            // thread is its own channel id, so `channelId` alone cannot tell a thread from a plain
+            // channel; the relay payload's channel type can, and it is host-extracted here exactly like
+            // every other field of this frozen origin. Stamped ONLY on a real thread type, so a plain
+            // channel's wake stays top-level and the standing seat keeps it.
+            ...(isThreadChannelType(msg.channelType) ? { thread: true } : {}),
+        };
+        const rendered = renderWake(buildDiscordUnifiedWake({
+            guildId: msg.guildId ?? "",
+            channelId: msg.channelId,
+            parentChannelId: str(input.auth.attributes.parent_channel_id),
+            isThread: isThreadChannelType(msg.channelType),
+            addressing: input.addressing,
+            threadEngaged: input.threadEngaged,
+            wakeId,
+            engagementTier: discordEngagementTier(domainKeyOf(input.partition)),
+            tail,
+            // 🔴 THE HYDRATION RIDES THE WAKE, NOT A PRE-RENDERED STRING (OPE-1749). `renderWake` holds
+            // both slots — these lines and `tail` — so core de-duplicates them against each other and
+            // spends the cap below that de-duplication, the same road every other surface takes.
+            contextLines: input.contextLines,
+            contextSource: input.contextSource,
+            botName: msg.botName,
+            catchUpUnavailable,
+            trigger: {
+                id: msg.id || "unknown",
+                author: msg.author.username ?? msg.author.id,
+                authorId: msg.author.id,
+                sentAt: atIso,
+                text: msg.content,
+                trust,
+            },
+        }));
+        const domainSurfaceKey = domainKeyOf(input.partition);
+        try {
+            // THE OWNED-THREAD INGRESS SEAM (§2.6, OPE-1719) — the INBOUND variant, the one Slack's front
+            // route has always used. A wake landing in a thread a live task worker or thread seat OWNS is
+            // dispatched to that owner's token instead of the standing seat's. Flag-off, and on every
+            // unowned thread, it is a byte-identical passthrough to `divertToUnifiedWindow`. The DM leg
+            // above stays on the raw divert on purpose: a Discord DM has no threads, so it can never own
+            // one, and a lookup there would only cost a store read.
+            await divertInboundToUnifiedWindow(input.receive, {
+                message: rendered.message,
+                // ONE SOURCE for the block now: `renderWake` rendered it from `contextLines` above.
+                context: rendered.context ?? [],
+                token,
+                window: {
+                    wakeId,
+                    origin,
+                    // ADDRESSED @mention ⇒ stamp `oe_addressing:"direct-mention"` (via stampUnifiedWindowAuth)
+                    // so the unified completion handler bridges the answer to this wake if the model writes
+                    // prose instead of calling `reply`. Watch/name-drop wakes omit it (prose stays dropped).
+                    ...(input.addressing === "direct-mention" ? { addressing: "direct-mention" } : {}),
+                    // `vendorTs` (OPE-1716): the snowflake's embedded creation time — see the DM leg above.
+                    ...spreadVendorTs(discordVendorEventTime(msg.id)),
+                },
+                // The DOMAIN-grain key (a thread/forum-post resolves to its parent channel via domainKeyOf),
+                // NOT the raw thread surfaceKey — the unified receive gate re-checks crossSurfaceWindow with
+                // an EXACT channels.includes match, and a thread id is never a listed channel. Passing the
+                // thread grain here refuses the wake fail-closed AFTER native was suppressed = orphaned
+                // silence (100% broken in forum channels, where every post is a thread). Identical to
+                // surfaceKey for base channels, so their behaviour is byte-unchanged.
+                surfaceKey: domainSurfaceKey,
+                // OPE-466/OPE-475 CARRIAGE, over the TRIGGER *AND* the backscroll siblings via
+                // `input.contextIngestion` — the caller graded them with {@link gradeDiscordContextLines}
+                // (the SAME resolution the trigger uses) before rendering `input.context`, so the join reads
+                // the SAME facts the render was built from.
+                //
+                // 🔴 DISCORD'S AUTHOR LEG COMES FROM OUR OWN CONFIG (OPE-516). Discord has no organisation
+                // concept, so `discordTrust` can NEVER positively refute an author — `member.pending` is the
+                // one platform signal and it is a SCREENING verdict, not a membership one. So the author leg
+                // is the AUTHOR-TRUST REGISTER (identity/author-trust.ts): on a guild the operator has armed,
+                // an author they did not declare grades `external`. On an UNARMED guild it contributes
+                // nothing, and the room declaration remains the whole statement, exactly as under OPE-489.
+                auth: stampNonMemberChatAuth(input.auth, [{ trust, refuted: msg.memberPending === true, ...authorFacts(msg) }, ...input.contextIngestion], { surfaceKey: domainSurfaceKey }),
+            });
+        }
+        catch (err) {
+            // OPE-970: same gap as the DM divert above — this leg's outer catch (below, `dispatchTurn`'s
+            // caller) only logged to the console. Audit it at the domain surface the wake actually targeted.
+            await auditSupervisorFailure({ org: deploymentOrg(), platform: input.partition.platform, workspace: input.partition.workspace, surface: domainSurfaceKey }, "surface.wake_failed", { message: String(err instanceof Error ? err.message : err).slice(0, 500), wakeId, addressing: input.addressing });
+            throw err;
+        }
+    };
+    // A wake failure PROPAGATES (the caller's catch owns it). OPE-174 removed a
+    // terminal-session-death rotate-and-redeliver branch here: it could never fire — a
+    // conversation-mode session PARKS at eve's token bound rather than failing, and a turn-time
+    // error cannot reject the awaited enqueue anyway (core's agent/channels/session-park.ts is the
+    // reachable handler).
+    // 🔴 EVERY WAKE READS THE ROOM SINCE THE SEAT LAST LOOKED (OPE-1695 (b), brought to Discord by
+    // OPE-1726). A FRESH generation renders its carried tail, as it always did; an ONGOING generation
+    // reads what the channel said since its own `lastWakeAt`, through the ONE shared catch-up path
+    // core holds — same bounds, same admission policy, same cap as Slack's. The read is bounded BELOW
+    // by the seat's last wake and ABOVE by the trigger, so a seat quiet for weeks pays for the recent
+    // tail and nothing more. FAIL-SOFT: the shared path never throws, and an unregistered fetch comes
+    // back as the UNAVAILABLE note rather than as a silent empty context.
+    const catchUp = session.fresh
+        ? undefined
+        : await seatCatchUp("discord", {
+            // The CONTAINER is the standing channel (a thread's PARENT when the auth carries one);
+            // the CONVERSATION is the thread, whose own channel id IS its read endpoint on Discord.
+            container: (isThreadChannelType(msg.channelType) ? str(input.auth.attributes.parent_channel_id) : undefined) ?? msg.channelId,
+            ...(isThreadChannelType(msg.channelType) ? { threadRoot: msg.channelId } : {}),
+            sinceMs: seatCatchUpSinceMs(existing?.lastWakeAt, Date.parse(atIso) || Date.now(), DISCORD_RAW_FETCH_REACHBACK_HOURS),
+            untilMs: Date.parse(atIso) || Date.now(),
+            ...(msg.id ? { excludeId: msg.id } : {}),
+            channelKey: domainKeyOf(input.partition),
+            // The caller's OWN vouch verdict — the same fact the trigger's tier was resolved from.
+            surfaceInternal: input.privacyOk,
+        }, {
+            trustFor: backscrollTrustResolver({ surfaceInternal: input.privacyOk, channelKey: domainKeyOf(input.partition) }),
+            // No `admit` (OPE-1857): the shared road resolves the domain's policy from the
+            // `channelKey` the request above already carries — the same key this line would have used.
+        });
+    await doWake(session.token, session.generation, session.fresh ? session.tail : (catchUp?.messages ?? []), catchUp?.unavailable);
+    await store.touchChannelSession(org, grain.registryKey, atIso).catch(() => undefined);
+    // OPE-794 — file this wake on the live generation's tail ring, AFTER it landed, and only the
+    // TRIGGER: never the backscroll rendered beside it. That is what stops a tail inheriting a tail
+    // (core's channels/session-tail.ts). Same registry key the rotation read and the spend counter
+    // use, so all three target one row.
+    await recordWakeTail(org, grain.registryKey, session.token, {
+        kind: "wake",
+        at: atIso,
+        from: "human", // bot authors are dropped at ingress (authForRelayMessage)
+        trust,
+        // THE AUTHOR GRAIN (OPE-1747) — byte-for-byte the facts this route's own `stampNonMemberChatAuth`
+        // join reads for the trigger, resolved through the one core road.
+        ...tailAuthorGrain({ trust, refuted: msg.memberPending === true, ...authorFacts(msg) }),
+        author: msg.author.username ?? msg.author.id,
+        authorId: msg.author.id,
+        id: msg.id || "unknown",
+        platform: "discord",
+        container: input.partition.surfaceKey,
+        text: msg.content,
+    });
+}
+/**
+ * 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 async function dispatchTurn(msg, auth, send, 
+// Injectable so the auto-thread fail-open path is testable without a live Discord call.
+createThread = createDiscordThread, 
+// Injectable so the thread→parent grain path is testable without a live Discord call.
+resolveParent = threadParentChannelId, 
+// eve's cross-channel `to` (the route supplies it) — the SINGLE-WINDOW divert primitive.
+// Optional + additive: absent (older callers/tests) ⇒ the divert block never runs, native path.
+receive) {
+    // THREAD→PARENT GRAIN (item 22). A message arriving IN an existing thread carries the
+    // thread's own channel id, which never matches a domain listing the parent channel and
+    // never accumulates against the parent's spend cap. Resolve the parent ONCE here (one
+    // cached REST `GET /channels/{id}` — discord-channel-info.ts, shared with the approval
+    // scope labels) and stamp it onto the auth, so everything downstream (partition
+    // domainKey, memory/RBAC/routing hops, the spend gate + hooks) stays sync. BEST-EFFORT:
+    // an unresolvable parent (no token, REST failure) keeps today's thread-grain behaviour
+    // — the turn is never blocked on this. (The auto-thread path below stamps its parent
+    // for free in dispatchSurfaceFor; this handles turns that START in a thread.)
+    if (isThreadChannelType(msg.channelType)) {
+        const parentChannelId = await resolveParent(msg.channelId);
+        if (parentChannelId) {
+            auth = buildDiscordAuth({
+                userId: msg.author.id,
+                guildId: msg.guildId,
+                channelId: msg.channelId,
+                channelType: msg.channelType,
+                parentChannelId,
+                // OPE-671: preserve the ✋ anchor — this REBUILDS auth from scratch, which would otherwise
+                // silently drop the messageId authForRelayMessage already stamped.
+                messageId: msg.id,
+            });
+        }
+    }
+    const partition = resolvePartition(ctxFromAuth(auth));
+    const key = engagementKey(msg);
+    const isDm = isDmChannel(msg.channelType);
+    // A DM or a mention always wakes; only a plain guild message needs the (async) engagement lookup.
+    // ONE engagement read, and it is the ROW rather than a boolean (OPE-418) — the row carries the
+    // durable STOOD-DOWN marker as well as "is this engaged", and both decide the same question.
+    // ── THE EXTERNAL-PARTICIPANT POLICY (OPE-507 author grain, OPE-504 room grain) ──────────────────
+    //
+    // POSITION IS LOAD-BEARING: this sits ABOVE the engagement read, the spend gate, every affordance
+    // (👀, typing, auto-thread) and both window diverts. A message the agent may not act on must cost
+    // nothing and show nothing — an affordance on a suppressed message tells the sender the agent is
+    // reading them, which is the opposite of the intended behaviour.
+    //
+    // Both grains are inert under their shipped values (`taint` / `engage`), so this whole block is a
+    // no-op on every deployment that has not opted in.
+    // EXPLICIT ADDRESSING — one fact, read twice: the verdict owes a private notice on it, and the
+    // OPE-885 ack keys on it. A DM is addressing by construction; `mentionsBot` is Discord's own
+    // mention signal, which a NAME-DROP never sets.
+    const addressed = isDm || msg.mentionsBot;
+    const externalVerdict = discordExternalVerdict({
+        policy: externalPolicyForRoom(domainKeyOf(partition)),
+        // The SAME per-message facts the taint author leg reads (access/taint-signal.ts): the resolved
+        // human tier plus the operator's author-trust query. Discord contributes no `refuted` — the
+        // platform has no organisation concept to refute against, which is why the register exists.
+        author: {
+            trust: resolveWakeTrustFromContext(ctxFromAuth(auth), { id: msg.author.id, isBot: msg.author.bot }, { principalFallback: true }),
+            ...authorFacts(msg),
+        },
+        addressed,
+        isDm,
+        roomKey: domainKeyOf(partition),
+    });
+    if (externalVerdict !== "proceed") {
+        // BEHAVIOUR 1 — an ADDRESSED message is owed an answer, so the sender gets a PRIVATE notice and
+        // the agent does nothing else. BEHAVIOUR 2 — an ambient message was owed nothing, so it is
+        // dropped in silence. The ROOM verdict posts its once-ever announcement instead. None wakes a
+        // model turn, and none shows an affordance.
+        // The private notice and the once-ever room announcement both ANSWER the person who addressed
+        // us, and both say more than the ack does — so either suppresses it.
+        let alreadyAnswered = false;
+        if (externalVerdict === "withheld-addressed")
+            alreadyAnswered = await postExternalSenderNotice(msg.author.id).catch(() => false);
+        if (externalVerdict === "silent-room")
+            alreadyAnswered = await announceSilentRoom(partition.surfaceKey, msg.channelId).catch(() => false);
+        // THE MENTION ACK (OPE-885): an explicit @mention or DM that got no private answer gets the one
+        // fixed host line, in the channel it was said in. An AMBIENT or NAME-DROP suppression stays
+        // fully dark — `addressed` is false for both, and this is the only gate.
+        const acked = owesSuppressedMentionAck({ addressed, alreadyAnswered }) &&
+            (await discordCreateMessage(msg.channelId, EXTERNAL_MENTION_ACK).then((id) => id !== null, () => false));
+        await appendAudit({
+            org: deploymentOrg(),
+            platform: "discord",
+            workspace: partition.workspace,
+            surface: partition.surfaceKey,
+            principalId: msg.author.id,
+            action: "discord.external_policy_suppressed",
+            detail: { verdict: externalVerdict, channelId: msg.channelId, ...suppressionRendering(acked) },
+        }).catch(() => undefined);
+        log(`suppressed ${partition.surfaceKey}: externalPolicy verdict "${externalVerdict}"`);
+        return;
+    }
+    const engRow = isDm || msg.mentionsBot ? null : await getThreadEngagement(partition, key);
+    const engaged = isDm || msg.mentionsBot ? true : engRow !== null;
+    // STOOD-DOWN SUPPRESSION (OPE-418), replacing the STOP REGEX that stood here. The regex matched
+    // the word "stop" in a followed surface and DELETED the engagement row; the agent now judges the
+    // ask itself between turns (`stand_down`) and sets a flag instead. A flag, not a delete, is what
+    // makes this gate possible at all: a deleted row is indistinguishable from a surface the agent was
+    // never invited into, so the old mechanism could suppress nothing here. A direct @mention is the
+    // re-invitation and always passes — it clears the marker via markEngaged({participating: true}).
+    if (!isDm && !msg.mentionsBot && engRow?.stopped) {
+        log(`suppressed ${partition.surfaceKey} — stood down here until an explicit @mention`);
+        return;
+    }
+    let nameDrop = false;
+    if (!shouldDispatchDiscord({ mentionsBot: msg.mentionsBot, isEngaged: engaged, isDm })) {
+        // NAME-DROP WAKE (item 25 — Slack parity): an un-followed guild surface whose message
+        // says the bot's display name gets a JUDGED turn (may end NO_REPLY) when the domain
+        // opted in via `nameDropWake` — checked at DOMAIN grain (domainKeyOf: a thread asks
+        // its parent channel's domain), same fail-closed default as Slack. No thread, no 👀,
+        // no engagement: the agent was not invited; the judged preamble owns the restraint.
+        // 🔴 THE TWO HALVES ARE READ SEPARATELY (OPE-1899), because only the split can tell a message
+        // that NAMED the agent from one that named nobody. `nameDropEligible` folds the name match into
+        // one boolean, so a candidate the DOMAIN FLAG refused is the one refusal this surface can state
+        // honestly — and it is exactly the refusal an operator reads back when the road looks dead.
+        const eligible = nameDropEligible({
+            mentionsBot: msg.mentionsBot,
+            isDm,
+            isEngaged: engaged,
+            // An allowlisted e2e driver counts as a user here too (item 29) — its name-drop
+            // scenarios must exercise the same gate a human's would. Everyone else: bot = bot.
+            authorIsBot: msg.author.bot && !isAllowedDriver(msg.guildId, msg.author.id),
+            channelType: msg.channelType,
+            content: msg.content,
+            botName: msg.botName,
+        });
+        nameDrop = eligible && nameDropWakeEnabled(domainKeyOf(partition), getConfig().loadDomains());
+        if (!nameDrop) {
+            // A candidate the flag refused writes the road's SILENT row; a message that named nobody
+            // writes nothing, which is the volume bound channels/name-drop-wake-audit.ts states.
+            if (eligible) {
+                await auditNameDropSilent(nameDropAuditKey(partition, msg), "nameDropWake not enabled for this channel's domain");
+            }
+            log(`drop ${partition.surfaceKey}: non-mention in a channel the agent isn't following`);
+            return;
+        }
+        // A name-drop IN A THREAD engages the thread — Slack's post-name-drop grain (its
+        // reply thread is followed), reached deterministically at dispatch (an engage-on-post
+        // state seed is dropped whenever this send RESUMES an old thread session, e.g. one of
+        // our own auto-threads whose engagement lapsed). A thread is a small, low-traffic
+        // scope and the stop verb above is the undo. BASE-CHANNEL name-drops deliberately do
+        // NOT engage — that would put a judged model turn on every subsequent channel
+        // message (the engaged-channel surprise from live testing). Best-effort.
+        if (isThreadChannelType(msg.channelType)) {
+            await markThreadEngaged(partition, key, new Date().toISOString());
+        }
+        // 🔴 THE POSITIVE ROW (OPE-1899) — the one line at which this road has decided to wake. Discord
+        // declines the wake-arm seam (channels/wake-arm.ts), so `via` is always the built-in policy here,
+        // and this route opens the native session rather than handing off to a standing seat.
+        await auditNameDropWoke(nameDropAuditKey(partition, msg), "name-dropped in an enabled guild surface — judged wake", {
+            road: "native",
+            via: "built-in",
+        });
+        log(`name-drop wake on ${partition.surfaceKey} ("${msg.botName}")`);
+    }
+    // SPEND CAP (pre-flight — the ONE shared gate, spend/ingress-gate.ts, the same function every
+    // other surface and the cross-surface divert call): a scope over its monthly budget DECLINES the
+    // turn with a VISIBLE refusal, never a silent drop, before any affordance (reaction/thread/
+    // typing) is shown. The CHECK fails OPEN (a broken store must never take a team's agent off the
+    // air); a definite OVER fails CLOSED — unless the sender is an admin over this scope, in which
+    // case the turn proceeds past the cap with a visible, hourly-throttled ⚠️ plus an audit row (sudo
+    // semantics: the guardrail binds the team, never locks out the budget owner; spend/bypass.ts).
+    // Discord is the surface whose admin evidence has TWO legs — the config roster and the
+    // REST-verified guild administrator, reached through the registered native-admin check, which is
+    // the reference implementation for that seam. DMs are NOT exempt (OPE-267 deleted the exemption);
+    // the gate picks the DM refusal variant itself, because "DM me to propose an override" is a loop
+    // with no exit when the refusal IS the DM.
+    //
+    // POSITION IS THE LOAD-BEARING PART, and Discord's has always been right: this gate runs BEFORE
+    // the single-window diversion below, so a Discord wake is decided here and never reaches the
+    // window ungated. Teams/GitHub/Linear were the opposite — their window leg returned BEFORE their
+    // native gate, which is the hole the divert-side gate (channels/unified.ts, door "window")
+    // exists to close. Both of Discord's doors now render the SAME refusal copy; while this block was
+    // hand-rolled they disagreed on one clause, so which door declined you decided which sentence you
+    // read.
+    //
+    // WHY THE HAND-ROLLED COPY IS GONE (OPE-302). It was kept deliberately for a while — byte-pinned
+    // by the scenario goldens, so migrating was a behaviour change with a re-record rather than a
+    // refactor. Two things came with the migration: the `spend.gate` audit row Discord alone never
+    // wrote (the divergence `6687d86f` recorded), and the loss of the two `log()` lines — deliberate,
+    // since a webhook function's console output never reaches `vercel logs`, which is exactly why the
+    // decision rides the audit trail instead.
+    const spendDoor = msg.mentionsBot || isDm ? "mention" : "engagement";
+    if ((await ingressSpendGate({
+        // The wake's OWN auth — including the thread→parent stamp resolved above — so the gate's
+        // internal domainKeyOf lands on the SPEND grain (a thread caps against its parent channel),
+        // which is the grain the cap gates and the key an override proposal must target. Freezing a
+        // thread's ephemeral key here was the live 2026-07-06 bug that grain exists to fix.
+        bindable: ctxFromAuth(auth),
+        // Discord's ONE ingress serves both of Slack's doors, so name the one this wake used: an
+        // @mention or a DM is the mention door; an engaged follow-up or a name-drop is the
+        // engagement door. That distinction is the whole point of the field — a live probe has to be
+        // able to tell which path refused.
+        door: spendDoor,
+        // The author id IS the attributed principal (discord-identity.ts stamps
+        // `principalId: userId`), so the person this turn's spend would be recorded under is the
+        // only person whose admin standing can buy a bypass of their own bill.
+        principalId: msg.author.id,
+        post: async (text) => {
+            await discordCreateMessage(msg.channelId, text);
+        },
+    })) === "declined") {
+        return; // drop — no model turn
+    }
+    // THE DM WINDOW DIVERT (OPE-356) — a DM lands in its OWN standing window, NOT in any shared one.
+    //
+    // POSITION IS LOAD-BEARING AND IT IS HERE FOR TWO REASONS. It sits AFTER the spend gate, so a DM
+    // is decided at Discord's own door and never reaches a window ungated (the property the comment
+    // above calls Discord's, kept). And it sits BEFORE the single-window block, which is not a race:
+    // that block's privacy floor refuses a guildless surface UNCONDITIONALLY, so a DM could never
+    // enter a shared window either way — the ordering just says out loud which window a DM belongs
+    // to, rather than leaving it to a `return false` two blocks down.
+    //
+    // BOTH DM SHAPES, one predicate ({@link isDmChannel}: type 1 and type 3). Slack first-classed 1:1
+    // `im` at stage 2 and its group DM (`mpim`) separately at stage 4 (OPE-355), because its
+    // DM-partner trust lookup is a 1:1 concept the mpim leg had to route around; Discord has no such
+    // lookup (discordTrust reads `member.pending`, which a DM has no
+    // member object for), and `rootDmGrainAttrs` already treats both as one standing grain. Splitting
+    // them here would invent a Discord-internal asymmetry that nothing in the fence needs — each is
+    // its own surface, so each gets its own surface-keyed window and its own byte-exact fence.
+    //
+    // Fail-closed to the NATIVE path when there is no `receive` at all (an older caller/test) ⇒
+    // byte-identical to the pre-OPE-356 per-channel DM session. The deployment-level `OE_DM_SEAT_ROTATION`
+    // hatch that used to sit beside it is gone (OPE-368): it was the last supported way to leave a DM on
+    // an un-wakeable native token, which is exactly the seat class the retired delegation anchor served.
+    if (isDm && receive) {
+        // The 👀 "seen" ack SURVIVES the re-seat — it is the DM's only affordance and a one-shot REST
+        // PUT with no session-coupled cleanup (a non-threaded 👀 STANDS as "seen"; only the auto-thread
+        // case is swap-tracked, and a DM never auto-threads). Typing deliberately does NOT: its
+        // re-triggers live on THIS channel's event handlers, which a diverted turn never reaches, so a
+        // single ~10s burst against a minute-long turn would read as "typing… then nothing" — the
+        // looks-like-a-crash tell the judged-wake typing gate exists to avoid.
+        if (statusUxEnabled())
+            await setDiscordReaction(msg.channelId, msg.id, EYES_EMOJI, "PUT");
+        await divertDiscordDmToWindow({ msg, auth, partition, receive });
+        await appendAudit({
+            org: deploymentOrg(),
+            platform: "discord",
+            // A DM has no guild; the binding keys its workspace to the caller's own user id (bindDiscord),
+            // which is what `partition` already carries — no fabricated guild id.
+            workspace: partition.workspace,
+            surface: partition.surfaceKey,
+            principalId: msg.author.id,
+            action: "discord.dispatched",
+            detail: { addressing: "direct-mention", dmWindow: true, channelId: msg.channelId },
+        }).catch(() => undefined);
+        log(`dm-window divert ${partition.surfaceKey}`);
+        return;
+    }
+    // SINGLE-WINDOW DIVERSION (the cross-surface shared-context window — see the section header
+    // above). When this surface's domain opted into crossSurfaceWindow AND the Discord privacy
+    // floor passes (discordSingleWindowPrivacyOk — an operator-VOUCHED guild surface; a DM never
+    // passes), the whole wake diverts into the synthetic unified channel: an @mention as an
+    // ADDRESSED `direct-mention` wake — the mention policy's suppressNative IS this early return,
+    // so none of the native affordances below (auto-thread, 👀, typing, per-channel session) run —
+    // and engaged/name-drop wakes as judged watch wakes. The mention still ENGAGES the surface
+    // first (exactly as the native path does) so plain follow-ups keep waking — and keep
+    // diverting. Floor not passed / flags off / no receive ⇒ fall through: byte-identical native
+    // behaviour (fail-closed: an un-vouched surface never joins the shared window).
+    const windowGrain = discordGrainFor(domainKeyOf(partition));
+    if (grainUsesUnifiedWindow(windowGrain) && windowGrain.domainName !== undefined && receive) {
+        const privacyOk = discordSingleWindowPrivacyOk({
+            guildId: msg.guildId,
+            workspaceKey: partition.workspaceKey,
+            surfaceKey: partition.surfaceKey,
+            domainKey: domainKeyOf(partition),
+        });
+        // The ONE shared mention decision (unified-window.ts seam via the thin Discord shim):
+        // addressed `direct-mention` ⟺ the native dispatch stands down for this mention.
+        const mentionPolicy = discordSingleWindowMentionPolicy(true, msg.mentionsBot, privacyOk);
+        if (privacyOk) {
+            if (msg.mentionsBot) {
+                // A mention is an invitation — participating engagement on THIS surface (the base
+                // channel/thread the mention landed in; no auto-thread on the window path), mirroring
+                // the native path's landmine fix so follow-ups wake without re-tagging.
+                await markThreadEngaged(partition, key, new Date().toISOString(), { participating: true });
+            }
+            // Backscroll: same condition as the native path (mention/name-drop hydration; an engaged
+            // follow-up's conversation already lives in the shared session). Fail-soft [].
+            // OPE-475: fetch the RAW lines (not the pre-rendered-string wrapper) so they can be graded
+            // with the SAME per-line resolution the native path uses ({@link gradeDiscordContextLines})
+            // before rendering — the render then carries the reference-only note for any demoted line,
+            // and `contextIngestion` carries the SAME facts to the join, which never sees the lines
+            // themselves on this leg (only the pre-rendered `context` strings reach `divertToUnifiedWindow`).
+            const windowLines = nameDrop || msg.mentionsBot
+                ? await fetchDiscordBackscrollLines({
+                    channelId: msg.channelId,
+                    triggerMessageId: msg.id,
+                    isThread: isThreadChannelType(msg.channelType),
+                    botId: msg.botId,
+                }).catch(() => undefined)
+                : undefined;
+            const gradedWindowLines = windowLines ? await gradeDiscordContextLines(windowLines.lines, ctxFromAuth(auth), msg.guildId) : undefined;
+            // THE DOMAIN'S ADMISSION POLICY, THE RENDER AND THE JOIN FACTS, over ONE admitted set
+            // ({@link discordSeatContextForWindow} — OPE-1800). This is the SEAT road, so the policy runs
+            // here and nowhere else on Discord; the native dispatch below keeps its whole hydration.
+            const seatContext = discordSeatContextForWindow(gradedWindowLines, windowLines?.source, windowGrain, domainKeyOf(partition), isThreadChannelType(msg.channelType));
+            const addressing = mentionPolicy.addressing ?? (nameDrop && msg.botName ? "name-drop" : "channel-watch");
+            await divertDiscordWakeToUnifiedWindow({
+                msg,
+                auth,
+                partition,
+                grain: windowGrain,
+                addressing,
+                privacyOk,
+                // The ENROLMENT fact, off the row this dispatch ALREADY read (OPE-1740). The narrow reading
+                // every other surface states: an @mention (or an earned reply) invited the agent here, and
+                // the invitation still stands. A warm name-drop latch (`participating: false`) is not an
+                // invitation, and a stopped row has already been left.
+                threadEngaged: engRow?.participating === true && engRow.stopped !== true,
+                receive,
+                contextLines: seatContext.lines,
+                contextSource: seatContext.source,
+                contextIngestion: seatContext.ingestion,
+            });
+            await appendAudit({
+                org: deploymentOrg(),
+                platform: "discord",
+                workspace: msg.guildId ?? "unknown",
+                surface: partition.surfaceKey,
+                principalId: msg.author.id,
+                action: "discord.dispatched",
+                detail: { addressing, singleWindow: true, channelId: msg.channelId },
+            }).catch(() => undefined);
+            log(`single-window divert ${partition.surfaceKey} (${addressing})`);
+            return;
+        }
+    }
+    // AUTO-THREAD. A mention landing in a base guild text/announcement channel opens a dedicated
+    // thread and the WHOLE turn re-keys onto it (see dispatchSurfaceFor). This stays inside the
+    // background dispatch (waitUntil) — one extra REST round-trip, invisible to the fast route
+    // ack. Fail-OPEN: a null from createThread (missing permission, rate limit, API error) keeps
+    // the base channel so the turn still runs inline — threading never gates delivery. Only a
+    // mention threads; a non-mention engaged wake is ALREADY in its conversation surface (a base
+    // channel it's following, or a thread of type 10/11/12 that shouldAutoThread excludes).
+    const statusUx = statusUxEnabled();
+    let threadId = null;
+    if (msg.mentionsBot && shouldAutoThread(msg.channelType, autoThreadEnabled())) {
+        threadId = await createThread(msg.channelId, msg.id, deriveThreadName(msg.content));
+        if (!threadId) {
+            log(`auto-thread failed for ${partition.surfaceKey} — falling back to an inline reply in the base channel`);
+        }
+    }
+    // STATUS UX: the 👀 "seen" ack — on DIRECT addresses (mention or DM), the turns with a
+    // guaranteed reply. On the auto-threaded mention it is swap-tracked (→ ✅ when the answer
+    // lands in the thread — the one case where the reply is away from the message AND a fresh
+    // session guarantees the seeded swap coords are never stale). Everywhere else it simply
+    // STANDS as "seen" — the answer arrives right underneath, so there's nothing to signal by
+    // removing it, and an untracked ack is immune to the resumed-session staleness class.
+    // Engaged non-mention wakes get NO reaction: the agent may judge silence, and eyes-ing every
+    // message in a followed channel reads as surveillance. Best-effort: setDiscordReaction
+    // swallows every failure — never blocks or drops the turn.
+    if (statusUx && (msg.mentionsBot || isDm)) {
+        await setDiscordReaction(msg.channelId, msg.id, EYES_EMOJI, "PUT");
+    }
+    // Resolve the surface the turn actually runs on: the thread (re-keyed) when one was created,
+    // else the base channel. Everything downstream (identity, continuation, reply state,
+    // engagement) reads from this single descriptor so the base/thread split lives in one place.
+    const surface = dispatchSurfaceFor(msg, auth, threadId);
+    // When we re-keyed to a thread, engagement must be stored under the THREAD's surfaceKey (its
+    // own silo), not the base channel's — so re-resolve the partition from the thread auth.
+    const dispatchPartition = threadId ? resolvePartition(ctxFromAuth(surface.auth)) : partition;
+    // Engage on mention so subsequent plain replies in this SURFACE also wake (best-effort).
+    // On auto-thread this engages the THREAD (where the conversation lives), NOT the base channel
+    // — a later base-channel message needs its own mention (→ its own thread), per the plan.
+    //
+    // participating:true — THE PARTICIPATING-FLAG LANDMINE FIX (mirrors slack.ts onInbound): a
+    // mention is an INVITATION, so the surface must be an invited PARTICIPANT, not a merely-warm
+    // watcher. Without the flag the mention left a `participating:false` row, which the new warm
+    // auto-disengage below would then shed after a run of silent turns — @mentioning the bot must
+    // never make it sheddable. participating:true also resets the silent streak and exempts the
+    // surface from the warm shed (sticky until an explicit stop).
+    if (msg.mentionsBot) {
+        await markThreadEngaged(dispatchPartition, surface.engagementKey, new Date().toISOString(), { participating: true });
+    }
+    // Assemble the state SEEDED into send (applied only when this send STARTS a session): the
+    // reply surface follows the re-key (surface.state.channelId); the 👀→✅ reaction target is
+    // included ONLY for the auto-threaded case (see the reaction comment above — the one case
+    // where the seed is guaranteed to reach a fresh session).
+    const turnState = buildGatewayState({
+        replyChannelId: surface.state.channelId,
+        // Seed the guild so the completion handler can rebuild the engagement partition (promote on
+        // reply / shed on silence). msg.guildId is the same for the base channel and any thread it
+        // spawns (a thread never leaves its guild); absent for DMs → no engagement bookkeeping.
+        guildId: msg.guildId,
+        original: statusUx && threadId ? { channelId: msg.channelId, messageId: msg.id } : undefined,
+    });
+    // Working signal: fire the native typing indicator on the reply surface right away (covers
+    // the gap until the turn's own events take over re-triggering it). Best-effort. JUDGED
+    // wakes (engaged / name-drop — anything not directly addressed) may end NO_REPLY, so for
+    // those the gate holds ALL typing back until the streamed reply text proves the model is
+    // actually answering — a judged silence then shows NOTHING instead of "typing… then
+    // nothing" (the looks-like-a-crash tell from live testing).
+    if (statusUx) {
+        if (msg.mentionsBot || isDm) {
+            openTypingGate(surface.state.channelId);
+            await triggerDiscordTyping(surface.state.channelId);
+        }
+        else {
+            closeTypingGate(surface.state.channelId);
+        }
+    }
+    // Durable resume: the continuation token keys the session on the (base or thread) channel id;
+    // a thread is its own channel id so threads resume independently. The reply posts back into
+    // turnState.channelId via the message.completed handler. The framework prepends the
+    // channel's name to the token.
+    // WAKE RENDER — the ONE shared renderer (normalized-wake.ts renderWake), NOT a Discord-local
+    // dialect. Classify the addressing the native path already computed: a name-drop is `name-drop`
+    // (highest bar); a mention/DM is `direct` (the conversation driver — raw body pass-through, no
+    // preamble/envelope, byte-identical to the old renderTurn(true)); an engaged non-mention is
+    // `thread-follow` (judged). The judged paths (thread-follow / name-drop) now render the FULL wake
+    // envelope + the canonical Slack-parity preamble instead of the old drifted prose stub — the
+    // convergence this migration exists to make.
+    const isThread = isThreadChannelType(msg.channelType);
+    const addressing = nameDrop && msg.botName ? "name-drop" : msg.mentionsBot || isDm ? "direct" : "thread-follow";
+    // PER-WAKE TRUST (identity/wake-trust.ts — audit-wedge F3), off the SAME auth the session binds
+    // with (the divert path resolves it identically). The trigger's author IS the message sender. A
+    // `direct` body passes through verbatim (trust unused in that render); a judged body renders it as
+    // the envelope's `<message trust=…>` attribute. `principalFallback` on `direct` mirrors the divert
+    // builder's `direct ? "principal" : "peer"` default.
+    const trust = resolveWakeTrustFromContext(ctxFromAuth(surface.auth), { id: msg.author.id, isBot: msg.author.bot }, { principalFallback: addressing === "direct" });
+    // WAKE/MENTION BACKSCROLL (Slack parity — discord-backscroll.ts): a name-drop or an @mention used
+    // to reach the model with ONLY the triggering message. Fetch the surrounding conversation as RAW
+    // ContextLines (W3 — no pre-rendered string flows through the plumbing; renderWake wraps them via
+    // the shared renderContext). We read the SURFACE THE HUMAN IS IN (msg.channelId) — for an
+    // auto-threaded mention that's the base channel where the conversation is, NOT the fresh empty
+    // reply thread. Skipped for DMs (the 1:1 history IS the conversation, carried by the durable
+    // session) and for plain engaged non-mention wakes (a follow-up in a conversation the session
+    // already holds). Fail-soft: undefined on any error → wake with just the message, exactly as before.
+    const backscroll = !isDm && (nameDrop || msg.mentionsBot)
+        ? await fetchDiscordBackscrollLines({
+            channelId: msg.channelId,
+            triggerMessageId: msg.id,
+            isThread,
+            botId: msg.botId,
+        }).catch(() => undefined)
+        : undefined;
+    // OPE-475: regrade the ContextLine backscroll siblings with the SAME per-line resolution the
+    // trigger uses just above, so a guest hydrated behind a member's trigger is graded too.
+    const gradedBackscrollLines = backscroll ? await gradeDiscordContextLines(backscroll.lines, ctxFromAuth(surface.auth), msg.guildId) : undefined;
+    // THE DOMAIN'S ADMISSION POLICY ON THIS ROAD TOO ({@link admitDiscordSeatLines} — OPE-1800), and
+    // the seam decides by the ROOM's grain, never by the road. A wake reaches this native arm either
+    // because the room has no seat at all — then nothing is narrowed — or because its seat STOOD DOWN
+    // (the guild vouch absent, or no `receive`), which access/window-routing.ts audits as
+    // `native-degraded`. Policing both is what keeps ONE admission answer per domain: a runtime vouch
+    // must not be able to widen what a `members-only` room's wake reads.
+    const nativeContextLines = admitDiscordSeatLines(gradedBackscrollLines, windowGrain, domainKeyOf(partition), isThread);
+    const rendered = renderWake(discordNativeWake({
+        channelId: msg.channelId,
+        // Container = the thread's PARENT when known (the domain/spend grain), else the channel; the
+        // conversation is the thread itself. Auth carries the parent when the turn started in a thread
+        // (stamped at the top of dispatchTurn) — mirrors the divert builder's locus mapping.
+        parentChannelId: str(surface.auth.attributes.parent_channel_id),
+        isThread,
+        isDm,
+        addressing,
+        // The ENROLMENT fact, off the row this dispatch ALREADY read (OPE-1740) — the same expression
+        // the unified divert passes, so one conversation cannot answer two ways by grain.
+        threadEngaged: engRow?.participating === true && engRow.stopped !== true,
+        botName: msg.botName,
+        contextLines: nativeContextLines,
+        contextSource: backscroll?.source,
+        trigger: {
+            id: msg.id || "unknown",
+            author: msg.author.username ?? msg.author.id,
+            authorId: msg.author.id,
+            sentAt: new Date().toISOString(),
+            text: msg.content,
+            trust,
+        },
+    }));
+    try {
+        await dispatchNativeWakeWithRetry(() => send(
+        // Backscroll is ADDITIONAL context, never a replacement for the message; omitted when empty so
+        // the payload is identical to today's on the no-history path.
+        rendered.context && rendered.context.length ? { message: rendered.message, context: rendered.context } : rendered.message, {
+            // OPE-466/OPE-475 CARRIAGE, over the TRIGGER *AND* the regraded ContextLine backscroll
+            // siblings. `member.pending` is Discord's only PLATFORM refutation and it is a screening
+            // verdict, and it rides the trigger's own relay payload only — {@link gradeDiscordContextLines}
+            // documents why it is unreachable for a backscroll sibling (Discord's own message-list REST
+            // shape carries no `member` object). The OPERATOR's refutation (`authorTrust`, OPE-516) IS
+            // reachable per sibling, so it is what closes the gap for a backscroll-hydrated guest; it
+            // yields `{}` on a DM, where there is no guild to arm.
+            auth: stampNonMemberChatAuth(surface.auth, [{ trust, refuted: msg.memberPending === true, ...authorFacts(msg) }, ...(nativeContextLines ?? []).map(contextLineIngestion)], isDm ? { dm: true } : { surfaceKey: domainKeyOf(dispatchPartition) }),
+            continuationToken: surface.continuationToken,
+            state: turnState,
+        }), { platform: "discord", workspace: dispatchPartition.workspace, surfaceKey: dispatchPartition.surfaceKey });
+    }
+    catch (err) {
+        // OPE-971: this native guild dispatch (a plain per-channel/per-thread continuation token, NOT
+        // an ambient-supervisor `channel_session` row) has no rotatable registry key — it is the same
+        // "thread seat, native session" shape stranded-seat.ts already documents as unhealable. This
+        // call turns a completely SILENT failure into an AUDITED one (`session.pruned_deployment_strand`,
+        // remedy "none") without inventing a rotation that cannot exist. No registryKey override: the
+        // token is passed as-is and correctly resolves to `not-a-window`.
+        await healPrunedDeploymentStrand({
+            token: surface.continuationToken,
+            surfaceKey: dispatchPartition.surfaceKey,
+            platform: "discord",
+            atIso: new Date().toISOString(),
+            err,
+        });
+        throw err;
+    }
+    log(`dispatched ${dispatchPartition.surfaceKey} (${isDm ? "dm" : msg.mentionsBot ? "mention" : nameDrop ? "name-drop" : "engaged"}` +
+        `${threadId ? ", auto-threaded+👀" : ""})`);
+}
+// --- engagement bookkeeping on completion (Slack parity) --------------------
+// The completion handler runs with only the LIVE session state (no auth), so — exactly like
+// slack.ts rebuilds its partition from teamId+channelId in the state — we rebuild Discord's
+// engagement partition from the seeded guild + reply channel id. The engagement KEY is the reply
+// channel id itself (Discord engagement is per-channel; a thread is its own channel id), matching
+// how dispatchTurn keys it. Returns null for a DM (no guild → no engagement) or a pre-seed
+// session — both then skip engagement bookkeeping, which is exactly right.
+export function engagementCoordsFor(state) {
+    if (!state.guildId || !state.channelId)
+        return null;
+    // userId is irrelevant to the surfaceKey (guild = workspace, channel = surface); pass "" so the
+    // rebuilt partition names discord/<guild>/<channel> exactly as the dispatch partition did.
+    const p = resolvePartition(ctxFromAuth(buildDiscordAuth({ userId: "", guildId: state.guildId, channelId: state.channelId })));
+    return { p, key: state.channelId };
+}
+// The audit partition for a terminal decision — same rebuild as engagementCoordsFor but
+// WITHOUT the guild requirement (a DM turn's silence/reply must still be auditable; its
+// workspace keys to the binding's DM fallback). Null only when the state names no channel
+// (pre-seed session) or the rebuild fails — the caller then skips the row (fail-soft;
+// auditing must never fail or post into the turn).
+function auditPartitionForGatewayState(state) {
+    if (!state.channelId)
+        return null;
+    try {
+        return resolvePartition(ctxFromAuth(buildDiscordAuth({ userId: "", guildId: state.guildId, channelId: state.channelId })));
+    }
+    catch {
+        return 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 async function promoteParticipatingOnReply(state) {
+    try {
+        const coords = engagementCoordsFor(state);
+        if (!coords)
+            return; // DM / pre-seed session — nothing to promote
+        const rec = await getThreadEngagement(coords.p, coords.key);
+        if (!rec)
+            return; // no existing engagement (base-channel name-drop) — don't grab the whole channel
+        // 🔴 `byOwnPost` — a POSTED reply is not a re-invitation, so this promotion must never lift a
+        // stand-down (OPE-1669, measured on Slack; the shape is identical here). The rule lives in
+        // channels/engagement.ts and re-reads the row rather than reusing `rec` above, so there is
+        // exactly ONE expression of it and no second copy to drift.
+        await markThreadEngaged(coords.p, coords.key, new Date().toISOString(), { participating: true, byOwnPost: true });
+    }
+    catch (err) {
+        console.warn(`[open-everywhere:discord-gateway] participating-promote failed: ${String(err)}`);
+    }
+}
+/**
+ * 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 async function maybeShedWarmSurface(state) {
+    try {
+        const coords = engagementCoordsFor(state);
+        if (!coords)
+            return;
+        const rec = await getThreadEngagement(coords.p, coords.key);
+        if (rec && rec.participating !== true) {
+            const streak = await bumpThreadSilentStreak(coords.p, coords.key);
+            if (streak >= WARM_SILENT_LIMIT) {
+                await disengageThread(coords.p, coords.key);
+                log(`warm surface shed after ${streak} silent turns — disengaged (${coords.p.surfaceKey})`);
+            }
+        }
+    }
+    catch (err) {
+        console.warn(`[open-everywhere:discord-gateway] warm silent-streak bookkeeping failed: ${String(err)}`);
+    }
+}
+export default defineChannel({
+    kindHint: "discord",
+    // 🔴 QUEUE, NEVER STEER (OPE-412, OPE-1732). eve's default is `steer`, and a steer delivery
+    // carrying a message CANCELS the turn in flight — rolling session history back to the last
+    // completed model call while that call's tool side effects (posts, PRs, writes) stay real and
+    // unrecorded. The policy resolves per RECEIVING channel, so the pin on `discordChannel`
+    // (channels/discord.ts) covers NOTHING here: that is the slash-command Interactions mount, and
+    // every Discord MESSAGE session lives on this channel, under the `discord:<threadId>` or
+    // `discord:<channelId>` continuation token this route builds. Live-proven on deploy #197
+    // (2026-09-11, session wrun_41M28D8M300GY5HGRQW63MR9ZA): two turns cancelled by ordinary
+    // follow-up messages, one of them 7.3 s after it had already completed and answered. This channel is a raw `defineChannel`,
+    // so `lint:turn-policy` — which reads the five vendor factories — cannot see this line;
+    // `scripts/discord-gateway-turn-policy-test.ts` is what holds it. See
+    // packages/providers/slack/agent/channels/slack.ts for the full note.
+    turnPolicy: "queue",
+    // Default seed; every session-starting dispatch overrides it with the real target channel id.
+    state: { channelId: "" },
+    // Hand event handlers the reply surface + the LIVE state object. `state` is eve's mutable
+    // write-back reference (auto-snapshotted at step boundaries) — turn.started WRITES this turn's
+    // holding-message id into it and message.completed CONSUMES it, which is what keeps the
+    // affordances per-turn-correct on resumed sessions (send-state is first-turn-only).
+    context: (state) => ({
+        channelId: state.channelId,
+        state,
+    }),
+    routes: [
+        POST("/eve/v1/discord-gateway", async (req, { from, waitUntil, to, attachSession }) => {
+            // eve 0.31 binds the channel-local address at `from(address)` rather than passing it in the
+            // send options, and moved `context` from the payload into the options. {@link
+            // DiscordGatewaySend} is OE's OWN dispatch shape (it long predates 0.31), so the whole
+            // dispatchTurn path below is untouched — the version-shaped difference is this one adapter.
+            const gatewaySend = (message, options) => {
+                const payload = typeof message === "string" ? { message, context: undefined } : message;
+                return from(options.continuationToken).send(payload.message, {
+                    auth: options.auth,
+                    state: options.state,
+                    ...(payload.context && payload.context.length > 0 ? { context: payload.context } : {}),
+                });
+            };
+            const rawBody = await req.text();
+            // 1) Verify the relay HMAC over the RAW body, fail-closed. Reject BEFORE parsing so we
+            //    never act on (or even JSON.parse) an unauthenticated payload.
+            const rejection = relayGate(req.headers.get("x-oe-relay-signature"), rawBody);
+            if (rejection) {
+                log(`rejected (${rejection.status}): ${rejection.reason}`);
+                return new Response(rejection.reason, { status: rejection.status });
+            }
+            // 2) Parse defensively. A malformed/unrecognized body is a relay bug, not a normal
+            //    no-op — 400 (a 4xx the relay logs + drops, never retries).
+            let json;
+            try {
+                json = JSON.parse(rawBody);
+            }
+            catch {
+                return new Response("invalid json", { status: 400 });
+            }
+            // Relay liveness heartbeat (OPE-775) — classified FIRST, before any wake path (message or
+            // reaction) gets a look at the body. It mints no session, no wake, no reply: one audit row,
+            // written async, ack immediately. See discordHeartbeatAuditRow's doc for what the row proves.
+            const heartbeat = parseRelayHeartbeat(json);
+            if (heartbeat) {
+                waitUntil(appendAudit(discordHeartbeatAuditRow(heartbeat, deploymentOrg())).catch(() => undefined));
+                return new Response("ok", { status: 200 });
+            }
+            // Inbound reaction — a distinct relay payload shape. Handled before the message parse:
+            // ingest async (telemetry always, a durable feedback row on a bot reply), ack immediately.
+            // A reaction never starts a turn — but since OPE-418 a ✋ can STOP one, which is why
+            // `attachSession` (eve's I/O-free cancel door, available on every route handler) is handed
+            // in here: the whole point is that a stop costs no session mint and no model call.
+            const reaction = parseRelayReaction(json);
+            if (reaction) {
+                waitUntil(routeDiscordReaction(reaction, liveDiscordReactionDeps(attachSession)).then((o) => log(`reaction ${reaction.channelId}/${reaction.messageId}: ${o.recorded ? "recorded" : "not recorded"} — ${o.reason}`)));
+                return new Response("ok", { status: 200 });
+            }
+            const msg = parseRelayPayload(json);
+            if (!msg)
+                return new Response("unrecognized relay payload", { status: 400 });
+            // 3) Drop bot authors + empty-content messages as ordinary no-ops (200 — nothing to
+            //    retry). buildDiscordAuth returns null for a bot author.
+            const auth = authForRelayMessage(msg);
+            if (!auth) {
+                // OPE-647: a MISPLACED driver id (pinned to a different guild) is a cross-tenant
+                // admission-refusal worth naming in the audit trail — every other bot-drop stays silent
+                // (ordinary noise; see isMisplacedDriver's doc for why the two are told apart).
+                if (msg.author.bot && isMisplacedDriver(msg.guildId, msg.author.id)) {
+                    await appendAudit({
+                        org: deploymentOrg(),
+                        platform: "discord",
+                        workspace: msg.guildId ?? "unknown",
+                        surface: msg.channelId,
+                        principalId: msg.author.id,
+                        action: "discord.relay_admission_refused",
+                        detail: { reason: "e2e-driver credential is pinned to a different guild; this guild is not vouched for it" },
+                    }).catch(() => undefined);
+                }
+                return new Response("ignored (bot author)", { status: 200 });
+            }
+            if (msg.content.trim().length === 0)
+                return new Response("ignored (empty content)", { status: 200 });
+            // 4) Dispatch async — the wake gate (engagement lookup) + turn run in the background,
+            //    the reply is posted from message.completed. Ack immediately. `to` arms the
+            //    single-window divert (byte-identical inert off the crossSurfaceWindow gates); its
+            //    fail-closed refusals surface in the catch instead of an unhandled rejection.
+            waitUntil(dispatchTurn(msg, auth, gatewaySend, undefined, undefined, to).catch((err) => log(`dispatch failed: ${String(err)}`)));
+            return new Response("ok", { status: 200 });
+        }),
+    ],
+    events: {
+        // Working signal: re-trigger the native typing indicator ("<bot> is typing…", ~10s TTL) as
+        // the turn progresses. turn.started covers the turn's opening; each tool-call boundary
+        // (actions.requested / action.result) refreshes it; and the STREAMED text/reasoning chunks
+        // (*.appended, throttled — they can fire many times a second) keep it alive through the
+        // final answer's generation, so typing runs right up to the reply landing instead of
+        // lapsing ~10s before it. Gaps during a single long silent tool run remain — same as a
+        // human pausing typing. All best-effort; typing must never delay or drop a turn.
+        //
+        // Every re-trigger ALSO respects the judged-wake typing gate (closeTypingGate at
+        // dispatch): a judged turn shows no typing at all until its streamed message text
+        // deviates from the NO_REPLY sentinel (the message.appended handler feeds the gate) —
+        // so a judged silence is silent from the very first second.
+        "turn.started": async (_data, channel, ctx) => {
+            if (statusUxEnabled() && typingGateOpen(channel.channelId))
+                await triggerDiscordTyping(channel.channelId);
+            // OPE-645: REPLY PRINCIPAL snapshot — snapshotted at turn.started for the
+            // same reason: message.completed has no live auth ctx, so the canonical row it writes cannot
+            // derive WHO from ctx at that point. Since OPE-2006 that row is the DROP row, never a
+            // `reply.post`. authPrincipalId(ctx) is the exact read bindFrom(ctx).principalId falls back to
+            // for an ordinary human turn (identity/binding.ts) — snapshotting it here means the drop row
+            // names the same person the turn's egress.policy rows already do.
+            channel.state.oeReplyPrincipalId = authPrincipalId(ctx);
+        },
+        // Tool-boundary re-triggers ALSO peek the card signal: action.result fires immediately
+        // after the card-posting tool returns — an unconditional re-trigger there is exactly the
+        // "typing for ~10s after the card" residue. (Typing can only ever be triggered, never
+        // cancelled — Discord's indicator is a ~10s TTL — so going quiet at the right moment is
+        // the ONLY lever; the last legitimate trigger's tail is unavoidable.)
+        "actions.requested": async (_data, channel) => {
+            if (statusUxEnabled() && typingGateOpen(channel.channelId) && !peekCardPostedThisTurn())
+                await triggerDiscordTyping(channel.channelId);
+        },
+        "action.result": async (_data, channel) => {
+            if (statusUxEnabled() && typingGateOpen(channel.channelId) && !peekCardPostedThisTurn())
+                await triggerDiscordTyping(channel.channelId);
+        },
+        // The *.appended re-triggers PEEK the card signal (never consume — message.completed
+        // owns the read-and-reset): once an approval card has posted this turn, the model's
+        // remaining narration is going to be SUPPRESSED, so keeping "typing…" alive for it
+        // would read as "typing… then nothing". The card is the reply; go quiet.
+        "message.appended": async (data, channel) => {
+            if (!statusUxEnabled())
+                return;
+            const soFar = data?.messageSoFar ?? "";
+            if (!typingGateFeed(channel.channelId, soFar))
+                return;
+            if (!peekCardPostedThisTurn() && typingRefreshDue(channel.channelId))
+                await triggerDiscordTyping(channel.channelId);
+        },
+        "reasoning.appended": async (_data, channel) => {
+            if (statusUxEnabled() && typingGateOpen(channel.channelId) && !peekCardPostedThisTurn() && typingRefreshDue(channel.channelId))
+                await triggerDiscordTyping(channel.channelId);
+        },
+        // A failed turn must NEVER be silent: without this handler a runtime failure left the
+        // human staring at 👀 + a dead thread with no reply and no clue (live 2026-07-06 —
+        // silence is what made a workflow-side failure invisible). Mirrors eve's own channel
+        // default: post a short honest error to the reply surface. Best-effort, never throws.
+        "turn.failed": async (data, channel) => {
+            openTypingGate(channel.channelId); // turn over — never leak a closed gate into the next
+            const detail = data?.error?.message;
+            log(`turn failed (channel ${channel.channelId || "?"})${detail ? `: ${detail}` : ""}`);
+            await postDiscordReply(channel.channelId, "⚠️ I hit an error while handling that and couldn't finish. Please try again — and if it keeps failing, check the deployment logs.");
+        },
+        // Deliver the turn's final reply back to Discord AND reconcile the 👀→✅ swap (auto-threaded
+        // mentions only). finalMessageAction (the shared, unit-tested decision slack-events.ts owns)
+        // stays the SOURCE OF TRUTH for whether there's a reply — a watch routine's NO_REPLY sentinel
+        // is SWALLOWED, and tool-only / empty finals post nothing — exactly as
+        // channels/discord.ts does. planCompletion turns that decision (+ whether this turn seeded swap
+        // coords, read consume-once from the live state) into the concrete ops; the handler is a thin
+        // executor. The reply is always a FRESH post — never an edit, so no "(edited)" tag. Every
+        // affordance op is best-effort/fail-open: the reply lands even if a reaction call fails.
+        "message.completed": async (data, channel, ctx) => {
+            const sessionId = ctx?.session?.id; // stamped into the terminal audit rows → joins to the transcript
+            const rawAction = finalMessageAction(data.finishReason, data.message);
+            // An interim tool-call step is NOT the final reply — touch nothing (typing re-triggers
+            // via the action events above; the swap coords stay for the real completion).
+            if (rawAction.kind === "buffer-tool-status")
+                return;
+            // Turn is over — clear the judged-wake typing gate so it can't leak into the next turn
+            // on this channel (a silent judged turn leaves its gate closed by design).
+            openTypingGate(channel.channelId);
+            // Consume-once: read this turn's swap coords and CLEAR them, so a resumed later turn can
+            // never react on THIS turn's message (the staleness class an earlier design hit).
+            const status = takeTurnStatus(channel.state);
+            // Card-signal (approvals/card-signal.ts, read-and-reset): a propose tool posted an
+            // approval card this turn → the card IS the reply; suppress the model's narration
+            // exactly as channels/slack.ts does. Consumed only on FINAL actions (the buffer-tool
+            // branch returned above), so an interim completion can't eat the signal early.
+            // repliedThisTurn (reply-signal.ts, same read-and-reset contract as channels/
+            // discord.ts): a mid-turn reply-tool post means an empty terminal is an ANSWERED
+            // turn, not a silence — consumed here so it never bleeds into the next turn either.
+            // TURN-ID KEYED (OPE-805): only THIS turn's own mark answers true.
+            // 🔴 READ ONCE (OPE-1639). The turn id keys every per-turn signal this handler consumes. Since
+            // OPE-2006 there is no terminal reply audit below to key as well: the closing prose is dropped
+            // and audited, so one read serves the silence decision and the signal consumes alike.
+            const turnId = ctx?.session?.turn?.id;
+            const repliedThisTurn = consumeRepliedThisTurn(turnId);
+            const cardPostedThisTurn = consumeCardPostedThisTurn();
+            // OPE-890: read-and-reset the no_reply TOOL signal (no-reply-signal.ts), same contract as
+            // Slack/Teams' finalMessageActionForTurn — needed here ONLY to tell the two silence routes
+            // apart below. Discord's OWN silence decision never needed this (isNoReply(message) alone
+            // decides it, because the tool's own note instructs the model to also emit the sentinel
+            // text — see tools/no_reply.ts's END_TURN_WITH_SENTINEL_INSTRUCTION), so consuming it here
+            // changes nothing about what gets posted or suppressed.
+            const noReplyToolCalledThisTurn = consumeNoReplyThisTurn() !== null;
+            // OPE-1647 — THE STAND-DOWN LATCH, and this handler needs its OWN copy of the read. Slack,
+            // Teams and the Discord INTERACTIONS channel take it inside `finalMessageActionForTurn`; this
+            // one calls the pure `finalMessageAction` instead, because it consumes the `no_reply` signal
+            // itself on the line above to tell the two silence routes apart. Swapping in the ForTurn
+            // variant would consume that signal first and break the split, so the latch is read here, on
+            // the same read-and-reset contract, and turned into the silent verdict below.
+            // 🔴 THIS IS THE GUILD PATH. Every guild wake completes here rather than in channels/
+            // discord.ts, so without this read a stood-down Discord thread reproduces deploy #187 exactly:
+            // the acknowledgement posts, the latch is set, nothing reads it, and the trailing prose follows
+            // it into the conversation the person asked the agent to leave.
+            const stoodDownSilentThisTurn = consumeStandDownSilenceThisTurn(turnId);
+            const action = stoodDownSilentThisTurn && rawAction.kind === "post" ? { kind: "silent", reason: STAND_DOWN_SILENCE_REASON } : rawAction;
+            const plan = planCompletion({
+                action,
+                reactionActive: Boolean(status.original),
+                cardPostedThisTurn,
+            });
+            // 1) Reaction — remove the 👀 from the ORIGINAL mention in its base channel (not the
+            //    reply surface, which is the thread). Absence = done; the bot never plants a ✅
+            //    (reserved for humans — the Slack-established convention).
+            if (plan.reaction === "clear" && status.original) {
+                await setDiscordReaction(status.original.channelId, status.original.messageId, EYES_EMOJI, "DELETE");
+            }
+            // 2) Deliver the reply into the reply surface (channel.channelId) as a fresh post.
+            //    AUDIT the posted reply (issue-surface parity): a discord.replied row records what was
+            //    said. ACTIONS-ONLY posture (audit-wedge build plan §1c, 2026-07-14): a judged silence
+            //    is NOT an audited action — the transcript answers "why did it stay quiet?", not the
+            //    audit log. The partition is rebuilt from the live state; best-effort, never fails the turn.
+            const auditP = channel.state.channelId
+                ? auditPartitionForGatewayState(channel.state)
+                : null;
+            if (plan.delivery.kind === "post") {
+                const text = action.kind === "post" ? action.text : plan.delivery.chunks.join("\n");
+                // 🔴 THE CLOSING PROSE IS DROPPED, NOT POSTED (OPE-2006). This branch used to route the
+                // guild path's terminal reply through `postTerminalProse`, with a raw `postDiscordReply`
+                // fallback for an unidentifiable state. Both are gone: the `reply` tool is the only channel a
+                // seat's words leave by, so a turn that ended in prose and never called `reply` has said
+                // nothing here. The row is the record — no re-send, no queue, no host-side re-post.
+                // WHAT TELLS THE MODEL is the seat prompt: Discord declares `closingProseDropped`, so a
+                // conversational seat here reads the `reply-only` delivery arm, whose copy states that the
+                // turn-final text is discarded — inside its persona when the token is supervisor-shaped, and
+                // through the `delivery` slot when it is not (instructions/access.ts `renderDeliverySlot`).
+                if (auditP) {
+                    await dropClosingProse({
+                        row: {
+                            org: auditP.org,
+                            platform: auditP.platform,
+                            workspace: auditP.workspace,
+                            surface: auditP.surface,
+                            principalId: channel.state.oeReplyPrincipalId,
+                        },
+                        chars: text.length,
+                        ...(sessionId ? { sessionId } : {}),
+                        anchor: { channelId: channel.channelId || null },
+                        log: (m) => log(`${m} (channel ${channel.channelId || "?"})`),
+                    });
+                }
+                else {
+                    // No resolvable partition, so there is no row to file it under — the drop still happens and
+                    // the log line is the whole record.
+                    log(`closing prose DROPPED (${text.length}c) — nothing posted, and no partition to audit it under (channel ${channel.channelId || "?"})`);
+                }
+            }
+            else if (action.kind === "silent") {
+                if (data.message)
+                    log(`judged silence (NO_REPLY) — nothing posted (channel ${channel.channelId || "?"})`);
+                // OPE-890: the sentinel route's own ALWAYS-ON row — the twin of tools/no_reply.ts's
+                // tool-route `reply.no_reply_observed` row (OPE-649). Only for a GENUINE bare-sentinel
+                // turn (the tool was not called this turn) — a tool-then-sentinel turn already wrote its
+                // own row inside the tool's execute() and must not be double-counted here.
+                if (action.reason === NO_REPLY_SENTINEL_REASON && !noReplyToolCalledThisTurn && auditP) {
+                    await auditNoReplySentinelObserved(auditP, sessionId).catch(() => undefined);
+                }
+            }
+            // 3) ENGAGEMENT BOOKKEEPING (Slack parity). A DELIVERED reply PROMOTES the surface to
+            //    participating (sticky, streak reset). A JUDGED-SILENT turn (NO_REPLY / empty final)
+            //    bumps the warm silent streak and sheds the surface at the limit. Both best-effort and
+            //    gated on the seeded guild — a DM / pre-seed session is a no-op.
+            // 🔴 THE PREDICATE IS THE DELIVERY, NOT `action.kind` (OPE-2006). It read `action.kind ===
+            //    "post"` while that meant "the closing prose posted". The prose is DROPPED now, so a turn
+            //    that ended in text and never called `reply` put NOTHING in the room — and promoting on it
+            //    would make a warm name-drop surface sticky-participating on an answer nobody saw, while
+            //    the `silent` branch below never runs to shed it. OPE-771 measured that shape at 23 of 36
+            //    owed answers. Only a `reply` tool post or an approval card is bytes in the room, which is
+            //    the same pair `channels/slack.ts` promotes on.
+            const deliveredThisTurn = repliedThisTurn || cardPostedThisTurn;
+            if (deliveredThisTurn) {
+                await promoteParticipatingOnReply(channel.state);
+            }
+            else if (action.kind === "silent") {
+                await maybeShedWarmSurface(channel.state);
+            }
+        },
+    },
+});
+//# sourceMappingURL=discord-gateway.js.map