81 Commits

Author	SHA1	Message	Date
JianFeeeee	d616582e96	fix: 回滚 user-question.js 那一搬（它把 check-shared-libs 打红两处），并把 drift 的非运行时差异摘出来 ... pi 逐处对文件后指出：我按"本平台不可达 ⇒ 搬去 test/lib/"把 `lib/user-question.js` 搬走，打红了 `deploy/check-shared-libs.sh` 两处（实测确认，脚本真退出码 1）： 共用模块缺失：plugins/pi-mail-bridge/lib/user-question.js 共用测试已分叉：test/user-question.test.mjs（opencode vs pi） 根因不是取舍而是口径：**`lib/` 上挂着两条方向相反的不变量** —— ① 共用模块四方逐字节同源（`check-shared-libs.sh`，连相对路径一起钉）； ② 本平台生产可达（我新加的规则）。而 `user-question.js` **是 dsh 桥的生产代码** （`plugins/dsh-mail-bridge/src/index.ts` 引用它）⇒ 两条必然冲突。 **`lib/` 首先是四桥共用命名空间，其次才是"本平台可达"**；可达性只能当**报告**， 不能当搬家判据。教训的形状：**一条新判据上线时，先找它可能与哪些既有不变量冲突** —— 我只看⻅了自己那条。 改动： - `user-question.js` 与它的测试回到 `lib/`、`test/`（路径也与 dsh 侧一致）， 两边逐字节相同已复验；`check-shared-libs.sh` 退出码 0。 - `reach.mjs` 增加 `sharedLibNames()`：直接从 `check-shared-libs.sh` 的 `ALL_LIBS` 读共用清单做豁免（不手抄常量），并把"进快照但本平台不可达"降级为**报告**。 - `layout-boundaries.test.mjs` 增加回归判据：共用模块必须留在 `lib/`、 测试相对路径与 dsh 一致、两侧逐字节相同。 - 删掉 `reach.mjs` / `docs/DEV-TOOLING.md` 里那句**无据的机制说明** （"user-question 走前缀动态 import"）：`localRefs` 的三条正则只认引号字面量， 对模板字面量形状是**盲的** ⇒ 那句若为真，搬走的就是生产代码而两条判据都会绿。 pi 读了 `src/` 下九个文件都找不到引用，我也确认是记忆偏差；理由改用 `addressing.js` （传递可达、`src` 直接引用数为 0）—— 它已足够证明"直接引用数不是可达性"。 顺带按 pi 的第二条建议：`deploy/check-deploy-drift.mjs` 判据 ① 把 **非运行时差异**摘出来（`jsonTestOnlyChange`，只豁免 `scripts.test` 一类字段， 只对"两边都在、仅内容不同"的文件生效）。理由：一条**永远黄、没人打算为它动手**的判据 唯一的下场是被学会忽略，那时真正的运行时漂移会被一起忽略。 ⚠️ 摘的条件很窄 —— **把运行时差异误判成非运行时比恒黄更坏（那是假绿）**， 所以 `main`/`start`/`dependencies` 变了、或解析不了，一律仍算运行时； 纯函数加了六个反/正样本的判据（含三个"必须算运行时"的）。 （该文件同时有另一条会话的改动，未提交、我未触碰；本次只加了我这一段。） 验证：`npm test` 463/463；`check-shared-libs.sh` 退出码 0；`--self-check` 18 条全过。	2026-09-14 20:11:58 +08:00
JianFeeeee	fb85a8728d	refactor(pi-bridge): 定下 lib/ 与 test/lib/ 的边界 —— 三个测试侧模块原来会随部署进 /opt ... pi 复核后指出：`lib/` 会被 `cp -a "$SRC/." "$STAGING/"` **整份打进生产快照** （排除清单只有 `test/`、`.git`、`node_modules/.cache`），而我们那三个测试侧模块 （`tmp-space.mjs`、`env-error.mjs`、`session-fixtures.mjs`）都住在 `lib/` 里。 后果不是几 KB，而是"漂移 N 处"这个数字**虚高**、哈希清单变长 —— 而"手抄哈希清单"正是我们刚定性为会过期的东西。 ## 规则写成**可判定的**，不写成约定 lib/ = 从生产入口可达的模块（会进快照） test/lib/ = 只被测试引用的模块（test/ 不部署、也不被注册进套件） `test/lib/reach.mjs` 真去走一遍 import 闭包（种子 = `src/index.mjs` + 源码里 `new URL('./x.mjs', import.meta.url)` 这类**按路径 fork 的子进程入口**）。 ★ 顺带纠正 pi 的规则表述：他写的是"被 `src/` import"，但实测 22 个 `lib/` 模块里 有 4 个 `src` **直接**引用数是 0 —— `addressing.js`（被 `lib/inbox-format.js` 引）、 `user-question.js`（走前缀动态 import）、`mail-session-id.js`、`crash-notify.mjs`。 **直接引用数不是可达性**，所以判据真走图而不是 grep。 ★ 也纠正他的排除清单名字：脚本里没有 `EXCLUDE_DIRS` 这个变量，就是一条 `rm -rf`。 ## 本规则多抓到一个 pi 没发现的 `lib/user-question.js` 也是**只被测试引用**（只有 `test/user-question.test.mjs` 用它） ⇒ 同样会进快照。已一并移到 `test/lib/`。剩下 `mail-session-id.js` 与 `crash-notify.mjs` 是**谁都不用**（生产与测试都不可达）—— 那是遗留物， 不动它们（不属本次范围），但记录在此。 ## 新增：因果**无关**的运行期判据 `test/lib/run-suite.mjs`：跑套件并从**同一次运行的 TAP**里数结果行，任何用例名 出现两次就红。为什么需要：静态那条（测试文件不许互相 import）只能发现**已知成因**。 实测跨文件重名**不会被 runner 拦**：两个文件各写一个同名用例 ⇒ `# tests 2 / # pass 2 / # fail 0`，两句 `ok`，零警告。 判据锚在 `^(ok|not ok) <n> - <名字>`（**结果行**），不是"名字出现过"—— pi 先前那条 `grep -c '<名字>'` 给 4 是因为 TAP 里名字既出现在 `# Subtest:` 头、 又出现在结果行，**2 倍效应 + 2 倍噪声恰好同值**，若行种类是 3 就会把两次读成三次。 本脚本自带 `--self-check`（干净样本放行 / 重复样本点名 / 只出现在头里的不算重复 / 名字含 `#` 不被截断）。 `package.json` 的 `test` 改为： node test/lib/env-preflight.mjs && node test/lib/run-suite.mjs ## 判据全进套件 `test/layout-boundaries.test.mjs`（新）：生产可达性不碰 `test/`、`test/lib/` 里不许藏 运行时模块、测试文件不许互相 import、`npm test` 必须接上 run-suite 那一层。 原来放在 `env-guard.test.mjs` 里那条"夹具不在测试文件里"已移到这里（集中边界判据）。 ## 变异自检（两条都实测红了才留下） - 造一个与巨行用例**同名**的探针文件 ⇒ `npm test` exit 1 并点名 `2× ★巨大的 message 行不进内存也不影响解析`； - 往 `src/gateway.mjs` 加一行指向 `test/lib/run-suite.mjs` 的真 import ⇒ 边界判据红并指出 `生产可达了测试代码：test/lib/run-suite.mjs`。 两条探针均已删除、`src/gateway.mjs` 用 `git checkout` 还原并 `cmp` 校验一致。 顺带修一处路径：`env-guard.test.mjs` 里 `PREFLIGHT` 仍指向旧的 `test/env-preflight.mjs` （前置脚本已移入 `test/lib/`）。 验证：`npm test` **462/462**、结果行重复检查 0 个重名、set 全绿。	2026-09-14 20:00:16 +08:00
JianFeeeee	f1059c5a6b	fix(pi-bridge): 夹具移出测试文件（import 它会二次注册整套用例）+ 测试侧写点全部兜住 + 判据不再往 /tmp 留垃圾 ... pi 复核了探针形状（论证闭合），又报了三条，全部实测成立。 ## 一、从测试文件 import 助手 ⇒ 那套用例被**再注册一遍**（最实质） `env-guard.test.mjs` 曾从 `session-scan.test.mjs` 取 `writeSession`。`node --test` 默认每个文件一个子进程，模块导入是进程内的 ⇒ 那个文件的 16 条用例在 env-guard 的进程里**又注册了一遍**。 实测确认：TAP 里巨行用例（单条往临时目录写 ~12 MiB）出现**两次** （`ok 87` / `ok 353`），测试总数 475。**判据自己在加倍压 /tmp** —— 而 /tmp 正是 这次事件的主角。修完：459 条，巨行用例 1 次。 修法就是 pi 指的形状，也正是 `translateEnvError` 那次的同一手法： 夹具移到**非测试模块** `lib/session-fixtures.mjs`（可被引用，不被注册进套件）。 ## 二、测试侧写点还是裸的 `makeRoot()` 的 `mkdtempSync`、以及 `writeSession` 里在 try **之外**的 `mkdirSync` （ENOSPC 也可能从这里出来）⇒ 绕过前置脚本时抛的仍是原始英文堆栈， 而"绕过前置也要说人话"正是这套兜底存在的理由。现在整段包一层，与 `selfCheck()` 同一形状：**覆盖范围不取决于"我以为的哪一行"**。 ## 三、判据往共享 /tmp 里留垃圾 `writeSession(tmpdir(), '--probe--', …)` / `'--probe2--'` 每跑一次就留两个目录、 且永不清理。现在改用 `os.tmpdir()`（纯字符串，不 statfs）当根：那两条的创建都被 假写打断 ⇒ 目录根本不会建出来 ⇒ 既不读也不写真实临时目录。 ## 四、一条新判据替代原来的文本接线检查 守**机制**：解析测试文件里的模块引用（静态 `from` / 动态 `import()` / `require()`）， 任何指向另一个 `.test.mjs` 的引用都算违规 —— 注释里提到文件名不算（注释不会注册用例）。 这条判据自己踩了两次，都留在注释里： 第 1 版 只匹配静态 from ⇒ 漏掉动态导入； 第 2 版 "文件里出现别的测试文件名" ⇒ 把**注释里的散文引用**也算成违规 （本仓库有 3 处这样的注释，逼人删掉有用的注释）， 而且**它被自己注释里的示例字面量扫到**。 **过宽和过窄都是坏的** —— 这正是这一串评审反复出现的同一族错误。 验证：`npm test` **459/459**（少了 16 条重复注册）；巨行用例出现 1 次； `--self-check` 18 条全过；`TMPDIR=/tmp node deploy/check-deploy-drift.mjs --self-check` ⇒ exit 2 + 人话。	2026-09-14 19:51:44 +08:00
JianFeeeee	6b7c12d9da	fix(pi-bridge): "开关被认"那条判据自己也有假绿 —— 我按真实测量分叉，于是永远走短路分支 ... pi 评审第二轮指出：上一版"开关真的被认"只在"真实测量不足"那个分支里断言， 机器一恢复健康（/tmp 被清空）这条就退化成"只验 --measure"的弱检查， 而它守的恰恰是"开关别静默失效"。 认下之后我做变异（把开关整个忽略掉、永远用真实测量）验证，**发现比这更糟**： 那条新写的判据**在变异下照样绿**。 原因是我写成了 `realAvail < MIN_FREE_BYTES ? (不足分支，只看退出码) : (充足分支)`， 而本机真实可用**就是 0** ⇒ 永远走不足分支；开关被整个忽略时，回退测量同样给 exit 2 ⇒ 断言通过。**"断言在，区分力不在"** —— 与 pi 点的是同一类病， 只是它藏在一个**跑不到的分支**里（嵌套三元短路），比"分支退化"更难看出来。 修法：不跟真实测量比，**让两个探针自己互为反面**，并断言**输出里的判定词** （不只看退出码 —— 退出码可能与真实状态巧合相同）： 探针 A：注入 1 字节 ⇒ exit 2 + 必须打印「< 需要」 探针 B：注入 128 MiB（>阈值）⇒ exit 0 + 必须打印「≥ 需要」 开关被忽略 ⇒ 两次都按真实测量给同一个答案 ⇒ 至少一条红。这个论证不依赖真实测量 是多少。变异自检实测：注入"忽略开关"的变异后，第 23、24、25 三条一起红。 顺带修一处**HEAD 里就带着的坏行**：第 162 行的 `test(..., () => {` 后面被塞进了 `// 覆盖…` 注释（上一次编辑吃掉了那个换行），整行不合法。这次一并拆回两行。 过程中我两次改坏文件（一次把手写 `replace` 的锚点算错、把"非法参数"那条整条删掉）， 两次都靠 `git checkout HEAD -- <file>` 拉回重做 —— 这正是上一轮写进 `lib/env-error.mjs` 的那条纪律（变异/改写只对已提交文件做、还原只走 git）当场生效。 验证：`npm test` **475/475**；env-guard 单跑 30 条全过（含 24 号在两个探针下的双断言）。	2026-09-14 19:46:07 +08:00
JianFeeeee	87359588eb	fix(pi-bridge): 评审第二轮 —— 判据在健康机器上会退化、"一处覆盖"取决于入口、笔误参数静默放行 ... pi 读了 `5bc579f` 之后报了两条新的 + 三条小的，全部认下并落地。 ## 一、"开关真的被认"那条判据在 /tmp 被清空后失去分辨力 上一版只在"真实测量不足"那个分支里断言（注入大数必须放行）。问题是： **"不足"正是机器恢复健康后会消失的条件** —— 那天这条判据就退化成"只验 `--measure` 可用"的弱检查，而它守的恰恰是"开关别静默失效"。 两个方向是对偶的、各守一个机器状态，所以改成**按实测分叉、在两个分支里断言相反的方向**： 真实不足 ⇒ 注入大数必须放行 （开关被忽略则回退测量 ⇒ 2 ≠ 0 ⇒ 红） 真实充足 ⇒ 注入 0 必须 exit 2（开关被忽略则回退测量 ⇒ 0 ≠ 2 ⇒ 红） 量不到就 `assert.fail` 并说明"无法分叉"—— 不静默跳过（跳过会把"失去分辨力" 伪装成"验过了"）。另把"端到端"那条的两个方向拆明白：只验"不足⇒2"时， 一个恒报不足的坏守卫也能绿。 ## 二、"一处覆盖全部写点"成立的前提是"从 main() 进来" `selfCheck()` 是**导出**的（用途就是被直接调），而兜住那三处裸写的 catch 在 `main()` 里 ⇒ 任何绕过 `main()` 的调用者撞上 ENOSPC 拿到的仍是原始英文堆栈。 **"覆盖范围取决于我以为的入口"正是这一串 bug 的共同病根**，所以把整段包一层 （`body()` + 统一 catch）：与入口无关，`main()` 那个退化为冗余的第二道。 实测：`TMPDIR=/tmp node -e 'import("./deploy/check-deploy-drift.mjs").then(m=>m.selfCheck())'` 现在拿到的是「环境不足…这是环境问题，不是检查器的问题」。 ## 三、`--inject-avail=abc` 静默放行（笔误 = 跳过守卫） `Number('abc')` = NaN ⇒ 判据当"没测到" ⇒ 放行。现在按仓库约定处理： **非法值 exit 2，未知参数也 exit 2**（`--measure` 少写 `=` 同样炸）。 `null` 仍是合法值（"没测到 ⇒ 放行"是有意的），加了判据把这两个方向都钉住。 ## 四、三条小的 - 两份实现（`lib/env-error.mjs` 的 `translateEnvError` 与 `deploy/` 的 `describeEnvError`）**不去重**，但两边各写一句"为什么不复用"： `deploy/` 的独立性比去重值钱（那份文件头整段在讲"服务不该依赖仓库是否存在"）。 并写明**第三份拷贝出现时再考虑共用**。 - 写点计数口径写进注释：本函数 **6 处写** = `mkdtempSync`×2 + `mk()` 内 ×2 + 三处裸写。免得与别处"五处"的说法对不上（上一封信里两个实测数字就是这么被误读的）。 - 变异自检的纪律补进 `lib/env-error.mjs` 头注释：**先证明能撤回来再注入变异， 且还原路径不能依赖被测对象**（那次把备份写进 `/tmp` —— 正是当时被占满的资源， 备份没写成而变异已覆盖源文件）。现在只对"已在 HEAD 干净提交"的文件做变异， 还原一律 `git checkout HEAD -- <file>`。 验证：`npm test` **475/475**；`--self-check` 18 条全过； `TMPDIR=/tmp node deploy/check-deploy-drift.mjs --self-check` ⇒ exit 2 + 人话。	2026-09-14 19:42:58 +08:00
JianFeeeee	5bc579f910	fix(pi-bridge): 按评审补三处 —— ENOSPC 只盖了一个写点、旧注释自相矛盾、兜底判据钉的是文本 ... pi 逐字读了上一版落地的代码，报了三个"还差一格"。都不是推翻，是同一根因 （"环境不足伪装成别的"）在这套守卫自己身上的残留。 ## 一、翻译只覆盖了 5 个写点里的 1 个（最实质） `selfCheck()` 要在临时目录造两棵样本树，写点有**五处**；上一版只把 `mk()` 里那两处 包了 try/catch，后面三处（`README.md` / `extra.mjs` / `test/t.mjs`）裸写。它们撞上 ENOSPC 时异常冒到 `main()` 的 catch：**退出码是对的（2），但打印的是原始英文 `ENOSPC: no space left on device, write` 加一段指向本文件的堆栈** —— 也就是上一版 要治的那个信号（"看起来像检查器坏了"）**恰恰在最需要它的路径上还在**。 改法：抽一个 `describeEnvError(e, what)`，在 `main()` 的 catch 里**统一**换成人话。 一处覆盖全部写点，以后再加写点也不用管。`mk()` 里那段裸判断一并换成调用它。 ## 二、`lib/tmp-space.mjs` 的头注释在说谎（读者已误读一次） 原文写"`availBytes` 为 `null`（读不到 / 平台不支持 / **字段为 0**）" —— 而"字段为 0" 指的其实是 `statfs.bsize === 0`（测量层确实 `if (!s.bsize) return null`），读起来 却像是在说"可用 0 字节也算不知道" —— **正是我上一版刚踩、刚补判据的那个坑**。 pi 第一遍读就误读成了后者。已把两个 case 分开写死，并注明"这条注释写错过一次"。 ## 三、兜底判据钉的是文本，不是机制 `env-guard.test.mjs` 原来对 `session-scan.test.mjs` 断言 /ENOSPC/ 与 /环境/， 而那段**解释性注释里本来就有这两个词** ⇒ 删掉整段翻译逻辑、只留注释，判据照样绿。 这正是 `permission-note.test.mjs` 自己警告过的"钉装饰不钉机制"。 改法（按仓库规矩，纯函数 + 反面样本 + 接线）： - 翻译逻辑提到 `lib/env-error.mjs` 的 `translateEnvError`（纯函数）； - 判据喂构造出来的错误验**行为**：ENOSPC 必须翻译且带药方、普通错误必须**原样返回 同一个对象**（"什么都翻译"比不翻译更坏 —— 真缺陷会被套上环境的外衣）； - `writeSession` 抽出 `write` 参数（**只为测试存在**，`pool.mjs` 的 `workerPath` 同一手法）， 于是"接线还在不在"是**行为**判据：喂一个必然 ENOSPC 的假写，翻译必须发生。 抽它的理由写在注释里 —— 是"可被反面样本喂"，不是复用（只有一个调用点）。 - 变异自检：删掉写点的翻译 ⇒ 第 28、29 两条立刻红（已实测）。 ## 四、顺带三处小的一致性问题 - 端到端那条判据原靠"本机 /tmp 恰好是满的"来验 —— 那是把判据绑在**会变的环境**上， /tmp 一清空就自动跳过、无声失效。前置脚本加两个**只为测试存在**的开关： `--measure=<dir>`（只量并打印 JSON）与 `--inject-avail=<n>`（绕过测量直接判定）， 于是"不足⇒exit 2"与"充足⇒放行"在任何机器上都验得了（两个方向都验，缺一即假绿）。 - 判据 ⑥ 原先只有它自己带圈号前缀，读者会去找不存在的第 ⑤ 条。改成 `checkLayout` 的每条都带**连续 id**（1..N），`name` 是纯展示串，并加一条"id 不许跳号"的自检。 - 两个实测数（`729_088` 字节 = 0.70 MiB、`712` 字节）是**不同时刻**量的，并列摆着像抄错， 各标了来历；`lib/tmp-space.mjs` 里那条改用"一度真是 0"的说法。 验证：`npm test` **474/474**（上一版 453）；`--self-check` **18 条全过**（新增 id 连续）； `npm test` 在临时目录不足时仍 exit 2 且一条用例都不跑。	2026-09-14 19:39:07 +08:00
JianFeeeee	0b548b8fcf	test(pi-bridge): 临时目录满时不再伪装成内存缺陷 —— 前置自检 + ENOSPC 兜底 ... 现场（2026-09-14 实测）：`/tmp` 是 tmpfs，被别人占满，`statfsSync` 实读 `bavail*bsize` 只剩 **0.70 MiB**。此时 `npm test` 红一条 not ok 323 - ★巨大的 message 行不进内存也不影响解析 error: 'ENOSPC: no space left on device, write' 那条红的**形状指向内存**（用例名里就写着"不进内存"，而它恰好是往临时目录写文件的 用例）⇒ 下一个踩到的人会去 `session-scan.mjs` 找一个**不存在**的内存缺陷。 改： - `lib/tmp-space.mjs`：测量与判据分开，判据是纯函数 `judgeSpace`，喂字节数即可验； 读不到可用空间（null/NaN）⇒ **不判红**（不知道 ≠ 不对，否则会造出"总在亮"的红灯）。 **但 0 字节不是"不知道"** —— 第一版把 `<=0` 一并当"没测到"，于是 `bavail` 只剩 712 字节时前置自检放行、紧接着 17 条用例 ENOSPC 全红：前置自检装了等于没装。 阈值 32 MiB = 实测单条用例最大写入量（`session-scan` 那条写 3×3 MiB 行 ≈ 12 MiB） ×2 + 8 MiB 机动，不是总容量的百分比（百分比在这套测试上没有依据）。 - `test/env-preflight.mjs`（名字不带 `.test.`，不被 glob 收进用例）： `package.json` 的 test 改成先跑它；不足时打印实测/阈值/目录并 **exit 2** —— 与 `deploy/redeploy-plugin.sh` 的 `2=环境问题` 同一套约定，看到 2 才知道 去查机器而不是查代码。文案里明写「这是环境不足，不是断言失败」。 - `session-scan.test.mjs`：兜底翻译 ENOSPC（`node --test 'test/*.test.mjs'` 会绕过 前置脚本，这一句不管套件怎么被调起来都生效）—— 这正是治那条误导的关键。 - `test/env-guard.test.mjs`：8 条自证 —— 纯函数两头 + 边界（≥阈值算够、<阈值不够） + 0 字节必须红 + 读不到不判红 + 阈值有据 + 端到端 exit 2 且文案对得上。 端到端那条**不假设本机 /tmp 仍然满**：先自己量一次，够用就跳过并说明原因， 免得它退化成一条"总在亮"或"总在绿"的假判据。 顺带修 `deploy/check-deploy-drift.mjs` 两处同源问题： - `selfCheck()` 要在临时目录造两棵小树，`/tmp` 满时抛 ENOSPC —— 而它是**未捕获异常**， 堆栈指向本文件，看起来像检查器坏了。翻译成说得清的错并让 main() 报 2。 - 新增判据 ⑥「工作区干净」—— **只提示，不参与 exit code**。判据 ① 比的是 「仓库工作区→快照」这一跳，覆盖不到「HEAD→工作区」那一跳（实证：一行未提交的 死代码被 17:20 的快照带进生产，而 ① 报的是"逐字节一致"）。做成红灯就是一条 总在亮的判据（本文件头自己骂过的病），所以只说、不判。 验证：`npm test` 453/453（新增 8 条）；`npm test` 在 /tmp 满时 exit 2 且不再跑用例； `node deploy/check-deploy-drift.mjs --self-check` 17 条全过（含 ⑥ 的三条正反面）。	2026-09-14 19:29:44 +08:00
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
JianFeeeee	33488760ce	fix(相位/安全): 部署门禁只判产物自证；静默 break 改成出声；内核读数带时间坐标 ... pi 2026-09-14 的裁定与两条更正，逐条落地。 1. **相位裁定（选 c）**：`packaging`/`build-stamp` 属于**构建相位**，不属于安装相位。 `run-all.mjs` 现在有相位：`AGENTMAIL_CRITERIA_PHASE=install`（部署门禁用）。 每条判据登记它读的哪一侧（`ARTIFACT`/`SOURCE`），install 相位里出现 SOURCE 侧判据 → 红； 被跳过的判据**点名打印**，不静默丢。汇总打 `RESULT phase=build|install`。 规则入册 `test/CRITERIA.md` §11（含三个真实实例：check-shared-libs 恒红、 packaging 一改前端就卡死、HOME 在门禁跑完之后才炸）。 安装相位**真正能判的那一半**：`deploy/install.sh` 读**产物自证**（不重算 dist）—— `releaseCandidate !== true` → 拒绝；产物 `gitRev` ≠ HEAD → "这个包比源码旧" → 拒绝； 放行要显式 `--allow-dirty` / `--allow-stale`；`--check` 干跑只报结论不拦。 实测干跑输出：`产物：gitRev=6702cc2 树=dirty releaseCandidate=false ｜ 当前 HEAD=6702cc2` → 报"不是发布候选 + 正式安装会被拒绝 + 要放行请显式说清"。 2. **别解析运行器文本**（pi §5）：`broken`/`red` 的判定改成按 TAP 的**名字**—— 文件级失败的测试名就是路径，断言失败的名字是判据名。变异双向验证： 未定义标识符 → 「跑不起来的判据」；把某条判据条件改成假 → 「红的判据」。 不再往关键字表里加补丁（那是往文本解析里加补丁，方向是错的）。 3. **静默 break 是安全相关**（pi §3）：`session_update` 找不到活动会话时不再静默 break， 改成出声日志（走 journalctl 那条通道），写清两种成因（此刻没在跑 / **接管会话**重启后无法定位）、 方向（收紧被延迟）、以及兜底的**前提**（"下次投递"要求这条会话还会收到新邮件）。 `lib/mail-session-id.js` 模块头同步改成安全相关措辞（"人以为自己收紧了权限、实际没有"）， 四桥逐字节同源，`check-shared-libs.sh` 退出码 0。 4. 内核读数补时间坐标（pi 13ea2fdf）：`BUILD_INFO.txt` 里除原始 `dep`/`=>` 行外， 现在还有 `kernelBinMtime` 与**正在运行的进程启动时间** —— 二进制会在两次读数之间被换掉， 没有时间坐标的读数不成立。	2026-09-14 16:54:30 +08:00
JianFeeeee	dae508b25b	docs(判据): 补「已知限制」与「缺省语义登记」两节；build.sh 把原始 dep/=> 行写进 BUILD_INFO ... pi 2026-09-14 两件： 1. **登记册真的没有**。我上封信说"已写进 test/CRITERIA.md 的已知限制一节"——**不成立**， 只有 `appearance-defaults.test.mjs` 里有那段注释。已在 CRITERIA.md 补 §9「已知限制」 （标识符只解析一层；静态判据的到期前提是"本工作区能装能点"）。 过度声明自己做过什么是这轮反复出现的那一类错，这次是同一个形状的又一例。 2. **新建 §10「缺省语义登记处」**（pi 的更正：不是无条件 fail-closed，而是"缺了的后果必须 有人登记 + 写明谁批准了这个方向"）。三条入库，各带依据： · 邮件 `permission_mode` 缺 → **不写、不改档**（窄），依据是本轮那个 `|| 'workspace'` 兜窄档的坑； · HomeAgent `plugin.json.sdk` 缺 → 内核**不读**（不是语义，是文档），依据内核 manifest.go 结构体 + registry.go； · HomeAgent `capabilities` 缺 → **不受限**（宽），依据内核注释明写的理由：17 个存量清单都没有它。 3. `build/BUILD_INFO.txt` 现在**原文贴入** `go version -m <内核>` 的输出，并附"这两行怎么读" （`dep … vX.Y.Z` 后面跟 `=> … (devel)` 时那串版本号只是 require 行残留；`=>` 必须按模块名联接）。 理由：这场争论的全部内容就是这两行该怎么读，原始证据必须和结论放在一起。	2026-09-14 16:50:33 +08:00
JianFeeeee	4f0a6e6097	fix(homeagent): 构建不许弄脏源码树 —— hmapdev 会重写 plugin.json，构建后还原并出声 ... 实测：`hmapdev build` 会重写受版本管理的 `plugin.json`（只吃掉了文件末尾换行）。 "构建把树弄脏"这件事在 electron 那边刚定过规矩（脏树产物不得自称发布候选）， 所以这里同样处理：构建前留快照，构建后若被改写就还原 + 打印一行说明 （不静默还原 —— 下一个人要知道这条工具会动源码）。 验证：`bash build.sh`（HOMEAGENT_SDK_DIR=…/sdk/v1.3.0）产出 build/plugin.bin（9018271 字节）， 构建后 `git status plugins/homeagent-mail-bridge/` 只剩我自己改的 build.sh。	2026-09-14 16:41:54 +08:00
JianFeeeee	7e696f9a8c	fix(homeagent): 撤回"另一条 SDK 血脉"的错误结论；build.sh 不再猜路径；清单判据改成一致性口径 ... pi 用只读文件系统逐条反驳了 357662e 的根因，三条我都验证并接受： 1. **"内核链 0.9.x 血脉"不成立 —— 那是我的搜索顺序造出来的事实。** 本机有 6+ 份 `third_party/homeagent-sdk` checkout： /root/ha-test/…（0.9.0，C-ABI 时代，无 plugin.bin 支持） /var/tmp/rel-1.3.12/…、/var/tmp/rel-1.3.11/…（1.3.0） /var/tmp/release-main/…、/var/tmp/clean-check/…、/var/tmp/homed-p3/…（1.2.0） 而 build.sh 第一版按候选根目录**第一个命中就算**，命中的正是 ha-test 那份老 checkout。 内核自己用的是 1.3.0 那份，与钉子 `sdk/v1.3.0`、与 `<SDK_ROOT>/current` **一致**。 两条教训写进注释了：别用"第一个存在的路径"当权威来源；别把模块版本字符串当身份 （`replace => local (devel)` 时它只是 require 行的残留）。 2. **"API 不兼容"也是同一个错造成的。** 换成正确的 SDK 之后： HOMEAGENT_SDK_DIR=/root/.homeagent/hmapdev/sdk/v1.3.0 bash build.sh → hmapdev build 成功，产出 build/plugin.bin（9018271 字节） 也就是说**这个插件在本机编得出来**，先前的 `SettingsAPI.DataDir` 报错是拿老 checkout 编的产物。 3. **判据把能工作的配置判红**（pi §2）：第 4 步原先硬校验"产物 SDK 模块版本 == 内核模块版本"， 而生产上能跑的组合恰恰是"内核 + v1.3.0 编的插件"。已删掉这个相等性判据： SDK 源码**只认显式指定**（HOMEAGENT_SDK_DIR），不猜、不试探； 内核那条 dep/=> 只作为**提示**打印（并且按模块名精确联接、只接受紧跟 SDK dep 行的 `=>`， 不再取"输出里第一个 =>"）；身份改记 **realpath + 内容哈希**； `meta.Version` 读取先剥注释（注释里的 `Version = "9.9.9"` 不再能赢）。 真正的不变量是 **wire 协议 protocol=2 + 一次真实握手**，写在脚本末尾（部署后回看日志）。 4. **清单判据改成一致性口径**（pi §5）：不再"禁止 sdk 字段"——那会把正在工作的那份清单 （/home/newqqagent/plugins/homeagent-mail-bridge/plugin.json 声明 sdk=1.3.0，正是 08:30 那次恢复的处置动作）判红，而我没有"内核不读该字段"的证据。现在：可以不声明； 声明了就必须与构建机指针一致。	2026-09-14 16:38:28 +08:00
JianFeeeee	357662ed08	fix(homeagent): 不再把 SDK 版本钉在源码里；构建期按内核的依赖表校验对齐 ... 崩溃循环的根因不是"忘了重编"，是**把 SDK 版本钉死**： - `plugin.json`/`plg.json` 写死 `"sdk": "1.3.0"`（本机已装 21 个插件里只有 3 个声明该字段）； - `go.mod` 的 replace 指向 `/root/.homeagent/hmapdev/sdk/v1.3.0`（绝对路径 + 具体版本目录）。 于是"照原样重编"只会再造一个装上去就崩的包。实测本机内核链的是**另一条 SDK 血脉**： $ go version -m /usr/local/bin/homed dep gitcode.com/JianFeeeee/homeagent-sdk v0.9.2 => ./third_party/homeagent-sdk (devel) 所以判据改成**两个二进制的依赖表一致**，而不是"版本号看起来像"： - `build.sh`：读内核的 SDK 依赖（`go version -m`）→ 据此解析 SDK 源码目录 → 用 `-modfile` 临时替换（不改动受版本管理的 go.mod）→ 构建 → **回头验产物**： 产物与内核链的 SDK 版本不一致就报错退出，绝不产出"装上去就崩"的包。 - `manifest_sdk_test.go`：① 清单不许写死 `sdk`；② go.mod 的钉子不得偏离构建机指针 （取不到基准就红，不许默默放过）；③ `build.sh` 必须在（它是与内核对齐的硬校验点）。 三条都做过变异验证（写死 sdk / 钉子漂到 v1.2.0 / 删掉 build.sh → 各自红）。 顺带查出一个比"重编"更根本的事实：本机 `build.sh` 跑到编译就失败 —— ./plugin.go:217:18: sett.DataDir undefined (type sdk.SettingsAPI has no field or method DataDir) 即本插件源码用的是 **1.3.0 SDK 的 API**，而本机内核链的是 0.9.x 血脉：**重编解决不了**， 要么内核改成链 1.3.x 的 SDK，要么把插件移植到内核那份 SDK（这是 HomeAgent 侧的决定）。	2026-09-14 16:27:02 +08:00
JianFeeeee	d5cfcbdc9c	fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上；状态写入点不再兜默认档 ... 线上事故（jianf 经 pi 转达）：补投路径漏传 permission_mode，插件拿 undefined 兜了 workspace 档，把 full 档会话写成 workspace-write + ask —— 不是"拦一次"，是一整轮 工具能力降级，且状态留在会话里；随后该会话每次受守卫调用都撞 409。 四件事： 1. **状态写入点不接受默认值**（新增共享 `modeForStateWrite`）：缺字段/脏值 → `null` = 不写状态。"默认值可以出现在**决策**里，不可以出现在**状态写入**里。" 同时保留共享契约的 fail-closed：真读到 workspace 才写 workspace。 2. **409 的两种含义分开处理**。`allowed-once` 只绕过**审批**，改不了**沙箱** —— 所以 dsh 桥在放行前先把服务端给的权威档位**写回会话**（这也就成了自愈路径： 已经降级的会话，下一次带档位的 409 会把它修回来）；只认服务端明说的 full， plan 与"链上没有人类"照旧 fail closed。 3. **同一处缺陷在 zcode / opencode 也在**（`hooks/permission.mjs` 与 `index.js` 都把 409 当永久失败拒绝）。我先前在回信里写过"这两个桥不转发权限询问，不需要改" —— 那句话是错的，我当时的搜索面只有 `<plugin>/src/*.mjs`。按 pi 的要求把这条 **否定性事实变成常驻判据**后，它第一次运行就红给我看。四桥现在都有 「409 + full → 放行」，且**排在永久失败分支之前**（含顺序变异自检）。 4. **共用测试重新同源**：`test/catchup.test.mjs` 从 `153985e` 起就是分叉的 （我那版把平台专属路径写进了共用文件），而 `deploy/install.sh` 第 24 行会跑 `check-shared-libs.sh` —— 也就是说**部署一直是红的**，我没跑过那个脚本。 共用文件只放契约（值/行为），跨平台配对judge 移到平台专属文件，四份逐字节相同。 另外把"判代码 vs 判理由"从记忆变成代码：`test/lib/read.mjs` 提供 `code()/prose()/bytes()`， 判据目录里不得再裸用 `readFileSync`（新判据 `criteria-hygiene` 管，含读取器自检）。 判据证据（每条都做过"能不能红"的变异）： - 写回去掉 → 红；纠正块挪到普通 409 之后 → 红；状态写入点退回兜默认 → 红； - zcode/opencode 的放行分支拿掉 → 各自红；共用测试分叉 → check-shared-libs 红。 各套件：dsh 388、pi 443、zcode 387、opencode 333（均经 npm test，含 tsc）； electron `npm test` 15/15 判据绿 + vitest 266 + typecheck；`check-shared-libs.sh` 退出 0； Go `go test ./...` 全 ok。	2026-09-14 16:21:27 +08:00
JianFeeeee	7028c244fd	dsh 桥同一处缺陷：409 带 full 档时也当场拒绝（并且把会话降级了） ... pi 报的是它自己的桥，但**同一处缺陷 dsh 桥也有**（`src/index.ts` 的 409 分支无条件 `return 'rejected'`），而且后果多一层 —— dsh 的档位是通过 `applyPermissionMode()` 写进会话的（沙箱 + 审批策略）。补投漏传档位时 `applyPermissionMode(session, '')` 把会话**降级**成 workspace：`danger-full-access → workspace-write`、 `never → ask`，于是每个受守卫的工具调用都去问一次，再被 409 拒绝 —— 一条 full 档会话只要有一封补投邮件，这一轮的工具调用全被自己人拦死， **顺带把自己的权限也降了**。 修法同 pi 桥：409 分支先认回包里的 `permission_mode`，是 full 就 `return 'allowed-once'`（DSH 的 ApprovalOutcome 只认 allowed-once/rejected/cancelled/unavailable）； plan 档与"链上没有人类"照旧 `return 'rejected'`。放行分支排在普通 409 之前，否则不可达。 判据 `test/permission-409-full.test.mjs`（含自检：拿掉放行分支必须红）。 自检那步发现我第一版判据又踩了同一个坑：「普通 409 分支里不许出现 allowed-once」 读的是**含注释**的正文，而那段的注释正好写着 "ApprovalOutcome 只认 allowed-once / rejected / …" → 误报。改成读剥注释的源码（规范里那条： 判"代码里有什么"读剥离版，判"理由写清了没"读原文）。 zcode / opencode 不转发权限询问（没有 409 分支），无需改。 验证：dsh 套件 383 通过（+2）；变异（拿掉放行分支）→ 自检红。	2026-09-14 15:51:38 +08:00
JianFeeeee	153985e8b1	补投路径漏传档位（full 档被误拦）—— 修因 + 兜底，并顺出同族另外四个字段 ... pi 报告：离线补投的邮件把 full 档会话当 workspace 档申请审批 → 服务端 409 → 桥按「永久失败」当场 block → 这一轮 bash/write/edit 全被拦（SSE 实时送达不受影响）。 jianf 让 pi 把这件转给我，我这边定位后**先跑变异再改**。 ## 1 根因：`mailToEvent` 少搬字段（不是服务端不给） `lib/catchup.js` 的 `mailToEvent()` 只搬了 8 个字段，没有 `permission_mode` / `permission_enforcement`，于是 worker 的 `msg.data?.permission_mode || 'workspace'` 落到默认档。**pi 以为收件箱行不含档位、于是建议"要么动服务端载荷要么另取一次"—— 实测不成立**：服务端一直就给了（`repo.ListInboxScoped` 的 SQL 里有 `JOIN sessions s` + `COALESCE(NULLIF(s.permission_mode,''),'workspace')`， `models.Mail.PermissionMode` 的注释写明"补拉路径必须有它们"）。所以修因只在插件侧： 补上这两个字段，键名与 SSE 逐字一致；缺字段时给空串（**不猜档**，猜宽了就是提权）。 `lib/catchup.js` 在四个桥里**逐字节相同**，一次改动四边同步（改后 md5 仍为一份）。 ## 2 兜底：409 带档位时按档位处置 服务端在"档位不该问人"时也回 409，并在回包里带 `permission_mode`。两种 409 的正确反应 **相反**：无人可问 → 拦；**full 档 → 放行**（本档无需审批，拦了就是把能干的活干死）。 `src/worker.mjs` 的 409 分支先认 `permission_mode === MODE_FULL` 放行， plan 档与"链上没有人类"照旧 fail closed —— 只有服务端明说 full 才放行。 ## 3 顺出的同族字段（用"配对"扫出来的，不是猜的） 把四个桥**读投递事件的字段**与 `mailToEvent` 的产出对了一遍，邮件类字段还缺三个： - `from_human`：dsh 的提示词靠它决定说不说"回信不用你自己发"。缺了它， **人发来的信在补投路径上被当成 Agent 来信、失去自动回信**（服务端注释早写明）。 - `in_reply_to`：SSE 那边等于 `ParentMailID`。缺了它，"这封是对我的回复"被当成新派的活， 两边互相客套到撞 hop 上限（生产实测 6 轮）。行里叫 `parent_mail_id`，**只改名不推算**。 - `session_alias`：缺了它插件只有 session_id，而 `send_mail` 不接受 session_id。 `reply_address` 是**唯一**行里真的没有的字段（SSE 在 notify 里按收件人现算）。 服务端注释明确说"插件不必自己拼（拼错了就是静默开新会话）"，所以由服务端补： `models.Mail.ReplyAddress` + `ListInboxScoped` 填 `FormatAddress(from_name,"",alias)`， 插件只搬运。 ## 4 判据（这次事故**单独看任何一个桥的测试都发现不了** —— 缺口在接口上） - `test/catchup.test.mjs`：补投必须带档位（缺字段给空串而非猜档）； ★ **四桥配对**：把 dsh/pi/zcode 读的邮件字段与补投产出配对，缺了就红 （非邮件事件字段走显式 ALLOW 并各写理由，白名单不许膨胀）。这条正是本次缺口的形状。 - `test/permission-mode-409.test.mjs`：409 + full 必须放行且放行分支在 block 之前， 非 full 仍拦；带**判据自检**（拿掉放行分支后必须判红）。 - `server/internal/repo/session_scope_test.go`：收件箱行带 `permission_mode`（含"没设过 回落 workspace"的反向对照）与 `reply_address`（与 `FormatAddress` 同形、path 位为空）。 变异验证：mailToEvent 去掉档位 → 2 条红；worker 新读一个补投没产的字段 → 配对判据红**并点名该字段**； 409 分支拿掉 full 放行 → 自检红；SQL 把档位写死成 workspace → Go 判据红。 ## 验证 `go test ./...` 全绿（新增 2 条）；四个桥套件全绿（pi 439 / dsh 381 / opencode 331 / zcode 385）。 **未部署**：`/opt/agentmail` 与 `sudo ./deploy/install.sh` 都在我的工作区之外（本会话文件策略 workspace-write，放宽需审批而这条链上没有人类），所以修复已进仓但**线上仍是有缺陷的版本** —— 需要有人跑一次 `sudo ./deploy/install.sh`（脚本自己会跑齐各套件）。	2026-09-14 15:49:45 +08:00
JianFeeeee	be0693821b	fix(agents): 四家桥的 read_inbox 一律按会话收窄（dsh/opencode/zcode/homeagent） ... 用户：「你还是没修好不同 session agent 收件箱隔离的问题」。上一轮我只修了 **pi**， 另外四家还漏着 —— 它们是**每一家各自实现** read_inbox，不修就还是漏。 ## 缺陷 列表按 Agent 列（整个收件箱），而 read_inbox 按契约把**列出来的都标成已读** ⇒ A 会话的回合会把 B 会话的未读标掉 ⇒ B 之后按 `?status=unread` 补投时 再也看不到那封信（静默丢信，不是"少看一封"）。用户是在别的 Agent 上看到它的。 ## 四家的修法（各自平台能力不同，但都要"并发安全"） | 桥 | 会话来源 | 为什么这样做 | |---|---|---| | dsh | 工具第二参数 `exec.agent.id` → `reverseMap` | 平台就在上下文里给了会话；**不能用模块级"当前会话"变量**（同进程可能同时跑多条会话的回合，会互相覆盖） | | opencode | 工具第二参数 `context.sessionID` → `reverseMap` | 同上 | | zcode | `AGENTMAIL_SESSION_ID`（在**调用时**读） | 一轮一个进程，驱动本来就注入它给授权钩子用；调用时读，避免将来复用进程拿到旧值 | | homeagent | `p.currentSessionID`（回合开始设、结束清） | Go 插件，本来就有这个状态 | 取不到会话一律**退回整体收件箱**（历史行为），不猜 —— 猜错就是静默丢信。 ## 判据 - 服务端语义：`server/internal/repo/session_scope_test.go`（读 A 不动 B、列表收窄、 计数与列表口径一致）。 - 桥侧接线：dsh 4 条、opencode 3 条、zcode 3 条、homeagent Go 1 条 （`TestInboxURLScopedBySession`，直接断言拼出来的 URL）。 每家都带**判据自检**：拿旧写法喂进来必须判红；dsh/opencode 还专门断言 "不得用模块级当前会话变量"。 - **部署件**（不是仓库）：四家的部署快照里都能 grep 到 `session_id=`。 - **线上实测**：用 opencode 自己的 Agent 身份请求收窄列表 —— 会话 A 3 封、 会话 B 0 封、两者无交集、且都是全量的子集。 套件：opencode **331**、dsh **381**、zcode **385**、homeagent ok，全绿。 四家桥已重新部署（dsh/opencode/zcode 快照切换 + homeagent 新 plugin.bin 并重启）， 四个服务均 active。	2026-09-14 12:07:45 +08:00
JianFeeeee	552fbc731e	fix(inbox): read_inbox 按会话收窄 —— 修「不同 session 的 agent 都能看到全部邮件」 ... 用户问：「你之前不是说你已经处理了不同 session 的 agent 都可以看到全部邮件的 问题了吗？」——**我得先纠正事实：上一轮我只做了诊断并问要不要动手，没有实施。** 这是我的表述问题（把"已定位并给了方案"说成了像"已处理"）。现在实施。 ## 缺陷 `read_inbox` 是**按 Agent** 的：列的是该 Agent 的全部未读（含别的会话的来信）， 并按契约把列出来的都标成已读 ⇒ A 会话的 worker 标掉 B 会话的未读。平时看不出来 （SSE 事件在途时队列兜着），但桥重启/漏事件后的补投判据是 `?status=unread` —— 被标掉的那封**再也不会补投** ⇒ 静默丢信。现场实例：另一条会话的来信在 `mail_reads` 里的 reader=pi、时间正是我读自己收件箱的那一刻。 ## 改动 - **网关**：`GET /mail/inbox` 与 `POST /mail/read` 支持可选 `session_id`。 不带 = 旧语义（整个 Agent 的收件箱，浏览器/脚本仍可用）；带了就只在这条会话内 列与标。`ListInbox` / `MarkAllInboxReadFor` 保持原签名并委托给新变体 —— 老调用点一个都不用改。 - **pi 桥**：`read_inbox` 把自己那条会话拼进 URL（worker 通过闭包把**邮件会话 id** 递给工具，而不是在启动时取快照）。 ## 判据 - repo 三条：列表按会话收窄（含"不带会话时两条都在"的反向对照）、 ★"标会话 A 不动会话 B"、会话内计数与列表口径一致（否则界面会出现"徽标 2、列表 1"）。 - handler/网关：非法 `session_id` ⇒ 400（不静默忽略）。 - pi 接线三条（URL 拼了收窄、worker 递了 id、判据自检：旧写法必须判红）。 - 线上只读 E2E：两条真实会话 A/B 列表**无交集**、不带会话能列出全部、非法 id 400。 ## 过程中测试当场抓到"只改了一半" `MarkAllInboxReadForSession` 里插 `mail_reads` 的语句我加了会话条件， **刷新冗余列的 UPDATE 忘了加** ⇒ 返回的"标掉几封"变成 2（应 1）。 判据一眼看出来了 —— 这类"改一半"正是这次要防的。 ## 范围（诚实说明） 另外四家桥（dsh/opencode/zcode/homeagent）的 `read_inbox` 工具签名里**没有会话上下文** （`execute(args)` / `execute(args, ctx)` 各不相同），要按各自框架的上下文 API 接线， 不是一行改动 ⇒ **未做**，列为待办（位置已定位）。所以：pi 上这个缺陷已消除， 另外四家仍在。 ## 部署 网关已部署并线上验证；pi 桥的部署**延迟到本轮结束后 150 秒**执行 （重启 pi 桥会掐掉我自己这一轮 —— 之前真发生过），日志 `/var/log/agentmail-pi-redeploy.log`，可用 `node deploy/check-deploy-drift.mjs` 核对。	2026-09-14 09:19:25 +08:00
JianFeeeee	51789ee72e	deploy: 标准目录部署 —— 运行时不再依赖源码目录 ... 用户注意到：「当前 agentmail 是在源码目录部署的，应当改为标准目录部署」。 查证后有三处实证（都不是猜测）： 1. ★ **失败通知钩子执行的是仓库里的脚本** （`/home/program/agentmail/deploy/service-failure-notify.mjs`，8 处引用： 4 个 drop-in + zcode/zcode-mail-bridge 单元 + agentmail-failure-flush）。 仓库一挪/一改名，故障通知就**静默失效** —— 而那条管线正是用来报告服务故障的。 2. **opencode-serve 的 cwd 就是源码目录**（`WorkingDirectory=/home/program/agentmail`）。 3. ★ **仓库里的 `deploy/*.service` 是旧的源码目录版本**（ExecStart 指向 `/home/program/agentmail/plugins/...`），而机器上的已被改过 —— 也就是说 **谁跑一次 install.sh 就会把部署退回源码目录**。drop-in 更是只存在于 /etc 里， 仓库完全没有它们。 ## 改动 - **唯一真相**：`deploy/systemd/` 镜像 systemd 目录结构，收进全部单元与 drop-in （8 个单元 + 12 个 drop-in），路径全部改到 `/opt`。 - 运行时脚本装到 **`/opt/agentmail/bin/service-failure-notify.mjs`**（自包含， 无相对导入）；`install.sh` 与 `redeploy-gateway.sh` 都会幂等地装它。 - opencode 的 cwd 改为 `/opt/agentmail`（与网关一致），已重启生效 （`/proc/<pid>/cwd` 已核）。 - 删掉 `deploy/*.service` 的旧副本，避免两个真相。 - dsh 的 `cordis.patch.yml` 注释里的安装示例也改到标准位置（运行时用的是环境变量， 那条注释是唯一残留）。 ## 判据（`deploy/check-deploy-drift.mjs` 新增「标准目录部署」四条 + 自检） ① 任何 unit/drop-in 都不得引用源码目录；② 已安装单元与 `deploy/systemd/` 逐字节一致； ③ 通知脚本在标准位置且可执行；④ 各服务的 cwd/ExecStart 不在源码目录 （homeagent/dsh/zcode 是**别的产品**的标准位置，按白名单放行）。 自检两个样本：引用源码目录的必须红、干净样本必须绿（证明不是恒真）。 顺带修掉一处**真漂移**：仓库里 dsh 的 `dist/index.js` 落后于部署件（改了 src 没重建）， 重建后 `check-deploy-drift` 报「四个宿主都在跑当前代码」。 ## 复核 - `/etc/systemd/system/` 引用仓库：**0** 个文件；`/opt/agentmail` 下只剩旧二进制/备份里 的构建路径（Go 嵌的源码路径，无害）与一条注释。 - 四个宿主都在跑当前代码；标准目录四项全绿。 - 全部服务 active，opencode/网关 cwd 均已在安装根下。	2026-09-14 08:38:33 +08:00
JianFeeeee	5b6fef764f	feat(appearance): 主题与壁纸搬到服务端（账号级）—— 回答"为什么背景存在本地" ... 用户质问：「为什么背景是保存在本地而不是服务器！」当时的实情是主题与壁纸只写 localStorage：换设备/换浏览器就没了，而且**多账号共用一份**（键是全局常量 `agentmail.background`）—— 同一台机器换账号背景不跟着走。而 localStorage 的 ~5MB 配额也解释了客户端那套"压到 2.4MB 以内"的限制本来就是为本地存储设计的。 现在：**服务端是权威（账号级），本地只是缓存**（首屏秒开、离线可用）。 ## 服务端 - 新表 `user_appearance`（两种方言），用**列**而不是 JSON：blob GC 要一眼看出 "这张图还有没有人用"。 - `/api/v1/me/appearance`：GET / PUT（主题+背景档）/ POST image（multipart）/ GET image / DELETE image。鉴权同其余 /me/*（cookie 或 Bearer）。 - 图片走**内容寻址的 blob 存储**（与附件同一套），库里只存 sha256；上限 4MB 兜底 （客户端会先压到 ~2.4MB），只收图片类型（非图片 415 —— 浏览器会把非图片渲染成 空白，用户只会看到"设置了却没变化"），超限 413 不静默截断。 - ★ **blob GC 的引用源加了这张表**：我在实现前先读了 `SweepUnreferencedBlobs`， 它只认 attachments / calendar_attachments。漏了这一处，壁纸会在下次 GC 时被当 孤儿删掉，而库里那行还在 —— 表现为"图 404、设置却显示已设置"。判据同时验了 壁纸存活**与**孤儿确实被清（否则"还在"可能只是因为 GC 没跑）。 ## 客户端 - `lib/appearance.ts`（纯函数：两侧形状换算、data URL→Blob）+ `stores/appearanceSync.ts` （pull / push / 去抖订阅 / 账号切换重新拉取）。 - 三条不变量都有判据：拉取以服务端为准；★ **拉取不会再推回去**（否则是自触发回环， 一次拉取顺带一次 PUT，服务端 updated_at 被无意义刷新）；本地改动会推上去。 - 壁纸**只在换图时上传一次**（几 MB 不该每次 PUT 都跟着走）。 - 降级**必须可见**：未登录/不可达 → `local-only`，推失败 → `pending`，背景设置里 有徽标与说明（"已同步 / 待同步 / 仅本机"）。静默降级会让人以为已经同步， 然后在另一台机器上发现没有 —— 正是这次的缺陷。 - 图片用**带认证的 fetch** 取回再转 data URL：`<img src>` 发不出 Bearer，而 `?token=` 会把密钥写进历史记录与服务端日志（明确不做）。 ## 判据 - Go 10 条：往返、★多账号隔离、非法值归一、上传/取回字节一致、非图片 415、 超限 413、删除、未登录 401（五个端点）、★GC 存活 + 孤儿对照。 - 客户端 10 条：形状换算、image 无图退回 none、越界夹取、拉取生效、 ★拉取不推送、推送 payload、未登录/500 → local-only、推失败 → pending、 ★壁纸只上传一次。 - 全量：server 10 包全绿、客户端 249 通过（含打包一致性判据 —— 它先红后绿， 因为前端改了必须重打安装包，这条护栏是先前特意留下的）。 ## 线上验证与交付 - jianf 设置 → 回包 saved=true；**gui-lab 读到自己那份默认值**（隔离生效）； gui-lab 上传 67B PNG → 取回 sha256 一致、`has_image=true`；DELETE 后 404。 - 网关已重打（WebUI 内嵌）并部署；Electron 安装包已重打（AppImage + deb）。 遗留：鸿蒙端还没有外观功能（数据已在服务端，将来可直接读）；本地缓存仍在（离线可用）。	2026-09-14 08:32:22 +08:00
JianFeeeee	1ec88866ac	fix(permission): 另外四家桥的"人类说明"缺口 —— 三家修、一家本来就有 ... 承接 453f451（pi 桥）。用户批准后把同款缺口在其余四家逐一核对： **zcode 本来就有**（`说明：${decision.note}`），homeagent / dsh / opencode 三家缺。 ## homeagent（Go，能完整修） SSE 事件结构里**根本没有 Note 字段**（json 里只有 decision/decided_by）⇒ 备注在 解码那一步就没了。补上字段，并把提示词抽成纯函数 `permissionDecisionPrompt(evt)`， 加了判据（说明必须出现 + 反向对照：无说明/空白说明不得凭空造出说明段）。 构建（`go build -buildmode=plugin`）后 install 到 `/home/newqqagent/plugins/homeagent-mail-bridge/plugin.bin` 并重启，已核验部署件 含新符号（`grep -a`，中文用 strings 查是查不到的）。 ## dsh / opencode（平台回执放不下理由 → 分两步） 两家的审批回执都是**三态字符串**：DSH `ApprovalOutcome` 只有 allowed-once / rejected / cancelled / unavailable，openCode 只有 once / always / reject —— **没有地方放人类的说明**。所以： 1. 提示词（"你之前发起的权限请求已有结论：…"）统一走 `permissionPrompt(data)`， 带上 `用户的说明：…`。dsh 原有**三处**内联文案（续谈/新会话/通知投递）， 措辞分叉正是这类信息漏掉的地方 —— 判据直接钉"只有一处拼这句话"。 2. 带说明的决策**另投一趟通知**，让模型在会话里看到理由。代价是多一轮；比悄悄 丢掉人的指令轻（原缺陷就是丢了指令，模型把同一条命令换写法又问一遍，连问 9 次）。 3. 决策回执不再被当成"新任务"（内容已随 permission_decision 交付），并记下 `decision_mail_id` 防重复 —— 与 pi 桥同源。 判据：dsh / opencode 各 5 条（含"拿缺陷时的源码形态喂进来必须判红"的自检）。 ## 部署与代价 - dsh → 快照 20260914-081456、opencode → 20260914-081516、homeagent → 新 plugin.bin， 三家的服务 active 且心跳/连接已核。 - 重启 dsh 时它正在"续谈"一封邮件（08:10:45 日志）——事后核对：那一轮**已回完** （faad0037 的 parent = 4919aa88），没有丢活。 - 套件：dsh 372、opencode 323、homeagent go test ok、zcode 382 全绿。	2026-09-14 08:17:23 +08:00
JianFeeeee	453f451fbb	fix(permission): 人类的备注必须到达模型 + 决策回执不再被当成新任务 ... 用户报的「很严重的问题」：被拒绝的 agent 看不到授权备注，且看不到他发的回复邮件。 按数据查到了两个**真缺陷**，都在桥的权限回路上（不是猜测，三层证据）。 ## 缺陷一：备注在桥内被连丢三处 网关其实一路都带着备注（`CreateDecisionMail(..., req.Note)` 把备注写进决策邮件正文， SSE payload 里也有 `"note"`），但桥的三个环节只传 decision： index.mjs `pool.routePermission(relayKey, String(data.decision))` pool.mjs `child.send({type:'permission_decision', relayKey, decision})` worker.mjs `resolve(String(msg.decision))` 模型最终看到的只有 `用户拒绝了这次 bash 调用`（pi 会话转录逐字可查）。 现场：人类写「我说了让你拉取仓库到program下你听不懂吗」，模型不知道要改什么， 把同一条命令换个写法又问了 —— 会话里连问 **9 次**（22:16–22:26）。 ## 缺陷二：决策回执照样被当"新任务"投递 + 等人的邮件被堵在后面 决策是**双通道**送达：SSE `permission_decision`（唤醒停放的 worker）+ 一封普通形状的 邮件（"Re: 权限请求 - 拒绝"）。以前两条都会起动作 ⇒ 同一件事被处理两次；而这条会话 的新邮件在 worker 停放期间只能排队。实测：人类 22:18:08 发出的更正 「不对，不是让你拉取到agentmail仓库，是让你拉取到program仓库！！」 直到 22:26:30（worker 回合结束）才被模型看到 —— **8 分钟**里它一直在错误的目录上打转。 转录里那封更正确实是模型自己 `read_mail` 读到的（不是没人给它）。 ## 改动 - 网关：`CreateDecisionMail` 写 `mail_type='permission_decision'` —— 桥据此区分 「控制面回执」与「新任务」。 - pi 桥（新增 `lib/denial-reason.js`、`lib/waiting-mails.js`）： · 备注随决策一路透传到**模型看到的拒绝理由**（工具拦截与通知投递两条路都带）； · 恢复停放的 worker 时，顺带把「等人期间新到、尚未标记已读」的邮件附进理由， 模型当场就能改道（这正是那 8 分钟的洞）； · 决策回执不再起新任务轮次（记进 deliveredMails）；若决策事件尚未到达， 退化为 B-4.3 的通知投递，且没有会话时不凭空新开。 ## 判据 - `test/permission-note.test.mjs`：11 条（备注进理由、无备注不得凭空造说明、 等人期间的邮件要点名 read_inbox、只挑本会话非权限类未交付的、上限、旧回包缺 session_id 不能丢邮件、接线 8 处形状、判据自检）。 - **扰动验证**：把备注从 `pool.mjs` 的 send 里去掉 → 接线判据 2 条红；恢复 → 11 绿。 - 既有 pi 套件 420/420；server 10 包全绿（新增 1 条 Go 判据验决策邮件的类型与备注正文）。 ## 现场证据（可复核） - 桥日志：9 次 `权限 <key> 决策 同意/拒绝（决策人 jianf）已转交 worker`，全程不含备注； 「worker 2135211 等待权限决策，让出并发额度（停放 1/5）」 - 会话转录：`{"toolName":"bash","content":[{"text":"用户拒绝了这次 bash 调用"}]}` ×6	2026-09-13 22:47:25 +08:00
JianFeeeee	49ec22f916	fix(pi): 等人点头的 worker 不再占并发额度，也不会被硬超时杀掉 ... 实测（今天全 Agent 演练时撞到的）：pi 的 `maxWorkers=3` 被**三个正在等人工授权**的 worker 吃满，于是新邮件只能排队 —— 而人可能十分钟后才看邮箱。清掉卡住的请求后队列 立即排空，机制本身没错，错的是"等待"被当成了"在干活"。 两处改动（`src/pool.mjs`）： 1. **等待期间让出并发额度**。worker 发 `permission_pending` 时把它的 entry 标为 parked，`pump()` 只数"在干活"的（`activeCount()`）。停放另有上限 `maxParked` （默认 5，防止内存无界：每 worker 约 140MB）；超出后仍占额度并打日志说明。 决策到达（`routePermission`）时解除停放，回到额度里。 2. **等待期间暂停硬超时**。硬超时的用途是回收**卡死**的进程，而等人点头不是卡死： 停放时清掉计时器，决策到达后重新起一个完整窗口。否则 worker 会在人还在读邮件时 被 SIGKILL —— 那次工具调用直接消失，人后来批了也没人接（这类"批了没反应"的现象 与此吻合）。 判据（`test/pool.test.mjs` 新增 3 条）： · ★ 等待授权的 worker 让出额度：另一个会话的邮件必须能开跑 · ★ 等人点头期间（800ms > 300ms 硬超时）不得被强杀，且恢复后能跑完 · 停放有上限：超出后仍占额度（不无限超发） **扰动验证**：整块回退到 HEAD → 3 条全红；修复后 3/3。全量 pi 套件 420/420。 已部署（快照 20260913-131216，桥重启并重新心跳）。	2026-09-13 13:14:56 +08:00
JianFeeeee	77699e216b	fix(webui): 新到的授权请求藏在折叠分组里 —— 徽标动了，内容看不见 ... 用户报告："我点到授权界面，才更新显示授权请求"。 先排除了推送本身：实测徽标是**实时**更新的（gui-lab 授权 7→8、jianf 1→2， 都没导航）。问题在内容：`PermissionList` 的展开状态 `const openSet = expanded ?? new Set(autoOpen)` —— 一旦手动点过一次， `expanded` 就冻结成"点的那一刻"的快照，此后新到的待决请求落在一个折叠的分组里： 徽标数字变了，正文却看不见，直到离开再回到授权页（组件重挂载、`expanded` 回到 null、默认展开重算）才出现。 这违反代码自己的设计意图（注释写着「有待决策请求的会话默认展开：那些是在等人 动手的，藏起来等于没解决问题」）。 修法：加一条**状态迁移**判据 —— 新出现的待决邮件（`sessionId:mailId`）让它所在 的会话自动展开。用 mail_id 而不是"会话有没有待决"作判据，是因为实测撞到的正是 "会话早就有待决、用户把它折叠了，之后又来了一条"；而用户在那之后再手动折叠同一 条不会被弹开（没有新 mail_id）。 验证： · 真浏览器复现：授权 2 → 3 而新请求正文不可见，重进页面才可见（复现成功） · 新增 `test/components/PermissionList-autopen.test.tsx`（3 条，含反向对照） · 扰动验证：撤掉修复 → 2 条目标判据红、对照判据仍绿；恢复 → 3/3 · 部署后同一探针复验：折叠状态下新请求**立刻可见**，不再需要重进页面 · 前端 239 测试全绿；桌面重打包与 WebUI 同源（index-jaRgHqX2.js） 顺带修掉一个**更严重的缺陷**（在做「用 zcode 写个网页」时被 agent 自己报出来的）： fix(plugins): zcode 的 read_mail 永远返回空正文 agent 回信原话：「read_mail 返回的正文是空的，收件箱预览在「点击计数…」处被截断」 —— 它因此只看到前两条要求，写出来的页面漏了第 3 条（生成时间）。 根因在 `lib/inbox-format.js` 的渲染端： const body = m?.body_preview || m?.body || ''; lines.push(`内容: ${String(body).slice(0, bodyLimit)}`); zcode 的 read_mail 用 `bodyLimit = 0` 表示"要全文"（HTTP 侧 `?body_limit=0` 也确实是这个语义，服务端返回了完整正文），但这里 `slice(0, 0)` 把正文渲染成 **空字符串** ⇒ 模型永远读不到全文，只能看收件箱里那段预览。 修法：`bodyLimit <= 0` 视为不截断；不截断时优先取 `body`（单封接口可能同时带 `body_preview`，那是短的那个）。四份副本逐字节同源（`check-shared-libs.sh` 通过），每个桥各加 2 条判据：0 = 不截断、不截断时优先全文。 扰动验证：退回旧写法 → 2 条红。 端到端验证：让 zcode 读全文并原样回报最后一行（一个随机标记）。 修复后它精确回出 `最后一行标记：ZTOKEN-2c7561fd` ✓ —— 修复前这不可能。 四家桥都已重新部署到新快照（pi/opencode/dsh/zcode），部署漂移检查： 「四个宿主都在跑当前代码」。测试基线：pi 417 / opencode 323 / dsh 372 / zcode 382。	2026-09-13 10:39:26 +08:00
JianFeeeee	2e28696e74	fix(pi): 模型选择落到「宿主默认」是静默的，而且日志把它说成「平台默认」 ... ## 现场 pi 每封来信都报 `模型 (平台默认) 失败: 402: Insufficient Balance`。 **把它读成「平台的模型没钱了」是错的** —— 真相是： - `modelAttemptOrder(范围, env默认)` 在「平台没划范围 **且** env 没指定」时 返回 `[undefined]`，语义是「交给宿主 SDK 用它自己的默认模型」； - pi.env 里 `AGENTMAIL_REPLY_PROVIDER/MODEL` **都是空的**，而 **opencode.env 里钉了 `llmsproxy`/`AUTO`** —— 这就是为什么其它三桥通、只有 pi 不通； - 于是落到了宿主的默认：`/root/.pi/agent/settings.json` 的 `defaultProvider: deepseek` + `defaultModel: deepseek-v4-flash` —— **直连 DeepSeek 云**（不是本地代理），那边的余额是零； - 而那个名字连本地代理的目录里都没有（目录是 `deepseek-v4.1-flash`）， 所以即使指对了代理也会 403。 ## 修 1. **配置**（`/etc/agentmail/pi.env`）：按 opencode 的约定钉上 `llmsproxy` + `AUTO`，并在注释里写明「留空的语义是交给宿主默认，平台管不着」 —— 这个语义本身就是坑。 2. **代码**：把那句 `(平台默认)` 改成 `宿主默认（平台未指定模型）`， 并在「平台未指定模型」时**显式告警**一次。一句话的日志差别决定了排查方向： 「平台默认」把人引向平台配置，「宿主默认」直接指向 `~/.pi/agent/settings.json`。 3. **断言**：`modelAttemptOrder` 的 `[undefined]` 语义 + 「源码里不能把宿主默认 写成平台默认」（只看字符串字面量，免得注释里的解释也被禁掉）。 ## 验证 - 配置前：`env | grep -i zcode|agentmail` 那条待决请求被拒（它会把 worker 环境里的 `AGENTMAIL_AGENT_KEY` 打进模型上下文）；顺带清扫 9 条早前实验遗留的待决请求。 - 配置后真发一封进 pi 的**已有会话**：6 秒内收到回信，标记原样返回 ✓ - 四桥漂移检查全通过；pi 415 测试全绿；「平台未指定模型」告警在生产日志里出现 0 次 （说明配置确实齐了）。 ## 仍然待定（需要你定） `/root/.pi/agent/settings.json` 的宿主默认 **仍指向 `deepseek/deepseek-v4-flash`**。 它影响**交互式 pi**（人工开着 pi 干活时用的就是它），而且那个模型名不在本地代理目录里。 桥这条路已经绕开它了，但要不要把宿主默认也改成 `llmsproxy/AUTO` （与 opencode 一致）需要你拍板 —— 那会改变交互式会话的行为。	2026-09-12 23:31:44 +08:00
JianFeeeee	630b5bfdd7	fix(bridges): 续谈失败静默 + duplicate_relay 静默挂死（两个都是「人那边什么都收不到」） ... 同一类问题在两个地方：出事的当下看不出来，表现是「信发出去了，然后再无音讯」。 ## 1）pi 的续谈失败不回失败信（实测缺口） 模型侧 402（余额不足）时，**新会话**那条路会回一封「处理失败」，而**续谈**那条路 只写日志就 `throw` —— 发件人什么都收不到。邮件驱动的会话没有本地界面可以看， 没有这封信就等于静默挂死。复现条件很普通：往一条**已存在**的会话再发一封信。 修法与邻居一致：续谈失败也回失败信。但**不能复用**共用库的 `renderFailureReport` ——那段文案说「划定范围内的模型全部调用失败」并建议「调整可用模型范围」， 而续谈是**故意不降级**的（换模型＝换会话＝丢掉上下文，而上下文正是发件人指定 这条会话的原因）。照抄等于让人去调一个在这里无效的旋钮，他会去改配置， 然后发现依然失败。新增 `renderResumeFailure`：点明是续谈、附上游错误原文、 建议「确实要换模型就新建一条会话」。 **活体验证**（模型侧仍是 402，失败本身就是测试条件）：发一封进 pi 的已有会话， 5 秒内收到失败信，内容含 402 原文且不再出现「调整模型范围」。 顺带把 pi 里 2 处没 clamp 的 relay_key 收敛（上一轮审计只看了权限键）。 ## 2）duplicate_relay：只有 zcode 认，另三桥会等一个永远不会来的决策 网关对重复的 relay_key 回 **HTTP 200 `{status:"duplicate_relay"}` 并提前返回**： 不建请求、不发邮件、**永远不会有人来决策**。zcode 桥认它并当场失败，而 pi/opencode/dsh 把它当成功，接着等 `permission_decision` 事件 —— pi 那句 `await new Promise(...)` 连超时都没有。这是 zcode 上一轮那个缺陷的同类， 只是发生在另三个桥上。 - `lib/relay-key.js`（**共用**，四处逐字节同源）新增 `isDuplicateRelay` / `DUPLICATE_RELAY_STATUS`：它长得像成功（200），所以必须单独认；对「发信」 那一侧重复就该当成功（幂等），但对「等一个决定」那一侧它与故障后果相同。 - pi / opencode / dsh 三桥在权限转发处接上判据并**当场拒绝** （各自用自己的拒绝形状：`block: true` / `output.status = "deny"` / `'rejected'`）。 - zcode 里那份本地实现收敛到共用库（同一判据不该有两个定义）。 ## 3）新增接线断言（带判据自检） `test/permission-forward-wiring.test.mjs`（pi/opencode/dsh 三份同一内容）： 纯函数测试对这类缺口天生无能为力（函数是对的，只是没人调用它），所以它读源码 验形态，钉住「判据在、落在权限转发这条路上、给出本桥形状的拒绝」。 三条自检都在写的过程中抓到了我自己的错： - 第一次 `ROOT` 算错 → 过滤后 0 个桥、循环全不跑而「全绿」→ 加了 「找不到装着各桥的目录就判红」； - 顺序判据写成「在文件里最早的 await 之前」，量到了别处的等待 → 三桥全红， 改成「必须在上报之后」； - dsh 是**两段式**（`.then` 里抛、`catch` 的 `duplicateRelay` 分支里拒）， 第一版抽取套错了分支 → 永远找不到 `return 'rejected'`。 扰动验证：把 pi 的判据禁用后该条变红，还原即绿（改动前后都核对了字节数）。 而 dsh 那条也暴露了：我把返回形状写成了 opencode 的 `{status:'deny'}`， **`tsc` 没报错**（返回类型是宽联合），只有对着邻居读才发现 DSH 要的是 `'rejected'` 字符串 + `noteDenial`。 ## 4）部署脚本：zcode 分支现在会重启驱动 `redeploy-plugin.sh` 的 zcode 分支只切软链（宿主是 ZCode 应用，不能重启它）， 但**驱动是我们自己的 unit** —— 不重启它，进程里跑的还是切换前的代码。 这个由刚写的 `check-deploy-drift.mjs` 当场抓到（它比进程启动时刻与软链切换时刻）， 而当时所有其它检查都是绿的。已补上重启并验证。 ## 复查 四桥全量 413 / 321 / 370 / 380 全绿；共用库四方同源；部署漂移四项全通过； 四桥真发真收冒烟（dsh/opencode/zcode 正常回信；pi 因模型侧 402 回失败信 —— 这正是上面第 1 条要修的路径）。 另：写这段时踩到一个自伤 —— 用 `npx asar extract-file <asar> dist/index.html` 检查包内容时，它把文件**写进了 cwd**，正好覆盖掉 Vite 的源码模板 `client/electron/index.html`（下次构建会拿被污染的模板去构建）。已还原并重建， 产物哈希与之前一致。要看 asar 内容请用 `@electron/asar` 的 API（返回 Buffer）， 别用这个 CLI 子命令。	2026-09-12 23:13:48 +08:00
JianFeeeee	d015d3694c	test(zcode): 把门禁判决实验收进仓库（test/manual/gate-e2e.py） ... 它是「yolo + 自有工具面 + 我们自己的门禁」这个姿态**唯一**的决定性验证： 批了→命令真执行（比对文件内容，不只看回信）；拒了→命令真没执行（文件不存在） **且回信把成因说成「人拒绝」而不是「超时」**；同会话第三次调用仍产生新请求 并在获批后执行（幂等键按调用唯一）。之前只放在 /root 下，会随环境丢弃。 顺手修两处会骗人的东西： 1. **不要用 `python3 run.py | tee log` 再取 `$?`** —— 那是 tee 的退出码（恒 0）。 实测踩过：脚本自己打印 5/6（有失败），后台任务通知却报 exit-code 0， 日志里那句 `EXIT=0` 完全是噪声。现在脚本把**自己的** exit_code 写进证据文件， README 也改成 `set -o pipefail` 的调用方式。 （同源问题第三次：PIPESTATUS 在 dash 下报错、`go build | head` 假绿、这次是 tee。） 2. **备注文字不再显示在通过项旁边** —— 通过的判据曾挂着「很可能又被当成重复请求 丢弃了」这种失败提示，会把「全绿」读成「有问题」。 已从仓库路径连跑三次 13/13（不同标记），确认收进仓库后仍可用。	2026-09-12 19:11:58 +08:00
JianFeeeee	a00cbf36fc	feat(zcode): yolo + 自有工具面 + 我们自己的执行门禁（headless 真正能干活了） ... 按用户裁定「yolo_own_tools」实现：平台让开（--mode yolo），它自带的一切 「能动机器」的工具被 --disallowed-tools 拿掉，执行类动作改由我们自己的 run_command / write_file 承担，而门禁就在这两个工具里 —— 逐次向发件人请示。 ## 为什么必须走这条路（实测，不是推断） MCP 工具的 needsApproval 在产物里**硬编码为 true**（与 annotations 无关）， 而 build/edit 档的判定最后一条是「需要审批 → ask」；headless 没有审批客户端 可问 ⇒ **每个 MCP 工具都被拒**（连 read_inbox 都调不动）。 我们本想让平台把询问转给钩子，但 PermissionRequest 在本版本（3.10.2 / CLI 0.16.5） **不可靠**：有时压根不注册，触发时也无条件在 ~5ms 内失败、命令从未被 spawn （用「钩子写 marker 文件」的副作用验证）。 于是选择只剩两个：「平台问、但问不到人 → 全拒」与「平台不问、我们自己问」。 后者才既可用又可审计。代价（平台不再提供第二道防线）写进了 README 的残余风险。 ## 新增 - `lib/approval.mjs`：授权往返的唯一实现（钩子与工具共用，否则必然漂移）。 三条不可动摇的规矩：只有明确同意才放行（判据是共用库的前缀白名单， 不是「不等于拒绝」）；永久失败（409/4xx）当场拒绝并把服务端建议带给模型； 暂时失败看有没有本地界面 —— 判据用**调用方传的 sessionId**（单一事实来源， 不再另读环境变量）。自己开 SSE 等决定，先建连再发请求。 - `lib/action-tools.mjs`：`run_command` / `write_file`。输出上限、超时上限、 默认 cwd=工作区；拒绝时**抛错**（MCP 层转 isError）而不是返回「已处理」—— opencode 上「工具失败但报成功」导致模型连试 6 次后放弃整个任务的教训。 平台保护目录（网关数据库/插件代码/服务单元/密钥目录）**无论谁批准都不写**， 且判定在门禁之前（不消耗人的注意力）——防的是自我强化：邮件驱动的 Agent 可能被来信诱导去改自己的插件代码，改完下一轮就换了一套规则。 - `REVIEWED_DENYLIST`（32 项）：逐条按「不拿掉会怎样」分类。名单来自 CLI 产物里 模型可见工具名的**权威注册表**（aIn 那个 28 项数组）+ 另一份更宽的候选集并集， **不采信模型自述**（基线里它用某个没点名的方式真的创建了文件）。 最容易被漏掉的是 `js` / `mcp__node_repl__js`：它挂在 MCP 上、 产物里自述「can run arbitrary JavaScript with full Node privileges, like Bash」。 - 提示词的能力说明（分档）：告诉模型自带工具被禁、动手要用哪两个工具、 会被请示；并明确「被拒是业务结果，不要重试、不要绕道」。 ## 修掉三个真缺陷（都是实测撞出来的） 1. **幂等键按「会话+工具」取 → 同会话第二次调用被静默吞掉**。 网关对重复 relay_key 返回 **HTTP 200** `{status:"duplicate_relay"}` 并提前返回： 不建请求、不发邮件、**永远不会有人来决策**。于是工具干等 → 被 MCP 调用超时 砍掉 → 模型回报「30 秒内未获批准」。从状态码到措辞全看不出问题，归因还完全 错了（像是人没理它）。改为**按调用唯一**（保留会话/工具前缀便于反查）， 并把 duplicate_relay 当成可读的拒绝（fail fast，不再干等）。 2. **授权窗口被 MCP 调用超时截断**。ZCode 对 MCP 工具调用有超时（默认量级 30 秒）， 而门禁要等人。已在插件清单声明 `mcpServers.agentmail.timeoutMs=600000` （实测生效：40 秒的命令没被砍，墙钟 50 秒通过），并让门禁**自己**把等待夹到 timeoutMs - 余量之下（`resolveWaitMs`）——被客户端杀掉时连理由都发不出去， 所以必须由我们自己先 settle。 3. **`--allowed-tools` 在 help 里写着但解析器不认**（`Unknown option`）。 留着会拼出一条永远跑不起来的命令行，现在 `buildRunArgs` 直接抛错并指出 替代方案。我在这里误判过一次：先看到「文件没创建」就以为白名单生效， 其实进程只是没退到 usage。判据缺了「进程真的执行了」这一环。 ## 自报改成如实 detectModeEnforcement 以前拿「钩子已注册」当 native 的凭据 —— yolo 下钩子 根本不会触发，那等于替一个不存在的能力背书。现在先看**我们那条链**是否就绪 （yolo + 禁用清单里真的有 Bash/js），就绪才报 native，并在理由里点明谁在把关 （实测输出：「执行类动作只能经我们自己的门禁…平台自带危险工具已禁用 32 项」）。 ## 验证 - 单测 376/376（新增 47 条）。重点在反向对照：一句「拒绝/deny/空串/平台自己的 shutdown 哨兵都不放行」之外，还验了「别人的决策不能拿来用（relay_key 配对）」、 「超时必须真的拒绝」、「同一会话两次调用必须用不同的幂等键」、 「重复请求要当场拒绝而不是干等」；执行工具的每条拒绝场景都配一个**文件系统断言** （「抛错了」不等于「副作用没发生」），保护目录还验了 `..`/`./` 绕不过去。 - 真模型端到端（`/root/e2e-zcode-gate/run.py`，13/13）： 批 → 命令真执行（文件内容=标记）；拒 → 命令真没执行（文件不存在） 且回信把成因说成「人拒绝」而**不是**「超时」；同会话第三次调用仍能产生新请求 并在获批后执行。判据本身也修了两处（授权请求邮件里带标记会被误当成回信； 备注在通过项旁边显示会误导）。 - 部署：`deploy/redeploy-plugin.sh zcode` 快照切换 + 握手自检； 驱动单元改为跑快照（生产不跑仓库工作区），env 与清单超时的关系写进注释。 - 顺手清掉一个遗留驱动进程（跑的是仓库路径的旧代码、连着网关 SSE、会抢邮件）。 ## 判据纪律（本轮又踩到、已写进代码注释） 「文件没被创建」不能区分「被拦住了」与「进程根本没跑」； 「未获批准」不能区分「人拒绝」与「窗口被截断」； 「工具报错」不能区分「命令失败」与「工具坏了」。 每一处都改成了验到**具体成因**。	2026-09-12 19:05:54 +08:00
JianFeeeee	10ff50e899	feat(homeagent): 输出通道改造 —— 通道名 email + 注入通道对齐 + 附件走路径 ... 修的是内核的交付判定与我们对不上的问题。 ## 根因 内核判断「这一轮到底有没有交付」**只认工具名前缀** `output_send__*` （internal/agent/core/process.go 的 isOutputDeliveryTool）。而 `send_mail` 是个普通工具，长得和 read_inbox 没有区别 —— 模型用它发完信，内核不知道 回复已经交付，照常补一句「请根据以上工具结果继续。」。模型把这句话读成 「还要再做一步」，而它手里唯一能做的「一步」往往又是再发一封信。 这个自我强化循环在 QQ 上有过真实事故（单轮 34 次 output_send__qq、514 秒）。 三处改动，缺一不可： 1. **通道名 `homeagent` → `email`**（按投递介质命名，与内核自带的 qq/webui/cli/acp/a2a 一致），内核据此拼出 `output_send__email`。 能力位声明必须与实现一致：原先声明了 CapFile 而 handler 不读 `type`， 于是任何 type=file 都会静默变成一封「把路径当正文」的邮件 —— 声明一个做不到的能力比不声明更糟（调用方无从发现）。现在 caps=7 且真的实现 text/file/image。 2. **注入来信时用通道名，不再用插件名**。内核的约定是「用回复该走的通道名 注入」：webui 传 "webui"，clawhubadapter 传它自己的通道名。我们原先两个 参数都传 `homeagent-mail-bridge` —— 那个名字**不是一个已注册的通道**， 于是注入来源、模型被告知要用的通道名、实际注册的通道名三者对不上。 3. **提示词补上平台特有的投递指引**（channel.go 的 deliveryHint）。 共用的 replyInstruction 对人来信说的是「回信不用你自己发，插件会替你转发」 —— 那句在 dsh/opencode/pi 上完全正确，在 HomeAgent 上却与内核的 persona （「必须显式调用 output_send__{通道名}」）相反。实测：模型听我们的、 返回纯文本、插件兜底转发，邮件确实到了，但内核不知道已交付。 现在两条口径对齐：优先走通道，兜底 relay 仍然生效且**不会重复发** （通道 handler 先 noteExplicitChannelSend，自动 relay 据此让位）。 同时按新纪律在 plg.json 声明 `sdk: "1.2.0"`；工具链据此同步了 go.mod 的 require/replace（它自己写的，含 store 里的绝对路径 —— 换机器跑一次 hmapdev build 会重新同步）。 ## 验证（真模型、真网关、真邮件） 进程构建：`hmapdev build` 报「SDK 1.2.0（项目声明 sdk=1.2.0）」、 子进程模式（协议 2）；go vet 干净、go test 通过。 部署：经内核自己的 pluginmgr（POST 127.0.0.1:9876/plugins，overwrite=true） 0.1.0 → 0.2.1 → 0.2.2，每次 config_kept=true；重启后 loaded/alive/心跳齐全， 插件日志「注册完成（15 个工具 + 1 个输出通道）」。 行为端到端（两封真邮件）： - 让模型列出通道 → 回信里列出 `email | text / file / image`，与注册的 caps=7 及描述逐字一致 - 让模型「原样重复标记」→ 内核日志 `executing tool: output_send__email`， 回流**恰好 1 封**，插件日志「模型已自行回复，跳过自动 relay」 - 让模型建文件并以 type=file 发送 → `cmd_run` → `output_send__email_help` → `output_send__email`，附件 chan-file-*.txt（15 字节）原样到达，relay 让位 这两条正是改造的两个动因：内核认得交付（循环被切断），以及附件走 「一个本地路径字符串」而不是 `attachment_ids=[...]` 数组 （opencode 上模型把数组写成 JSON 字符串、连试 6 次放弃整个任务的那个失败模式， 在结构上就不存在了）。	2026-09-12 17:38:32 +08:00
JianFeeeee	3a6d572020	feat(zcode): 工具加 MCP 注解 + headless 档位映射改为 plan（否则一个工具都用不了） ... ## 逆出 ZCode 的 MCP 权限判定，并据此让工具真的可用 逐字逆自 CLI 产物： Ari(): annotations.readOnlyHint === true → riskLevel "low" annotations.destructiveHint === true → riskLevel "high" needsApproval = true ← **硬编码为真，与注解无关** checkBuildMode(): needsApproval || destructive || sideEffectScope !== "none" → ask checkPlanMode(): permissionName === "mcp" && !destructive → allow 两条合起来的结论不直观但很关键： - **build 档下每一个 MCP 工具都要审批**（needsApproval 恒真），而 headless 模式没有交互式审批客户端 ⇒ 全被拒。实测：模型连 read_inbox 都调不动， 只能从提示词里猜；更糟的是它**绕道**用 Bash 去读网关的 sqlite WAL 文件 （它自己在回信里如实交代了这件事）。 - **plan 档下只要不声明 destructive，MCP 工具直接放行**。 于是两处改动： 1. `lib/tools.mjs` 给每个工具加真实注解（读类 readOnlyHint，写类 destructiveHint:false——它们确实不破坏任何东西）；`lib/mcp-rpc.mjs` 透传 annotations。**漏传不是"少个提示"，而是工具在该档下全被拒**。 2. `src/turn-mode.mjs` 的 workspace 档映射从 build 改为 **plan**。 build 在本环境等于「什么都不能做」，那不是保守而是不可用；plan 才是真的 fail-closed：危险的自带工具被平台直接拒，能用的只有我们声明为非破坏性的工具。 日志会明确写出为什么退档。可用 `AGENTMAIL_ZCODE_MODE_MAP` 覆盖 （平台修好钩子后只改配置就能恢复 build，不必等发版）。 ## 真模型验证 场景 A 的判据同时加强：**正文本标记只出现在邮件正文里**（驱动的提示词只带主题 与 mail_id），所以模型必须真的读信才可能答对。通过 —— 约 20-30 秒一轮。 反过来说，早先那版「通过」是假的：标记在主题里，模型从提示词抄一遍就行。 ## 仍然做不到的（见 README 已知缺口） 授权桥（PermissionRequest 钩子）在本版本（3.10.2 / CLI 0.16.5）**不可用**： 有时根本不触发，触发时在 ~5ms 内失败且**命令从未被 spawn** （用「钩子写 marker 文件」的副作用验证，process 与 command 两种类型都一样）。 所以 workspace 档「危险操作问人」目前在 headless 下无法实现。 单元 329/329。	2026-09-12 16:49:28 +08:00
JianFeeeee	42816b4d1e	fix(zcode): 真模型跑通后发现的三处缺陷（register / 工具活动日志 / SSE 关停） ... 真模型端到端（场景 A 通过：6893 事件、175 秒、530 字回信）把三处只有真跑才 暴露的问题照了出来： 1. **register 调不通**：驱动按 pi 的客户端 API 写了 `client.register()`， 而本插件的 GatewayClient 没有这个方法 —— 靠此前手工注册过才没暴露。 补上后才发现第二个坑：`/agent/register` 的认证与其它接口**不同**， 它只认 `Authorization: Bearer` 或 **body 里的 `secret`**，不认 `X-Agent-Secret` 头（其它接口认）。实测报错： HTTP 400 需要 Authorization: Bearer <密钥> 或 body 里的 secret 所以没密钥时把 secret 放进 body。 2. **一轮 6893 条事件，日志里什么也看不见**：邮件驱动的会话没有界面， 「模型正在干什么」只能来自日志，否则一个五分钟的回合与一个卡死的回合 在外部完全一样。新增 `describeRunEvent`，只记工具调用与权限事件 （全记等于没有日志），并由 runTurn 通过 onEvent 逐个交出来。 3. **关停没真断 SSE**：驱动调的是 `client.stopSSE?.()`，而客户端没有这个方法 （`?.` 让它静默变成空操作）。改成持有 createSSEClient 的句柄并在关停时 stop。 验证：单元 325/325、授权桥 e2e 5/5、驱动 e2e（桩）7/7、快照握手 12 项。	2026-09-12 16:16:37 +08:00
JianFeeeee	6a7356ebe7	fix(zcode): 软链部署下入口静默不执行 + 部署脚本支持 zcode 快照 ... ## 缺陷：入口判断不解析软链 → 生产形态下 main() 从不执行 `mcp/server.mjs` 与 `src/index.mjs` 都这么判断是否被直接执行： import.meta.url === `file://${process.argv[1]}` 而 ESM 的 `import.meta.url` 是**解析过软链的真实路径**，argv 是命令行里写的那个。 生产布局是软链（`/opt/agentmail/plugins/<name>/current` → 时间戳目录）， 于是两者不等、`main()` 从不执行：**没有输出、没有报错、退出码 0**。 它是被部署脚本的后置验证抓到的：第一次从快照起 MCP 服务器时 「握手 0 个工具、stderr 一个字都没有」，而同一个文件从仓库路径跑完全正常 （仓库路径没有软链）。这类缺陷只在部署形态下出现，本地怎么试都对； 表现（静默成功）又与「功能没被调用」一模一样。 修法：新增 `lib/is-main.mjs`，**两侧都 realpath** 后比较（只归一 != 「同一文件」）。 单测含目录软链、文件软链、文件不存在（保守判否，避免被 import 时误跑一遍）。 ## 部署脚本：引入 HOST 概念，四个插件一条部署路径 pi/opencode/dsh 的宿主是 systemd 单元，zcode 的宿主是 ZCode 应用本身 —— 没有我们的单元可重启。于是： - `HOST=systemd`：重启单元 + 看网关库里有没有新心跳（原有判据） - `HOST=zcode`：**从快照起一次 MCP 服务器并走完握手**，这与 ZCode 加载插件 走的是同一份入口代码；另查 `plugins list` 报告的路径是不是 current 后置验证带**判据自检**：握手函数对坏路径必须返回 0，否则判据本身失效就拒绝通过。 计数用 `grep -o | wc -l` 而不是 `grep -c` —— 每条响应只占一行，tools/list 的 11 个工具名全在同一行，用 -c 会得到 2，把好快照判失败（实测踩过）。 ## 生产已切到快照 `/opt/agentmail/plugins/zcode-mail-bridge/current → 20260912-150547`， `~/.zcode/cli/config.json` 的 `plugins.dirs` 已指向 current， `zcode plugins list` 报的路径就是快照路径。仓库不再是生产代码。 验证：单测 325/325；快照握手 12 个 name 字段；官方 __zcode-plugin-host 从快照 启动正常；钩子从快照跑通 409 → block；坏路径能被握手判据发现（反向对照）。	2026-09-12 15:06:49 +08:00
JianFeeeee	c5e1d562eb	feat(zcode): 邮件驱动 —— 收到来信就自动开工，并把结论回信 ... 第三步（补齐一等 Agent 的另一半）：驱动进程订阅 SSE，按邮件起一轮 headless ZCode，取最终文本回信。 ## --mode 是必传的（不传等于关掉授权系统） ZCode 的权限判定里 `mode === "yolo"` 一律 allow （"Yolo mode bypasses permission prompts"），而 `--prompt` 的默认 mode **就是 yolo**。 所以驱动不传 --mode 时：授权钩子根本不会触发，整个授权系统**静默消失** —— 不报错，只是没有任何询问，看起来一切正常。 档位映射（依据是 CLI 产物里的规则表，不是猜）： plan → --mode plan （mode.plan.nonReadOnly：非只读一律拒） workspace → --mode build（mode.build.highRisk / sideEffect：Bash/Write/Edit → ask） full → --mode yolo （刻意绕过） buildRunArgs 收不到 mode 直接抛错；测试里有一条反向对照钉住「只有 full 能得到 yolo」， 含大写 FULL（共用库 normalizeMode 严格匹配，落回 default 而不是 yolo —— 好性质，也钉住）。 ## 一轮怎么跑 node <zcode.cjs> --prompt <提示词> --output-format stream-json \ --cwd <工作目录> --mode <m> [--resume sess_xxx] --max-turns N 用 stream-json 而不是 --json：`--json` 全程无输出，一个卡住的回合与一个正在 干活的回合在外部完全一样，而邮件驱动的会话没有界面，日志是唯一能看见它的地方。 输出契约（逐条事件 + 末尾 {type:"result",sessionId,response}）同样逆自 CLI 产物。 会话延续靠 --resume + 存回的 sess_…：丢了它模型每封信都从零开始。 ## 回信策略（与另三桥同源） - 人来信 → 自动把本轮最终文本回过去（relay:'summary' + relay_key 走免配额通道） - Agent 来信 → **不**自动回（Agent 间必须自己 send_mail，否则两边把对方的 「已收到」当待办，无限客套） - 一轮跑不起来 → **必回**失败信，且给出 ZCode 自己的成因（没登录/缺模型配置/ CLI 路径不对）。没有本地界面时，什么都不发等于「信发出去了，然后再无音讯」。 刻意不复用共用库那份 renderFailureReport：它的建议是「调整可用模型范围」， 对 ZCode 什么也解决不了。 - 模型这一轮自己发过信 → 让位。工具跑在 ZCode 派生的 MCP 服务器**进程**里， 与驱动内存不通，所以经 lib/explicit-sends.mjs 落盘对齐（不记的后果线上实测过： 收件箱里两封说同一件事的邮件，311 与 342 字节）。 ## 两处健壮性（都是实现时自己发现的真问题） - 超时必须**必然** settle：既不退也不报错的孩子会让 Promise 永不 settle， 而队列是串行的 → 那封信永远挂住、后面的信全都不再被处理。 现在 SIGTERM → SIGKILL → 无论如何收尾；定时器刻意不 unref （unref 过的定时器让「没有其它句柄」的进程直接退出，收尾根本没机会跑）。 - 关停时终止在途回合：否则 systemd 杀掉驱动后那个 ZCode 还在跑工具， 而既没有驱动看着它、也没有本地界面看着它。 ## 自报强制力只声明得出来的事 驱动启动时读自己的 hooks/hooks.json，确认 PermissionRequest 已注册才报 native， 否则报 advisory 并在日志里写明原因 —— 不替一个不存在的能力背书。 ## 验证 - 单元 320/320（新增 90 项：turn-mode 8、zcode-run 17、driver 19、prompt 14 + 继承的共用测试；含反向对照） - 邮件驱动端到端 7/7 × 3 次连跑稳定：桩 CLI 替掉 ZCode，真网关真邮件 —— SSE 订阅、去重、工作目录、档位映射、参数拼装（--mode 必须对）、 stream-json 解析、回信、Agent 来信不回、CLI 失败必回失败信 - 授权桥端到端 5/5 × 3 次连跑稳定 - 共用模块四方同源（新纳入 catchup/relay-dedup/relay-policy/workspace， 反向验证：让 workspace.js 分叉会被抓住） ## 我自己写错并被测试抓出来的三处（值得记） 1. 验证脚本把人类发信写成了 /api/v1/mail/send（**Agent** 路由）→ 401。 报错「Missing Authorization: Bearer …」其实已经指明走错了路由表。 2. findReply 按「驱动验证（人）」这种片段找，第二次跑时命中了**上一轮遗留的回信** → 正文比对失败、后续参数核对变成「无法判定」。收件箱是跨轮次共享的持久状态， 必须按唯一 marker 定位（与之前「待决权限列表」那次是同一类错误）。 3. 停旧驱动只发 SIGTERM 不等退出 → 新旧两个驱动同时订阅 SSE， 同一封信被回两次，判据取到哪封取决于时序 → 时灵时不灵。改成等 exit 事件。 另：桩脚本用 process.exit 截断管道写入，导致 stderr 时有时无 —— 改用 exitCode。	2026-09-12 14:58:36 +08:00
JianFeeeee	c774904c0c	feat(zcode): 授权桥 —— PermissionRequest 钩子把危险工具授权交给人 ... 第二步：让 ZCode 上的 Bash/Write/Edit 授权走 AgentMail 的人工审批， 而不是只靠本地界面。 钩子契约从 CLI 产物里逆出来（不猜协议）： - 输入走 stdin：{hook_event_name, tool_name, tool_input, session_id, permission_mode…} - 输出走 stdout，schema **严格**：{"decision":"approve"} / {"decision":"block","reason"} 多一个键就会报 "Hook stdout failed HookJSONOutput schema validation" - 空输出 / 不以 { 开头 = 不表态；exit 2 = 拒绝；其它非零 = 钩子失败 - 注入的环境变量含 ZCODE_PLUGIN_ROOT / ZCODE_PLUGIN_DATA / ZCODE_SESSION_ID （MCP 配置里用 ZCODE_SESSION_ID 反而会抛「需要运行时会话上下文」） 档位判定与 pi 桥逐条对齐（plan 直接拒 / workspace 问人 / full 批准）， 判定逻辑抽成纯函数 lib/hook-policy.mjs 以便穷举： 其中 full 档必须**返回批准而不是不表态** —— 钩子一旦触发说明 ZCode 本会去问人， 不表态等于让那个询问照常发生，full 档就退化成了 workspace 档。 钩子自己开 SSE 等决定，不依赖桥进程：网关的 SSE 是扇出的 （clients 按唯一 id 存，SendToAgent 推给该 Agent 的所有客户端）， 一次性进程也能订阅到自己那条 permission_decision。这样交互模式下同样可用 （人自己开着 ZCode 干活时并没有桥在跑）。先建连再发请求是有意的： 反过来会有一个窗口，人在窗口内点的同意推送给当时还不存在的客户端。 fail closed 但区分模式：永久失败（409/4xx）一律拒绝；暂时失败在 AGENTMAIL_SESSION_ID 非空（邮件驱动、没有本地界面兜底）时拒绝， 交互模式则不表态让人就地决定。 「一直同意」落盘（lib/grants-file.mjs）：钩子是一个事件一个进程， 不落盘那个选项就是骗人的。判定仍交给共用的 permission-grants.js。 共用模块同源范围扩到 9 个（新增 permission-mode / relay-key / permission-grants / sse-client）—— 档位语义与决策判定分叉会让「同意」 在 ZCode 上悄悄变成另一种意思。 验证： - 单元 229/229（新增 hook-policy 14 项、grants-file 8 项，含反向对照） - 共用模块四方同源检查通过 - 授权桥端到端 5/5，全部带反向对照： 同意→approve；拒绝→block 且原因必须来自人的拒绝（不能是超时兜底）； plan 档拒绝且**不产生**任何权限邮件；无人可问(409)→fail closed； 非守卫工具→不表态 - `zcode plugins list` → agentmail@inline [enabled]，hooks: 1， mcp: plugin:agentmail:agentmail 我自己写错的两处判据（都已修，值得记下）： 1. 待决权限列表里有历史积压（实测 6 条，含其它 Agent 的条目）， 只按「第一条新的」取会拿到无关请求 —— 于是人点了同意而钩子在等自己那条， 最后超时。第一版还把这个超时误报成「拒绝路径通过」。 现在按「启动前快照差集 + session_id + agent_name」三重过滤。 2. 「无人可问」控制组最初传了个非 UUID 的 session id，走的是 400（参数错）， 验不到 409 那条真实路径。改为真的造一条只有 Agent 没有人类的会话。	2026-09-12 14:09:10 +08:00
JianFeeeee	e0e6f86d94	feat(zcode): AgentMail 的 ZCode 插件 —— MCP 工具面 + 官方宿主启动验证 ... ZCode 用插件扩展能力（.zcode-plugin/plugin.json 声明 skills/commands/hooks/ mcpServers），所以适配它的正确形状是**插件**而不是又一个独立桥进程。 本提交是第一步：把 AgentMail 的工具面做成 MCP 服务器。 协议层（lib/mcp-rpc.mjs）手写，不引 @modelcontextprotocol/sdk： 协议面只有 initialize / notifications/initialized / tools/list / tools/call， 手写可省掉一条构建链与 1MB 打包产物（与 pi/opencode/dsh 三桥零运行时依赖的 取向一致），并让这一层成为可穷举的纯函数。分帧照官方插件产物实测确认是 换行分隔 JSON（Content-Length 出现 0 次，StdioServerTransport + split("\n")）。 工具面（lib/tools.mjs）与另三个桥**同名同参**，渲染走共用的 addressing/inbox-format/discovery（逐字节同源，已纳入 check-shared-libs.sh）。 测试里有一条断言直接拿 pi 桥的工具名做对照：少一个就让某平台行为与其它平台不同， 那种问题只在单平台复现，排查代价最高。 两处按真实缺陷定的行为： - 工具失败回 result+isError 而非 JSON-RPC error —— 后者会让模型看不到失败原因， 只能重试（opencode 连试 6 次发不出附件正是这个后果） - attachment_ids 声明放宽为 anyOf 数组/字符串并在桥侧归一 —— 模型常写成 JSON 字符串，服务端严格解码会拒（同样来自 opencode 那次失败） 入口 mcp/server.mjs 修掉一个真实缺陷：stdin 关闭即 process.exit 会杀掉在途请求， 表现为「协议全对但访问网关的调用完全没有响应」。现按在途计数 drain， 且把 stdout 写入也计入，避免最后一条响应卡在缓冲区。 顺带修 check-shared-libs.sh 的一个既有假绿：本机 PATH 上的 diff 是鸿蒙 SDK 工具链的 diff，不认 -q 且对不同的文件仍返回 0 —— 于是该检查器**一直是永真输出**。 改用 cmp -s，并加自检（判据本身必须先被证明能发现差异）。反向验证： 让 zcode 或 pi 的共用模块分叉，检查器都正确报错并返回 1。 验证： - 单元 33 项 + 继承共用测试 87 项 = 120/120 - `zcode plugins list` → agentmail@inline [enabled]，mcp: plugin:agentmail:agentmail - 经官方 `node zcode.cjs __zcode-plugin-host <server.mjs>` 启动 → 握手与 tools/list 正常 - 真实网关调用：以 zcode 身份 read_inbox / suggest_address / list_contacts 均返回	2026-09-12 13:47:51 +08:00
JianFeeeee	4b1946ccb4	fix(dsh): 补共用库类型声明 + 测试前强制构建 —— 堵住两个会静默通过的通道 ... # 1. 缺 .d.ts 导致构建失败（上一提交引入） `lib/attachment-ids.js` 是上一提交新增的共用库，但没配 `.d.ts`。dsh 桥走 TypeScript 编译，于是： src/index.ts(65,40): error TS7016: Could not find a declaration file for module '../lib/attachment-ids.js' pi 与 opencode 不做类型检查，所以只有 dsh 会在这里红 —— 很容易被当成偶发放过。 补上声明，类型刻意写成 `unknown`：这个函数的全部意义就是接收**不可靠的输入**， 用 `string[]` 收窄签名会让人误以为调用方本来就该给对形状。 # 2. 测试从 dist/ 导入，却不先构建 → 可以测到改动前的旧产物 dsh 的测试有两类导入：`../lib/*.js`（直连源码）与 `../dist/index.js`（编译产物）。 test 脚本原本是纯 `node --test`，**不先构建**。于是「改 src → npm test 全绿」 完全可能只验证了旧 dist —— 实测就踩到了：提交前那次 361 通过跑的是改动前的产物， `lib` 本身有覆盖（attachment-ids.test.mjs 直连 lib），但**入口的接线没被测到**。 加 `pretest: tsc -p tsconfig.json`（npm 会在 test 前自动执行）。 反向验证：往 src 注入一个类型错误后 `npm test` **EXIT=2**（构建先失败）， 而不是拿旧 dist 蒙过去；恢复后 361 通过 / 0 失败。	2026-09-12 11:36:03 +08:00
JianFeeeee	b374ce1f20	fix(plugins): 附件 id 归一 —— 修 opencode「做完全部活却发不出附件」 ... # 现象（全功能演练抓到，根因来自 opencode 自己的内部记录） opencode 把四个步骤全做完了（2× download_attachment、read 读到内容、 upload_attachment 成功），却在最后一步卡死：`send_mail` 连续 **6 次**失败， 然后放弃整个任务，自述为「attachment_ids 参数有框架级序列化 bug」。 真实形状（从 opencode 的 part 表里取出的原始输入）： input.attachment_ids = "[\"10e73e9f-c2a9-4226-bdb5-34ef1b340eb8\"]" ← 字符串 error: 字段 "attachment_ids" 类型不对：期望 string 数组，收到 string 模型把数组写成了 **JSON 字符串**，桥原样转发，服务端的严格解码器按契约拒收。 # 修在哪一层 **不在服务端放宽。** 那个「严格」是刻意的，挡的是字段名拼错、结构写错这类真 错误 —— 松开之后真 bug 会被静默接受（同一封邮件少几个附件，HTTP 仍是 200）。 **在桥这一层收。** 桥是适配器：模型侧的形状天生不可靠，而适配器的职责就是把 不可靠的输入归一成契约要求的形状。对模型宽容、对服务端严格 —— 这与 homeagent 那个 Go 插件里的 `stringList` 是同一个判断（那边注释写着「也接受 单个字符串……拒绝它只会换来一次重试，而意图毫无歧义」）。 接受的形状：数组 / JSON 数组字符串 / 单个 id / 逗号或空白分隔 / 混进 null 与数字时丢掉坏的保留好的。空串与 null 一并丢掉，与服务端 `parseAttachmentIDs` 保持一致。 # 三桥同源 新增共用模块 `lib/attachment-ids.js` + 同名测试，已加入 `deploy/check-shared-libs.sh` 的两个清单（实现与测试都必须逐字节相同 —— 只同步实现不同步测试，等于允许一侧偷偷放宽约定）。 三份 md5 一致，检查脚本通过。 # 测试 `test/attachment-ids.test.mjs` 17 条，三桥各一份。含**反向对照**：把 JSON 字符串 分支去掉后必须变红（实测 3 条失败）—— 否则这条判据就是空转，事故会复发。 全量：pi 401 / dsh 361 / opencode 312，0 失败。	2026-09-12 11:20:13 +08:00
JianFeeeee	a60ab66a40	refactor(plugins): 删掉「摆了一套权限规则却没人调用、且形状没人能消费」的死代码 ... # 问题 `lib/permission-mode.js` 里的 `opencodePermissions(mode)` 实现完整、注释详实 （含 6 条实测结论）、还有 9 条测试把行为钉住；opencode 的 `index.js` 第 45 行 确实 import 了它 —— 然后**全文件再没有第二次出现**。 静态审计要花力气才能发现它是死的，而读代码的人会理所当然地以为 「opencode 的 plan 档由这套规则拦着」。实际 opencode 是 advisory。 比 9.17（给了按钮不实现）更深一层：那只是没实现，这个是**看起来像实现**。 # 它不只是没接上，而是接不上 查 1.18.29 的 SDK 类型定义，三条都排除： SessionCreateData.body 只有 { parentID, title }；query 只有 { directory } → 会话级根本没有 permission，也没有 agent permission 只存在于 Config / AgentConfig，且是 map 形状 → { edit, bash, webfetch, doom_loop, external_directory } → ask|allow|deny Permission 事件（permission.updated 的 properties）没有 action 字段 → { id, type, pattern?, sessionID, messageID, callID?, title, metadata, time } 而函数返回的是 `{permission, action, pattern}[]` —— **与三者都不匹配**， 并且 deny 了 `task`（本版本 permission 的合法键里没有 task）。 所以不是「加一行调用就生效」，而是**输出没有任何消费者**。 # 为什么 opencode 的 per-session 强制做不到（如实说明） Config / AgentConfig 是配置文件级（全局或项目级）。邮件桥若靠改配置给某条会话 加 plan 限制，会连带锁住这个人**其他所有**会话的同一工具 —— 一条 plan 档的邮件 把人身兼的其他工作一起禁掉，不可接受。 opencode 目前唯一的拦截路径是「它自己先问 → 桥转发 → 服务端按档位 409 → 桥当场 block」，**前提是它的配置恰好是 ask**；若配置直接 allow，桥连 permission.updated 都看不到。这就是它只能是 advisory 的原因，不是缺工作量。 # 改动 - 删除 `opencodePermissions` 及其 doc 注释、`OpencodePermissionRule` 接口声明 （三份共用库同时改，改后 md5 仍逐字节相同） - 删除 opencode/index.js 里那行未使用的 import - 删除 9 条针对该函数的断言（三桥各 9 条） - **6 条实测结论没有丢** —— 搬进 `docs/PLUGIN-CONTRACT.md` 新增的 §9.18， 连同上面那三条类型证据与「为什么 per-session 做不到」 删掉而非保留，是因为留下的就是陷阱：函数存在、注释写着「实测过」、 测试还全绿，唯一缺的是调用点 —— 下一个人会以为档位在这里被强制。 # 验证 - `deploy/check-shared-libs.sh` → 共用模块三方同源 - 三桥 `npm test` 全绿：pi 400 / dsh 360 / opencode 311，0 失败 （删除前 pi 409 / opencode 320，各 −9 即被删断言；dsh 另有并发提交新增测试， 净 −9 后为 360） - `node --check` 四个改动文件全过；ESM 动态 import 该 lib 成功， 导出里已无 `opencodePermissions`，index.js 只引用仍存在的符号 - 本改动不影响运行时行为（删的是一个从未执行的函数与一个未使用的 import）	2026-09-11 23:59:24 +08:00
JianFeeeee	f11415834a	test(dsh-mail-bridge): 断言真实注册的工具都带 type:object ... 上一个 commit 只断言了编译函数的输出；那个测试对一个**运行期** bug 是无效的： bug 的本质是 defineTool 在 ESM 下静默降级，源码看着没问题、注册出去的是裸映射。 所以这里跑**真实的 apply()**，用假 ctx 截下 ctx.tools.register 的入参逐个断言 —— 源码怎么写都不算数，注册出去的东西才算数。 要点： - 工具注册包在 ctx.effect() 里，假 ctx 必须真的执行该回调 - effect 里会起 SSE，故放子进程跑并在拿到结果后主动退出 - 断言前先确认注册数 >= 11，避免在空集合上假通过 实测该测试能抓住修复前的形态（parameters 顶层键就是 gateway_url/key_token， 没有 type/properties），并单独覆盖被上游拒过的 connect_to_server。	2026-09-11 22:28:47 +08:00
JianFeeeee	e9df62a565	fix(dsh-mail-bridge): ESM 下 defineTool 静默降级导致工具 schema 非法 ... 现象：dsh 经 llmsproxy AUTO 走到 gozen 时 400： Invalid schema for function 'connect_to_server': schema must be a JSON Schema of 'type: "object"', got 'type: null'. 根因：插件 package.json 是 "type": "module"（ESM），而源码用裸 require.resolve / require 载入 @deepseek-ai/dsh-tools。ESM 里 require 是 undefined，require.resolve 抛 ReferenceError，被 catch { return opts; } **静默吞掉** —— defineTool 恒等返回，工具的 parameters 以**未编译的裸映射** 注册： { gateway_url: {type:'string'}, key_token: {type:'string'} } // ❌ 而不是合法形态： { type:'object', properties:{ gateway_url:…, key_token:… } } // ✅ 后果波及全部 11 个 mail-bridge 工具。严格的上游直接 400（实测 OpenCode Go）， 宽松的（Claude 系）不校验 —— 所以只在特定 AUTO 档位暴露，表现为「某个模型 突然不能用了」。 修法： 1. 用 createRequire(import.meta.url) 取得合法的 require（ESM 标准做法）。 2. 兜底也必须产出**合法** schema —— 新增 parametersToJsonSchema，在 dsh-tools 不可用时自己编译：required:true 提升到根级 required 数组 （JSON Schema 不允许属性自带 required），type:object 必补。 绝不再静默把裸映射发出去 —— 那比直接报错更难查。 实测 11 个 mail-bridge 工具全部产出合法 schema，包括真机被拒的那个 connect_to_server。测试 test/tool-schema.test.mjs 覆盖：裸映射编译、 required 提升、数组 items、空 spec、被上游拒过的实际工具。	2026-09-11 22:12:01 +08:00
JianFeeeee	4050827e5c	feat(permission): 新增第三种强制力 partial —— DSH 如实自报，不再冒充 native ... # 问题 审计发现 DSH 自报 mode_enforcement=native，而实测它的 Landlock 沙箱受内核 ABI 版本限制、拦截覆盖不完整（PLAN.md L5 自己写的就是 dsh = Landlock partial）。 只有 native / advisory 两个取值时，这个平台无论标哪个都是在说假话： - 标 native → 人会以为 plan 档是硬保证，把它当安全边界依赖； - 标 advisory → 又低估了它（确实在拦），而「平台无法强制」会让模型 在本可依赖的边界上过度保守。 多一个取值比多说一句假话便宜。 # 改动 - Go models：EnforcementPartial = "partial"，ValidEnforcement 接受它； NormalizeEnforcement 对显式自报值一律原样保留（partial 降级到任一极端都是假话）， 未知值仍然 fail-closed 到 advisory。 - 三桥共用 lib/permission-mode.js（逐字节同源）：ENFORCE_PARTIAL + modeBriefing 三态措辞。partial 版必须同时做到两件事： 说清「覆盖不完整」，并收回 native 那句「都会被平台拦下」的承诺 —— 否则模型会以为越界一定被拦，于是不必自己小心。 - 前端 PermissionChip：三个点形区分（实心 / 靶心 / 空心）+ 三套 tooltip 文案； 认不出的强制力按 advisory（与后端同方向）。 - DSH 插件心跳改报 partial。 - 顺带修正活跃 DSH 会话的历史快照：那批 native 是插件当时的**误报**， 不是能力变化，因此把 status<>'archived' 的 dsh 会话改为 partial； 归档会话按设计保留（不重写已结束的历史）。改前已 sqlite3 .backup 备份。 # 验证 - agents.mode_enforcement：dsh 由 native 变为 partial（心跳生效） - Go 全量、三桥插件 320/362/409、前端 196 全绿（新增 PermissionChip 11 例） - 三桥共用模块同源校验通过 - 关键判据：partial 的措辞与 native/advisory 两两不同，且不含「无法强制」	2026-09-11 12:04:06 +08:00
JianFeeeee	429149e118	chore(format): 撤销误入提交的整体重排，并关闭本仓库的格式化器 ... # 发生了什么 pi-lens 内置「安全格式化」：它会自动安装 biome 并对**编辑过的文件**跑 `biome format --write`。本机原先没有任何 biome 配置，于是 biome 用它自己的 默认值 —— tab 缩进 + 双引号 —— 把文件整体重写。 我在 19a3161 那次提交里用了 `git add -A`，把这批与功能无关的重排一起扫了进去： 约 7000 行改动散落在 20 个文件上，使那次提交无法审查，还掩盖了 server/internal/handler/permission.go 的一处删行（实为文件末尾空行，无代码丢失）。 # 为什么是「关掉」而不是「配置成我们的风格」 试过把缩进/引号/lineWidth 全部对齐本仓库习惯（biome.json + space/2/single/ lineWidth 120）：`biome format --write` 仍然改动 17 个文件。原因是本仓库从未按 biome 的规则排版过 —— 注释按语义换行、数组与调用按可读性手工折行， 这些无法由格式化器还原。也就是说只要格式化器开着，每次编辑都会产生与内容无关的 大面积 diff，把真正的改动埋掉。 因此 biome.jsonc 里 formatter 与 linter 都关闭：本仓库的静态检查由 tsc / go vet / tree-sitter / ast-grep 与各自测试套件承担，不引入会改动无关行的 自动修复。 （pi-lens 这一版把 format 服务的 enabled 硬编码为 true，没有配置开关， 所以只能在仓库侧用 biome 配置让它不动文件；已验证 `biome format --write` 对这些文件零改动。） # 本提交内容 把 19a3161 里除「有意改动」外的 20 个文件还原到重排前的样子。 19a3161 中真正有意的改动是 deploy/install.sh 的扩展注册与 plugins/pi-mail-bridge/extension/index.ts 新文件，两者原样保留。 验证：Go 全量、三桥插件（320/362/409）、前端 196 全绿； `biome format --write` 对还原后的文件零改动。	2026-09-11 12:03:51 +08:00
JianFeeeee	19a3161ee4	feat(pi): 交互式 pi 会话接入邮件工具（send_mail/read_inbox 等 10 个） ... 问题（⑧）：守护进程用 noExtensions:true 起会话，它的邮件工具只给模型在邮件 会话里用；人在 TUI 里敲的 pi 拿不到。结果是平台的建设者自己收不到邮件 —— 一个「邮件驱动」的平台，维护者只能绕到 curl + 密钥直连 Gateway 才能看收件箱。 新增 plugins/pi-mail-bridge/extension/index.ts：把同一套工具（createMailTools） 注册到交互式会话。两者是同一条 AgentMail 身份（agent pi）的两个入口，与 DSH 的 「TUI + 邮箱是同一个 Agent」一致。 密钥解析顺序（交互式 pi 的环境里没有 AGENTMAIL_*）： 1. 进程环境 2. AGENTMAIL_ENV_FILE（默认 /etc/agentmail/pi.env）—— 与守护进程同一把密钥， 因此身份一致 3. AGENTMAIL_CONFIG_DIR/agent.key 或 ~/.agentmail/agent.key （兼容 key 与 key_token 两种字段名；实测本机文件用的是 key_token， 只认 key 会静默读不到） 拿不到密钥时不注册任何工具并明确告知 —— 挂一组永远 401 的工具比没有更糟。 不注册 connect_to_server：它会重写 Gateway 坐标并重新登记密钥，而交互式会话与 守护进程共用同一身份，一次 TUI 对话不该改到守护进程的配置。 为什么不会重复注册（读 SDK 实现确认，并用探针实测）： resource-loader.js 里 noExtensions 为真时只用 cliEnabledExtensions， settings.json 的 extensions 数组被排除 —— 即 noExtensions:true 只加载 命令行 -e 传入的扩展。 探针：noExtensions=true → 扩展数=0；false → 16 个且含 pi-mail-bridge。 deploy/install.sh 增加幂等的扩展注册步骤（写入 settings.json 的 extensions）。 验证：headless pi 实际调用 read_inbox 返回真实邮件主题；工具清单含 send_mail/read_inbox/read_mail/forward_mail/upload_attachment/download_attachment/ suggest_address/list_contacts/session_participants/read_thread（10 个）， connect_to_server 按设计排除。	2026-09-11 11:32:47 +08:00
JianFeeeee	1692c615c6	fix(dsh): session_update 在插件重启后仍能定位活会话（权限热更新不再静默失效） ... sessionMap 是纯内存表，插件重启后为空。而 session_update（人在 WebUI 改权限 档位）原来只查这张表 —— 于是「插件刚重启 + 那条会话还没收到新邮件」时， 那条更新被静默忽略：人在界面上把 full 改回 workspace，DSH 运行时仍按 full 执行。 人以为自己收紧了权限，实际上没有。 邮件新建的会话 id 是确定性的（mail-<邮件会话 id>，模型降级重试时带 -r<i>）， 所以重启后可以按前缀在活会话里定位，并顺手把 sessionMap/reverseMap 补回去 —— 不补的话这条会话后续的自动转发也会一起失效。 - lib/mail-session-id.js（dsh 专用，9 例测试）：id 派生与匹配的纯函数。 放宽成前缀匹配会把 mail-abcdef 误判成 mail-abc 的会话；非数字后缀 （-retry / -rx）也不匹配，避免误改别的会话的档位。 - 接管会话（adopted）仍是例外：其 DSH 会话 id 由平台生成、推不出来， 重启后无法热更新 —— 已知取舍；下次投递会按邮件里的 permission_mode 重设。 - tsconfig 清理：allowJs 原先写在根层（无效位置），移入 compilerOptions 后 会让 lib/*.js 进入 TS 程序并违反 rootDir；这些模块已有 .d.ts 提供类型， 该选项本就不需要，直接移除。 测试：dsh 358（新增 9）/ opencode 316 / pi 405 全绿。	2026-09-11 10:47:30 +08:00
JianFeeeee	f91efd2d8d	feat(question): DSH ask_user_question 桥接 + 前端问答面板 + 待办字段全路径透出 ... 问题（P0）：DSH 有两个独立的人机交互 seam —— approval/request（危险工具审批） 与 ask_user_question → ctx.userQuestions（模型主动提问）。原来只桥接了前者。 邮件驱动的会话没有本地 UI，而 ask() 的 provider 是 DSH host 注册的本地 UI 实现， 于是在那里等人点选永久等不到，那一轮工具调用**静默挂死**。 修法（不抢注全局 provider —— registerProvider 只允许一个活动实例，抢注会让 平台自己的界面失效）：在 tools/execute around-dispatch 里只对**邮件驱动**的 会话接管 ask_user_question，其余原样 next()。失败一律当场报错而不是 next()： 下一个 answerer 是本地 UI，邮件会话没有兜底 UI，放过去就是挂死。 - lib/user-question.js（三桥逐字节同源，14 例测试）：DSH questions[] ↔ AgentMail 单问题询问邮件的双向映射。多问题时把选项并集摊平、按 label 归属分配回各问题 （label 认不出来就不猜测放行）；无选项题走自由文本 custom。 - Gateway：kind=question 且无选项时**不再**回落「同意/拒绝」（那会让自由文本 问题变成两个毫无意义的按钮）；主题按类型区分「权限请求 / 需要回答」； 推送 payload 带上 permission_kind / multi_select / options。 - mails.permission_kind / permission_multi_select 此前只存在于结构体与写入路径， 五个读路径的 SELECT/Scan 都没带 —— 前端永远拿到空串，把提问渲染成批准/拒绝。 container 修正五处并加 repo 测试（含反向验证：删掉任一处字段，测试即失败）。 - 前端 PermissionPanel：question 走「勾选 + 自由文本」，多选/单选、空回答禁止提交； approval 路径不变（回归测试覆盖）。 测试：opencode 316 / dsh 349 / pi 405 / 前端 185 / Go 全量 全绿。	2026-09-11 10:44:18 +08:00
JianFeeeee	c401eb2da2	fix(bridges): SSE 跨分片保帧 + Last-Event-ID；pi worker 有界重投；systemd 故障上报；清理误提交二进制 ... 三个平台桥原本各自手写 SSE 解析，有两个共同的静默丢事件缺陷： 1. evt/data 是每次 read() 的局部变量 —— TCP 把一帧 'event: x\ndata: {...}\n\n' 切在换行处时，前半段的 event 名被丢掉、 后半段只剩 data，整帧静默丢弃。表现为「新邮件偶尔收不到」 「权限决策点了没反应」，日志里一个字都没有。 2. 重连不带 Last-Event-ID —— 断线期间的事件留在服务端 per-agent 环形 缓冲里永远回放不出来（pi 与 homeagent 已正确使用，DSH/opencode 没有）。 修法：抽出共用 lib/sse-client.js（三桥逐字节同源，check-shared-libs 校验）， 把「跨 chunk 保帧状态」与「Last-Event-ID 断点续传」写对一次。pi 桥的 gateway.mjs 也改为复用同一实现（保留 reconfigure 时清断点的语义）。 pi worker 丢任务：worker 未回报 done 就退出（SIGKILL/OOM/崩溃）时， 主进程原来只记一行日志就 pump() —— 那封邮件永远没有回音。改为按 1s/2s 退避有界重投（默认 3 次），到上限记「放弃」并可观测。 systemd 故障上报：四个宿主服务接入 service-failure-notify.mjs 的 ExecStopPost/--report 与 ExecStartPost/--flush。进程内 uncaughtException 捕获不了 SIGKILL/OOM，只能由 systemd 统一覆盖。正常 stop/restart 不发信。 仓库卫生：server/server（24MB 构建产物，f9d757b 误提交）移出版本库。 测试：opencode 302 / dsh 335 / pi 391 全绿（新增 12 例 SSE 帧解析 + 2 例 worker 重投）；Go 全量通过；四平台重启后在线且无错误。	2026-09-11 10:27:41 +08:00
JianFeeeee	f9d757b5e5	chore: directory migration - gateway→server, web→client/electron	2026-09-08 19:16:35 +08:00
JianFeeeee	89a4784c10	opencode+dsh: 空回复兜底 —— idle 但无 assistant 文本时回失败通知 ... 缺口：模型 idle（轮次正常结束）但没有产出任何 assistant 文本时， 两个插件此前静默 return —— 发件人等不到任何回复也得不到交代。 （模型「全部失败」已有 renderFailureReport 兜底，但「跑完却没产出」 不等于失败，走不到那条。） 补： - opencode relaySummary: if (!last) → 发一封「处理失败：无回复文本」通知 - dsh agent/status idle: if (!lastText) → 同款通知 - 都走 relay:summary 免配额 + relay_key 幂等 - 都只给人类来信发（Agent 间不自动转发）	2026-09-07 07:05:45 +08:00
JianFeeeee	be9f46cf73	dsh: resume 续谈也挂载 standard preset —— 修复旧会话没有文件工具 ... 根因：startAgent 的 resume 分支 setup: undefined，注释说 「resume 从磁盘恢复，工具已在」—— 实际上工具是通过 setup 回调 presets.mount 注册的，resume 不传 setup 就没有任何文件工具。 presets.mount 修复之前创建的旧会话（setup:undefined 时代）从此 没有 read/write/edit/bash/glob/grep，用户反馈「dsh 无法看到工作区文件」。 修复：把 presets.mount 抽成 setupPreset 函数，create 与 resume 共用。 resume 恢复的是会话历史，不是工具注册 —— 两者必须都挂。 实测：旧会话 318f0703 resume 续谈后 setup 回调触发、mount 成功， 模型用 glob 列出工作区文件、read 读取、write/edit 可写，完整回复。	2026-09-07 06:31:19 +08:00
JianFeeeee	8960085152	opencode: mode_enforcement 改为 advisory（permission 参数不被 API 支持）	2026-09-06 20:39:48 +08:00