@open-everywhere/provider-discord 0.1.0

package/agent/approvals/discord-flow.ts

@@ -0,0 +1,469 @@
+// The Discord I/O half of the admin approvals flow — the sibling of flow.ts's Slack
+// wiring, funnelling through the SAME platform-neutral decide core (resolveApprovalClick).
+// Two entry points:
+//
+//   postDiscordApprovalCard()          — the CardPoster the propose tools inject into
+//                                        requestApproval on a Discord surface: renders the
+//                                        pure card (discord-card.ts) and posts it via the
+//                                        Discord REST create-message API with the bot token.
+//                                        NEVER throws (CardPoster contract) — any failure
+//                                        resolves undefined and requestApproval expires the
+//                                        pending + throws its own explanatory error.
+//   postDiscordJudgeLiftNotice()       — the JudgeLiftNoticePoster this bundle registers
+//                                        (OPE-1103): the notice for an action the armed judge
+//                                        LIFTED, carrying the one "This should not have run"
+//                                        button. Same REST transport, opposite failure
+//                                        posture — the act has already run, so a failed post
+//                                        is logged and swallowed, never fatal.
+//   handleDiscordApprovalInteraction() — called by the Discord front route
+//                                        (channels/discord-front.ts) for every verified
+//                                        interaction body. Returns null for anything that
+//                                        isn't an `oe-approval:` MESSAGE_COMPONENT click
+//                                        (the caller forwards those to Eve — PING, slash
+//                                        commands, Eve's own `eve_input:` HITL buttons);
+//                                        otherwise it OWNS the click end-to-end and returns
+//                                        the interaction RESPONSE body to send. NEVER throws
+//                                        — Discord's interactions endpoint must answer
+//                                        within 3s, so every failure mode is fail-soft.
+//
+// WHY the click path is response-shaped (vs. Slack's fire-and-forget chat.update): a Discord
+// component click is answered by REPLYING to the interaction itself — type 7 UPDATE_MESSAGE
+// rewrites the very message the button lives on (no bot token, no extra REST call), and
+// type 4 + flags 64 is an EPHEMERAL note only the clicker sees (the denial UX Slack fakes
+// with a thread note).
+//
+// 🔴 THE THREE-SECOND BUDGET, AND WHAT THIS DOOR PUTS INSIDE IT (OPE-1407). Discord gives an
+// interactions endpoint THREE SECONDS and does not redeliver an expired token, so an admin whose
+// decision really landed can still see a red "This interaction failed" over it. This door used to
+// spend the whole click inside that budget: `resolveApprovalClick` AND `deliverDecisionFeedback`,
+// which posts a notice through Discord REST and dispatches a decision wake. The FEEDBACK now runs
+// off the response path under the route's `waitUntil` when there is one (`DiscordApprovalDeps`).
+// Nothing in the interaction response depends on it, so it is the leg that should never have been in
+// the budget.
+//
+// 🔴 `resolveApprovalClick` STAYS ON THE RESPONSE PATH, and this door therefore CANNOT copy the
+// grant door's ack-then-decide shape (access/discord-grant-click.ts). That door answers every case
+// with one `type 4` ephemeral, so a `type 5` deferred ephemeral plus a follow-up edit is the same
+// answer arriving later. This door answers with THREE different shapes chosen by the resolution:
+// `type 7` REPLACES the card with the decided render and strips its buttons, `type 6` acks silently
+// and leaves the card alone, `type 4` sends an ephemeral refusal and leaves the row pending. The
+// shape is not known until the decision is made, and Discord fixes a response's KIND at the first
+// response. Deferring as `type 5` would drop the card replacement — the decided card would keep its
+// buttons — and deferring as `type 6` would have no way to send the refusal branches' ephemeral
+// without overwriting the pending card in the channel. Closing that half needs a follow-up MESSAGE
+// (`POST /webhooks/{app}/{token}` with `flags 64`) rather than the `@original` edit this package
+// has, and that behaviour cannot be measured offline. It is a separate change, and OPE-1407's
+// definition-of-done comment records it as open.
+
+import {
+  resolveApprovalClick,
+  deliverDecisionFeedback,
+  discordDecisionWakeTarget,
+  postDiscordDecisionNotice,
+  clickerFloorRefusalNotice,
+  judgeContradictionNotice,
+  type ApprovalClickResolution,
+  type DecisionWakeDeps,
+  type ApprovalOutcome,
+  type PendingActionRow,
+} from "@open-everywhere/core/agent/adapter-api.js";
+import {
+  OE_DISCORD_APPROVAL_PREFIX,
+  parseDiscordApprovalCustomId,
+  pendingDiscordCard,
+  decidedDiscordCard,
+  judgeLiftNoticeDiscordCard,
+  isGuildAdministrator,
+  scopeWithinGuild,
+  type DiscordCardMessage,
+} from "./discord-card.js";
+import { guildIdFromScopeKey, isGuildAdminViaRest } from "./discord-admin.js";
+
+function log(msg: string): void {
+  console.log(`[open-everywhere:discord-approvals] ${msg}`);
+}
+
+// Discord interaction-response wire constants. Defined locally: eve's exported
+// DISCORD_INTERACTION_RESPONSE_TYPE enum has no UPDATE_MESSAGE (7) — its HITL path only
+// ever defers — so importing it would still leave the one we need most as a bare literal.
+const RESPONSE_CHANNEL_MESSAGE = 4; //  CHANNEL_MESSAGE_WITH_SOURCE — a fresh reply to the click
+const RESPONSE_DEFERRED_UPDATE = 6; // DEFERRED_UPDATE_MESSAGE — ack, leave the message as-is
+const RESPONSE_UPDATE_MESSAGE = 7; //  UPDATE_MESSAGE — replace the message the button lives on
+const EPHEMERAL_FLAG = 64; //          only the clicking user sees the reply
+
+/** One Discord interaction response body (`{ type, data? }`), ready to JSON out. */
+export type DiscordInteractionResponse = Record<string, unknown>;
+
+/** Injectable seams so the poster is unit-tested without a live token or network. */
+export interface DiscordPostDeps {
+  readonly fetchFn?: typeof fetch;
+  readonly token?: string;
+}
+
+/**
+ * Render + post the approval card into `row.channelId` via Discord REST create-message
+ * (`POST /channels/{id}/messages` with `content` + `components`). Resolves to the posted
+ * message's id, or undefined on ANY failure — no token, an over-long custom_id (render
+ * throws), a non-ok status, a network error, or a response missing an id. NEVER throws,
+ * and the bot token is a SECRET — it rides the header, never a log line (both conventions
+ * lifted verbatim from channels/discord-gateway.ts's discordCreateMessage).
+ */
+export async function postDiscordApprovalCard(
+  row: PendingActionRow,
+  summaryLines: readonly string[],
+  deps: DiscordPostDeps = {},
+): Promise<string | undefined> {
+  return postDiscordCardMessage(row, deps, "approval card", () => pendingDiscordCard(row, summaryLines));
+}
+
+/**
+ * THE JUDGE-LIFT NOTICE POSTER (OPE-1103) — the `JudgeLiftNoticePoster` this bundle registers, and
+ * the Discord half of what was a Slack-only surface.
+ *
+ * It is NOT the CardPoster above with a different render, and the two must stay apart: that one
+ * posts the PENDING card for a LIVE row, and `requestApproval` treats its failure as fatal (it
+ * expires the pending and throws, because a proposal nobody can see must never linger). Here the
+ * frozen args have ALREADY RUN. A thrown error could not undo them and would only turn a completed
+ * action into a failed tool call, so this resolves `void` on every path — the core's own contract
+ * for the hook.
+ *
+ * WHAT A FAILURE COSTS, stated plainly: the room loses its only trace of the lift and the one button
+ * that answers it. The audit rows (`approval.autoapproved`, `approval.judge.verdict`) still land, so
+ * the event stays queryable — but nobody in the room is told. That is why the failure is LOGGED
+ * rather than swallowed silently.
+ */
+export async function postDiscordJudgeLiftNotice(
+  row: PendingActionRow,
+  summaryLines: readonly string[],
+  outcomeLine: string,
+  deps: DiscordPostDeps = {},
+): Promise<void> {
+  await postDiscordCardMessage(row, deps, "judge-lift notice", () => judgeLiftNoticeDiscordCard(row, summaryLines, outcomeLine));
+}
+
+/**
+ * Render + POST one code-rendered message into `row.channelId` via Discord REST create-message
+ * (`POST /channels/{id}/messages` with `content` + `components`), and hand back the posted message's
+ * id — or undefined on ANY failure: no token, no channel, an over-cap custom_id (the render throws),
+ * a non-ok status, a network error, or a response missing an id. NEVER throws.
+ *
+ * `render` is a THUNK, not a rendered message, so an over-cap custom_id is caught by this function's
+ * own try rather than at each call site. `what` names the message in the log line only.
+ *
+ * The bot token is a SECRET — it rides the header, never a log line (both conventions lifted
+ * verbatim from channels/discord-gateway.ts's discordCreateMessage).
+ */
+async function postDiscordCardMessage(
+  row: PendingActionRow,
+  deps: DiscordPostDeps,
+  what: string,
+  render: () => DiscordCardMessage,
+): Promise<string | undefined> {
+  const token = deps.token ?? process.env.DISCORD_BOT_TOKEN;
+  if (!token) {
+    log(`DISCORD_BOT_TOKEN is not set — cannot post the ${what} to channel ${row.channelId}`);
+    return undefined;
+  }
+  if (!row.channelId) {
+    log(`no channel id on the pending row — nothing to post the ${what} to`);
+    return undefined;
+  }
+  const doFetch = deps.fetchFn ?? fetch;
+  try {
+    const card = render(); // throws on an over-cap custom_id — caught below
+    const res = await doFetch(`https://discord.com/api/v10/channels/${row.channelId}/messages`, {
+      method: "POST",
+      headers: { authorization: `Bot ${token}`, "content-type": "application/json" },
+      body: JSON.stringify({ content: card.content, components: card.components }),
+    });
+    if (!res.ok) {
+      log(`Discord create-message failed (${res.status}) posting the ${what} to channel ${row.channelId}`);
+      return undefined;
+    }
+    const body = (await res.json()) as unknown;
+    const id = body && typeof body === "object" ? (body as Record<string, unknown>)["id"] : undefined;
+    return typeof id === "string" && id.length > 0 ? id : undefined;
+  } catch (err) {
+    log(`Discord ${what} post error for channel ${row.channelId}: ${(err as Error)?.message ?? String(err)}`);
+    return undefined;
+  }
+}
+
+/** The subset of a MESSAGE_COMPONENT interaction the approval click path reads. This is
+ *  untrusted wire JSON reaching a public URL (post-signature-check, but Discord relays
+ *  whatever a client sends) — every field is probed, nothing is assumed (same defensive
+ *  posture as discord-gateway.ts's parseRelayPayload). */
+export interface DiscordApprovalClick {
+  readonly customId: string;
+  /** The clicking user's id — `member.user.id` in a guild, top-level `user.id` in a DM. */
+  readonly clickerId?: string;
+  readonly guildId?: string;
+  /** `member.permissions` — Discord's stringified permission bitfield for the clicker in
+   *  the channel the click happened in. Absent outside guilds. */
+  readonly memberPermissions?: string;
+}
+
+function isObject(v: unknown): v is Record<string, unknown> {
+  return typeof v === "object" && v !== null;
+}
+function str(v: unknown): string | undefined {
+  return typeof v === "string" && v.length > 0 ? v : undefined;
+}
+
+/**
+ * Probe a raw interaction body for an `oe-approval:` MESSAGE_COMPONENT click. Returns null
+ * for anything else — wrong type, no custom_id, or a foreign prefix — which the caller
+ * treats as "not ours → forward to Eve". A click that IS ours but is missing its clicker
+ * still returns (with `clickerId` undefined) so the handler can fail soft ON the click
+ * rather than forward a half-understood payload to Eve (mirrors handleApprovalPayload's
+ * malformed-payload branch). NEVER throws.
+ */
+export function parseDiscordComponentClick(raw: unknown): DiscordApprovalClick | null {
+  if (!isObject(raw) || raw["type"] !== 3) return null; // not a MESSAGE_COMPONENT interaction
+  const data = isObject(raw["data"]) ? raw["data"] : undefined;
+  const customId = data ? str(data["custom_id"]) : undefined;
+  if (!customId || !customId.startsWith(OE_DISCORD_APPROVAL_PREFIX)) return null; // not ours — forward
+  const member = isObject(raw["member"]) ? raw["member"] : undefined;
+  const memberUser = member && isObject(member["user"]) ? member["user"] : undefined;
+  const user = isObject(raw["user"]) ? raw["user"] : undefined;
+  return {
+    customId,
+    clickerId: (memberUser ? str(memberUser["id"]) : undefined) ?? (user ? str(user["id"]) : undefined),
+    guildId: str(raw["guild_id"]),
+    memberPermissions: member ? str(member["permissions"]) : undefined,
+  };
+}
+
+function ephemeral(content: string): DiscordInteractionResponse {
+  return { type: RESPONSE_CHANNEL_MESSAGE, data: { content, flags: EPHEMERAL_FLAG } };
+}
+
+/** Test seams for the decide FEEDBACK (task #106) — absent ⇒ the live poster/dispatch. */
+export interface DiscordApprovalDeps {
+  /** Notice poster — defaults to {@link postDiscordDecisionNotice} (bot-token create-message). */
+  readonly postNotice?: (row: PendingActionRow, text: string) => Promise<unknown>;
+  readonly decisionWake?: DecisionWakeDeps;
+  /**
+   * The route's own `waitUntil` (OPE-1407). PRESENT ⇒ the decision FEEDBACK runs off the response
+   * path and the interaction is answered as soon as the decision itself is made. ABSENT ⇒ the
+   * feedback is awaited first, the pre-OPE-1407 shape — correct, and slower by a Discord REST post
+   * plus a wake dispatch.
+   *
+   * 🔴 TWO LEGS MOVE, AND THE SECOND ONE EXECUTES. The decision FEEDBACK above, and the core's
+   * OPE-251 session-grant RELEASE (OPE-1709), which this file forwards into `resolveApprovalClick`
+   * below — an "Approve for session" click decides and runs up to `MAX_SESSION_GRANT_RELEASES`
+   * sibling cards, so it is the heavier of the two. Do not read this hook as feedback plumbing.
+   *
+   * 🔴 WHAT DOES NOT MOVE IS THE RESPONSE BODY. `resolveApprovalClick` decides it, so that CALL
+   * cannot be deferred without answering before the answer is known — see the header. Handing it the
+   * hook defers work it starts, never the resolution it returns.
+   */
+  readonly waitUntil?: (p: Promise<unknown>) => void;
+}
+
+/**
+ * Map a decide resolution to the interaction response — the Discord rendering of exactly
+ * what handleApprovalPayload renders as Slack calls. Pure → unit-tested as a matrix.
+ *   decided / expired → type 7: REPLACE the card with the decided render (components: [],
+ *                       so the buttons are gone and the card can't be re-clicked — the CAS
+ *                       already protects correctness; this is the UX half).
+ *   denied            → type 4 ephemeral: the row stays pending (a real admin can still act
+ *                       on the same card), the clicker alone is told why.
+ *   unknown           → type 4 ephemeral: same wording as the Slack card-text fallback.
+ *   everything else   → type 6: silent ack, leave the message alone (a stale re-click /
+ *                       lost race / unregistered kind — same silent-by-design branches as
+ *                       the Slack path; re-rendering could clobber the winner's card).
+ */
+export function discordResponseFor(res: ApprovalClickResolution): DiscordInteractionResponse {
+  switch (res.outcome) {
+    case "unknown":
+      return ephemeral("This approval request is no longer known (it may have already been decided or has aged out).");
+    case "not-pending":
+    case "expired-race":
+    case "unregistered-kind":
+    case "lost-race":
+      return { type: RESPONSE_DEFERRED_UPDATE };
+    case "expired": {
+      const card = decidedDiscordCard(res.row, res.summaryLines, "expired");
+      return { type: RESPONSE_UPDATE_MESSAGE, data: { content: card.content, components: card.components } };
+    }
+    case "denied":
+      return ephemeral("Only a domain/org admin — or a server administrator, for this server's own scopes — can decide this request.");
+    case "clicker-denied":
+      // The clicker gate (OPE-185, core approvals/clicker-floor.ts) — same UX as `denied`: an
+      // ephemeral to the clicker alone, card untouched, row still pending.
+      //
+      // ⚠️ NOT REACHABLE FROM THIS SURFACE TODAY, and it is honest to say so rather than let the
+      // branch imply Discord enforces something it doesn't. The gate runs only for a caller that
+      // supplies a `clickContext`, and `handleDiscordApprovalInteraction` below deliberately
+      // supplies none: Discord has no member supplier (the privileged GUILD_MEMBERS intent, and no
+      // guest concept to map onto `hasGuest` even then), so every leg would be inert anyway and
+      // Discord clicks stay byte-identical to pre-OPE-185. The case exists because the resolution
+      // union is SHARED across surfaces, and this switch must stay exhaustive over it.
+      return ephemeral(clickerFloorRefusalNotice(res.reason));
+    case "halted":
+      // The break-glass halt arrow at the click (OPE-1604, core approvals/flow.ts) — same UX as
+      // `denied`: an ephemeral to the clicker alone, message untouched, row still pending, so the
+      // same card works again once an admin runs `resume` — until the TTL sweep reaps it, which a
+      // halt does not stop (see the `halted` resolution's own doc). REACHABLE from this surface: unlike the
+      // clicker gate above, this arrow needs no `clickContext` and runs for every click path.
+      // `res.notice` is core's ONE halt renderer (access/halt.ts `haltRefusalMessage`), so a
+      // Discord room and a Slack room read the same sentence — including the fail-closed clause
+      // when the halt state could not be read at all.
+      return ephemeral(res.notice);
+    // NB: this renderer stays PURE — the decide/expire decision FEEDBACK (fresh notice beside the
+    // card + window wake, task #106 — an UPDATE_MESSAGE edit is invisible to backscroll, exactly
+    // like Slack's chat.update) is handleDiscordApprovalInteraction's side-effect leg, not a
+    // response concern.
+    case "contradicted":
+      // The judge-contradiction overrule (OPE-965; reachable on this surface since OPE-1103, when
+      // `postDiscordJudgeLiftNotice` above started rendering the button). An ephemeral to the
+      // clicker, message UNTOUCHED — deliberately unlike `decided`, which strips its buttons: the
+      // notice reports an act that really did happen and stays in the room as its trace, and a
+      // second click is a defined no-op the copy answers ("already flagged, it still counts once").
+      // `judgeContradictionNotice` is core's ONE renderer for all four outcomes, so this room and a
+      // Slack room are told the same thing about the same overrule.
+      return ephemeral(judgeContradictionNotice(res.contradiction));
+    case "decided": {
+      const card = decidedDiscordCard(res.row, res.summaryLines, res.outcomeLine);
+      return { type: RESPONSE_UPDATE_MESSAGE, data: { content: card.content, components: card.components } };
+    }
+  }
+}
+
+/**
+ * Handle one verified Discord interaction body. Returns null for anything that isn't an
+ * `oe-approval:` component click (caller forwards to Eve); otherwise owns the click and
+ * returns the interaction response to send. The approver policy on this surface is
+ * two-legged, fail-closed:
+ *   - the config-as-code roster (clickerMayDecide inside the core — org admins, or the
+ *     FROZEN row domain's admins; a Discord clicker is matched as the PLATFORM-QUALIFIED key
+ *     `discord/<user-id>`, which is why this call states its platform rather than letting the
+ *     core infer one — see `clickerPlatform` below), OR
+ *   - Discord-native standing: the clicker's member.permissions carries ADMINISTRATOR
+ *     (missing/unparseable → not an admin) AND the frozen row's scope is inside THIS guild
+ *     (scopeWithinGuild — a guild admin is authority over their own server's scopes only).
+ * NEVER throws — an unexpected failure resolves to an ephemeral note, because the
+ * interactions endpoint must always answer.
+ */
+export async function handleDiscordApprovalInteraction(raw: unknown, deps: DiscordApprovalDeps = {}): Promise<DiscordInteractionResponse | null> {
+  const click = parseDiscordComponentClick(raw);
+  if (!click) return null; // not ours — the front route forwards to Eve
+
+  try {
+    const parsed = parseDiscordApprovalCustomId(click.customId);
+    if (!parsed) return null; // ours-prefixed but unparseable → forward (mirrors parseApprovalAction's null)
+
+    if (!click.clickerId) {
+      // It WAS ours; fail soft on the click rather than forward a half-understood payload.
+      console.error(`[open-everywhere:discord-approvals] component click "${click.customId}" carries no user id — ignoring the click`);
+      return ephemeral("Couldn't read who clicked — this decision was not applied.");
+    }
+    const clickerId = click.clickerId;
+
+    const res = await resolveApprovalClick({
+      org: parsed.org,
+      id: parsed.id,
+      decision: parsed.decision,
+      clickerId,
+      // The clicker id is a Discord snowflake, so the roster arm matches it as
+      // `discord/<id>` (identity/principal-key.ts). Stated here rather than inferred: this
+      // surface passes no `clickContext`, and a DM-context click has no room to read a platform
+      // off at all — the leg that most needs the roster is exactly the one with no other source.
+      clickerPlatform: "discord",
+      // 🔴 THE ROUTE'S `waitUntil` REACHES THE CORE TOO (OPE-1709). The decision FEEDBACK below
+      // already rides it; this hands the core the same hook for the OPE-251 session-grant RELEASE,
+      // which decides and EXECUTES the sibling cards the grant covers. Both legs are work nothing in
+      // the interaction response depends on, so both belong off the three-second budget. Absent ⇒
+      // the core awaits the release, the same "no waitUntil ⇒ no defer" rule this file's feedback
+      // leg states below.
+      ...(deps.waitUntil ? { waitUntil: deps.waitUntil } : {}),
+      // Discord-native admin leg — "administrator of the guild the FROZEN row's scope lives
+      // in", two evidence paths by where the click happened:
+      //   in a guild → the payload's member.permissions is authoritative for THAT guild, so
+      //     it must also BE the row's guild (scopeWithinGuild) — a guild-A admin clicking a
+      //     card in guild A for a row aimed at guild B proves nothing about B.
+      //   in a DM   → no member payload exists at all, so ask Discord directly: REST-check
+      //     the clicker's standing in the row's own guild (isGuildAdminViaRest, fail-closed;
+      //     a non-guild scope — Slack, a DM bucket — resolves no guild and denies). This is
+      //     what makes the over-budget escape hatch work: the ⛔'d channel drops every turn,
+      //     the proposal happens in a DM, and the card lands there — the admin must be able
+      //     to decide it where it is.
+      platformAdmin: async (row) => {
+        if (click.guildId) return isGuildAdministrator(click.memberPermissions) && scopeWithinGuild(row.scopeKey, click.guildId);
+        const rowGuild = guildIdFromScopeKey(row.scopeKey);
+        return rowGuild ? isGuildAdminViaRest(rowGuild, clickerId) : false;
+      },
+    });
+    // Decision FEEDBACK (task #106 — Slack click-path parity): a fresh notice beside the card (the
+    // UPDATE_MESSAGE response is an EDIT, invisible to backscroll) + the cross-thread window wake.
+    // The wake's guild id comes from the SIGNED interaction (Slack's team.id analogue — the frozen
+    // scopeKey can name a different workspace under an explicit-scope override); a DM-context
+    // interaction has none → no wake, fail-soft, the notice still posts beside the card. No transport
+    // failure throws out of it; the egress spoof's Vercel refusal can (OPE-1132). On the AWAITED path
+    // below that refusal reaches the caller's own catch, which answers the interaction anyway rather
+    // than leaving Discord to retry. On the DEFERRED path the response has already gone, so the catch
+    // around the deferred promise logs it instead and the door's answer is unaffected.
+    //
+    // 🔴 IT RUNS OFF THE RESPONSE PATH WHEN THE ROUTE GAVE US A `waitUntil` (OPE-1407). It is a
+    // Discord REST post plus a wake dispatch, and nothing in the interaction response depends on it,
+    // so it is exactly the leg that should not sit inside a three-second budget. See the header.
+    const feedback = (): Promise<void> | undefined => {
+      if (res.outcome === "expired") {
+        return deliverDecisionFeedback(
+          {
+            row: res.row,
+            summaryLines: res.summaryLines,
+            outcome: "expired",
+            outcomeLine: "expired",
+            executed: "none",
+            target: discordDecisionWakeTarget(res.row, click.guildId),
+            postNotice: (text) => (deps.postNotice ?? postDiscordDecisionNotice)(res.row, text),
+          },
+          deps.decisionWake,
+        );
+      }
+      if (res.outcome === "decided") {
+        return deliverDecisionFeedback(
+          {
+            row: res.row,
+            summaryLines: res.summaryLines,
+            outcome: res.row.status as ApprovalOutcome,
+            outcomeLine: res.outcomeLine,
+            executed: res.executed,
+            clickerId,
+            target: discordDecisionWakeTarget(res.row, click.guildId),
+            postNotice: (text) => (deps.postNotice ?? postDiscordDecisionNotice)(res.row, text),
+          },
+          deps.decisionWake,
+        );
+      }
+      return undefined;
+    };
+
+    const pending = feedback();
+    if (pending !== undefined) {
+      if (deps.waitUntil === undefined) {
+        // No place to run it past the reply: await, the pre-OPE-1407 shape. On a serverless host a
+        // promise left running after the response is frozen with the invocation, so a defer with
+        // nowhere to live would DROP the notice — strictly worse than answering slowly.
+        await pending;
+      } else {
+        // TOTAL. This runs after the response has gone; a throw here reaches the host's unhandled
+        // rejection handler and tells nobody anything. The decision itself has already landed and is
+        // audited, so what a failure costs is the notice and the wake — logged, never fatal.
+        deps.waitUntil(
+          pending.catch((err: unknown) => {
+            log(`deferred decision feedback failed for "${click.customId}": ${(err as Error)?.message ?? String(err)}`);
+          }),
+        );
+      }
+    }
+    return discordResponseFor(res);
+  } catch (err) {
+    // Genuinely unexpected (store outage, …) after we'd established this WAS our click —
+    // fail soft with an honest ephemeral note; never throw out of the interactions path.
+    console.error(`[open-everywhere:discord-approvals] click handling failed softly for "${click.customId}": ${String(err)}`);
+    return ephemeral("Something went wrong handling this click — the decision was not applied.");
+  }
+}

package/agent/approvals/discord-scope-label.ts

@@ -0,0 +1,27 @@
+// The Discord scope-label resolver — EXTRACTED from core approvals/scope-label.ts (OPE-114 stage 4).
+// Friendly DISPLAY labels for an approval-card scope key, registered via registerScopeLabelResolver
+// from registerDiscordProvider(). DISPLAY ONLY, never an access/execution input; fail-open (any
+// lookup failure → undefined ⇒ the card renders the raw key). Uses the shared discord-channel-info
+// `GET /channels|guilds/{id}` fetch (moved into this bundle).
+//
+//   discord/<guild>            → `the <guild name> server`
+//   discord/<guild>/<channel>  → `#<channel name>`
+//   discord/<guild>/<thread>   → `#<parent name> · thread "<thread name>"` (anchor on the parent —
+//     an auto-thread's name is derived from the triggering message, gibberish as a scope label).
+
+import type { ScopeLabelResolver } from "@open-everywhere/core/agent/adapter-api.js";
+import { fetchDiscordInfo } from "../channels/discord-channel-info.js";
+
+export const discordScopeLabelResolver: ScopeLabelResolver = async ({ workspace, surface }) => {
+  if (surface) {
+    const info = await fetchDiscordInfo("channels", surface);
+    if (!info) return undefined;
+    if (info.parentId) {
+      const parent = await fetchDiscordInfo("channels", info.parentId);
+      if (parent?.name) return `#${parent.name} · thread "${info.name}"`;
+    }
+    return info.isThread ? `thread "${info.name}"` : `#${info.name}`;
+  }
+  const info = await fetchDiscordInfo("guilds", workspace);
+  return info?.name ? `the ${info.name} server` : undefined;
+};