@open-everywhere/provider-discord 0.1.0

package/agent/channels/discord-post-arm.ts

@@ -0,0 +1,230 @@
+// discord-post-arm — Discord's POST arm for the post-arms registry (OPE-114 stage 1c). Absorbs,
+// VERBATIM, Discord's arms out of the three reply/delivery spines: reply-post.ts (resolveReplyTarget's
+// discord case + dispatchReply's POST-messages branch + the discord splitForDiscord chunking used by
+// postTerminalProse), unified-reply.ts (liveDiscordPost, incl. the auto-thread restore + engage), and
+// unified-redrive.ts (the discord describe/container cases). The write seam is discord-post.ts (the
+// same one the reply tools use — deliberately NOT the gateway module).
+
+import {
+  DISCORD_MESSAGE_MAX,
+  discordAddReaction,
+  discordEditMessage,
+  discordExistingThreadForMessage,
+  discordOpenDmChannel,
+  discordPostMessage,
+  discordPostMessageWithButtons,
+  discordThreadForMessage,
+  splitForDiscord,
+} from "./discord-post.js";
+import {
+  bindFrom,
+  markThreadEngaged,
+  deploymentOrg,
+  recordOwnPost,
+  type PostArm,
+  type TargetResolveBag,
+  type ReplyTarget,
+  type ReactTarget,
+  type UnifiedWakeOrigin,
+  type UnifiedReplyDeps,
+  type EditLocus,
+  type DirectMessageRequest,
+  type DirectMessageDelivery,
+  type DirectMessageAction,
+} from "@open-everywhere/core/agent/adapter-api.js";
+
+type DiscordTarget = Extract<ReplyTarget, { platform: "discord" }>;
+type DiscordOrigin = Extract<UnifiedWakeOrigin, { platform: "discord" }>;
+type DiscordReactTarget = Extract<ReactTarget, { platform: "discord" }>;
+
+/** UNIFIED: POST /channels/{id}/messages under the bot token. The target channelId is the frozen wake
+ *  origin's (host-side, never model-authored); a thread IS its own channel id so a threaded trigger
+ *  replies into its thread. The FIRST chunk anchors to the triggering message via message_reference
+ *  (fail-soft when the trigger was deleted); Discord caps a message at 2000 chars, so a long reply
+ *  splits and posts in order. Errors re-wrapped token-free (defensive parity with the other arms —
+ *  discordPostMessage's own errors are already clean, but never risk echoing a transport body).
+ *  Auto-thread restore (origin.autoThreadName ⇔ an addressed mention in a base channel): open the
+ *  thread off the mention and answer there — the native path's UX the divert skips.
+ *  discordThreadForMessage is idempotent (finds an existing thread) and fail-open (null ⇒ today's
+ *  in-channel reply, anchored to the mention via message_reference). */
+async function liveDiscordPost(origin: DiscordOrigin, text: string): Promise<string> {
+  let targetChannelId = origin.channelId;
+  let anchorToMessage = origin.messageId;
+  // The auto-thread branch is GUILD-ONLY, and now says so structurally. `!("dm" in origin)` narrows
+  // to the guild variant so `origin.guildId` type-checks below (OPE-315) — no behavioural change:
+  // the DM variant cannot carry `autoThreadName` in the first place (the type forbids it and the
+  // validator refuses it, D4), precisely because the engagement row this branch writes is keyed on
+  // the guild. The narrowing makes that unrepresentable rather than merely unreached.
+  if (!("dm" in origin) && origin.autoThreadName && origin.messageId) {
+    const threadId = await discordThreadForMessage(origin.channelId, origin.messageId, origin.autoThreadName);
+    if (threadId) {
+      targetChannelId = threadId;
+      anchorToMessage = undefined; // the thread already hangs off the mention — no reference needed
+      // ENGAGE the thread we just opened — the native path engages at dispatch, but this thread
+      // only exists NOW, so the divert path must enroll it here or non-mention follow-ups inside
+      // it are dropped at the wake gate (live-found 2026-07-19: J-DISC's continuity leg — the
+      // reply landed, then "expand that..." produced zero audit rows). The partition mirrors what
+      // the gate resolves for a message ARRIVING in the thread (workspace=guild, surface=thread id,
+      // key=thread channel id — engagementKey). markThreadEngaged is best-effort/never throws, and
+      // a later "stop" disengages normally: nothing re-engages until OE next replies here.
+      const workspaceKey = `discord/${origin.guildId}`;
+      const surfaceKey = `${workspaceKey}/${threadId}`;
+      await markThreadEngaged(
+        { org: deploymentOrg(), platform: "discord", workspace: origin.guildId, surface: threadId, workspaceKey, surfaceKey, key: surfaceKey },
+        threadId,
+        new Date().toISOString(),
+        { participating: true },
+      );
+    }
+  }
+  let first: string | undefined;
+  try {
+    for (const chunk of splitForDiscord(text)) {
+      if (!chunk.trim()) continue; // never post an invisible empty message
+      const id = await discordPostMessage(targetChannelId, chunk, first === undefined && anchorToMessage ? { replyToMessageId: anchorToMessage } : undefined);
+      first ??= id;
+    }
+  } catch {
+    throw new Error(`unified reply couldn't post to Discord — create-message failed on channel ${targetChannelId}`);
+  }
+  if (first === undefined) {
+    throw new Error(`unified reply couldn't post to Discord — nothing to post (empty reply) for channel ${origin.channelId}`);
+  }
+  // 🔴 OPE-793 — THE ONE PLACE AN ARM POSTS SOMEWHERE ITS SPINE CANNOT NAME. When the auto-thread
+  // branch above fires, this reply lands in a thread that did not exist when the wake origin was
+  // frozen, so the spine's own ledger write records `origin.channelId` — the BASE channel — and an
+  // `edit_reply` addressed at the thread would be refused as not-ours. Recording the real channel
+  // here closes that, and only that: the id is one this call just posted, at the locus it posted to.
+  // Best-effort by construction (recordOwnPost never throws); a lost row costs an edit, never a post.
+  if (targetChannelId !== origin.channelId) {
+    await recordOwnPost(deploymentOrg(), { platform: "discord", channelId: targetChannelId }, first);
+  }
+  return first;
+}
+
+/**
+ * UNIFIED, WITH A COMPONENT PLANE (OPE-1720): the same single-window post as {@link liveDiscordPost},
+ * carrying a row of tappable actions under it. Discord is the SECOND surface to implement this
+ * member, and it may only do so because the tap lands: `discord-front.ts` classifies the `oe_input:`
+ * custom_id and `discord-approval-card.ts` settles it.
+ *
+ * 🔴 NO AUTO-THREAD BRANCH, DELIBERATELY. `liveDiscordPost` may open a thread off the mention and
+ * answer there. A governed approval card must not move: the people who can answer it are watching the
+ * conversation it was asked in, and burying the buttons in a freshly-created thread is how a card
+ * goes unanswered. The anchor still rides — the card hangs under the triggering message through the
+ * same `message_reference` a plain reply uses — so it is placed and never moved.
+ *
+ * 🔴 IT FALLS BACK TO TEXT RATHER THAN SPLITTING. Discord caps a message at 2000 characters and a
+ * button row cannot be split across messages: a row attached to the wrong part would sit under a
+ * fragment. So an over-cap card posts through the ordinary splitting path and loses the SHORTCUT,
+ * never the meaning — `DirectMessageAction`'s own rule, which the question bridge's text already
+ * satisfies (it prints the prompt, the options, and the line saying a reply may name one).
+ */
+async function liveDiscordPostWithActions(origin: DiscordOrigin, text: string, actions: readonly DirectMessageAction[]): Promise<string> {
+  const buttons = actions.map((a) => ({ customId: a.id, label: a.label, intent: a.intent }));
+  if (buttons.length === 0 || text.length > DISCORD_MESSAGE_MAX) return liveDiscordPost(origin, text);
+  try {
+    return await discordPostMessageWithButtons(origin.channelId, text, buttons, origin.messageId ? { replyToMessageId: origin.messageId } : undefined);
+  } catch {
+    throw new Error(`unified reply couldn't post to Discord — create-message with buttons failed on channel ${origin.channelId}`);
+  }
+}
+
+/** EDIT (OPE-793): `PATCH /channels/{id}/messages/{mid}` through the same write seam the post path
+ *  uses. Ownership was already decided upstream against the own-post ledger; this is transport only. */
+async function editDiscordMessage(locus: EditLocus, messageId: string, text: string): Promise<void> {
+  await discordEditMessage(locus.channelId, messageId, text);
+}
+
+/** EDIT ADDRESS (OPE-798): the other half of the auto-thread branch in {@link liveDiscordPost}.
+ *
+ *  When that branch fires the reply lands in a thread — and a Discord thread IS its own channel —
+ *  while the frozen wake origin still names the BASE channel. The arm already records an own-post
+ *  ledger row on the thread so the fence passes; without this the PATCH still went to the base
+ *  channel and Discord answered 404 (measured live, deploy #89). Here the edit path resolves the
+ *  SAME thread the post path used, so the ledger read and the PATCH address one conversation.
+ *
+ *  🔴 READ-ONLY: `discordExistingThreadForMessage`, never `discordThreadForMessage`. The post path
+ *  may CREATE the thread; the edit path may not. A create at edit time would open a new empty thread
+ *  — a visible message in the room, and still a 404 for a message that is not in it.
+ *
+ *  Fail-soft to the base locus on every unknown: a DM origin, a wake with no auto-thread name, a
+ *  message with no thread, an API failure. That degrades to today's behaviour, which is correct for
+ *  a reply that genuinely went to the base channel. */
+async function retargetDiscordEditLocus(origin: UnifiedWakeOrigin, locus: EditLocus): Promise<EditLocus> {
+  const o = origin as DiscordOrigin;
+  if ("dm" in o || !o.autoThreadName || !o.messageId) return locus;
+  const threadId = await discordExistingThreadForMessage(o.channelId, o.messageId);
+  return threadId ? { ...locus, channelId: threadId } : locus;
+}
+
+/**
+ * DM (OPE-623): open the 1:1 conversation with a Discord user and post there. The SECOND provider to
+ * implement this member — Slack was the only one, and several core behaviours read the registry
+ * rather than a platform list precisely so that they tighten the day a second arm appears:
+ *
+ *   • `link_identity` can now offer the DIRECTORY transport on Discord (it needs a directory arm AND
+ *     a DM arm; channels/discord-directory.ts is the other half).
+ *   • `claimVenueRefusal` (core identity/link-flow.ts) now REFUSES a `link <code>` claim typed in a
+ *     Discord channel and points the person at the DM. A code is a bearer secret for its whole TTL,
+ *     so it must not be posted where a room can read it. That is a deliberate tightening, not a
+ *     regression: it only arms where a private door exists.
+ *   • link-set change notices (`notifyLinkSetMembers`) and the governance DM-delivery venue
+ *     (core access/pane-venue.ts) reach Discord accounts instead of skipping them.
+ *
+ * The caller names WHO, never WHERE — opening the conversation is this arm's business. `text` goes
+ * through the same 2000-char splitter every other Discord post uses, so a long notice arrives whole
+ * rather than 400-ing; the FIRST part's id is the returned anchor.
+ */
+async function deliverDiscordDirectMessage(input: DirectMessageRequest): Promise<DirectMessageDelivery> {
+  const surfaceId = await discordOpenDmChannel(input.principalId);
+  // BUTTONS (OPE-622): Discord has a component plane, so a caller's `actions` render as a row under
+  // the text and a tap comes back to the interactions endpoint (channels/discord-front.ts). The
+  // button path cannot split an over-cap message, so a long text falls back to the plain splitting
+  // post rather than failing — the caller's copy always stands on its own without a button.
+  const buttons = (input.actions ?? []).map((a) => ({ customId: a.id, label: a.label, intent: a.intent }));
+  if (buttons.length > 0 && input.text.length <= DISCORD_MESSAGE_MAX) {
+    return { surfaceId, messageId: await discordPostMessageWithButtons(surfaceId, input.text, buttons) };
+  }
+  const messageId = await discordPostMessage(surfaceId, input.text);
+  return { surfaceId, messageId };
+}
+
+export const discordPostArm: PostArm = {
+  platform: "discord",
+  resolveTarget: (bag: TargetResolveBag): ReplyTarget | null => {
+    // On Discord the surface channel already IS the thread — no separate thread ts.
+    const channelId = bag.str("channelId");
+    return channelId ? { platform: "discord", channelId } : null;
+  },
+  dispatchReply: (target, text) => discordPostMessage((target as DiscordTarget).channelId, text),
+  dispatchUnified: (origin, text, deps: UnifiedReplyDeps) => (deps.postDiscord ?? liveDiscordPost)(origin as DiscordOrigin, text),
+  // OPE-1720: Discord declares the unified component plane because the tap route exists on it —
+  // `discord-front.ts` classifies the `oe_input:` custom_id and `discord-approval-card.ts` settles
+  // it. The injected `postDiscord` override is honoured VERBATIM and drops the buttons: a test that
+  // scripted a text-only post must not start receiving a card it never asked for.
+  dispatchUnifiedActions: (origin, text, actions, deps: UnifiedReplyDeps) =>
+    deps.postDiscord ? deps.postDiscord(origin as DiscordOrigin, text) : liveDiscordPostWithActions(origin as DiscordOrigin, text, actions),
+  describeRedriveTarget: (origin) => `discord channel ${(origin as DiscordOrigin).channelId}`,
+  redriveContainerId: (origin) => (origin as DiscordOrigin).channelId,
+  editMessage: editDiscordMessage,
+  retargetEditLocus: retargetDiscordEditLocus,
+  deliverDirectMessage: deliverDiscordDirectMessage,
+  // REACT (OPE-987): the message-level (channelId, messageId) pair `setReaction` already takes for
+  // the host-placed ✋ glyph — closer to Slack's per-message granularity than to GitHub/Linear's
+  // conversation-anchor one (post-arms.ts `ReactTarget`'s header explains why the union carries both
+  // shapes). `channelId` comes off the binding's post-back target, same as `resolveTarget` above;
+  // `messageId` is NOT on that target (Discord threads reuse `channelId` for their own identity, so
+  // the triggering message rides its own `anchorMessageId` field — identity/binding.ts, OPE-671) —
+  // read via `bindFrom(bag.ctx)` rather than widening the bag's target shape for one extra field.
+  resolveReactTarget: (bag: TargetResolveBag): ReactTarget | null => {
+    const channelId = bag.str("channelId");
+    if (!channelId) return null;
+    const messageId = bindFrom(bag.ctx).anchorMessageId;
+    return messageId ? { platform: "discord", channelId, messageId } : null;
+  },
+  react: (target, emoji) => {
+    const t = target as DiscordReactTarget;
+    return discordAddReaction(t.channelId, t.messageId, emoji);
+  },
+};