jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
926 Commits 1 Branch 0 Tags
d1099526ad9009510dd17b56b337a65e6a35c99f
Commit Graph

7 Commits

Author SHA1 Message Date
JianFeeeee
d1099526ad fix(寻址): flatten 的候选**逐条**标注 —— 第一版把 §C 噪声放进了新端点 
## 缺口（部署后实测才发现，是我自己引入的）

第一版 flatten 只在响应的 `paths[]` 数组里标注。实测：

    222 条候选，其中 37 条（16%）落在桥内部目录（/root/.pi/mail-sessions/<uuid>）
    而标注在**另一个数组** —— 模型必须自己把 candidates 与 paths 对照才认得出

那正是「§C 噪声淹没信号」换个位置复活。我在动手前的判断是「先修 C 再修 A，
否则新端点会把噪声一起放大」—— 做了 A，却让 C 的噪声原样跟进了 A。

只在真机跑过 `flatten=1` 才看见：单测全绿（它们只断言了 paths[] 有标注），
是生产数据的 16% 把它翻出来的。

## 修法

`AddressedCandidate` 逐候选带 `path_kind` / `path_note` / `is_absolute_path`，
MCP 渲染逐条打 `⚠`。

marker 收敛到 repo 层一份，handler 的 `classifyPath` 改为委托调用：

    同一目录在 path 列表里标成「工作区」、在候选列表里却没标 ——
    而那两个数组是**同一次调用**返回的。两处各写一份 marker 时，
    改一处忘另一处就会出现这种自相矛盾，且没有任何报错。

## 判据（2 格）

    TestFlattenAnnotatesEachCandidate  桥内部目录/相对路径能分类 + 带说明；
                                        真工作区不得被误标（否则全是噪声）
    TestClassifyPathAgreesWithRepo     handler 与 repo 口径必须逐条一致

## 顺带

第一版 flatten 本身已验证有效（生产实测）：

    flatten=1 → 222 条候选、66 个工作区
    /home/program/agentmail 125 条 · /root 16 条 · root 2 条
    ⇒ root 与 /root **同时可见**且各自带 path，不再需要「先猜 path 再枚举」

    path 标注：66 条候选里 35 条桥内部目录 + 1 条相对路径被标出
 2026-10-02 16:06:00 +08:00
JianFeeeee
1b810a4898 fix(寻址)★★: 补「按 name 直出全部可投递地址」+ 标注 path 候选里的坑 
## 起因

DSH 侧 Agent 报了一份寻址缺口（2026-10-02，全部结论有 API 实测复现）。
三段式寻址 `name@path.session` 里 session 段是**人的寻址入口**，而枚举它
必须先知道 path —— 但 path 恰恰是调用方无从得知的：

    给 name      → 只给 path（要再调一次才知道有哪些会话）
    给 name+path → 给会话别名（但 path 得先猜对）

于是一个闭合的环。报告实测的踩坑：投 `pi@root` 返回 **200**，落进一条标题
为「拓展坞实测硬件正常…」的无关会话 —— 投递成功，所以调用方不知道自己投错了。

## 修法

**① A 项：`flatten=1` 一次给出全部可投递地址**

`SuggestAddressesForPeer` + `suggest?name=&flatten=1`。每个候选自带
`path` 与可直接塞进 send_mail 的 `address` —— 调用方不必自己拼，
拼错就是那个「猜错比报错更糟」。

可见性口径**不放宽**，与原 name+path 那一支逐条一致（「我参与过 + 与该 name
匹配」）。报告本身也确认问题不在权限：同一批数据给了 path 就能列出 17 条。

按 path 分组平铺而非嵌套：嵌套时调用方要发一封「不知道在哪个 path」的信
仍得遍历全部组；平铺一次给全，模型不必做「先猜 path 再枚举」两步。

**② B/C 项：标注而非隐藏**

`paths[]` 每项带 `kind`（workspace / bridge-internal）与 `is_absolute`。

选标注不选过滤的理由：桥内部目录（`/root/.pi/mail-sessions/<uuid>`）
确实**是某些会话的真实 cwd**（实测那条 workspace='root' 的会话 uuid 正是
其中之一）—— 滤掉等于让那些会话彻底不可见；而留着不标，64 条候选里 33 条
是噪声，模型选中即静默投错（实测 64 条中 33 条是它）。

`suggestions` 保持原样与原顺序 —— SuggestPaths 按最近使用倒序
（刚用过的那个几乎总是下一封想用的），排序被打乱等于让模型取最老的那个。

## ★★ 顺带修掉一个生产级缺陷（实测撞出来的）

给 `SessionCandidate` 加 `LastActivity` 时用了：

    COALESCE(s.updated_at, '0001-01-01 00:00:00+00')

COALESCE 让驱动返回 **string**，扫进 time.Time 报 `unsupported Scan`
⇒ 命中 `return out, err` ⇒ **整个候选列表变空**（实测一条都列不出）。

生产影响：`updated_at` 为 NULL 的历史会话会全部静默消失。
而那个错误信息里**没有任何线索**指向「是你加的 COALESCE 害的」——
本次是我自己加的列触发的，排查花了几步。

改为扫进 `sql.NullTime`（NULL 即零值），平台镜像那条同理。
注释里写明为什么不能 COALESCE 兜底，免得下次有人再加回去。

## MCP 侧同步

`suggest_address` 加 `flatten` 参数，且**渲染必须单独写**：
flatten 的响应没有 `suggestions` 字段，走原来的分支只会回一句
「（没有 session_flat 建议）」—— 模型拿不到任何地址，等于白问一次。

path 形状的渲染把两类坑直接顶到眼前：桥内部目录、相对路径
（`root` 与 `/root` 在数据里是两个不同工作区，实测 1 条 vs 17 条）。

## 判据（8 格）

含「address 必须与候选自身 path/alias 一致」（那正是静默投错的解药）、
「两个工作区都要出现」（原形状缺的就是这一维）、
「不带 flatten 时行为一字未变」（各桥与 WebUI 都走那一支）、
「flatten 不得把 new 混在候选里」（没有真实会话时它看起来像出路）。

**变异验证**：

    COALESCE 兜底（那个真 bug）          → 红 1 ✓
    flatten 段放回 path=="" 之后（顺序 bug）→ 红 1 ✓（kind 变回 "path"）

## 实测校准了一处报告里的数字

报告写「近似写法返回 0 条」，实测返回 **1 条，内容是 `new`** ——
服务端在任何 path 下都追加的新建占位。所以选错 path 时调用方看到的不是
「空」，而是「只有 new 可选」：**看起来像一条出路**，于是顺着它新建，
恰好落进猜错的那个工作区。比报 0 更危险（0 会让人停下，new 会让人继续）。

§E 无需修：`validateSessionAlias` 已拒绝别名含 `.`。

全量 14 包绿。
 2026-10-02 15:59:56 +08:00
JianFeeeee
de6b91516a feat(默认会话): 非邮件轮次用 /tmp 默认会话作合法 session_id —— 配套 15e4fe9 的收严 
`15e4fe9` 让未声明 session_id 的读信一律 403，而 homeagent 的工具**全局可调** ⇒
对话里自主调 read_mail/read_thread 时 `currentSessionID` 为空 ⇒ 403。
不能因此让「非邮件轮次读信」这个能力消失（它是 10-01 那个 read_inbox 修复的
用户可见部分），所以给它一个合法声明。

## 关键约束：workspace 能回落 cwd，session_id 不能

`session_id` 是 AgentMail 会话的 UUID，进程 cwd 给不出它 ⇒ 只能问服务端。
落点选 `/tmp`：非邮件轮次没有真实工作目录，而 /tmp 是中性落点（不属于任何真实
项目，不会把项目邮件混进来），且满足 `UnreadWorkspaces` 的 `workspace LIKE '/%'`
（能被寻址补投）。

## 服务端：`GET /api/v1/agent/session/default`

**复用**已有的默认会话语义（`FindOrCreateDefaultSession`，8 个测试覆盖），
只把它开放成可查询形状 —— 不新造概念。

★ 第一版调 `FindOrCreateDefaultSessionCreated`，判据当场报**每次都新建**
（连问两次得到两个不同 UUID）。根因：那个函数的复用条件含
`EXISTS (SELECT 1 FROM mails …)`，空会话不满足 ⇒ 永远「没找到可复用」。
改「先查后建」仍不够。想深一层：**根本不该建** —— 非邮件轮次若 `name@/tmp`
一封都没通过，收件箱本来就该是空的，不需要一条 id 才能表达「空」。
⇒ 改成**纯只读**：没通信过就返回 `session_id: null`。
GET 有副作用是坏味道，它会被桥每轮调一次。

同时把匹配 SQL 抽成 `defaultSessionMatchSQL` 共享常量：`FindExisting` 与
`FindOrCreate` 必须给出**同一个**答案，否则「查到的默认会话」与「发信落进去的
会话」会静默分叉（各写一份 SQL 的话，改一边不会红）。

## 桥（homeagent）：effectiveSessionID = 信封 → 默认会话

⚠ 取值函数**不发请求**。我第一版把 HTTP 塞进 `effectiveSessionID`，
`&Plugin{}` 构造的测试当场 nil panic，且 scopeQuery 变成「拼 URL 时顺带发请求」。
IO 移到装配期 `register()` 里的 `ensureDefaultSession()`。

⚠ `client == nil` 时**不标记已问** —— 那不是「答案是空」而是「还没资格问」，
标了会永久缓存空值。而 register() 里就会调它，真的会在插件加载阶段崩。

## 判据

服务端 6 格（含★「不是万能钥匙」：拿默认会话 id 去读别人的会话仍须 403 ——
少了这格，这个端点就是「声明一个合法会话然后读遍全场」的后门）。
homeagent 6 格。
三个变异各红 1 格：退回旧的整体放弃 / 未就绪也标记 / 默认落点与服务端不一致。

## 未改：pi / dsh / opencode

实测它们的裸奔已停止（pi 自 Sep 26、opencode 自 Sep 28，`[agent-scope]` 日志归零），
`getMailSessionId` 由 worker 闭包注入且只有一处装配点。dsh 待单独核。
 2026-10-02 01:09:19 +08:00
JianFeeeee
a5fc86bc1a fix(addressing)!: 寻址不按工作区筛 + 联系人地址不再从垃圾 from_workspace 拼 
用户：「任意 agent 的寻址是任意的，而不是按工作区区分，去落实吧」。

① 拆掉两处"按工作区收窄"（那是我把**寻址**当成了**权限**）：
   · AgentListContacts 不再走 ListContactsInWorkspace ⇒ 列表 = 我参与过的会话（事实，不是授权）；
   · AgentSuggestAddress 的会话候选不再走 SuggestSessionCandidatesInWorkspace。
   两个 InWorkspace 变体（连同钉旧口径的用例）一并删除，避免死代码。
   生产实测：pi 的联系人从"只剩同工作区"变成 5 条，横跨 TrueAgent/agentmail/其它工作区。
   agentScope 仍调用（校验 session_id 格式 + 未声明时告警），只是它的工作区不再当过滤器。

② 联系人地址的 path 取自**会话**，不再取第一封邮件的 from_workspace：
   `COALESCE(NULLIF(s.workspace,''), NULLIF(m.to_workspace,''), '')`。
   那条老路把地址拼成 `zcode@zcode.<别名>` —— 正是用户预言的"感染"：一个可被复制出去的
   错误地址。from_workspace 与"对方在哪"无关，只用 to_*。

③ **清除感染源（数据）**：658 行 from_workspace = from_name（pi 406 / dsh 137 / zcode 89 /
   homeagent 17 / opencode 9）已清空。带去重前备份（/root/gotmp/agentmail-pre-fromws-purge-*.db）
   与回滚脚本，回滚**在副本库上真跑过**（恢复 658 行）才敢落地。
 2026-09-15 10:07:18 +08:00
JianFeeeee
6b86836343 fix(read)!: 读信只认会话 —— 删掉「同工作区」那道闸门 
用户订正：「是应该发到对应 session 的信，因为 agent 多 session 架构，不同 session 的
记忆是隔离的。你之前那个修法简直荒谬」

我把两条轴混在一起了：**工作区**决定 cwd/沙箱/线索可见面，**会话**决定记忆与收件箱。
原先 AgentMayReadSession 判「参与过 + 同工作区」，两头都错：

  · 太松：同工作区内、我参与过的**别的会话**也放行 —— 会话之间记忆隔离，读别的会话
    就是绕过隔离（用户上午的要求本就是"不同 session 不同收件箱"）；
  · 太严：我在 A 工作区的上下文里读不到**自己刚发起**、落在 B 工作区那条会话。
    zcode 撞上这条，403 文案还写着 cross-workspace ⇒ 它推断出"那五位 agent 不存在"。

新判据两句：① target 必须就是 scope（我当前那条会话）；② 我参与过 target（防伪造
session_id）。scope==nil 保持迁移期放行（五家桥实测都带 session_id）。

403 文案换成「这封信不在你当前所在的那条会话里：每个会话各有各的收件箱（会话之间的
记忆是隔离的）。你当前在会话 <id>。要读它，就在它那条会话里读 —— 每封来信都会把 worker
唤醒到它自己那条会话上」。报"我在哪"安全，目标会话在哪不报。

判据：workspace_scope_test 的该用例改名并重写为五条形态（自己那条会话放行 / 同工作区
另一条会话拒 / 别的工作区会话拒 / 伪造 session_id 拒 / 未声明 scope 迁移期放行）。
生产实测：① 200 ② 403 not-your-session（新文案）③ 403（伪造）。
 2026-09-15 09:59:21 +08:00
JianFeeeee
1b8cd43935 fix(auth): 工作区成为读权限的边界 —— Agent 侧读端点按会话工作区收窄 
用户报的：「agentmail 工作区的邮件会话被 trueagent 工作区的 agent 看到了，
还需要我亲自去解释。」

## 根因不是漏了一个 WHERE，是隔离单位选错了

Agent 注册时 `workspaces` 是空的（B-1.2：cwd 由每封邮件的 `to_workspace` 决定），
所以**一个 Agent 同时服务所有工作区**。而可见性判据一直是
`AgentCanAccessSession(agentName, sid)` = "这个 Agent 名出现在这条会话的 from/to/cc 里"
—— 于是同一个 agent `pi`，在 TrueAgent 里干活的 worker 眼里，对 agentmail 的会话
也成立。

现场证据：`mail_reads` 里 08:11–09:19 有 8 次「同一瞬间读了多个不同工作区的会话」
（08:23:59 一次跨 agentmail / TrueAgent / webui4frpc 三条会话），最后一次是 09:19:11
—— 正好停在 `read_inbox` 按会话收窄那个提交（552fbc7，09:19:25）之前。
更要紧的是 `mail_reads` 只记 `reader_name`、**没有「读的人当时在哪个工作区」这一列**，
所以这类越界读在数据上与正常读**无法区分** —— 这也是为什么只能由用户自己去解释。

## 改法：补一维，而不是逐个端点打补丁

- 新增 `repo.AgentMayReadSession(agentName, scope, target)`：① 参与过（原有判据）
  ② 两条会话的 `workspace` 相同（新增）。`scope` = 调用方当前所在的那条会话。
- 服务端只认一条**会话 id**（`?session_id=`），由它反查 workspace ——
  **不接受调用方直接声明工作区**，否则等于让它自己给自己发通行证。
- 应用到四个读端点：`read_mail` / `read_thread` / `session_participants` /
  `list_contacts`，以及 `contacts/suggest` 的**会话候选**（name/path 两段不收窄：
  跨工作区**发信**是设计允许的，被挡的只是"浏览同行的线索"）。
- 未声明 `session_id` 时保留旧语义（放行）并**记警告日志**：迁移要能分步走，
  但"还有谁没接线"必须可观测（另四家桥仍走这条路）。
- pi 桥：五个读工具全部带上自己那条邮件会话 id（由 worker 闭包注入，模型改不了）。

## 顺手修掉一个真 bug

联系人查询的未读计数子查询里一直有 `r.reader_name = $1`，而原写法是
"forUser 为空就不传参" ⇒ $1 悬空：Postgres 直接报 `no parameter $1`，
SQLite 把 `= $1` 当 `= NULL` 比、次次不成立（未读计数静默退化成"全部未归档"）。
管理员 `?all=true` 走的正是这条路。现在 $1 恒传。

## 判据（两侧都验 + 变异）

- repo：同工作区放行 / 跨工作区拒且 reason 分得清 / 没参与过拒 /
  未声明 scope 的旧语义；列表类有反向对照（不带收窄两条都在）；
  建议补全同工作区照常给候选、跨工作区查路径不给、不带收窄会给（对照组）。
- ★ 这条判据我第一版**写错了对照组**：拿 path=wsA 去比 —— 而 path 本来就收窄，
  于是"不带收窄"也只剩一条，判据等于空的。改成拿 path=wsB 比才有区分力。
- 变异 3 处（拿掉工作区判据 / ListContactsInWorkspace 不收窄 /
  SuggestSessionCandidatesInWorkspace 不收窄）⇒ 各自恰好红在对应那条断言。
- pi 桥 14 条：6 个读工具 × 带上/不带 scope 两侧 + worker 闭包 + 自检；
  变异 read_mail 去掉收窄 ⇒ 恰好那一条红。

（工作区是多会话共用的，本次只 add 了 server/ 与 plugins/pi-mail-bridge/ 的 7 个文件。）
 2026-09-14 23:03:25 +08:00
JianFeeeee
f9d757b5e5 chore: directory migration - gateway→server, web→client/electron 2026-09-08 19:16:35 +08:00