fix(inbox): 收件箱按**工作区**收窄（三维地址的 path 位此前从未被使用）

用户 12 天前就提过（`552fbc7` 只修了 session_id 那一维），这轮才真修。用户原话：「难道让一个不在项目工作区的 agentsession 去修工程吗？」 # 缺陷（生产实测，2026-09-26）在 `mc` 工作区干活的 pi 读收件箱拿到 **200 封，其中 191 封属于 `/home/program/agentmail`** —— 它照着那些信里的断言去改 agentmail 的代码，把手上的 mc 活丢在一边。用户当场问它「你怎么干着干着修 agentmail 去了？」（这条对话就在 mc 会话的 jsonl 里）根因：`ListInboxScoped` 的 WHERE 只有 `m.to_name = $1`（+ 可选 session_id）， **没有任何 workspace 条件**。三维地址 `name@path.session` 的 path 位在收件箱侧从未生效 —— 那不是"另一种语义"，是没兑现契约。 # 三条守卫全部只覆盖自动转发，防不住这个 | 守卫 | 只覆盖 | 为何无效 | | --- | --- | --- | | 会话预算 | `relay != ""` 才扣 | 这批信 relay=0（模型主动发）⇒ 不扣 | | maxRelayHops=5 | 同上，只数 relay | 同上 ⇒ 不进那个分支 | | 插件自动转发守卫 | 插件代劳时 | 日志明说"本轮不自动转发" ⇒ 模型自己发的不受管 | # 服务端 · `ListInboxScoped` / `CountUnreadScoped` / `MarkAllInboxReadForSession` 三处统一加 `s.workspace = $N`（用会话的 workspace，不用 mails.to_workspace：后者是信封字段、可能是抄送或历史遗留；"线索属于哪个工作区"是会话属性）。 ★ 三处必须是**同一个谓词** —— 列表看不到的信却被"全部标掉"标掉就是静默丢信（session_scope_test.go 记过这个形状）。 · **workspace 在 Agent 侧必需，缺了 400**（用户裁定：「不带 workspace 是错误发件格式，直接退回！」）。旧语义（不带=全部）正是缺陷本身，不留兼容回退。 · 人类侧**不过滤**（一个人跨工作区，WebUI 按 session_workspace 分组显示）—— 所以"必需"这条约束放在 Handler 而不是 repo 层：它是接口契约，不是数据层不变量。 · 新增 `UnreadWorkspaces`：心跳是**进程级**（一个桥服务所有工作区），没有 "我的工作区"可言；但只有总数桥不知道去哪个工作区补投 ⇒ 心跳回 `pending_workspaces` 清单，桥逐个消费。 · 决策载荷补 `workspace`（服务端知道 session→workspace，插件重启后推不出来）。 · `TouchAgentLastSeen` 从 HeartbeatAgent 拆出：middleware 在每个认证请求上都调它，而那时工作区还没解析（请求体没读），原来在白算一次 CountUnread。 # 三个插件（pi / opencode / dsh） · 读类工具带 `workspace`；补投从"读一次全局收件箱"改为**逐工作区**读。 · pi：worker 信封的 `to_workspace` 经闭包递进工具（不是会话文件 header 的 cwd —— 后者是"会话上次落在哪"，前者是"这封信寄到哪个工作区"）。 · opencode/dsh：插件常驻、信封在 deliverMail 那刻就消费掉了 ⇒ 新增 `sessionWorkspace` 映射（键与既有 reverseMap 同一把）。 · 修一处真 bug：`UnreadWorkspaces` 原先会返回相对路径工作区（历史库里有 `workspace='root'`），桥侧实测撞 400（`补投工作区 root 失败`）⇒ 只报可寻址的。 # 实测凭据 · 改前：`pi` 的收件箱 200 封混 3 个工作区（agentmail 191 / TrueAgent 7 / huawei 2） · 改后：agentmail=100（total 228）、mc=16、TrueAgent=7 —— 各工作区独立 · 不带 workspace ⇒ **HTTP 400**，话术给出可执行步骤 · 桥日志：`rw=/home/newqqagent/plugindev/editdoc-upgrade` —— 终于是别的工作区了（改前 78 次 worker 启动**全部**是 `/home/program/agentmail`） # 判据 · `server/internal/repo/workspace_scope_test.go`（3 条）：两向收窄 + **反向对照**（不带时两条都看得到 ⇒ 证明是收窄不是清空）+ 未读数同口径 + 相对路径必须报错 · `plugins/pi-mail-bridge/test/inbox-workspace-scope.test.mjs`（4 条）：接线 + 取信封而非 cwd + 补投逐工作区 + 判据自检 · dsh 那条 `取不到会话时退回整体收件箱` **改了**：它钉的"退回整体"正是缺陷，现在钉"两维各自缺席时各自不带、服务端 400 让错误可见" · 变异验证：服务端 2 处 + 插件 3 处，全部判红后恢复回绿全量：server `go test ./...` 绿；三插件 513+340+403 全绿。
2026-09-26 07:44:33 +08:00
parent b85f2b26f0
commit 7634be8966
22 changed files with 957 additions and 179 deletions
--- a/plugins/opencode-mail-bridge/index.js
+++ b/plugins/opencode-mail-bridge/index.js
@ -273,7 +273,16 @@ const readInboxTool = {
    const filter = args.filter || DEFAULT_INBOX_STATUS;
    const limit = args.limit || DEFAULT_INBOX_LIMIT;
    const mailSessionID = reverseMap.get(String(context?.sessionID ?? "")) || "";
-    const scope = mailSessionID ? `&session_id=${encodeURIComponent(mailSessionID)}` : "";
+    const workspace = sessionWorkspace.get(String(context?.sessionID ?? "")) || "";
+    /*
+      ★ 两维收窄都要带：
+        · session_id —— 只列**这条线索**的信（防"A 会话标掉 B 会话的未读"）
+        · workspace  —— 只列**这个工作区**的信（防"在 mc 干活却读到 agentmail 的信"）
+      服务端对缺 workspace 直接 400 —— 那是刻意的（旧语义正是缺陷本身）。
+      workspace 拿不到时**不带**，让服务端报 400：错误可见，好过静默跨工作区。
+    */
+    const scope = (mailSessionID ? `&session_id=${encodeURIComponent(mailSessionID)}` : "")
+      + (workspace ? `&workspace=${encodeURIComponent(workspace)}` : "");
    const data = await apiGet(`/mail/inbox?status=${filter}&limit=${limit}${scope}`);

    // 渲染与已读策略放 lib/inbox-format.js：它们与平台 SDK 无关，
@ -603,6 +612,28 @@ function startSSE(onEvent) {
 // 条目，而 GC 收不掉（还被强引用着）。
 const sessionMap = new BoundedMap(MAX_TRACKED_SESSIONS); // agentmail session_id -> opencode session id
 const reverseMap = new BoundedMap(MAX_TRACKED_SESSIONS); // opencode session id -> agentmail session_id（供 event 钩子回写命名）
+
+/*
+★ 2026-09-26：opencode session id -> **工作区**。
+
+# 为什么要这一张表
+
+收件箱接口现在要求 `workspace`（缺了 400），而 `read_inbox` 的 URL 是从
+`context.sessionID` 现场拼的 —— 那里只有 opencode 的会话 id，推不出工作区。
+
+# 与 pi 桥的差别（同一件事的两种做法）
+
+pi 的 worker 一个进程只服务一封邮件，信封就在手上（`data.to_workspace`），
+所以它直接把闭包传进工具。opencode 是**插件常驻、按会话分派**，
+信封在 `resolveSessionForMail` 那一刻消费掉了，到 `read_inbox` 时已经不在作用域里。
+⇒ 在这里留一份映射，键与 reverseMap 同一个（都是 opencode 的 session id）。
+
+# 用户报的缺陷（这一维此前完全没做）
+
+在 `mc` 工作区干活的会话读收件箱拿到 agentmail 的 191 封信，照着去改 agentmail
+的代码。三维地址 `name@path.session` 的 **path 位本来就该参与寻址**。
+*/
+const sessionWorkspace = new BoundedMap(MAX_TRACKED_SESSIONS); // opencode session id -> 工作区绝对路径
 const syncedTitles = new BoundedMap(MAX_TRACKED_SESSIONS); // opencode session id -> 已回写过的标题（去重，避免 session.updated 刷屏）

 // 权限询问的双向定位。
@ -666,6 +697,7 @@ async function resolveSessionForMail(client, directory, data, kind) {
    if (mailSessionID) {
      sessionMap.set(mailSessionID, adoptedID);
      reverseMap.set(adoptedID, mailSessionID);
+      if (wantDir) sessionWorkspace.set(adoptedID, wantDir);
      // 标记为邮件驱动：接管之后这条会话**开始**参与邮件往来，
      // 轮次结束要把总结转回发件人。不标记的话邮件投进去了却永远没有回音。
      mailDrivenSessions.add(adoptedID);
@ -706,6 +738,7 @@ async function resolveSessionForMail(client, directory, data, kind) {
  if (mailSessionID) {
    sessionMap.set(mailSessionID, sessionID);
    reverseMap.set(sessionID, mailSessionID);
+    if (wantDir) sessionWorkspace.set(sessionID, wantDir);
    mailDrivenSessions.add(sessionID);

    // slug 在创建时就有（如 nimble-lagoon），立即作为寻址别名回写；
@ -1186,28 +1219,46 @@ export default async function mailBridge(input) {
   * SSE 只推连上之后的事件，插件重启前发来的邮件不会再推一次。
   * 不补的话那封邮件永远躺在收件箱里，而发件人以为 Agent 收到了。
   */
-  async function catchUp(pending) {
+  async function catchUp(pending, workspaces) {
    if (!pending) return;
-    try {
-      const box = await apiGet("/mail/inbox?status=unread&limit=20");
-      const tasks = selectCatchup(box?.mails ?? box, deliveredMails);
-      if (tasks.length === 0) return;
-      console.error(`[mail-bridge] 补投 ${tasks.length} 封离线期间的邮件（共 ${pending} 封未读）`);
-      // 串行：每封都要起一轮模型，并发放出去等于对上游打 N 个并发请求
-      for (const ev of tasks) {
-        // 逐封再查一次：拉收件箱和逐封投递之间 SSE 可能已经投过其中某封
-        // （selectCatchup 只在拉完那一刻去过重）
-        if (deliveredMails.has(ev.mail_id)) continue;
-        deliveredMails.add(ev.mail_id);
-        try {
-          await deliverMail(client, directory, ev, "mail");
-        } catch (e) {
-          console.error(`[mail-bridge] 补投 ${ev.mail_id} 失败:`, e?.message || e);
-        }
-      }
-    } catch (e) {
-      console.error("[mail-bridge] 补投失败:", e?.message || e);
+    /*
+      ★ 逐工作区补投，不再读一次全局收件箱。
+
+      旧写法 `apiGet("/mail/inbox?status=unread&limit=20")` 不带任何收窄，
+      会把**所有工作区**的漏投一起重放 —— 在 mc 干活却被补投 agentmail 的信。
+      清单来自心跳的 `pending_workspaces`（心跳是进程级、没有"我的工作区"，
+      所以由它给清单，这里逐个消费）。
+    */
+    const list = Array.isArray(workspaces) ? workspaces : [];
+    if (!list.length) {
+      console.error(`[mail-bridge] 补投跳过：pending_mails=${pending} 但服务端未给出 pending_workspaces（旧版服务端？）`);
+      return;
    }
+    let delivered = 0;
+    for (const ws of list) {
+      try {
+        const box = await apiGet(`/mail/inbox?status=unread&limit=20&workspace=${encodeURIComponent(ws)}`);
+        const tasks = selectCatchup(box?.mails ?? box, deliveredMails);
+        if (tasks.length === 0) continue;
+        // 串行：每封都要起一轮模型，并发放出去等于对上游打 N 个并发请求
+        for (const ev of tasks) {
+          // 逐封再查一次：拉收件箱和逐封投递之间 SSE 可能已经投过其中某封
+          // （selectCatchup 只在拉完那一刻去过重）
+          if (deliveredMails.has(ev.mail_id)) continue;
+          deliveredMails.add(ev.mail_id);
+          try {
+            await deliverMail(client, directory, ev, "mail");
+            delivered += 1;
+          } catch (e) {
+            console.error(`[mail-bridge] 补投 ${ev.mail_id} 失败:`, e?.message || e);
+          }
+        }
+      } catch (e) {
+        // 单个工作区失败不影响其余（与"心跳失败不报错"同一原则）
+        console.error(`[mail-bridge] 补投工作区 ${ws} 失败（不影响其余）:`, e?.message || e);
+      }
+    }
+    if (delivered) console.error(`[mail-bridge] 补投 ${delivered} 封离线期间的邮件（共 ${pending} 封未读，跨 ${list.length} 个工作区）`);
  }

  let caughtUp = false;
@ -1232,7 +1283,7 @@ export default async function mailBridge(input) {
      // 每轮心跳都补的话会把「模型正在处理中、尚未标已读」的邮件重复投递。
      if (!caughtUp) {
        caughtUp = true;
-        await catchUp(res?.pending_mails);
+        await catchUp(res?.pending_mails, res?.pending_workspaces);
      }
    } catch {
      // 心跳失败不报错：网络抖动很常见，下一轮会补上。