@addozhang/dsh-discord 0.6.4-rc.2 → 0.6.4

package/README.md

@@ -20,7 +20,7 @@ No extra process: the adapter is a DSH plugin that mounts straight onto your `ds
 
 - **Mention-driven sessions** — an authorized `@bot <task>` in a bound channel anchors a thread (your message becomes the first post), creates the DSH session, and submits the prompt at most once. Follow-ups inside the thread queue without a mention. Attached images ride along: they are downloaded from the Discord CDN within strict size/host bounds and submitted as image parts for multimodal models.
 - **Stream rendering** — typing indicator, one head message edited in place, per-tool activity rows, fenced long-answer splitting, one-time finalize; the activity message is deleted when the turn ends.
-- **Approvals & questions** — DSH asks become buttons, select menus, and a free-text modal. Ownership is enforced (the asker — or the thread owner on later turns — clicks), expiry sweeps fail closed, and settled controls grey out in place.
+- **Approvals & questions (dual surface)** — DSH asks become buttons, select menus, and a free-text modal, mirrored to the web/desktop panel at the same time: the first surface to answer wins and the other auto-retires (Discord carries the ask alone when no web client is connected). Ownership is enforced (the asker — or the thread owner on later turns — clicks), expiry sweeps fail closed, and settled controls grey out in place.
 - **Session control** — `/steer`, `/stop`, and `/queue list|remove` with turn-ownership checks; `/project bind|list|info` and `/session resume` for guild↔workspace binding and history; `/guild forget` for operator cleanup.
 - **Model selection** — `/model show` reads the session's live model directory; `/model select` walks an interactive provider → model → reasoning cascade, or applies a typed `provider/model` directly. Open to any authorized member by default; restrictable to Host operators.
 - **Adapter status** — `/info` shows the adapter version, connection state, and project links (feedback, docs). Works in any channel.
@@ -40,11 +40,12 @@ Two channels ship in parallel, each pinned to the dsh host surface it was verifi
 
 | Channel | Adapter | dsh CLI | Install |
 |---|---|---|---|
-| **next (0.2.1 line)** | `>=0.6.1-rc.1` — npm `next` | `0.2.1-rc.2` — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord@next` |
-| **stable (0.1.7 line)** | `0.5.0` — npm `latest` | `0.1.7-rc.1` — exact version | `dsh plugin --profile web add @addozhang/dsh-discord` |
+| **stable (0.2.1 line)** | `0.6.4` — npm `latest` | `0.2.1-rc.3`+ — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord` |
+| **next (0.2.1 line)** | `>=0.6.1-rc.1` — npm `next` | `0.2.1-rc.3`+ — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord@next` |
+| Legacy (0.1.7 line) | `0.5.0` — exact version | `0.1.7-rc.1` — exact version | `dsh plugin --profile web add @addozhang/dsh-discord@0.5.0` |
 
 - **The rows do not mix.** Adapter `0.6.1+` carries runtime dependencies (`dsh-storage-domain`/`dsh-credentials`) pinned to the dsh `0.2.1` line — on any other host line the exact-version compatibility gate disables them (the storageDomain service never arrives and the plugin stays inactive); adapter `0.6.0-rc.1` is the `0.2.0-rc.2` pairing (both sides are exact-version installs now that the dist-tags moved to 0.2.1), and adapter `0.5.0` pins the `0.1.7` line symmetrically. Adapter `>=0.5.0-rc.4` (including `0.5.0`) speaks the 0.1.7 profile-backed settings forms and controller services and will not load on older hosts (the startup probe refuses with one actionable diagnostic); `0.5.0-rc.1`–`rc.3` target dsh `0.1.6-alpha`; adapter `0.4.x` talks to the former `apiProxy` surface, which `0.1.6-alpha` removed — it remains the pairing for the dsh `0.1.5` stable line, reachable by exact version (e.g. `@addozhang/dsh-discord@0.4.0`). A mismatched pair fails at startup.
-- To switch the dsh CLI line: `npm install -g @deepseek-ai/dsh@latest` (0.2.1-rc.2, pairs with adapter 0.6.1-rc.1) or `npm install -g @deepseek-ai/dsh@0.1.7-rc.1` (pairs with adapter 0.5.0).
+- To switch the dsh CLI line: `npm install -g @deepseek-ai/dsh@latest` (0.2.1-rc.x, pairs with adapter 0.6.1+) or `npm install -g @deepseek-ai/dsh@0.1.7-rc.1` (pairs with adapter 0.5.0).
 - Right after a `next` release, the `@next` spec can resolve to a stale cached version. If the installed copy looks old, install by exact version instead (e.g. `@addozhang/dsh-discord@0.5.0-rc.4`) and verify the `version` field inside the profile's `node_modules`.
 
 ## Install

package/README.zh.md

@@ -20,7 +20,7 @@
 
 - **@提及驱动会话** — 在已绑定的频道中，被授权的 `@机器人 <任务>` 会锚定一个线程（你的消息成为首帖）、创建 DSH 会话，并且至多提交一次。线程内的后续消息无需 @ 即可排队。消息附带的图片会一并送达：在严格的大小与主机白名单约束下从 Discord CDN 下载，并作为 image parts 提交给多模态模型。
 - **流式渲染** — typing 指示、单条头消息原地编辑、逐工具活动行、代码围栏感知的长文分段、一次性收尾；Turn 结束时活动消息会被删除。
-- **审批与提问** — DSH 的 ask 渲染为按钮、下拉菜单与自由文本弹窗。所有权强制校验（提问者——或后续 Turn 的线程属主——才能点击），超时清扫 fail-closed，结算后的控件原地置灰。
+- **审批与提问（双面）** — DSH 的 ask 渲染为按钮、下拉菜单与自由文本弹窗，并同时镜像到 web/桌面端：两端先答先得，另一端的控件与卡片自动失效（无 web 客户端时 Discord 单独承载）。所有权强制校验（提问者——或后续 Turn 的线程属主——才能点击），超时清扫 fail-closed，结算后的控件原地置灰。
 - **会话控制** — `/steer`、`/stop`、`/queue list|remove` 带运行所有权校验；`/project bind|list|info` 与 `/session resume` 管理 Guild↔工作区绑定与历史会话；`/guild forget` 供操作员清理。
 - **模型切换** — `/model show` 读取会话的实时模型目录；`/model select` 走交互式 provider → 模型 → 推理强度级联，也可直接填写 `provider/model` 应用。默认对所有授权成员开放，可收紧为仅 Host 操作员。
 - **适配器状态** — `/info` 显示适配器版本、连接状态与项目链接（反馈/文档）。任意频道可用。
@@ -40,11 +40,12 @@
 
 | 通道 | 适配器 | dsh CLI | 安装命令 |
 |---|---|---|---|
-| **next（0.2.1 线）** | `>=0.6.1-rc.1` — npm `next` | `0.2.1-rc.2` — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord@next` |
-| **stable（0.1.7 线）** | `0.5.0` — npm `latest` | `0.1.7-rc.1` — 精确版本号 | `dsh plugin --profile web add @addozhang/dsh-discord` |
+| **stable（0.2.1 线）** | `0.6.4` — npm `latest` | `0.2.1-rc.3`+ — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord` |
+| **next（0.2.1 线）** | `>=0.6.1-rc.1` — npm `next` | `0.2.1-rc.3`+ — npm `latest`/`next` | `dsh plugin --profile web add @addozhang/dsh-discord@next` |
+| 旧线（0.1.7） | `0.5.0` — 精确版本号 | `0.1.7-rc.1` — 精确版本号 | `dsh plugin --profile web add @addozhang/dsh-discord@0.5.0` |
 
 - **两行不可混搭。** 适配器 `0.6.1+` 携带的运行时依赖（`dsh-storage-domain`/`dsh-credentials`）钉在 dsh `0.2.1` 线——装到其它宿主线会被宿主的精确版本兼容门禁用（storageDomain 服务缺失，插件保持未激活）；适配器 `0.6.0-rc.1` 是 `0.2.0-rc.2` 的配对（dist-tags 已移到 0.2.1，两侧都只能精确版本号安装），适配器 `0.5.0` 同理反向钉在 `0.1.7` 线。适配器 `>=0.5.0-rc.4`（含 `0.5.0`）使用 0.1.7 的 profile-backed settings forms 与控制器服务，在更旧的宿主上无法加载（startup 探针会给出一条可操作的诊断后拒绝激活）；`0.5.0-rc.1`–`rc.3` 对应 dsh `0.1.6-alpha`；适配器 `0.4.x` 使用旧版 `apiProxy` 宿主面（该面已在 `0.1.6-alpha` 中移除）——它仍是 dsh `0.1.5` stable 线的配对，可用精确版本号安装（如 `@addozhang/dsh-discord@0.4.0`）。错配会在启动时失败。
-- 切换 dsh CLI 通道：`npm install -g @deepseek-ai/dsh@latest`（0.2.1-rc.2，配适配器 0.6.1-rc.1）或 `npm install -g @deepseek-ai/dsh@0.1.7-rc.1`（配适配器 0.5.0）。
+- 切换 dsh CLI 通道：`npm install -g @deepseek-ai/dsh@latest`（0.2.1-rc.x，配适配器 0.6.1+）或 `npm install -g @deepseek-ai/dsh@0.1.7-rc.1`（配适配器 0.5.0）。
 - `next` 刚发版后，`@next` 规格可能解析到过期的缓存版本。若装到的版本偏旧，请改用精确版本号安装（如 `@addozhang/dsh-discord@0.5.0-rc.4`），并核对 profile `node_modules` 中的 `version` 字段。
 
 ## 安装

package/lib/dsh/host-asks.d.ts

@@ -11,6 +11,14 @@
  * renders the ask through the adapter's ask-wiring (buttons, ownership,
  * expiry) and resolves with the user's answer; every other ask passes
  * through to the original path (the web UI keeps working unchanged).
+ *
+ * Dual surface (16.105, 2026-10-30): a claimed ask is ALSO forwarded to
+ * the original entry under a relayed abort signal, so a connected web
+ * client renders the same card. The two surfaces race and the first
+ * decisive answer wins: a web answer settles the claimed ask and retires
+ * the Discord controls; a Discord answer aborts the relay and the web wait
+ * closes. The pre-binding passthrough direction stays single-surface (the
+ * 2026-10-26 decision on issue #11 — status quo).
  */
 /** Narrow approval-request shape the service receives. */
 export interface HostApprovalRequest {
@@ -68,6 +76,18 @@ export interface HostAskDeps {
             questions: ReadonlyArray<Record<string, unknown>>;
         }): void;
         disableControl(key: string): Promise<void>;
+        /** Record a web-surface resolution and retire the Discord controls. */
+        onApprovalResolved(input: {
+            sessionId: string;
+            approvalId: string;
+            outcome?: string | undefined;
+        }): void;
+        /** Record a web-surface resolution and retire the Discord controls. */
+        onQuestionResolved(input: {
+            sessionId: string;
+            questionRpcId: string;
+            outcome: 'answered' | 'cancelled';
+        }): void;
     };
     approvalTimeoutMs(): number;
     questionTimeoutMs(): number;

package/lib/dsh/host-asks.js

@@ -11,6 +11,14 @@
  * renders the ask through the adapter's ask-wiring (buttons, ownership,
  * expiry) and resolves with the user's answer; every other ask passes
  * through to the original path (the web UI keeps working unchanged).
+ *
+ * Dual surface (16.105, 2026-10-30): a claimed ask is ALSO forwarded to
+ * the original entry under a relayed abort signal, so a connected web
+ * client renders the same card. The two surfaces race and the first
+ * decisive answer wins: a web answer settles the claimed ask and retires
+ * the Discord controls; a Discord answer aborts the relay and the web wait
+ * closes. The pre-binding passthrough direction stays single-surface (the
+ * 2026-10-26 decision on issue #11 — status quo).
  */
 /** One claimed ask: a settle promise raced against the ask's abort signal. */
 class PendingAsk {
@@ -48,6 +56,36 @@ class PendingAsk {
         this.cancel();
     }
 }
+/**
+ * Relays the host's abort signal into an owned controller so the losing
+ * ask surface's wait can be closed independently: the web leg receives
+ * `relay.signal` instead of the host's own signal, and a Discord answer
+ * aborts it to settle the web card without touching the host's signal.
+ */
+class SignalRelay {
+    controller = new AbortController();
+    constructor(source) {
+        if (source === undefined)
+            return;
+        if (source.aborted) {
+            this.controller.abort(source.reason);
+            return;
+        }
+        source.addEventListener('abort', () => { this.controller.abort(source.reason); }, { once: true });
+    }
+    get signal() {
+        return this.controller.signal;
+    }
+    /** Close the relayed wait (a no-op when the source signal already did). */
+    abort(reason) {
+        this.controller.abort(reason);
+    }
+}
+/** The question waterfall's "no connected answerer" rejection shape. */
+function isNoProvider(cause) {
+    return typeof cause === 'object' && cause !== null
+        && cause.code === 'NO_PROVIDER';
+}
 /**
  * Wrap both ask services. Thread-bound sessions get the Discord ask flow;
  * everything else passes through untouched. Returns the settle ports the
@@ -57,6 +95,8 @@ class PendingAsk {
 export function installAskServicePatches(approval, questions, deps) {
     const pendingApprovals = new Map();
     const pendingQuestions = new Map();
+    /** Live web-surface waits for claimed asks, keyed by ask id. */
+    const webRelays = new Map();
     // Capture the current entries (own or prototype) before patching; dispose
     // restores exactly these.
     const originalRequest = approval.request.bind(approval);
@@ -73,6 +113,11 @@ export function installAskServicePatches(approval, questions, deps) {
             if (questions !== undefined && originalAsk !== undefined) {
                 questions.ask = originalAsk;
             }
+            // Close every live web wait before cancelling the Discord surface:
+            // the relayed abort lets the original entries settle their cards.
+            for (const [, relay] of [...webRelays])
+                relay.abort();
+            webRelays.clear();
             for (const [, pending] of [...pendingApprovals])
                 pending.dispose();
             pendingApprovals.clear();
@@ -105,9 +150,40 @@ export function installAskServicePatches(approval, questions, deps) {
         });
         const pending = new PendingAsk(pendingApprovals, approvalId, req.signal, () => 'cancelled');
         pendingApprovals.set(approvalId, pending);
+        // Dual surface (16.105): the web surface races the Discord buttons
+        // through the original entry under a relayed signal. The first
+        // decisive outcome wins; 'unavailable' (no connected answerer, or an
+        // answerer failure the host normalizes fail-closed) and 'cancelled'
+        // (an abort racing the decision) never decide for the user.
+        const relay = new SignalRelay(req.signal);
+        webRelays.set(approvalId, relay);
+        void Promise.resolve()
+            .then(() => originalRequest({ ...req, signal: relay.signal }))
+            .then(outcome => {
+            if (outcome !== 'allowed-once' && outcome !== 'rejected') {
+                deps.log('discord_ask_dual_web_ignored', { kind: 'approval', approvalId, outcome });
+                return;
+            }
+            if (!pending.resolve(outcome))
+                return;
+            deps.log('discord_ask_dual_web_won', { kind: 'approval', approvalId, outcome });
+            deps.askWiring.onApprovalResolved({ sessionId, approvalId, outcome });
+        })
+            .catch((cause) => {
+            // The real entry normalizes answerer failures to 'unavailable';
+            // a rejection here means the relay closed the wait (the Discord
+            // surface won) or the host aborted — both already settled.
+            if (relay.signal.aborted)
+                return;
+            deps.log('discord_ask_dual_web_failed', { kind: 'approval', approvalId, cause: String(cause) });
+        });
         if (req.signal?.aborted === true)
             pending.dispose();
         void pending.promise.then(() => {
+            webRelays.delete(approvalId);
+            // Close the web wait when the Discord surface settled first (a
+            // no-op when the web answer already won or the host aborted).
+            relay.abort();
             deps.onWaitState?.(threadId, false);
             void deps.askWiring.disableControl(approvalId).catch((cause) => {
                 deps.log('discord_ask_control_disable_failed', { key: approvalId, cause: String(cause) });
@@ -144,9 +220,36 @@ export function installAskServicePatches(approval, questions, deps) {
             const cancelledAnswer = { answers: [] };
             const pending = new PendingAsk(pendingQuestions, rpcId, req.signal, () => cancelledAnswer);
             pendingQuestions.set(rpcId, pending);
+            // Dual surface (16.105): mirror the batch to the web surface under
+            // the relayed signal; the first complete answer batch wins.
+            const relay = new SignalRelay(req.signal);
+            webRelays.set(rpcId, relay);
+            void Promise.resolve()
+                .then(() => originalAsk({ ...req, signal: relay.signal }))
+                .then(answer => {
+                if (!pending.resolve(answer))
+                    return;
+                deps.log('discord_ask_dual_web_won', { kind: 'question', rpcId });
+                deps.askWiring.onQuestionResolved({ sessionId, questionRpcId: rpcId, outcome: 'answered' });
+            })
+                .catch((cause) => {
+                // NO_PROVIDER = no connected web client: the Discord surface
+                // carries the ask alone (the pre-dual-surface behavior).
+                if (isNoProvider(cause)) {
+                    deps.log('discord_ask_dual_web_absent', { kind: 'question', rpcId });
+                    return;
+                }
+                if (relay.signal.aborted)
+                    return;
+                deps.log('discord_ask_dual_web_failed', { kind: 'question', rpcId, cause: String(cause) });
+            });
             if (req.signal?.aborted === true)
                 pending.dispose();
             void pending.promise.then(() => {
+                webRelays.delete(rpcId);
+                // Close the web wait when the Discord surface settled first (a
+                // no-op when the web answer already won or the host aborted).
+                relay.abort();
                 deps.onWaitState?.(threadId, false);
                 void deps.askWiring.disableControl(rpcId).catch((cause) => {
                     deps.log('discord_ask_control_disable_failed', { key: rpcId, cause: String(cause) });

package/lib/features/reconcile-bindings.d.ts

@@ -73,3 +73,32 @@ export interface BindingReconciliationPlan {
 }
 /** Plan one reconciliation pass. Pure: callers decide how actions are applied. */
 export declare function planBindingReconciliation(input: BindingReconciliationInput): BindingReconciliationPlan;
+/**
+ * One direct channel probe for a thread binding the guild's active-thread
+ * listing did not account for (16.104). The shapes mirror the REST client's
+ * outcome vocabulary; `completed` needs no body — existence is the verdict.
+ */
+export type ThreadChannelProbeOutcome = {
+    outcome: 'completed';
+} | {
+    outcome: 'rejected';
+    status: number;
+} | {
+    outcome: 'unknown';
+};
+export type ThreadChannelProbe = (threadId: string) => Promise<ThreadChannelProbeOutcome>;
+/**
+ * Refine facts for thread bindings absent from `/guilds/{id}/threads/active`.
+ * That listing drops both deleted threads and Discord-archived ones, so
+ * absence alone proves nothing (the pre-16.104 planner kept such threads
+ * forever — deleting a bound channel orphans every thread binding under it,
+ * permanently excluding those sessions from `/session resume`). One
+ * `GET /channels/{threadId}` each settles it: 200 → `ok` (alive, including
+ * Discord-archived — the thread remains the binding's live surface and a
+ * post un-archives it), 404 → `missing` (verified deletion → retire),
+ * anything else → `unknown` (keep-blocked, exactly the inconclusive
+ * posture the reconciliation spec mandates). Probes run sequentially; a
+ * retired binding leaves the table, so the probe set only ever shrinks to
+ * the genuinely alive or persistently unreachable.
+ */
+export declare function refineUnlistedThreadFacts(threadIds: readonly string[], probe: ThreadChannelProbe): Promise<Record<string, 'ok' | 'missing' | 'unknown'>>;

package/lib/features/reconcile-bindings.js

@@ -52,3 +52,30 @@ export function planBindingReconciliation(input) {
     });
     return { channelActions, threadActions };
 }
+/**
+ * Refine facts for thread bindings absent from `/guilds/{id}/threads/active`.
+ * That listing drops both deleted threads and Discord-archived ones, so
+ * absence alone proves nothing (the pre-16.104 planner kept such threads
+ * forever — deleting a bound channel orphans every thread binding under it,
+ * permanently excluding those sessions from `/session resume`). One
+ * `GET /channels/{threadId}` each settles it: 200 → `ok` (alive, including
+ * Discord-archived — the thread remains the binding's live surface and a
+ * post un-archives it), 404 → `missing` (verified deletion → retire),
+ * anything else → `unknown` (keep-blocked, exactly the inconclusive
+ * posture the reconciliation spec mandates). Probes run sequentially; a
+ * retired binding leaves the table, so the probe set only ever shrinks to
+ * the genuinely alive or persistently unreachable.
+ */
+export async function refineUnlistedThreadFacts(threadIds, probe) {
+    const facts = {};
+    for (const threadId of threadIds) {
+        const probed = await probe(threadId);
+        if (probed.outcome === 'completed')
+            facts[threadId] = 'ok';
+        else if (probed.outcome === 'rejected' && probed.status === 404)
+            facts[threadId] = 'missing';
+        else
+            facts[threadId] = 'unknown';
+    }
+    return facts;
+}

package/lib/index.js

@@ -21,7 +21,7 @@ import { handleSelectInput, handleModalSubmit } from './features/question-routin
 import { createCopy, permissionPresetLabel } from './i18n.js';
 import { createInteractionRouter } from './features/interaction-router.js';
 import { channelBindingKey, parseChannelBindingKey, threadBindingKey, parseThreadBindingKey, discordDomainSpec, CHANNEL_BINDINGS_TABLE, THREAD_BINDINGS_TABLE, INTENTS_TABLE } from './state/domain.js';
-import { planBindingReconciliation } from './features/reconcile-bindings.js';
+import { planBindingReconciliation, refineUnlistedThreadFacts } from './features/reconcile-bindings.js';
 import { guildKeysToForget, sweepExpired } from './state/retention.js';
 import { staleUncertainIntents } from './features/reconcile-intents.js';
 import { createHostEventRouter } from './dsh/host-events.js';
@@ -673,6 +673,28 @@ export function apply(ctx, config = DEFAULT_DISCORD_SETTINGS) {
                             if (facts[channelId] === undefined)
                                 facts[channelId] = 'missing';
                         }
+                        // The active-thread listing drops Discord-archived threads too,
+                        // so an unlisted thread binding is *absent evidence*, not
+                        // deletion — one direct channel probe each settles it (16.104):
+                        // 404 retires the orphan (deleting a bound channel kills every
+                        // thread under it), 200 keeps it (archived threads are still the
+                        // binding's live surface), anything else stays unverified.
+                        const unlistedThreads = [...threadKeyById.keys()].filter(threadId => facts[threadId] === undefined);
+                        if (unlistedThreads.length > 0) {
+                            const refined = await refineUnlistedThreadFacts(unlistedThreads, async (threadId) => {
+                                const probed = await rest.request('GET', `/channels/${threadId}`);
+                                rpcLog('discord_reconcile_thread_probe', {
+                                    threadId,
+                                    outcome: probed.outcome === 'rejected' ? `http-${String(probed.status)}` : probed.outcome,
+                                });
+                                if (probed.outcome === 'completed')
+                                    return { outcome: 'completed' };
+                                if (probed.outcome === 'rejected')
+                                    return { outcome: 'rejected', status: probed.status };
+                                return { outcome: 'unknown' };
+                            });
+                            Object.assign(facts, refined);
+                        }
                     }
                     // Default surface (16.34/16.37): the adapter's category and the
                     // general control channel are ensured on every READY. Bound home

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@addozhang/dsh-discord",
-  "version": "0.6.4-rc.2",
+  "version": "0.6.4",
   "description": "Discord adapter for DeepSeek Harness · DeepSeek Harness 的 Discord 适配器",
   "license": "MIT",
   "type": "module",