MailUI4Agents

Files

pi f0884d03be fix(pi-bridge): 决策到了没唤醒等待者 —— 整条授权链断掉（用户报「授权机制有问题」）

现场（用户：「我发现授权机制有问题，你看看 webui4frpc 的那个 session」）：
同一条会话一天被问 6 次「是否允许执行 bash？」，**每次人都在 8 秒内点了同意**，
而每一轮都恰好烧满 10 分钟（TURN_TIMEOUT_MS），回信只有一句 59 字的开场白。
该 agent 自己的会话转录里写着：**"The bash tool keeps returning 'No result provided'"**。

根因：`worker.mjs` 的 `permission_decision` 分支取出了等待者、删了表项、存了备注，
**却没有调用 `resolve`**：

    const resolve = pending.get(msg.relayKey);
    if (!resolve) return;
    pending.delete(msg.relayKey);
    decidedExtra.set(msg.relayKey, { ... });
    return;                       // ← 等的人永远醒不过来

于是一条命令走完下面这一整圈：
  ① 工具调用挂着不动 → 一轮跑到 10 分钟 TURN_TIMEOUT_MS 才结束；
  ② 桥把模型那半句开场白当「本轮总结」发回（59 字）；
  ③ 会话里留下**没有 toolResult 的 toolCall** → 下一轮 pi SDK 给它补一条
     `isError: true` 的「No result provided」→ 模型重试 bash → 人又被问一遍。

为什么之前全绿：`permission-note.test.mjs` 的 WIRING 钉的是
`decidedExtra.set(msg.relayKey)`（**备注＝装饰**）与 `renderDecisionReason`，
**没有一条钉"唤醒"**。2026-09-13 那次修备注时把唤醒弄丢，判据照样全绿
—— 钉装饰不钉机制。

改：
- `resolve(msg.decision)` 补回，放在 `decidedExtra.set` **之后**（hook 醒来要读备注渲染
  拒绝理由，顺序反了会复现 2026-09-13 的「备注丢失 → 模型重复追问」）
- 判据：WIRING 补一条「必须唤醒」；另加 `checkDecisionBranch` **按标记切出决策分支正文**
  判"存在 + 归属 + 顺序"（不用"相距 N 字符"的窗口断言 —— 第一版就是那样假红的）
- 三种反面写法做变异自检：删掉 resolve / resolve 早于备注 / resolve 挪出分支，都必须红
- 全套 445 条通过

跨端核对：dsh 桥的 `pendingApprovals` 有 `pending.resolve(outcome)`（没这个问题）；
opencode 走原生 permission 回复、zcode 走事件钩子 —— 这条路径只有 pi 桥有。

2026-09-14 19:16:22 +08:00

addressing.test.mjs

feat: agent 邮件寻址能力全面补齐 + .new 别名替换

2026-09-03 12:09:12 +08:00

adopt.test.mjs

feat(adopt): 邮件可投进平台上已存在的会话（TUI 与邮箱同一入口）

2026-09-04 11:14:44 +08:00

attachment-ids.test.mjs

fix(plugins): 附件 id 归一 —— 修 opencode「做完全部活却发不出附件」

2026-09-12 11:20:13 +08:00

bounded.test.mjs

feat: L0 线协议冻结 + 附件链路修复 + 人/Agent 区分