|
|
1ea92098d1
|
fix(四桥)★★: parent_from 方向判据在 dsh/opencode 上是死代码 —— 接线补齐
## 起因：修部署漂移时撞出来的
b0c8719（2026-09-30）给 `inboundHeadline` 加了 `parentFrom`/`selfName`，
用来分辨「回的是你那封」与「多方线索里的他人续谈」——单向续信链（8 封全是
对方发来的）同样满足 `in_reply_to`，不判方向就会被逐封宣称「回的是你那封」，
模型把它当新任务处理。**但只有 pi 桥接了**：
pi parentFrom: data?.parent_from ✓（turn.mjs:148）
dsh 从不传 ✗ 3 处
opencode 从不传 ✗ 1 处
判据函数是三个桥**同一份** relay-policy.js 的拷贝，看起来测过了 ——
但「函数支持」≠「调用方传了」。三个桥各自都有 relay-policy 单元测试且全绿，
因为它们只测那个**纯函数**，没有一个测「桥真的把参数传进去了」。
dsh 还多一层：它有一份**手写**的 `lib/relay-policy.d.ts`，缺这两个字段
⇒ tsc 报 TS2353 ⇒ 调用方即使想传也过不了类型检查。那行判据是被类型系统
**主动拦住**的死代码。只补 .js 不补 .d.ts 等于没补。
## 改动
dsh 3 处 + opencode 1 处调用点补 `parentFrom`/`selfName`，对齐 pi 的样板；
dsh 的 `.d.ts` 补声明（注释写明「光有声明不够，调用点也得传」）。
## 新增判据 deploy/check-parent-from.mjs（7 格）
不只是查「有没有传」，还查**三处曾经不一致的接缝**：
① 每个 inboundHeadline 调用点都传了 parentFrom（次数写死，新增调用点
忘了传要能被发现，而不是被 `>0` 静默接受）
② 传了 parentFrom 就必须传 selfName —— 只传前者时
`parentFrom === selfName` 永不成立，判据形同虚设
③ 三份 relay-policy.js 都真的有 `parentFrom === selfName`
④ dsh 的 .d.ts 声明与实现一致（否则 tsc 拦住，判据等于没有）
**变异验证**：撤一处传参 → 红 2；只撤 selfName → 红 1；撤 .d.ts 声明 → 红 1。
## ★ 判据自身也踩了两次坑（都已修）
1. 初版 `.d.ts` 那格用 `\bparentFrom\b` 全文件搜 ⇒ 撤掉字段声明后，
**注释文字里还留着这个词** ⇒ 照样匹配 ⇒ 变异不红（假绿）。
改为只认字段声明 `^\s*parentFrom\??\s*:\s*string\s*;`。
2. 初版 `.mjs` 写了 `require` ⇒ ReferenceError（ESM）。已改 import。
## 顺带修掉 6 个陈旧判据（都在 HEAD 上、此前静默红着）
`turn.test.mjs` 的「回信到达时明说不是新任务」：只造 `in_reply_to` 却断言
`/m-0/`，而 `b0c8719` 新增的「我的回复」分支文案里压根不含父邮件 ID ——
判据没跟上那次改动。已改成覆盖三种情形（parent_from 是我 / 是别人 / 缺席）。
★ 我第一版改完是**假绿**：只断言 `/续谈/` 时，把 `mine` 分支改坏也会走
「续谈」分支而照样通过。加反向断言（mine 不含「续谈」、theirs 不含
「不是新任务」）后才抓住。变异 A/B 各 35 pass / 1 fail。
`cross-bridge-permission-routing.test.mjs`：zcode 的路径与目录还指向
`d09ef39` 已删的 `hooks/`、`mcp/` ⇒ ENOENT。zcode 确实**没有** 409 分支了
（移除执行类工具所致，非缺陷）⇒ `permanent: null` 表示不适用，并加反向
守卫：若 `src/` 里出现 `isPermanentFailure` 就红（防止前提变了却继续空转）。
`isPermanentFailure` 是 `lib/relay-key.js` 的通用网关辅助，与权限放行无关 ——
踩过一次：把 `lib` 加进扫描范围后对着共享辅助函数误报。
全量：pi 533 / opencode 364 / dsh 433，零红（此前 4 红）。
## 部署与端到端
pi / opencode / dsh 三个宿主均已部署；dsh 已真实收发验证：
[dsh-mail-bridge] 本轮不自动转发：来信方 pi 是 Agent…
[dsh-mail-bridge] new_mail -> 新会话 mail-8e8bf319…
|
2026-10-03 00:25:28 +08:00 |
|
|
|
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 |
|
|
|
ca64d12057
|
feat: 工作区归属修复 + 平台会话同步 + 对话树整树展开 + DSH 插件
四个各自独立的生产缺陷，共同的根源都是「本该属于会话的属性没有存在会话上」。
## 1. dsh 指定工作目录完全失效（所有会话落进「未分组」）
插件建会话时用的 cwd 是自己拼的 `~/.dsh/mail-sessions/mail-<uuid>` ——
每封邮件一个全新的空目录。DSH 与 opencode 都按 cwd 给会话分组，于是所有
邮件会话既不属于任何项目、彼此也不同组。
而 Gateway 从来没把地址里的 path 位发给插件：`notifyRecipients` 的 payload
只有 mail_id/session_id/from_name/subject，`to_workspace` 虽然入库了却不在
SSE 事件里，插件即使想用也拿不到。
- SSE `new_mail` 事件加 `to_workspace`。**每个收件方拿到自己那个地址的 path**，
不是主收件人的 —— 抄送给 opencode@/a 与主发给 dsh@/b 是两个工作区
- 两个插件的 cwd 都改为取寻址的 path 位；不存在的目录**不创建**而是回退到
兜底目录（一个笔误不该在磁盘上落下真目录，Agent 会在里面一无所获地干活）
- 拒绝相对路径：cwd 的相对基准是 harness 进程的启动目录，systemd 下通常是 `/`
## 2. 会话别名列不出工作区下的历史会话（无法选择）
workspace 只存在于 `mails.to_workspace` 上，「这个工作区下有哪些会话」必须
JOIN mails 再从收发双方的 workspace 里猜。而 Agent 回信时 from_workspace
填的是 **Agent 名**而不是路径，旧条件 `to_workspace = $p OR from_workspace = $p`
在只剩 Agent 回信可匹配时两边都对不上。
- `sessions.workspace` 新列，`CreateSession` 从地址的 path 位带入
- `SuggestSessionCandidates` 取代 `SuggestSessionsFor`：以会话自己的 workspace
为权威，历史会话（该列为空）回退到 mails 反推 —— 升级后老会话不该消失
- `FindOrCreateDefaultSession` 同步改用会话的 workspace
## 3. 平台侧会话在补全里根本不存在
人直接在 opencode/DSH 界面上开的会话，Gateway 一无所知。
新增 `agent_platform_sessions` 镜像表，插件在心跳里上报快照。
**上报而非 Gateway 反向拉取**：当前架构是单向的（Agent 持密钥主动连 Gateway，
Gateway 从不外呼），反向拉取需要它保存各平台的地址与凭证，那是另一套信任模型。
- 与 sessions 表分开存：镜像里是别人家的会话，id 属于平台的 id 空间，没有
本侧的 owner/预算/邮件。混进 sessions 会让每一处「按会话鉴权」都要先判断
这条到底是不是真的本侧会话
- **整表替换而非增量合并**：平台侧删掉的会话必须从候选里消失 —— session 位是
三态语义，指向不存在的会话直接 404
- **nil 与空数组语义不同**：插件拉不到列表时省略该字段（保留镜像），
而不是传空数组把镜像抹掉
- **subagent 子会话不上报**：实测 DSH 的 list 里混着 49 条子会话，标题就是
派活的提示词前缀（九条都叫 "You are auditing ONE file"），slug 全撞名；
它们是父 agent 内部的工作单元，人往里发邮件毫无意义
- **slug 撞名只留最近那条**：服务端只能取其中一条，上报同名项只会让补全里
出现几个点哪个都不确定的候选
- DSH 插件此前**完全没有心跳** —— Gateway 靠 last_seen 判在线，一直靠注册撑着
补全候选带标题与来源：`suggestions` 保留纯字符串数组（不打破已部署的前端与
第三方客户端），新增同序的 `candidates`。过滤时标题也参与匹配 —— 人记得的是
「缓存选型」而不是 brisk-harbor 这种随机短名。
## 4. 对话树看不见抄送与转发产生的分支
旧实现从锚点分「祖先链 + 子树」两路展开，而**兄弟节点既不是锚点的祖先也不是
它的子孙**：一封抄送给两个 Agent 的邮件收到两个回复，从其中一个看树永远看不到
另一个；挂在原件上的转发分支同理。
改为先 `ThreadRootOf` 上溯到线索根，再从根整树 BFS。只剩一个加载方向，
因此不再需要滚动位置补偿。前端补上抄送人列表与转发标记 —— 树上两个兄弟节点
为什么并列，唯一的解释就是父邮件抄送给了两个人。
## 5. DSH 插件（Phase 7.7）
卡了一下午的 `Cannot read properties of undefined (reading 'kind')` 根因是
`followup()` 的参数形状：DSH 要完整的 UserMessage（content + source），
而我照抄了 opencode 的 parts 数组。错误抛在 agent-loop 内部，不指向调用点。
- `agent/status` → idle 时自动转发最后一条 assistant 消息（对应 opencode 的
session.idle），复用 relay-dedup 让位于模型的主动回信，走免配额通道
- `approval/request` 权限询问转邮件问人。与 opencode 的差异：那边的
permission.ask 是同步钩子只能立即返回 ask，DSH 这边是异步 waterfall，
可以真的等人 —— 拆插件时未决询问一律 fail closed，否则 await 永不返回
- 会话别名由模型标题派生（保留中文，去掉 `.` `@` `/` 等寻址分隔符 ——
留在别名里会让它自己被解析器切开）
- 逻辑放 lib/ 下的纯函数并加测试：三类约定都是「错了不当场报错、只在深处
炸一个无关错误」
## 其他
- `deploy/reset-demo.sh`：清空演示邮件数据，保留账号与密钥。备份用 `.backup`
而非 cp（WAL 下 cp 拿到的是缺尾巴的库）；手工按依赖顺序删（SQLite 的
foreign_keys 默认关，声明了 REFERENCES 也不级联）；只在目标是默认库时才碰
systemd（演练时误停过一次生产服务）
- 插件 dist/ 不进版本库，install.sh 负责构建
- `permission_decision` 事件补 session_id：插件重启丢了待决映射时要靠它定位会话
|
2026-09-02 20:05:51 +08:00 |
|
