|
|
dfd5661e24
|
refactor(线索树): 回填接口化 —— 数据操作不进结构迁移通道
用户 2026-10-04：「一切数据调用都要接口化」。这条要求直接指向上一轮的两个错误。
## 撤掉的：Migrate 里的自动回填
`Migrate` 是**结构**变更通道（建表、加列）。让��兼做数据改写（给会话写
parent_session_id）是混用通道，后果不是理论上的：
- 不可重跑 —— 上一轮那次回填已经在部署中执行，`app_meta` 标记
`2026-10-04T02:54:37Z`，**无法通过任何方式重跑或撤销**；
- 不可审计 —— 库上看不出谁在什么时候改的；
- 不可触发 —— 没有接口能主动执行它。
⇒ 移到 admin 端点，与 `DELETE /admin/sessions/{id}`、
`POST /admin/agent-keys` 同一档。
## 加的
POST /api/v1/admin/sessions/tree/backfill 默认 dry-run，显式 dry_run=0 才写
GET /api/v1/admin/sessions/tree/preview 只读
`PreviewSessionParents`（repo 层，只读）是必需的配套：接口化之后**验证本身
也必须走接口**，那么「回填到底会改什么」就得有一条不写任何东西的接口来回答，
否则只剩「先写了再看看对不对」。
## 判据抓到的真 bug：注释说默认 dry-run，代码默认就写
if v := r.URL.Query().Get("dry_run"); v != "" { // 参数缺失 → 整个 if 落空
...
}
n, err := repo.BackfillSessionParents(...) // ← 直接执行
误点一次 POST 就改了 6 条真实会话的拓扑，且没有任何预览。修成
`dry := true` 起手、只在显式解析出 false 时才写。
## 判据自己假绿了一次（本轮第四次做形状判据）
`TestBackfillDefaultsToDryRun` 初版读源码、数 `AdminPreviewSessionParents`
出现几次。变异 `dry := false`（**正是上面那个 bug**）之后判据**依然全绿** ——
因为 `if dry {…}` 分支在源码里始终存在。
⇒ 改成行为测试：真起 httptest 发一个不带参数的 POST，然后去**库里**看
parent_session_id 有没有被写。重测同一变异，两条断言都红：
★ 无参 POST 的响应应表明这是预览，实际：{"dry_run":false,…}
★ 无参 POST 就把 parent_session_id 写成了 "31949dc4-…"
同轮修掉判据两次「匹配比语义宽」：`strings.Contains(seg, "UPDATE")`
把 `ORDER BY c.updated_at DESC` 里的 `updated` 当成了写库；
函数边界用 `strings.Index("\nfunc ")` 在「函数是文件最后一个」时落空，
取到全文后把别的函数里的 UPDATE 判成预览写库。
## 尚未验证
树端点只能验到「匿名被正确拒绝（401）」—— **不足以证明树能用**。
缺 admin 凭证，admin 全看 vs 普通用户收窄的差异还没在真数据上跑过。
14 包全绿。
|
2026-10-04 12:03:58 +08:00 |
|
|
|
cd894d5e4d
|
feat(线索树)★★: 会话级父子 + 树视图 —— 跨会话分叉第一次可见
## 要解决的问题
用户 2026-10-04：「对话树实现得非常原始，根本没有形成/展示为树结构」。
★ 先纠正我自己的一个误判：我先前只看 `ContactPanel`（会话列表）就断言
「前端纯平铺、零层级」。那是不完整的检查 —— `ThreadView.tsx` 早就在用
`node.depth` 做缩进 + 连接线渲染**会话内**的邮件树，服务端 `DescendantsRaw`
也早就有 `WITH RECURSIVE … lvl`。所以**会话内**的树是有的。
真正缺的是**跨会话**：`sessions` 表根本没有 `parent_session_id`，
而生产库实测有 **6 封**邮件的 parent 指向**另一条会话**，
界面上它们是几行互不相干的东西。而「A 交给 B 之后 B 继续推」正是
协作里最常见的形状 —— 那 6 条里就有 `本机-agent-能力盘点 → 渲染自检`
这种纯分叉。
## 回填后的真实拓扑（生产数据）
harmony-emu-unblock ─┐
deploy-pi-bridge-… ─┴→ 邮件驱动…项目概述 ─┬→ 核实-HomeAgent-mail-bridge
└→ 邮件驱动…项目概述-2 → 时间显示自检
本机-agent-能力盘点 → 渲染自检
## 可见性：逐节点过滤 + 剪断不可见祖先（安全边界）
树天然会把父节点带给子节点，而「我能看见 B」≠「我能看见 B 的父 A」
（A 可能是别人与别人的对话）。
所以按节点过滤之后**必须重算 parent**：不可见的祖先一律跳过、树在可见处
重新起根。只过滤不重算，输出里就带着不可见父的 session_id 与标题 ——
一条真实的泄露路径，而且它藏在「树视图」这个新功能里，没人会想到去查。
**admin 看全部**（用户 2026-10-04 定的分层）。
★ 与 Agent 侧那条边界无关：`AgentMayReadSession` 是 15e4fe9 / 095213b
修出来的越权防护（Agent 只能读自己参与过的会话）；本端点属人类登录态，
admin 全看是显式授权的。两者语义不同，不要混谈。
## 回填只跑一次
回填改的是会话**拓扑**，不是派生数据。若每次 Migrate 都跑，
「某人手工把 parent 改对」会在每次重启时被悄悄改回去 —— 与既有
`backfillMailReads` 同族（其注释：每次跑会把「某抄送方读过」按主收件人
写成已读，正是那次要修的语义错误）。故用 `app_meta` marker 守住。
★ 判据分两包：`repo` 测回填口径与剪枝，`db` 测「二次 Migrate 不覆盖人工设置」。
只写在 repo 包就只测到「回填幂等」，测不到 Migrate 那一层。
## 实现中修掉的三个真 bug（都被判据抓到）
1. **参数顺序反了** —— `t.lvl < ?` 是 SQL 里第一个占位符，我放在 args 末尾
⇒ 根查询拿到一个整数、匹配不到任何行，树只返回递归分支那半。
2. **环下打满 55s 超时** —— 计数写成相关子查询，环下每个节点都重跑一次
mails 计数。改成 `LEFT JOIN` 两个聚合后 0.01s。
3. **`IN (NULL)`** —— parentIDs 为空时该表达式恒不匹配任何行。
## 判据（8 格）
含防环（环下 0.01s + 耗时断言）、不覆盖人工父、不把同会话内邮件父子
当会话父子、不回填不可见祖先（两个变异分别去掉「过滤」「剪断」都转红）。
★ 判据自己错了一次：「隐藏不可见祖先」那格我写成「对每个可见节点都断言
depth==0」，但 B 重起根（0）、C 仍挂在 B 下（1），两者不同 —— 判据红而代码
是对的。（又是「判据比语义宽/窄」那一族。）
14 包全绿。
|
2026-10-04 12:03:58 +08:00 |
|
|
|
d284f1f0af
|
feat(admin): 真实删除会话的 API —— DELETE /api/v1/admin/sessions/{id}
## 为什么要有
此前清理测试数据只能手工敲 sqlite3，而那立刻暴露了这套 schema 的两个陷阱，
两者都不是「照着表名删」能发现的：**级联在这套 schema 里不成立**。
attachments → CASCADE ✔ 唯一声明了自动的
mails → NO ACTION
mail_reads → NO ACTION
relayed_mails → NO ACTION
permission_requests→ NO ACTION
session_agent_locks→ NO ACTION
漏删任何一张都不会报错，只会在几周后的一次体检里以 `foreign_key_check`
悬空引用的形式冒出来 —— 那时已经没人记得它是怎么来的。
实现按依赖倒序删 7 张表，全在一个事务里（任何一步失败即整体回滚；
半删比不删更糟：会话没了但邮件还在，而用户以为已经删干净了）。
返回**实际删掉的行数**而不是只回 200：一个只删了 sessions 却漏了 mails 的
实现也能返回 200，而 mails 还在意味着那封对话在界面上看不到却仍在库里。
## 两个设计决定
**① 挂 `AdminOnly` 组，不挂 `UserAuth` 组。**
会话是多方的协作记录（多个 Agent + 人类的往来）。`UserAuth` 组里任何登录
用户都能看到自己的全部会话 —— 放那里等于让任何人删别人的历史。
**② 刻意不进 MCP 工具面。**
删除不可撤销，而 MCP 的调用方是**模型**：误判一次就是真丢数据。
与 `connect_to_server` 刻意不提供改坐标参数同一条原则 ——
**不可逆的运维动作不进模型可及的面**。Agent 要结束线索走归档。
## ★ 实现中测出的两件事（都改了我的判断）
**① `parent_mail_id` 那步不是必需的 —— 我一开始写错了注释和判据**
我以为「有回复链时删除会撞外键约束」。实测：
DELETE FROM mails WHERE session_id = X → 同语句内删父子，SQLite 不报错
`NO ACTION` 只在删除后**仍有行**引用被删行时才拦，同语句内删父子是合法的。
所以那步是**防御性冗余**（为「将来拆成两条语句」那件事留的），
注释已改为陈述实测，不再说它必需。真正必须先处理的是 schema 本身：
历史数据里已有 7 条悬空引用，是早于这套代码的既存违规。
**② 判据自身出了两次假绿，都是同一个原因：观察方式比语义宽**
| 变异 | 表面 | 真相 |
|---|---|---|
| 撤掉 mails 删除 | 0 红 | 变异**没应用**（按字符串匹配命中了文件头注释） |
| 撤掉 parent 断开 | 0 红 | 变异确实应用了，但判据**断言了一个 SQLite 不提供的保证** |
第二次值得记：我写了个「删除是否生效」的断言，它报「未生效」，我一度以为
删除失败 —— 实际是**全文搜 `parent_mail_id = NULL` 命中了文件头注释里
同一句话**。断言本身写错了，不是删除错了。
改用**代码行特征**（反引号包裹的 SQL / 错误文案）判定后，两个真实变异都转红：
漏删 mails → 2 格红 ✓
漏删 session_agent_locks → 1 格红 ✓
## 判据（5 格）
除上面两条，另含：删不存在的会话必须报 `ErrSessionNotFound`（幂等返回 200
会让「重试」与「成功」不可区分）；不得误删别的会话；中途失败必须整体回滚
（用触发器注入失败，断言会话与邮件都还在）。
全量 14 包绿。
|
2026-10-03 13:41:02 +08:00 |
|
|
|
cf0ba1382c
|
fix(安全)★★: 停用（status='disabled'）不拦鉴权 —— 两条路径都能绕过
## 缺口怎么被发现的
给公网 MCP 接入做验证时注册了一个一次性探针身份
（`mcp-wan-probe`），收尾执行 `UPDATE agents SET status='disabled'`，
本以为凭证就此失效。实测：
POST /api/v1/mcp（带该凭证） → 200
tools/call send_mail → 已发送（真的发出去了）
## 根因
`SetAgentDisabled` 这个 API 存在、返回成功，但 **status 只在投递方向被检查**
（`EnsureAgentDeliverable`，repo.go:209）。两条鉴权路径都不查：
VerifyAgent(ctx, name, secret) 选了 status 却从不判断 ← 缺口
VerifyAgentKey(ctx, token) 拿到名字直接返回 ← 同一个缺口，更严重
第二条要紧：Bearer key_token 正是 `middleware/auth.go` 注释里标「推荐」的
路径，官方建议用它 —— 它因此成了绕过停用的最短路。
缺口形状是「接口存在、返回成功、但只做了一半」，比没有这个接口更危险：
运维会以为停用已经生效。实测语义完全反了 ——
**停用只挡住了「别人给它发信」，没挡住「它自己发信」**。
## 修法
停用 ⇒ **拿不到 Agent 身份** ⇒ `AgentAuth` 直接 401，后续 handler 根本不执行。
这比「拿到身份后在某个业务分支拒绝」强：后者会让列表类 API 仍泄露身份存在。
两个细节：
* 返回 `sql.ErrNoRows`（而非自定义错误）⇒ 与「凭证不存在」**不可区分**，
否则可用该接口枚举出哪些名字是真实 Agent。判据里有专测这一格。
* status 检查放在 `wsJSON` 解析**之前** ⇒ 停用身份不会被解析出工作区，
那会让调用方以为它还「活着」。
## 判据（4 格）
**其中「反向对照」这格最关键**：`status='online'/'active'/''` 必须照常通过。
没有它，一个「永远返回 ErrNoRows」的 `VerifyAgent` 也是全绿的 ——
而那会让**所有** agent 都登不上，是比原缺口更大的事故。
**变异验证**：
撤掉 VerifyAgent 的 status 检查 → 3 格红 ✓
撤掉 VerifyAgentKey 的 status 检查 → 1 格红 ✓
全量 14 包绿。
|
2026-10-03 12:18:39 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
560c462768
|
feat(mcp): GET /api/v1/mcp —— 投递侧事件流（让接入方被动收信，不用轮询）
## 这半边解决什么
工具面（POST）只解决「接入方**问**」。这一条解决「服务端**说**」：
邮件投递时把 new_mail / session_update 推给接入方，让它**拉起对话** ——
与各桥靠 /api/v1/events/stream 收信是同一件事，只是方言不同：
桥: id: 7\nevent: new_mail\ndata: {…}\n\n
MCP: {"jsonrpc":"2.0","method":"notifications/message","params":{…}}
## 为什么复用 sse.Manager 而不是另起一套
Manager 里那些东西**都是踩过坑才对的**：writeMu 串行化（2026-09-28 -race
实测 http.ResponseWriter 并发写会把 JSON 劈成半截，800 帧只切出 459 个完整）、
Last-Event-ID 回放（宁可重复也不丢失）、心跳（反代按空闲 30-58s 掐连接）、
环形缓冲上限、断线清理。复制一份等于把那些坑再踩一遍，
而两边的修复从此各走各的。
代价是 `sse.Client` 多了一个可选 `Frame` 钩子：
**nil = AgentMail 原格式，各桥与 WebUI 行为一字未变**（默认值即历史行为）。
## ★ 回放是第三条写路径，漏了就只在断线时现形
`Send` / `SendWithID` / `replay` 是三条写 Res 的路径。原先**三条都把格式写死**，
只改前两条的话：MCP 客户端**平时**一切正常，只有带 `Last-Event-ID` 重连时
才会收到一批自己解不开的帧 —— 同一个连接上两种方言。
判据 `TestCustomFrameAppliesToReplayToo` 专门钉这条，并带反向对照
（nil 帧必须回落 AgentMail 格式）。
`Frame` 必须在**注册时**传入（`AddClientWithFrame`），不能事后设 ——
回放发生在「先写响应、再注册」的前半段，事后设只影响之后推来的事件。
原先 `AddClient` 保留为薄封装，各桥与 WebUI 调用点一字未改。
## 判据（6 格）
Frame 是 JSON-RPC 2.0 通知 + 帧完整性（单事件、\n\n 结尾）
payload 原样嵌入（不是 JSON 字符串）—— 再 marshal 会让客户端解析两次
event_id / event_type 必带（前者是 Last-Event-ID 续传的依据）
Accept 判定（含 q 值、大小写）
匿名 GET → 401（不能变成静默的匿名订阅）
缺 Accept → 406（接错的客户端会静默收不到东西）
## 顺带修：TestAdvanceRecurrenceLunar 的时区缺陷（★ 今天第三次假红）
全量测试红了，查下来是**我今天早些时候改判据时引入的**，与本次改动无关。
农历换算必须按**本地公历日**算（`AdvanceRecurrence` 里那句
`eventTime.In(time.Local)` 就是这条规则）。库里读回的 EventTime 是 **UTC**
（DSN 用 `_timezone=UTC`），UTC 比本地晚 8 小时，跨零点时农历日差一天：
start (Local) = 2026-10-04 农历日 24
after (UTC) = 2026-11-01 16:00 农历日 23 ← 断言没换算时区（错）
after.In(Local) = 2026-11-02 00:00 农历日 24 ← 正确
服务端代码一直是对的，是判据没照做。失败信息里现在打印时区，
免得下次要重新推导一遍。变异验证：去掉 `.In(time.Local)` → 红 1 ✓
（这条判据是农历的第三次假红了：3459605「断言要求不存在的农历日」、
今天早些「起点写死日期 + advanceToFuture 跳过过期月份」、现在「没换算时区」——
三次都是判据自己写错，代码三次都对。它依赖 Local 时区与「今天」，
天生脆弱，值得记着。）
## 验证
go test ./... 14 包全绿
go test ./internal/sse/ 含新判据绿
go test ./internal/mcp/ 6 格新判据 + 原 19 格全绿
|
2026-10-02 15:37:34 +08:00 |
|
|
|
095213b981
|
fix(安全)★★: 声明别人的 session_id 就能读那封信 —— 补「参与方」判据
## 漏洞（实测，生产可利用）
对照实验（同一会话、同一 Agent，绕开 MCP 直打原生端点）：
主人 mcp-peer 读自己的信（带正确 session_id） ⇒ 200（正常）
他人 mcp-probe 读同一封信（**带正确 session_id**） ⇒ 200 ★ 泄露正文
绕开 MCP、直接 `GET /api/v1/agent/mail/{id}?session_id=...` 同样 200
⇒ 根因在网关，不在任何接入方式。
生产复核（现行 8180，未改任何代码）：
dsh 声明 gui-lab 的 session_id ⇒ HTTP 200，拿到完整正文
## 根因：判据里没有「你是谁」这一项
上一版（今天早些时候，15e4fe9 那次）只把 `if scope == nil { return true }`
改成拒绝，堵住的是「**不声明** session_id 就放行」。剩下的半边是
「声明一个**别人的** session_id」。
判据只有一句 `*scope != target` —— 它问的是「你声明的会话是不是目标会话」，
而 `session_id` **由请求方自己给**。于是任何持有 Agent 凭据的客户端只要报出
一个已存在的会话 id，就能以那条会话的身份读它。
漏洞的形状就写在签名里：函数**收了** `agentName`，却被 `_ = agentName` 丢弃。
## 「信任边界在桥」这个前提不成立
函数头原来写着「信任边界在**桥**：`session_id` 由 worker 闭包注入（模型改不了）」。
那是对我们自家四个桥的陈述，**不是**服务端能强制的事实：
1. 桥与网关之间是普通 HTTP。任何拿到 Agent 凭据的客户端都能直接调这些端点
（本次实测即是如此）。
2. 「由闭包注入」是对我们自己代码的信心，不是收到请求时能重新验证的事实。
上一版收口时也用过同类理由（「迁移期未结束」），实测同样不成立 ——
这是同一天内第二次。
## 修法：把「声明」变成可验证的事实
保留 `*scope != target`（2026-09-15 裁定：会话是独立单位、不跨会话读取），
**另加**一道参与方校验：
scope == target 且 agentName ∈ 该会话的参与方（from / to / cc） ⇒ 放行
- 不引入工作区轴（那是 cwd/沙箱那条轴，2026-09-15 明确划开）。
- 不新建表、不加迁移。
- 参与方判定与 `SessionParticipants` 同源（逐封扫 mails，同一个 `models.Address`
JSON 解析），避免两处对同一份数据给出不同答案。
- 抄送方算参与方：生产里有 2622 行非空 cc_list，只认 from/to 会把正当读者判成外人。
## fail closed
查参与方出错（DB 不可用、cc_list 解析失败）一律拒绝并带错误。
这道闸的失败模式必须是沉默的拒绝 —— 一旦「查不到就放行」，
数据库一抖就等于把漏洞重新打开，且没有任何日志。
## 判据（9 格，含改写）
改写 2 格：`AllowsOwnSession` 原来用 `uuid.New()` 造一条**不存在的**会话
就断言放行 —— 那正是漏洞的形状；`IgnoresAgentName` 断言「身份不参与判断」，
**这条断言本身就是漏洞**。两者都改成断言新事实。
新增 7 格，覆盖：声明别人会话被拒 / 抄送方放行 / 主收件方放行 / 空身份拒绝 /
判定随身份改变 / 跨会话仍拒（参与方也不行）/ fail closed。
**变异验证**（每条确认已应用后才数红格）：
退回漏洞原状（跳过参与方校验） → 红 3
只认 from_agent（漏 to 与 cc） → 红 1 ★（先测时红格为 0，补了主收件方那格才抓住）
fail open（查不到就放行） → 红 1 ★（同样先红格为 0，补了 fail-closed 那格）
后两条是**补判据的过程**：`return true` 那版和「只看 from」那版都能全套通过，
说明原先的判据盯不住这两个改法。
## 对现有桥的影响（部署前实测）
按生产数据核对四个桥：「from_agent 是它、但它不是任何邮件参与方」的会话
只有 1 条，且**零邮件**（一条权限请求测试会话）—— 那类会话没有邮件可读，
判据影响为零。桥不会被误伤。
## 波及面
`AgentMayReadSession` 有 5 个消费点：read_mail / read_thread / 读会话参与者 /
forward 的源信 / AgentGetMailThread 另一分支。全部自动获得这道判据。
全量 14 包绿。
|
2026-10-02 13:27:43 +08:00 |
|
|
|
6757644756
|
fix(判据): 农历推进的起点必须在未来 —— 否则 advanceToFuture 跳过过期月份必假红
## 现象
部署被测试闸拦下（这正是纪律该做的事）：`TestAdvanceRecurrenceLunar` 报
「间隔 58 天不像一个农历月」。已确认与本次 SSE 改动无关
（把我的改动全部 stash 后它同样红）。
## 根因（实测复算，不是推测）
`AdvanceRecurrence` 走 `advanceToFuture`，职责是「推进到**未来**」：
已经过去的农历月会被跳过（`if cur.After(now) { return }` 那个循环）。
原起点写死 `2026-09-03`，而今天已是 10-02 ⇒ 那个农历月（10-02）已过去
⇒ 循环再推一个月。探针实测：
起点 2026-09-03 ⇒ 落点 2026-10-31 间隔 58 天 ← 旧起点，今天跑必红
起点 2026-10-03 ⇒ 落点 2026-11-01 间隔 29 天 ← 明天，正确
农历库本身是对的：直接调 `AddMonths(1).ToSolar()` 得到的落点恰好 29 天。
所以**不是代码缺陷，是判据的期望依赖了「今天离起点不到一个月」**这个
随日期漂移的前提。
## 修法
起点改为「明天」起算（不写死具体日期 ⇒ 明年跑也成立），
农历日的期望也跟着起点走。
★ 不用 `time.Now().AddDate(0,1,0)` 那种相对写法：农历月 29/30 天不定，
起点落在月末时下一个同农历日可能被夹（commit 3459605 记的同族假红）。
明天起算同时满足「确保在未来」与「落点就是下一个农历月」。
## ★★ 修判据时差点削弱了它（变异验证抓出来的）
把起点改成明天后判据绿了，但我立刻做变异验证：
变异：advanceToFuture 不跳过已过期月份 ⇒ TestAdvanceRecurrenceLunar **全绿**
因为起点在未来，第一个落点本来就在未来，循环与单步没有区别 ——
**我修好了假红，却顺手删掉了「跳过过期」这个真行为的判别力。**
补了一格：用**已过期 70 天**的起点单独钉它，落点必须在未来，
否则「每次扫描都重复触发同一封提醒」。变异重测 ⇒ 红 1 格。
这是同一天内第二次判据自身缺陷（第一次是 SSE 那格只查文本不查控制流）。
**改判据后必须变异验证判别力还在**，否则就是用改测试掩盖问题。
|
2026-10-02 10:57:59 +08:00 |
|
|
|
477b74230f
|
fix(限流): 用 ORDER BY ts 取窗口内最早一条，不靠 MIN(ts) —— 429 的 retry_after 恒为 60
## 缺陷
`SELECT MIN(ts) FROM rate_limits ...` 的聚合结果被 SQLite 驱动按 **string**
返回，扫进 `*time.Time` 失败 ⇒ 落到兜底 `return false, 60`。
⇒ 所有 429 的 `retry_after` 恒为 60，与真实剩余窗口
（最长 `sessionRateWindow` = 1h）完全无关。调用方拿到的重试提示是错的：
限流窗口还有 55 分钟，它却说 60 秒后重试。
## 修法
`SELECT ts FROM rate_limits WHERE bucket = $1 AND ts >= $2 ORDER BY ts ASC LIMIT 1`
排序取值走**结果集本身**，驱动按列类型给 `time.Time`；语义等价。
★ 同一形状的坑今天已出现两次：上午 2h 冷静期因 UTC vs HKT 差 8 小时而形同虚设，
晚上权限记账因两处 `if` 守卫而静默失效。**根子都是「SQLite 侧的时间/类型处理
与直觉不符」，而症状在别处。**
## 判据
4 格（retry_after 反映真实窗口 / 绝不超过 window / 窗口滚动后放行 /
只数窗口内的记录），其中主判据显式对比「修复前 60，修复后 ≈window」。
本改动此前已随 2026-10-01 的两次部署进入线上二进制（vcs.modified=true），
本次补提交以让 provenance 对得上。
|
2026-10-02 10:02:35 +08:00 |
|
|
|
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 |
|
|
|
15e4fe9203
|
fix(安全): 未声明 session_id 不再放行 —— 实测任意 agent 可读全部邮件正文
## 漏洞（亲自实测，不是读码推断）
用 dsh 的密钥、不带任何 session_id，逐个 GET `/api/v1/agent/mail/{id}`：
20 封别人的信（收件方 pi / homeagent / opencode，分属
/home/program/TrueAgent 等不同工作区）⇒ **20 封全部 200，拿到完整正文**，0 拒绝。
对照（证明闸本身没坏，只有一个缺口）：
带自己参与的 session_id 读别人的信 ⇒ 403 ← 闸有效
不带 session_id ⇒ 200 ← 漏洞
根因是 `AgentMayReadSession` 的一个分支：`if scope == nil { return true }`。
该函数 2026-09-15 的注释写明「首次接线前的旧语义（未声明 scope）保持放行」——
那是**迁移期妥协**，不是设计。
## 为什么「迁移期」已经结束（实测数据推翻了当初的假设）
当初假设「未接线的桥/脚本/浏览器会走这里，等接完就收口」。而
`[agent-scope]` 警告日志累计 203 次，按调用方拆开：
homeagent 125 / dsh 40 / pi 37 / opencode 1 / 其它 0
⇒ **202/203 来自四个桥自己**，集中在 `/api/v1/agent/mail/{id}`（pi 24 次）、
读会话参与者、`/mail/{id}/forward`。
不是「少数旧客户端没接线」，而是**主力客户端在裸奔**，而放行恰好把它们全漏过去。
日志抓手已完成使命：它精确指出了「谁还没带」，答案就是所有人。
## 为什么不能靠「补齐调用方」收口
要同时改四个桥（pi 的 `getMailSessionId` 有 `= () => ''` 的默认值，
忘注入就是静默空串 ⇒ 回到裸奔）。**默认放行与默认拒绝的差别就在这里：
前者的失败模式是沉默的。** 任何一处漏了 = 静默越权，且没有任何东西会红。
## 判据
`grep -rln AgentMayReadSession --include=*_test.go` ⇒ 修改前**零覆盖**。
一个决定安全边界的函数没有任何判据，这就是妥协能活到今天的原因。
新增 4 格：未声明须拒 / 声明且相等须放行 / 跨会话须拒 / 判定不随 agentName 变
（后者钉住 2026-09-15 裁定「每个 session 是独立『用户』」，防有人顺手加按 agent 的仲裁）。
两个变异都经得起：恢复放行、reason 改成 handler 不认识的值，各红一格。
reason 复用既有的 `not-your-session`：新增 reason 不同步改 handler 的 switch
就会把 403 变成 500；复用后 canReadSession 的 self 为空时，文案自然表达
「你还没声明自己在哪条会话」。
验证：13 包全绿 + `-race` 干净。
|
2026-10-02 00:34:13 +08:00 |
|
|
|
1d7b018734
|
fix(权限): 决策人��空时不再静默跳过已读记账 —— 那让权限邮件永远显示未读
## 形状
`DecidePermission` 的函数头承诺「权限邮件对他（决策人）也应当变成已读」，
但那两段记账都被 `if decider != ""` 包着。而**未读判据是 mail_reads**
（`unreadFor` / `readStateFor`），不是行级那列。⇒ decider 为空时：
mails.status = 'read' （全局冗余列改了）
mail_reads —— 没有这一行 （事实表没记）
⇒ 收件人在收件箱里**永远看到这封未读**，尽管它早已决策完。
## 线上实证
13 封这样的历史邮件，收件人均为 jianf，2026-09-08 / 09-13，主题全是
「权限请求: 请求执行 bash」—— 每一次都已被人类决策过（同意/拒绝）。
## 为什么今天 HTTP 路径触发不了
`permission.go` 会沿会话树上溯找人类（`NearestHumanInThread`），
HTTP 层传的也是 `user.Username`。但 repo 层是**所有调用方的门**，
`MarkMailRead` 早就为同一件事挡了（reader 是必填语义），只挡它一个等于漏网。
静默跳过正是 `if decider != ""` 的写法问题：它把「不知道谁读的」记成「不用记」。
## 同族核对（不是只看这一处）
全 internal/ 树扫 `UPDATE mails SET status ... 'read'`，共 4 处，
逐处核对其前置 45 行是否有 mail_reads 记账：
MarkMailRead ✓ / MarkMailsReadFor ✓ / MarkAllInboxReadForSession ✓ / DecidePermission ✗
⇒ 唯一缺口就是这一处。事实表本身干净：无空读者、无孤儿行。
## 判据
新增 2 格：空 decider 报错 / 决策后 mail_reads 必有记录且派生读数为 read。
两个变异都经得起（去掉报错守卫、去掉 mail_reads 写入，各红一格）。
## 顺带记一个判据的坑
`mail_status_readers_test.go` 的 readRe 是**纯文本**匹配 `mails.status`，
会把我注释里提到该列名也算成「新增一处读取」，导致那条清册判据变红。
已在注释里避开那个写法并写明原因 —— 改这块代码时若它突然变红，先看是不是注释。
|
2026-10-02 00:15:02 +08:00 |
|
|
|
4d8165fde9
|
fix(回路): Agent↔Agent 加 2h 冷静期；冷却期内 relay 不自动重投递
缺口：maxAgentPingPong=8 撞闸后**计数永不回落** —— 只有人类插话才归零。
旧文案把出路指向「请由人类插一句话」，而那条线索上常常**根本没有人类**
（2026-10-01 报告：agent 一封都发不出，且那条线索无人在场）。
修法（两条要求分别落地）：
① 2h 恢复机制：撞闸即写入 session_agent_locks（落库，内存态一重启就"恢复"，
且多副本各算各的）；到期自动放行，人类插话立刻解锁（优先于到期）。
② 锁定期间的邮件不自动重投递：冷却期内 relay 直接 403 丢弃 ——
**不排队、不占幂等键、不入库**。排队会在 2h 后一次性灌回去，
那等于把刚压住的回路换个更糟的形状放出来。
实测踩到的三个坑（都被判据抓住）：
- `VALUES ($1,$2,$2,...)` 让 until_at 复用 locked_at 的 $2 ⇒ 锁诞生即过期
- driver 以 UTC 扫回 DATETIME，而 time.Now() 是本地(HKT+8) ⇒ 差 8h > 2h 的一半 ⇒ 锁形同虚设
- 只查**收件方**是否人类，漏了**发件方** —— 而「人类插话解锁」的常态就是
人回信、收件方仍是 Agent ⇒ 人插话反被自己写的闸 403 拦下，那条出路根本不存在
- SQLite 没有 GREATEST；在 DATETIME 上按**字符串**比大小 ⇒ CASE 也会错。
改为「已有锁一律不碰 until_at」。
判据：repo 6 格（含"读失败不得读成未锁定"—— 最初 0 格能抓，变异测试补的）
+ handler 4 格。三个变异全部经得起（且每��都先确认变异编译通过再数红格 ——
本轮多次 grep 得 0 实际是 build failed，测试压根没跑）。
|
2026-10-01 19:41:06 +08:00 |
|
|
|
974bf2a62f
|
fix(server): ★ relay 邮件不计入 Agent 互发上限 + 该闸放行 relay 发送 —— 修「退信把通道自己锁死」的会话死锁
症状（生产会话 0094eee5 `harmony-push-真机验证`）：
homeagent 的 3 封失败退信（relay:"summary"）被 CountTrailingAgentPingPong
计入「Agent 互发」计数，与 5 封模型主动往返合计 8 ⇒ 触发上限。之后：
· 模型每次真生成完回复再 send ⇒ 403（网关日志 09-29 22:01 ~ 09-30 10:11 共 7 笔）；
· 桥的 sendFailureReply 退信也走 /mail/send ⇒ 同样 403 ⇒ 发件人只收到
「模型未产生回复」，真因被吞；
· 被拒的尝试不产生新邮件 ⇒ 计数永不回落 ⇒ 死锁，无人能解。
发件方收到的错误与「模型没说话」在桥侧合并成同一文案（plugin.go:1022），
把内核侧限流误报成模型故障 —— 两个 Agent 各自查错了方向一整天。
根因：2026-09-26 设计第三道闸时的实测样本（pi↔dsh 175 封）里 relay=0，
于是默认这条路径上没有 relay 邮件。但插件代劳的退信同样满足
「Agent→Agent + 无人类」，被并进同一个闸。relay 本有自己的更严闸
（maxRelayHops=5），两类回路挤在同一个计数里是设计疏漏。
修法（两处，缺一不可）：
1. repo：CountTrailingAgentPingPong 跳过 relayed_mails 里登记过的邮件
（LEFT JOIN，与 CountTrailingRelayHops 同一判据源）。
2. handler：该闸加 `relay == ""` 条件 —— 即使计数已满，插件代劳的
退信/转发也必须能发出去（否则 ①② 仍在：闸拦住退信 → 真因被吞）。
红绿（生产同款数据形状）：
3 主动 + 3 relay + 2 主动 ⇒ 缺陷版数出 8（FAIL，与生产实测一字不差），
修复后 5（PASS）。人类参与打断连续性的语义不变（回归 TestAgentPingPongResetsOnHuman）。
自证边界：单测证明的是计数器与闸门的判据；「死锁会话已解锁」要在部署后
用真实会话验证（见下一笔提交）。403 文案同时删掉了「或说明为何这轮必须继续」
—— 模型的任何说明本身也要走 send，被同一道闸拦着，这条恢复路径不存在。
|
2026-09-30 17:08:49 +08:00 |
|
|
|
a3ca64b744
|
fix(归档): 权限决策同样不得把归档邮件改回 read ＋ 修正决策路径误用参与方判据
pi 2026-09-28 §五 指出 DecidePermission 与 MarkMailRead 是同一族的反向写入，
只堵后者等于堵一半。成立，本轮收口。
## 1) DecidePermission 补守卫（pi §五）
UPDATE mails SET permission_result=$1, status='read' WHERE mail_id=$2
↑ 无 archived 守卫
与 MarkMailRead 同一处形状，补 `AND status <> 'archived'`。
判据 TestDecidePermissionDoesNotUnarchiveMail，已实测去掉守卫即转红。
★ mail_reads 的 INSERT 仍**不加**守卫（与 MarkMailRead 同口径）：
事实表（谁读过，不可撤销）与派生列（全局可见性，可重算）语义不同，
一起挡会让「谁读过」不可审计 —— 判据 TestDecidePermissionDoesNotUnarchiveMail
顺带断言「决策人 bob 的 mail_reads 行仍要写进去」，防止守卫误伤事实表。
## 2) 修正 e78888b 的一处误用（我自己发现的）
DecidePermission 的 handler 路径（handler/permission.go）我原先挂了
`SessionOpenFor`（存在 + 未归档 + **参与方**），而该路径上一行刚放行的是
「该邮件收件人本人 **或** 管理员」—— 管理员本来就可以给任何线索做决策。
叠上参与方会把管理员挡在门外。改为 `EnsureSessionOpen`（只判存在 + 未归档）。
★ 这个错是在写 e78888b 时想到了、说了「要改成 EnsureSessionOpen」，
但**当时没落进文件**就提交了。已补，并在注释里写明两个函数的差别，
免得下一个人「顺手统一」把管理员又挡掉。
## 读侧清册
仍为 repo.go=13：新增 1 处命中在注释散文里，改措辞而非改数字。
repo/handler 全绿；internal/notify 的 TestInReplyToCarriesParentSender
仍是既有欠账 in-reply-to-ignores-direction，非本轮引入。
|
2026-09-28 11:12:59 +08:00 |
|
|
|
2b77b17e65
|
fix(归档): 标已读不得把归档邮件改回 read —— e78888b 的不变量有反向缺口
pi 2026-09-28 复核 e78888b 时指出：EnsureSessionOpen 堵住了「往归档会话里建邮件」，
但 MarkMailRead 能**反向**打破同一个不变量。复核成立。
POST /api/v1/mail/{id}/read（对归档会话里的一封）
→ GetMailByID（无 status 过滤）→ UserCanAccessSession（只查参与方）
→ UPDATE mails SET status='read' WHERE mail_id=$1 ← 不查 status
实测：mails.status `archived → read`，而 sessions.status 仍是 archived
⇒ 两表分叉，且 readStateFor 返回 'read' 而非 'archived'，
**归档语义在行级被抹掉**。已加 TestMarkReadDoesNotUnarchiveMail，
先确认它在修之前转红（不是改完就绿的装饰）。
同族的批量路径 MarkAllInboxRead 本来就有守卫
（`session_id IN (SELECT ... WHERE status <> 'archived')`，markread_test.go:126
断言了它）—— 缺的只有单封这一处，所以这是漏网而非设计如此。修法与批量那条同形。
★ mail_reads 的 INSERT 刻意**不加**守卫：已读是按读者记的事实，
人确实读过，归档不该改写它。行级那列是「全局可见性」的冗余、mail_reads 是
「谁读过」的事实，两者语义不同 —— 一起挡会把事实也丢掉。
读侧清册仍为 repo.go=13：新增的那 1 处命中在注释里（散文里拼了列名字面量），
改写措辞而不改数字 —— 让数字 +1 会给未来新增读取凭空送出 1 格余量。
|
2026-09-28 11:07:32 +08:00 |
|
|
|
e78888b756
|
fix(归档): 两表判据分叉的成因收口 —— TouchSession 不再写 status，建邮件一律拒归档会话
pi 2026-09-28 裁定 §1/§2 认可「判据分叉」这个定性，§4 要求做 1+2，
并把 permission/request 点为第三个复活入口。本轮做 1+2，并补上第四个。
# 缺陷：归档后不可见，判据挂在两张表上
unreadFor / readStateFor 判邮件行 （repo.go:unreadFor）
ListInbox / UnreadWorkspaces 判会话行 （repo.go:ListInbox）
两边对同一条已归档线索给出不同答案，而每一边单独看都「是对的」。
分叉由 `TouchSession` 的 `SET status='active'` 与建邮件 INSERT 只写
邮件行共同造成 ⇒ 只要有一个写路径碰会话行而不碰邮件行，半活会话就能被造出来。
# 改法：让不变量由构造保证，而不是逐个入口堵
· TouchSession 只剩 updated_at —— 它是全库唯一能解除归档的入口
· EnsureSessionOpen 是 CreateMail / CreatePermissionMail / CreateDecisionMail
的共同前置（集中一处，新增建邮件函数必须经过它）
· ErrSessionArchived 与 ErrSessionNotFound 分列：调用方要能分开回话
· resolveTarget 的 reply_to 分支恢复归档契约（此前绕过别名路径的 404）
· permission/request 补 SessionOpenFor：存在 + 未归档 + 参与方
· FindSessionByPlatformID 补 s.status（adopt 路径，pi 未列的第四个入口）
# 判据：写成不变量而不是单点
session_status_invariant_test.go：对任意 session_id，
sessions.status='archived' ⟹ 该会话全部邮件 archived。入口级回归单测仍在，
但它们是说明。已实测把 TouchSession 改回旧实现后该判据转红
（不是「改完就绿」的装饰）。
# 读侧清册
mail_status_readers_test.go 的清册仍为 repo.go=13 / thread.go=1 / migrate.go=4：
本轮新增的 5 处命中全在注释里（散文里拼了列名字面量），已改写措辞而不改数字
—— 让数字变化会给未来新增读取凭空送出 5 格余量，正是那张表要防的事。
# 遗留（pi 裁定本轮不做，已登记）
FindSessionByAddress 无 status 条件：补上会把重复归档从 200 变成 404，
属行为变更，不在 bugfix 里夹带。
|
2026-09-28 11:01:38 +08:00 |
|
|
|
db640e2360
|
fix(repo): platform_sessions 整表替换的域是 (agent, workspace) 而非 agent
修 `DEBTS.json` 里记的 `platform-mirror-replace-domain-too-wide`
（pi `b9c7308c` 报的，当时只做了定位未修）。
# 缺陷
`ReplacePlatformSessions` 的 DELETE 域是 `agent_name` 单列，而**每个上报者
只知道自己一个 directory**：
plugins/opencode-mail-bridge/index.js:1147
client.session.list({ query: directory ? {directory} : undefined })
⇒ A 工作区的桥上报一次就把 B 工作区上报过的镜像全擦掉，下个工作区的桥
再上报又擦掉 A 的。表现为「镜像按 project 轮换」。
# 生产实测（不是推断）
sqlite3 agent_platform_sessions GROUP BY workspace：
dsh 77 条散在 **25** 个工作区（/home/program/agentmail 25、/tmp 20 …）
pi 151 条散在 **62** 个工作区
# 后果已在生产数据上可见
镜像被擦 ⇒ `notify/mail.go` 的 `PlatformSessionFor` 查不到 ⇒
`sessions.platform_id` 留空。实测 **18 条活跃会话里 17 条 `platform_id` 为空**。
空 platform_id 不止"少个跳转"：`notify/mail.go:94` 用它决定
`platform_session_id` 发给谁，owner 取错就抛「平台侧会话已删」⇒ 邮件静默消失。
# 修法
DELETE 域收窄到**本次上报覆盖的那些工作区**（wsOrder，去重保序）。
一次上报跨多个工作区 ⇒ 那些各自整表替换；本次没出现的一律不动。
仍然是"整表替换"而非增量合并 —— 镜像是平台快照，增量合并会让已删会话永远
留在候选里，而 session 位是三态语义、指向不存在的会话直接 404（"选了却送不到"）。
## ★ 一条判据覆盖不到的分支，单独补了判据
`if len(wsOrder) > 0` 这个守卫（wsOrder 为空 ⇒ 什么都不删）**既有判据碰不到**：
所有既有用例传进来的 list 都带 workspace。实测把守卫改成 `>= 0`（空清单也按
agent 清，退回缺陷），**全部既有判据仍然绿**。
补 `TestReplacePlatformSessionsWithNoWorkspaceKeepsEverything`：
一次不带 workspace 的上报后，`/A` 与 `/B` 的镜像都必须还在。
变异验证：该判据能抓住这个变异（而既有判据抓不住）。
# 关于"空 IN ()"
守卫去掉会拼出 `workspace IN ()`。SQLite 与 PostgreSQL **都**是恒假（不报错），
所以行为上等价 —— 但那是依赖两个数据库的隐式巧合，不是读代码能看出来的保证。
守卫保留，并在注释里写明这一点。
# 生产验证
部署后用 opencode 的真 key 打一次带 `workspace=/ZZZ` 的心跳：
· 写入 opencode /ZZZ 1 行
· **dsh 的 25 条 /home/program/agentmail 镜像一行没少** ✓
（修前这次上报会把它们全擦掉。已 DELETE 掉测试行）
注：三个桥本次心跳都没带 `platform_sessions`（opencode 的 `reportSessions`
在 `directory` 为空且拉取失败时返回 `undefined`，服务端按 nil 跳过替换），
所以"三次采样镜像不变"**不能**作为修复生效的证据 —— 上面那次主动打心跳才是。
# 未解决（DEBTS 那条的后半）
`agent_platform_sessions` 主键仍是 `(agent_name, platform_id)`：
同一个 platform_id 出现在两个 workspace 会撞 UNIQUE ⇒ 无 ON CONFLICT +
defer Rollback ⇒ 整个 DELETE 回滚 ⇒ 镜像永久停滞。
本改动只消除"擦错别人"，没消除"同 id 跨 ws 撞约束"。要不要给 PK 加 workspace
仍未决（涉及 SQLite 需重建表 + 具名索引会丢 + 孤儿 _new 表自愈，见 DEBTS 原文）。
|
2026-09-26 14:20:23 +08:00 |
|
|
|
667d368a48
|
refactor(repo): workspace 谓词抽成共享构造器 + 删一个死函数
用户 2026-09-26：「审查一下服务端，我觉得现在还是有大量不符合设计的地方与冗余代码」。
# 先说审查结论：**"大量冗余"核不出来**
| 检查项 | 读数 |
| --- | --- |
| 99 个 handler | **全部注册，零死路由** |
| 死函数 | 2 个（本次删 1，另 1 个被测试用、保留） |
| 注释占比 | 23%（这个仓每个非显然决定都记"为什么"，是有意的） |
| 测试 | 13644 行 = 源的 41% |
# 但找到一处真问题：`workspace` 谓词手抄了三遍
同一件事在三处各写一遍：
args := []any{agentName}
if strings.TrimSpace(workspace) != "" {
args = append(args, workspace)
q += fmt.Sprintf(` AND s.workspace = $%d`, len(args))
}
★ 代价不是"多几行"，是**加参数要改三处、漏一处不会编译报错**。
本次给三个函数加 workspace 参数（`ListInboxScoped`/`CountUnreadScoped`/
`MarkAllInboxReadForSession`）就是手抄了三遍。
同仓有同类先例：`quota.go` 里那条 `★★★ 判据自检` 记的
「占位符编号错位导致静默少行」—— 根因完全一样（同一个模板抄多处，
靠人肉保持一致）。
⇒ 抽 `workspaceScope(q, args, workspace) (string, []any)`，三处各变成一行。
# 为什么"必需"这条不在 repo 层
`checkWorkspace` **允许空**：空 = 不过滤 = 人类侧（一个人跨工作区，WebUI
按 session_workspace 分组显示）。"Agent 侧必须带"是**接口契约**，放在 Handler。
抽出来的函数注释里把这层分工写死了，免得后来者以为 repo 层该拒绝空值。
# 与 `FindOrCreateDefaultSession` 里那套**故意不共用**
那里要的是「工作区为空时从 mails 反推」（历史会话兼容），语义更宽。
合并前要先确认那是不是想要的行为 —— 现在保持分开。
# 删 `SessionMailCount`
全仓零调用（连测试都没有）。`GetSessionMailByID` 也只被两个测试用，
但它是那两个测试的被测对象，**不删**（测试专用包装与死代码不是一回事）。
# 验证
· 变异：把 `workspaceScope` 改成永远不过滤 ⇒
`TestInboxListIsScopedByWorkspace` + `TestMarkAllReadIsScopedByWorkspace` 判红
· 12 个包通过；`internal/repo` 唯一的 FAIL
（`TestReplacePlatformSessionsKeepsOtherWorkspaces`）**改动前就红** ——
已用 `git stash` 式回退验证，它是 `DEBTS.json` 里记的 platform_sessions
PK 缺陷那条判据，与本次无关。
# 顺带记一笔（对我自己的）
本机 `go` 是 1.24.4 而 `go.mod` 要求 1.25.0，**`go build` 会去下载 toolchain
并因离线失败**（exit=1）。我前面几轮用 `go build ./... | head -5 && echo "编译 ok"`
判断，把 `head` 的 exit 0 当成了编译成功 —— **那是假的**。本轮才发现，
改用本地已有的 `toolchain@v0.0.1-go1.26.7` 才拿到可信结果。
⇒ 判据里凡用 `cmd | head && echo ok` 的形状，退出码被管道最后一道吞掉，
之后一律用 `cmd >/dev/null 2>&1; echo $?` 或显式检查 `${PIPESTATUS[0]}`。
|
2026-09-26 14:08:48 +08:00 |
|
|
|
4175c0ba45
|
fix(bridge): ★ 投递即标已读 —— 修「桥重启 → 重投 → 回声」
用户 2026-09-26 原话：
「我都不记得我下达这个任务，是你的桥自动重投存在 bug」
「就是你的错误的重投机制造成了回声」
# 我上一轮把因果搞反了
我先认定是「两个 Agent 自发辩论」，还为此写了第三道防线（数 Agent↔Agent
连续往返）。**方向错了** —— 是**桥把同一封信反复投递**，每次投递起一个
worker 回信，回信又触发下一轮。模型在做什么？它在回答一封被重复投进来的
旧信。用户根本不知道有这回事。
# 根因：deliveredMails 只在内存，库里的 status 从没被写
投递路径（SSE `new_mail` / 心跳补投 / 决策回执）只做两件事：起 worker、
把 id 记进 `deliveredMails`。**没有任何一处调 `/mail/read`** —— 桥里唯一
那处标已读在 `read_inbox` 工具里，要等模型自己去读收件箱。
于是每封被投递的信**永远是 unread**；而 `catchUp` 按 `status=unread` 拉
⇒ 桥一重启（**每次部署都会**），积压的"未读"被当成离线漏投**再投一遍**。
# 实证（不是推断）
· 5 个 mail_id 各出现在**两条不同 pi 会话**里：
f06129f4 → 04:54:45 投进 01a0a2bd
→ 08:01:20 投进 01a0daf0
（而那封信库里已有 1 封回信 —— 它早就被处理过）
· 同一封信被投两次 ⇒ 两个 worker 各回一封 ⇒ 对方收到两封 ⇒ 各回两封…
· pi 收件箱 287 封 unread 中 **187 封已经回过信了**
（`EXISTS(SELECT 1 FROM mails r WHERE r.parent_mail_id=m.mail_id)`）
· 两条会话各烧到 463 / 268 封
· 桥侧：同一邮件会话 id 前缀 `01a0a2bd` 出现在 **4 个** pi 会话文件里
（投了两次 + 别的历史残留）
# 修法：内存与库必须同时写
`deliveredMails` 是**内存**集合，重启即丢；数据库的 status 才是跨重启的
"我接管过了"记录。两者只写其一 ⇒ 口径不一致 ⇒ 重投。
新增 `markDelivered(id)`：**凡是标记"我接管了这封"的地方都走它**
（SSE / 补投 / 决策回执三个投递点），同时写内存与库。漏一处就是一条重投
路径 —— 这正是缺陷的形状（四处各自 add，没有一处标已读）。
标已读只改 status，不改内容、不删行；`read_inbox` 传 `status=all` 照常可见。
而"已交给一个 worker 处理"正是那封信此刻的真实状态 —— 库里本来就该记这件事，
而不是"模型有没有顺手调过 read_inbox"。
# 四个桥：三个有缺陷，第四个早已修过
| 桥 | 投递标已读 | 说明 |
| --- | --- | --- |
| pi | ✗ → ✓ | 三处 add 都不标 |
| opencode | ✗ → ✓ | 同上 |
| dsh | ✗ → ✓ | 同上 |
| **homeagent** | **✓ 早有** | `ledger` 落盘，跨进程 |
homeagent 不用这个修法：它的 `ledger` 记 `delivered`/`completed` 两个状态，
只有 `completed` 才跳过（投过但被中断的**仍然重投**并带说明）—— 那份设计的
注释里就写着 18:59:38 那次实测，比我今天这个修法更早也更完整。
所以对它只做了「补投按工作区收窄」那一半（见下条）。
# 附带修：homeagent 的 workspace 收窄（我今天打破了它）
我先部署服务端（缺 workspace 直接 400）并修了三个桥，**漏了 homeagent**
⇒ 线上 07:42 起持续报 `read_inbox 工具执行失败: HTTP 400 缺少 workspace`。
这是我造成的，靠自己的日志发现的（pid 还是重启前的旧进程 2291455）。
修法与另三个同源：`currentWorkspace`（信封的 `to_workspace`）在回合期间暂存
（与 `currentSessionID` 同一形状、同一生命周期），`inboxURL`/`scopeQuery` 带上它，
补投从"读一次全局收件箱"改为逐工作区（清单来自心跳的 `pending_workspaces`）。
# 清理重投燃料
151 封归档（80 封回声：会话全程无人类 + 71 封 `permission_decision` 不可投）。
★ 用 `archived` 而不是 `read` —— `read` 还能被 `status=all` 拉出来重投。
判据用服务端自己的口径（`unreadFor` = `m.status<>'archived'` 且
`mail_reads` 无该读者），不手写 SQL 猜语义。
后置：pi / dsh / opencode / homeagent 在**所有工作区**的 unread 全部为 0。
# 判据
· `delivery-marks-read.test.mjs` × 3（pi / opencode / dsh）各 4 条：
核心那条钉的是「`deliveredMails.add` **只允许**出现在 markDelivered 内部」——
任何别处直接 add 就是绕过标已读的重投路径。另加自检反例。
变异验证：绕过投递点 / markDelivered 不写库 / 补投绕过，三处全判红。
· `inbox_workspace_test.go`（homeagent）5 条：URL 带 workspace、带不到时不带
（让服务端 400：错误可见好过静默越界）、补投逐工作区、两处投递路径都设工作区
且都清空。变异 3 处全判红。
· 改了两条既有判据（pi / dsh 的 permission-note）：原来钉
`deliveredMails.add(decisionMailID)` —— 那个形状**就是**缺陷载体。
语义没变（仍"不再当新任务"），载体变了。
全量：pi 517 / opencode 344 / dsh 407 / homeagent 除一条既有的
`TestSDKPinMatchesBuildMachinePointer`（依赖构建机路径，改动前后同样红）全绿。
|
2026-09-26 09:18:39 +08:00 |
|
|
|
9311612358
|
test(repo): 建 (d1) 判据 —— 上报非空 list 时不得删除其它 workspace 的行（**今天可写、现在红、修好即绿**）
pi `e77154d1` §三 指出我"把 (d) 整体归入 due"是**反方向的错**: 判据的**可得性**本身要复核 ——
把今天就能给的判据当成"要等未来才能给"，余额里就挂着一个今天就能变绿的缺口。
我先写仓内探针逐条跑（跑完即删），四条读数:
[修前] 播下 /A=2 → B 上报 /B=1 ⇒ (d1) FAIL: /A = 0，期望 2 ★本缺陷
[修前] T\L @DELETE前 = [/A] ⇒ 响 ✓（我那形状确实抓得到真缺陷）
[修好] 共存 /A=2 /B=2 → /A 仍 = 2 ⇒ (d1) PASS ⇒ 修好即绿 ✓
[修好] T\L @DELETE前 = [/A] ⇒ ★ 假阳：修好后每次心跳都常鸣
[修好] 与"实际删除域"比 destroyed = [] ⇒ 不响 ✓ 无假阳
⇒ ★★ 同时**撤回我 §三 提的 `T\L ⇒ WARN` 形状**（记入 DEBTS 补记之九）:
根因: "即将被销毁"由 **DELETE 的谓词**决定，不是由 T\L 决定。
修前 DELETE 域 = 整个 agent ⊋ L ⇒ T\L 恰等于被销毁集合（碰巧对）
修后 DELETE 域 = 按 ws 删 = L ⇒ 被销毁 = ∅，而 T\L 仍非空 ⇒ **恒假阳**
而修好后表里天然共存多 ws（那正是修复目标）⇒ **每次心跳常鸣**
⇒ 落进本仓「**还清了反而红**」那个坑 —— 我为 (d) 拒绝超前断言的理由，
在我自己提的形状里以假阳形式复现了。忠实形状: `destroyed = 被本次 DELETE 移除
且未被本次 list 重插的 ws`（与实际删除域同源 ⇒ 修前响/修后不响，且 [] 时仍覆盖）
⇒ ★★ (d) 拆两半: **d1 = 本条**（每项自带 Workspace ⇒ 不需要请求级字段 ⇒ 今日可判）；
**d2 = 上报 [] 时只清自己那个 ws**（需要"这次上报属于谁"）⇒ 与 scope 字段同 due
自查: 探针第一版把"取 T"写在 Replace **之后** ⇒ 量到删除后的表 ⇒ 结论会全反
（据此差点得出"漏报"的相反结论）；已把取 T 排到 B 上报**之前**重测。
教训: **观测点必须与被观测的判据在同一时刻** —— 与"判据要锚定到它防的那个动作"同一条。
测试: ./internal/repo/ 245 通过、唯一红项即本条（它断言的正是尚未修复的缺陷）
登记: platform-mirror-d1-cross-workspace（余额 28→29）；-run Debt ⇒ ok
|
2026-09-26 09:15:30 +08:00 |
|
|
|
7634be8966
|
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 |
|
|
|
31939f2b10
|
服务端: 顶栏内容端点（一言句库缓存 + 个人签名）+ 修老库升级时序 bug
用户裁定：
· 「可以在服务器集成一言与签名，同时 app 本地缓存一部分」
· 「摘要也应该放在顶部，显示摘要不显示一言，显示一言不显示摘要」
· 「自动轮播，要有消失出现动画。同时注意，是纯文字不要加底」
新增端点
· GET /api/v1/me/topbar → { quotes: [{text, source}], signature }
一次给一批（默认 10 条），客户端拿去本地轮播 —— 轮播是秒级的，
每条问一次服务器既浪费又会在断网时停下（而轮播的观感依赖"一直有下一条"）。
· PUT /api/v1/me/signature —— 改个人签名（「我的」页用）
· quotes 表（句库缓存）+ users.signature 列
设计要点
· 一言**落库缓存**：库里有就**不打外网**（常态路径）；不足 20 条才去
hitokoto 补一批。补失败**不影响返回** —— 装饰性内容不该成为失败点
（顶栏少轮播内容是小事，整个接口 500 会让 App 启动时顶栏坏掉）。
· 签名存 users 而不是 quotes 表：它是**用户资料**（跟账号走、
在「我的」页可编辑），放 quotes 里会让"改签名"变成"改一条 quote"。
· 限长 80 字，超了**拒绝且不落库** —— 顶栏是一行，静默截断比报错更坏
（用户以为存进去了，实际存的是被砍过的）。
· 迁移改两处（本仓既定纪律）：init_sqlite.sql 给新库 +
sqliteAddColumns 给老库。
★ 顺手修掉一个既有 bug（不是本次引入的）
「从很旧的库升级会直接启动失败」：
migrate sqlite (语句 #10 … idx_sessions_path_alias_uniq):
SQL logic error: no such column: workspace
根因是**时序**：这条索引引用 sessions.workspace，而那是**后补的列**
（sqliteAddColumns），索引却住在 init_sqlite.sql（在补列**之前**执行）。
新库没事（建表时就有该列）；老库直接炸，且报错指向索引名 ——
看着像索引写错，实际是顺序问题。
生产库一直没暴露，因为它早就补过列了（暴露面只有"从很旧的库升级"）。
证据：`git stash` 掉当天全部改动后**同样复现**。
修法：把索引搬到 migrate.go 的 sqliteAddIndexes（那个列表在补列之后跑）。
测试（internal/handler/topbar_test.go，5/5）
① 签名账号隔离 —— bob 没设过就该是空串，不能串到 alice 的
（本仓 user_appearance 那轮踩过"多账号共用一份"，同一形状不许重演）
② 有货不打外网（灌 25 条，断言返回不超过 quoteBatchSize）
③ ★ 外网挂了仍返回 —— 耗时 4.01s = quoteHTTPTimeout，
证明它真去拉了并按超时降级，不是假绿
④ 限长：81 字拒绝**且不落库**；80 字（边界）接受
⑤ 未登录读写都 401
★ 两个踩过的坑（记进注释了）
1. `init_sqlite.sql` **只能写 `--` 行注释**：切语句器只跳过 `--` 开头的行，
块注释的文字会被当 SQL 执行。我第一版用 `/* */`，新库初始化直接失败，
且报错指向一个完全无关的地方（no such column: workspace）。
2. 该 SQL 文件的 splitStatements 也会被注释里的反引号/连续减号破坏。
|
2026-09-25 16:29:19 +08:00 |
|
|
|
65de1c3884
|
跨端对齐：授权栏 navigator_only + 组件按页拆分 + 服务器补 permission_options
用户两项裁定落地（均为 ask_user 明确选择）：
① 授权栏口径 = navigator_only（照 WebUI 架构）
· 新建 pages/PermissionPanel.ets —— 详情页的决策面板，
对应 MailView.tsx:693 的 PermissionPanel（审批型 / 主动提问 / 已处理 三态）
· 决策入口从授权栏移到 MailDetailPage；MailDetailPage 原来只显示一个
「权限请求」小标签、根本没有决策入口（比 WebUI 少一整块，且反了：
栏里能决策、点进详情反而不能）
· PermissionTab 删掉内联「同意/拒绝」+ 备注框 + decide()：
整卡可点 → onOpenMail（对齐 WebUI PermissionList.tsx:81 的 pick()）
· PermissionRequest 补 source_account_id（客户端侧记来源，跳详情要定位网关）
② 服务器补 permission_options —— 修一条真实的、跨端共有的缺口
· mails.permission_options 从 INSERT 起就写进去，但**从来没有任何读路径
选过它** ⇒ 详情端点永远返回空。WebUI 的决策面板读 mail.permission_options，
所以提问型的预设选项**两端全部落空**（审批型靠 ['同意','拒绝'] 兜底蒙混）
· GetMailByID 补选该列 + JSON 反序列化（与 cc_list 同款）
③ 组件按页封装（用户要求「以便与 WebUI 一一对应」）
MainPage.ets 4592 → 3192 行
· pages/PermissionTab.ets 720 行 ↔ PermissionList.tsx
· pages/ContactsTab.ets 796 行 ↔ ContactPanel.tsx
· pages/NavDestinations.ets 181 行 ↔ Navigation 壳
· pages/NavShared.ets 65 行 ↔ 跨栏共用件
④ 判据跟着组件搬家（否则静默失效，不是红）
harmony-logic 的 pageCode / harmony-nav 的 navSrc 改为显式文件名单；
harmony-appearance 的 PANE_SOURCES 补 ContactsTab；harmony-contacts 三个
test 并入 ContactsTab；harmony-logic 的决策断言改指 PermissionPanel，
并新增「授权栏不许再有内联决策」两条（navigator_only 的正形状）。
animation-audit：共享元素转场判据从「同文件共址」改为「按 id 找驱动」。
旧形状把 in/out 端必须在同一文件当成代理，而两端**天然在两处**；
抽出写信页（NavDestinations 持有 in 端）后误报。新判据仍要求每个 id
都有 Motion.morph 驱动 —— 变异实测：把驱动换成裸 animateTo 仍判红。
判据：files=34 checks=556 red=1（仅 build-stamp，产物待重构建）
|
2026-09-24 10:10:32 +08:00 |
|
|
|
3459605dc0
|
修复: TestStaleLunarRecurringDoesNotFlood 是**日期相关的假红** —— 它要求一个不存在的日期
这条红不是"既有代码缺陷"，是**测试的期望写错了**。`go test ./...` 现已 **rc=0 全绿**。
## 形状：断言要求「农历日原样保持」，而目标月可能根本没那一天
if d := lunar.FromSolar(after.EventTime.In(time.Local)); d.Day != lunar.FromSolar(e.EventTime).Day
起点是 `time.Now().AddDate(-1,0,0)`，推进落到哪个农历月**随日期浮动**。
农历月 29/30 天不定 ⇒ 落到 29 天的月份时，"30 日"**不存在**，夹到 29 是
`ToSolar` 明确设计的行为（它连 `clamped` 都返回了）。旧断言却要求 30 ⇒ 必红。
实测（2026-09-21，起点 = 农历七月三十）：
落点 = 2026 年农历**八月廿九**，而该月只有 **29** 天
⇒ 正确结果就是 29；旧断言要 30 ⇒ 无论代码对不对都红。
**所以它是一条"日期相关"的假红**：每年那几天必红，与 `git bisect` 的结果无关。
pi 独立复核过它在**上次部署时的 HEAD `e8b260d`** 上同样 FAIL —— 与我一致。
## 我不是靠"看不见"修的：先排除了另外两种解释
- **不是时区/基准不一致**（我第一版猜这个）：探针打印了两个基准，
`e.EventTime` 未转本地 / 转本地，**农历日都是 30**，而左侧是 29 ⇒ 基准不是原因。
- 也不是推进逻辑多走了一步：`AddMonths(1)` 对 7月30 得 8月30（`Date` 只加月份），
是**后面 `ToSolar` 往 29 天的月里落时才夹**。
## 修法：期望取 `min(原日, 目标月天数)`
days, err := lunar.DaysInMonth(got.Year, got.Month) // 读不到就 Fatal，不静默
if want > days { want = days }
**没有放松真正的约束**：落到**长月**却少一天，仍然红。
变异验证：把 `RecurLunarMonthly` 的 `AddMonths(1)` 改成 `AddMonths(2)` ⇒
`农历日从 30 变成 29（目标月 30 天，期望 30）` **红**（在最终代码上重跑确认）。
## 由此**新发现**一条真缺陷（本次**不修**，因为要改产品语义）
顺着"夹取"往下量，发现 `addSolarMonthClamped` / 农历 `AddMonths` 的夹取是**粘的**：
公历 每月31日: 1-31 → 2-28 → 3-28 → 4-28 … （3 月有 31 天却停在 28）
农历 每月30日: 7月30 → 8月29 → 9月29 → 10月29 …（9 月有 30 天却停在 29）
一旦被夹过一次，**此后再也回不到原始日**。而 `calendar.go:401-405` 的注释恰恰把
"一次溢出永久改变规则"称作**要避免的** bug —— **注释说的和实现对不上**。
根因：落点被写回 `event_time`，而**没有一列保存原始锚点日**（`calendar_events` 无此列）。
要真修得加锚点列 + 迁移，改的是**产品语义**，不是本次部署能顺带做的 ⇒ 已如实报给 pi。
|
2026-09-21 05:06:53 +08:00 |
|
|
|
17908c1623
|
修复: 已读**权威列**静默少行 —— markReadFor 占位符整体错位一格（最后一封永远标不上）
★ 这是我自己那封"重投"的根因。我先在自己的收件箱上量到症状：
`read_inbox` 列了 **5 封**，落库只有 **4 封**变成已读，**少的正是最后一封**。
顺着症状读 `repo.go` 才看到机制，不是先读代码再猜。
## 根因：reader 的占位符与调用方的 `$1` 撞号
`markReadFor` 原把 reader **前置**成 `$1`：
append([]any{reader}, args...) // → $1=reader, $2=args[0], …
而两个调用方的 `where` 早把 `$1` 用成了 recipient：
MarkMailsReadFor : $1=recipient，$2..$(N+1)=ids，args=[recipient, ids...]
MarkAllInboxReadForSession : $1=recipient，$2=sessionID，args=[recipient, …]
⇒ 绑定表整体**右移一格**，`IN ($2 … $(N+1))` 实际收到 `(recipient, id1 … idN-1)`：
· **最后一封永远插不进**（idN 从没被绑定）
· **只传 1 封时一封都不插**（`$2` = recipient）
· 带 session 那条 `$2=recipient` 被当成 `session_id` ⇒ 同样一行不插
## ★ 为什么长期零痕迹（比 bug 本身重要）
调用方返回的"标了几封"来自**随后那条 `UPDATE mails`**，它用的是**没被前置**的 args
⇒ **计数正确**、冗余列也正确，**只有权威列 `mail_reads` 静默少行**。
而未读判据是 `mail_reads`（`unreadFor`）⇒ 邮件**看起来已读、实际仍算未读**
⇒ 重启补投（`catchUp`）时被当新信**重投**。
**原有的 4 个测试全都守着这个 bug**：它们断言的是 `statusOf()` —— 读的正是那列
**冗余**。判据读错了列 ⇒ 守的是"看起来对"的值，不是**决定行为**的那个值。
## 实测（探针 + 变异，两边都跑）
修复前：单封 mail_reads=0（期望 1）；传 4 封 → n=4 但只插 3 行（丢第 4 封）
修复后：单封 mail_reads=1；传 4 封 → 插 4 行；抄送、幂等、MarkAllInbox 各自 1 行
新判据 5 条在**旧实现上变异验证**：4 条红（含指名"漏标第 [5] 封"），
第 5 条「别人的邮件不该留下行」**正确地不红**（鉴权本来就没坏）。
★ **我中途假绿过一次，如实记**：第一版探针只有 `t.Logf` 没有 `t.Errorf`，
变异态 `go test` 仍 **rc=0** —— 读数（0/3 vs 1/4）确实变了，但**判据没断言**。
这正是本仓那条「判据在，但走不到」。改成 `t.Fatalf` 后才真抓住。
## 我另外自伤了一次（同一个判据抓到我）
`mail_status_readers_test.go` 数的是**原始源码**里 `mails.status` 的出现次数（不剥注释）。
我新写的注释里就有一句"…冗余列 `mails.status` 正确"，把清册从 **13 撑到 14** ⇒
`TestMailsStatusReadersAreRegistered` 红。改掉那句措辞后回到 13。
⇒ 记一条：**在那个文件里写注释也会被记账**，说明它数的是"字面出现"而非"真读列"。
（我没有改那个判据 —— 它数得紧是有意的，我改的是自己的措辞。）
## 状态
`go test ./...`：`internal/repo` 仍有一条红 `TestStaleLunarRecurringDoesNotFlood`
（「农历日从 30 变成 29」= **日期相关**）。**我把 `repo.go` 还原成 HEAD 版单跑过，
它同样 FAIL** ⇒ 与本次改动无关的既有红，我没动它。
其余 12 个包全 `ok`。新判据 5/5、原有 `TestMarkMailsReadFor*` 4/4。
|
2026-09-21 04:25:17 +08:00 |
|
|
|
63649031d8
|
后端: 销掉一份漂移的欠账副本 + 钉住 user_appearance.user_id 的语义陷阱
## 一、`user_appearance.user_id` 存的是**用户名**（不是 UUID）—— 陷阱显式化
审计时实测到的差异：
| 表 | `user_id` 存的是 |
|---|---|
| `user_keys` | **UUID**（`809967c5-…`） |
| `user_sessions` | **UUID** |
| `user_appearance` | **用户名**（`jianf`）← 与兄弟表不同 |
**功能上自洽**（本包读写都用 username，handler 一律传 `user.Username`），
所以**不是活跃 bug**。但它是个**不报错的陷阱**：按兄弟表的习惯写
LEFT JOIN user_appearance a ON u.user_id = a.user_id
会**静默匹配到 0 行**。我自己审计时就先踩了一次 —— 查出来全是空，
差点当成"这些账号从没设置过外观"（实际 jianf 有记录）。
**没有改列名**：表里有生产数据（壁纸本体在 blob 里、由 `image_sha256` 引用），
改列要迁移 + 回滚预案，收益只是"名字更好看"。选择**把语义钉住**：
文件头写清（**指名兄弟表**当锚、说清**失败长什么样**）+ 新判据
`appearance_semantics_test.go` 双向校验（repo 层不得混入 UUID 语义、
handler 层不得出现 `user.UserID`）。
★ 判据从源码读而不是运行时测：这里要钉的是**约定**，
而约定的存在形式就是注释与命名 —— 行为测试证明不了"下一个人不会踩"。
## 二、销掉一份**已经漂移**的欠账副本
`debt_registry_test.go` 里有一份**手写副本** `debts` map（给 `debtSummary()`
打印用），而**没有任何判据校验它与权威 `docs/DEBTS.json` 一致**。
实测漂移得很厉害：
- 副本 3 条 vs 权威 **17 条**；
- 里面还留着 **`gesture-semantics`** —— 那一笔已于 2026-09-19 还清并销账；
- `static-criteria` 的余额还是旧值 **7**（权威已是 5）。
后果很具体：**`TestMain` 打印的余额是错的**，而余额的全部意义就是"能看全"。
处理：**删掉副本**，让 `debtSummary()` 直接读权威 JSON（同一个事实不留两份），
并加判据 `TestDebtSummaryReadsAuthoritativeLedger` 双向钉住：
① 不许再引入手写副本；② 打出来的数字必须与 JSON 一致，
且**每一笔余额>0 的都要出现在打印里**（漏掉的欠账等于不存在）。
同时修了 `TestDebtLedgerMatchesMeasurement` 里一条**硬编码欠账清单**的断言
（它点名要求 `gesture-semantics` 必须存在 —— 还清了反而红）。
改成断言**形状**（跨端净值 + 本包可实测的那笔必须同处登记），不点名具体笔数。
★ 教训：硬编码欠账清单不可维护，漏改的后果是"还清了反而红"。
## 三、写这三条判据时连踩两次**自匹配**
`strings.Contains(src, "var debts = map[string]debt{")` —— 那串字**本身**
出现在断言的 `t.Fatal` 消息里（以及我留的说明注释里）⇒ 恒红。
（`run-all.mjs` 的自检锚点也栽过一次，那里改用 `lastIndexOf`。）
修法：锚点**拼出来**（`"var " + "debts" + " = map..."`）+ 注释措辞避开那个声明。
## 四、验证
`go test ./...` → **13 个包全过**。
新增：`appearance_semantics_test.go`（4 条断言）、
`TestDebtSummaryReadsAuthoritativeLedger`（2 条）。
|
2026-09-19 16:27:09 +08:00 |
|
|
|
dfb4b8537e
|
chore(test): 删掉为已撤回的过滤写的判据（判据不该给错误实现护航）
|
2026-09-15 12:54:36 +08:00 |
|
|
|
7e1adfd731
|
revert(过度矫正): 撤回"目录合不合法"的两道门槛 —— 错在投递，不在值
用户否掉了我上一步的方向：「？拒收那个目录干啥？明明是你的网关投递逻辑造成的错误」。
他是对的。/home 是**合法目录**，平台不该替用户裁定"哪个目录算工作目录"：
网关地址受理处的 400、建议接口的过滤、桥侧的同类闸（revert 141003d）全部撤回。
判据随之删除 —— 判据不该给错误的实现护航（那会让错的东西看起来有保障）。
保留的是**真修复**（ad1f3f1，已在线）：
- 会话解析按 (path, 别名)：错投的根因是解析只看别名、path 被当提示；
- 唯一索引 (path, 别名)；无 path 时"唯一才认，否则报歧义"；
- 毒数据清理（/home 污染值 0|0|0）。
核心回归判据 TestFindNamedSessionForRequiresPath 保留。
仍未修（用户指的那一处）：SSE 投递只按 name 广播 —— 同名不同 path 的客户端谁接到谁处理。
下一 commit：投递也带会话身份，只投给声明了该会话的客户端。
|
2026-09-15 12:54:25 +08:00 |
|
|
|
ad1f3f14c3
|
fix(session): 会话身份 = (path, 别名) —— 修用户报的错投，并堵住 /home 这类毒 path
用户 2026-09-15 的订正：「agent 平台的 session 是和 path 绑定的，path+session 才能
指定到准确的 agent，而授权也是对 session 授权，而不是整个 agent」；随后报了一个
严重错投：「工作区在 TrueAgent 的 pi 客户端，发送邮件给 dsh 被投递给了工作区在 home
的客户端」。
根因是四处叠加（都有实测证据）：
1. 解析只按别名：`WHERE session_alias = $1`，path 被当可选提示 ⇒ 两条不相干的
线索能落进同一会话；
2. 别名全局唯一 ⇒ path 在解析时冗余，进一步被忽略；
3. 桥按来信的 to_workspace 起 worker（实测日志 `新建 pi 会话 …（cwd=/home）`）；
4. 投递（SSE）只按 name 广播。
本提交改 1/2 + 堵源头：
- 解析按 (path, 别名)：给了 path 必须两者同时命中，对不上就是 ErrSessionNotFound
（**绝不**退回按别名找）；没给 path 则要求该别名唯一，多条时 ErrSessionAmbiguous
（不许掷骰子）；
- 唯一索引从 `(session_alias)` 改成 `(COALESCE(workspace,''), session_alias)`
（两方言 + 显式 DROP 旧索引；EnsureSessionAlias 靠唯一索引判撞名，自动变成按 path）；
- 新 IsPlausibleWorkspace（与目录建议**同源**一条规则）：地址受理处拒收不像工作目录的
path（`/home`、`/root`、`~/.pi/mail-sessions/…`、顶层挂载点），并给出可执行文案；
- 建议接口的候选过滤改用同一条规则（只留具体目录；祖先容器让位给更具体的候选）。
判据：新增/改写 4 组，全部做变异验证 —— 三条核心变异（解析退回按别名找 / 歧义时
掷骰子 / 去掉「深度≥2」）全部变红。过程中判据还抓到自己一个漏洞：
IsPlausibleWorkspace("/home") 在旧规则下是 true（/home 不是 root 的家目录）。
★ 语义变化（会让旧测试红）：不同 path 下的同名别名现在是两条独立会话，不再"撞名"。
TestAdoptHandlesAliasCollision 已按新模型重写为两侧（同 path 才加后缀）。
未做：桥侧仍按来信 to_workspace 起 cwd（下一步）；线上的库要等下一次启动才跑迁移。
|
2026-09-15 12:20:28 +08:00 |
|
|
|
46fa7fa729
|
feat(push): 可选、配置式、多厂商的推送通道（HMS 为首个实现）
用户要求：推送密钥必须是可选项（自部署后端不能写死推送方式），且要支持
多厂商配置式接入 —— 每个用户各自部署服务器、自己选厂商、自己配凭证。
所以落地成：
· internal/push：通道抽象 + 工厂表（RegisterType），加厂商不改配置层与端点形状；
HMS 只是第一个实现（internal/push/hms.go）
· 配置在 PUSH_CONFIG（默认 <AGENTMAIL_DATA_DIR>/push.json），一项一个厂商，
凭证走文件（app_secret_file / files.*，建议 600）；环境变量只是可选覆盖
· 没配 = 整条推送路径连一次查库都不发生（shouldDispatch 早退）；
单项配错（未知类型/密钥读不到/enabled:false）只跳过那一条，不影响启动
· push_tokens 表带 provider 维度 + 三个 /me/devices/push-token 端点；
没配推送时端点照存并回 enabled:false（登记成功 != 服务端开了推送）
· notify.Recipients 末尾异步挂钩：收件人名单直接用 SSE 那份 seen（两条通道
共用同一份"谁该收到"的判据）；失败只记日志，绝不拖住收信
HMS 的形状是拿真凭证打线上接口问出来的（v1 + message.token[] + testMessage；
payload/target 形状 v1 不认、v2 要服务账号 JWT）。未上架应用必须 test_message=true，
单批 ≤10 token（MaxTokensPerRequest 声明）、每日 1000 条兜底（项目级额度）。
实测：App ID + App Secret 能换到 access_token（3600s）；形状被线上服务接受。
判据：repo 6 条 + push 12 条 + handler 3 组，全部做过**变异验证** ——
过程中抓出两条假判据（异步分发与 t.Cleanup 赛跑而假绿；密钥文件优先级没被覆盖）
并补掉。Go 全量测试与 go vet 干净。
★ 未验：端到端真机送达（需要真机 token + 客户端按 com.jianf.agentmail 重编并签名，
签名指纹还要在 AGC 登记）—— 从未真正发出过一条能到达设备的推送。
详见 docs/HMS-PUSH-PLAN.md 的「实现状态」一节。
|
2026-09-15 11:21:00 +08:00 |
|
|
|
b806a05bfa
|
跨端: harmony 管理页（用户管理）+ P4c 壁纸上传入口 —— 「功能做全再交付」的两块
pi 的交付清单里缺的两块（`docs/GUI-PLAN-HARMONY.md` 原先把管理后台划在首版之外，
用户明确要求「功能做全再给我」之后收进来）。
标 `跨端:` 是因为判据落在 `client/electron/test/`（鸿蒙的判据目录一向量在那里），
代码本体全在 `client/harmony/`。
## 管理页（用户管理）
- `pages/AdminUsersPage.ets`：新建 / 编辑（显示名·角色·白名单）/ 启停 / 重置密码。
排布照 `AdminUsersPage.tsx`，包括「受限」徽标口径（普通用户且白名单非空才显示）、
最后登录缺席与空串都显示「从未登录」、管理员对白名单两项忽略。
- 入口在设置页底部，**仅管理员可见**（`role === 'admin'` 严格相等，与 `App.tsx` 同口径）。
读不到身份时**不**显示也不报错（乐观放行会让每个普通用户看到点进去 403 的入口）。
- `api/AdminApi.ets` + `model/AdminUsers.ts`（纯逻辑，零 import ⇒ 判据能真跑）。
- 启停**只发 status 一个字段** —— 服务端是部分更新，多发字段会把显示名与白名单一起改掉。
- `model/Models.ets` 补管理端 DTO；`main_pages.json` 注册路由。
## P4c 壁纸上传
- `model/ImagePrep.ts`：阈值与两档策略（2560/0.85 → 1280/0.78，入口 20MB，压后上限 3.5MiB）。
**一处有意不对齐 WebUI** 并写明理由：WebUI 卡 data-URL 长度（含 base64 膨胀），
鸿蒙内存直传 ArrayBuffer，卡的是字节数。
- `common/BackgroundPicker.ets`：不设 / 预设 / 自定义图片 + 浓度与模糊滑杆。
上传链：picker → 判可不可以 → 逐档按 desiredSize 解码压缩 → 上传 → **请页面以服务端为准重新同步**。
失败**必带原因**（服务端 415/413 文案原样透出）。用户取消选图**不算失败**。
- `ApiClient.uploadBytes`：MultiFormData.data 收 ArrayBuffer（核了 SDK，since 11；本工程 23）
⇒ 内存直传，不需要 base64 也不需要临时文件。
## 两处真 bug（变异测试逼出来的，不是"新写坏的"）
1. **压缩循环的第二档此前是死代码**：循环里的 break 与循环外那句 shouldRetryWithActual
互相抵消 —— 把循环里那处改成 `if (true)`（永远只压一档）整套判据照样全绿。
收成一处判定（overLimit），循环外只读结论，并加结构性判据（该函数在这条链上只许调用一次）。
2. **壁纸的模糊档一直是「只写不读」**（计划文档 §7.12 登记过）：滑杆能拖、值能存、
blurStyleFor 也写了，就是**没有调用点**，壁纸一点没糊。
本次补上的调用点分两层：壁纸层 `.blur(px)` = **图片内容模糊**
（与 WebUI 的 `filter: blur(var(--bg-blur))` 同一个量、同一个数，所以不需要映射表）；
而那张**材质档**映射表 `blurStyleFor` 也终于有了调用点（`navMaterialFor` 内部复用它）。
`docs/HARMONY-ALIGN-PLAN.md` 的 §7.12 两行（材质 / 壁纸模糊度）已一并改准、不再互相矛盾。
## pi 复核后**改回来的**（这一笔里我自己犯的两处，都由 pi 抓出）
1. **导航条材质一度绑定到 `bg_blur`，`bg_blur=0` 时整个消失。**
我把 `NavBar` 从固定档改成 `blurStyleFor(bgPlan.blurPx)`，而滑杆 `min: 0` 可达、
`blurStyleFor(0) === 'NONE'` ⇒ 用户把壁纸调清晰时**导航条一点材质都没有**。
而且它与本笔自己的论证**相反**：刚论证完"图片内容模糊"与"面板材质"是两个物理量，
转头把面板材质接到壁纸模糊这个输入上。
现在**分层**：`blurStyleFor` 是通用映射（**允许** NONE —— "0 px 不模糊"是它的正确语义）；
`navMaterialFor` 是**导航条专用、有下限**的入口（0 px ⇒ 最薄档）。
判据钉**可达性**（滑杆 0..40 每个整数 + 界外值都不许 NONE，且三档都要出现 ——
否则"恒定最薄档"会让滑杆成为死控件）。
2. **`Theme.navMaterial` 被我弄成了死令牌**，而看着它的判据**照样绿**
（那条只断言"声明存在且不是 NONE" —— 守的是声明，坏的是活的调用路径）。
现在导航条真的用它；并把同文件里**只覆盖 `Theme.overlay` 一个令牌**的死令牌规则
**铺到 Theme 的全部 35 个令牌**（量**外部引用数**：只被 Theme 内部方法读、
而那个方法自己有外部调用点 ⇒ 不算死 —— `chipSpentBg` 是这种；`navMaterial` 当时
唯一的消费者是一张可整体删掉的局部表，所以必须被抓）。
## pi 复核后**补上的**（这一笔漏掉的接线，都是我造成的）
- **`test/run-all.mjs` 的 SUITE 没接两个新判据文件** ⇒ HEAD 上 `npm test`
**一条判据都不跑、直接 exit 1**（套件自检 2 就是为这件事写的）。已接入，
并把两条登记进 `STATIC_ONLY`（`.ets` 要设备 ⇒ 静态欠账）。
- **`debt-visibility` 是我自伤**：那两个新文件里有 5 处"边界声明"但一次都没登记。
我当时报"2 条失败是改动前就红" —— **只对一半**：这条在父提交上是**绿的**。
我那次 `git stash push -u -- client/harmony` 的对照是**无效对照**
（`-- client/harmony` 把 `client/electron/test/` 整个排除在外，新判据文件根本没被 stash），
所以两次跑都红、看着像"既有"。已按 pi 的建议改用 `git worktree` 到父提交做对照。
现在两处都登记进 `docs/DEBTS.json`（含 `static-criteria` 5→7，Go 侧同一份登记同步改）。
## 一并修正的旧判据（都是"太宽/太窄/钉错东西"，不是放宽标准）
- 「模糊归属」：原文「壁纸层不许有**任何**模糊调用」把**图片内容模糊**与**面板材质**
混为一谈（WebUI 侧核实：`.app-backdrop` 的 filter 与它之上那层的 backdrop-filter
是两个不同的量）⇒ 改成按两种模糊分别钉。
- 「bgBlur 只写不读，消费侧必须为 0」：值不再成立，**形状保留**（逐文件登记 + 计数 + 理由），
标题与断言里的假话一并改掉。
- isDarkMode 那条 `/dark\s*\)/` 断的是**参数顺序**（加一个入参就误红）⇒ 改成"dark 在实参里"。
- 三条钉 `backgroundBlurStyle` **整条字面表达式**的断言 ⇒ 改成钉语义
（"用系统材质 + 材质有下限"），不再匹配那一行的字符。
## 判据
新增 `harmony-admin.test.mjs`（22 条）、`harmony-imageprep.test.mjs`（29 条）；
`harmony-presets.test.mjs` 加 1 条（模糊档搬运与归一，含 `-0` 那个洞：
`Math.round(-0.4)` 是 `-0` 而 `-0 < 0` 为 false ⇒ 改成判 `!(r > 0)`）。
**`node test/run-all.mjs`：22 个判据文件全部跑起来**，红的只有 1 个：
`build-stamp`（`dist` 是 `a5fc86b` 上构建的，`gitRev` 对不上当前 HEAD）。
这条**不是我的代码造成的**（可证：`a5fc86b..HEAD` 之间，`srcHash` 覆盖的那批文件
——`client/electron/src` 等——**一个都没动过**，所以 `srcHash` 没变，差的是 `gitRev`），
但也**不是"改动前就红"**：任何推进 HEAD 的提交都会让它变红，正确修法是重构建。
## 未验（如实标注）
- **本机无设备/无模拟器 ⇒ 全部观感未验**：管理页排版与卡片观感、滑杆手感、
模糊在真机上的实际档位观感、系统材质在自绘悬浮条上的实际效果。代码齐 ≠ 真机验过。
- 预设档**没有**上模糊（壁纸在预设档下是一叠自绘矩形，系统材质对它不生效）——
这是我**主动收的范围**，不是漏，真机看一眼再决定要不要补。
- **Go 侧的 `debt_registry_test.go` 我没能跑**（沙箱里没有 Go 模块缓存，`go test` 起不来），
只做了 `gofmt` 校验；那处改动是一行 `Count: 5 → 7`。
|
2026-09-15 11:17:23 +08:00 |
|
|
|
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 |
|
|
|
81ec77ae1f
|
fix(read)!: 会话即主体 —— 读路径不再做任何"谁有资格"的仲裁
用户（第二次、说明白了）：「我要求的是不同 session 不同收件箱，而不是复杂的权限隔离……
每个 session 是相对独立的单位，他们不应该公用一个相对私有化的设施，相当于每个 session
概念上是一个独立的『用户』」
所以 AgentMayReadSession 只剩一句话：**target 必须就是 scope**（我当前所在的那条会话）。
删掉两样东西：
· 工作区比较 —— 那是 cwd/沙箱那条轴的事，混进读信就制造了 zcode 那次误判
（cross-workspace 的 403 让它推断"那五位 agent 不存在"）；
· **参与性仲裁** —— 那是我加的"相对私有化"设施：把 agent 当成一个跨所有会话的人，
于是它既太松（同工作区内能互翻收件箱）又太严（发起者读不到自己发起的会话）。
会话是独立单位，不需要一个更高层身份来"授权"它读自己的收件箱。
信任边界在桥：session_id 由 worker 闭包注入（模型改不了），等同"邮件客户端替它持有的
每个账号行事"。未声明 scope 的旧语义保持放行（记警告）。
判据重写为：① 我就是这条会话 → 放行；② 同工作区另一条会话 → 拒；③ 别的工作区会话 → 拒
（同一个理由 not-your-session）；④ 未声明 → 迁移期放行；⑤ **显式钉住"不做参与性仲裁"**
（声明自己是哪条会话即以其行事，即便该 agent 名义上没参与过）—— 这条是模型的一部分，
免得以后被"好心"加回来；将来若要做"每个 session 自带凭据"，那是加凭据而不是加回这层仲裁。
生产实测：① 200；② 403「这封信不在你当前所在的那条会话里……」；③ 200（迁移期放行）。
|
2026-09-15 10:01:24 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
d25770ea2f
|
fix(欠账): Skip 进余额且条件必须是测量；豁免按文件+次数；三笔欠账合成一处可读余额
pi 2026-09-14 三条（他接受了我对"恒红=相位错"的反驳，但指出 Skip 带来的两处漏洞）。
1. **Skip 必须进余额、条件必须是测量**：
- **条件**：跳过与否由 `measureMailStatusDebt` **实测**（详情路径的 status 是否真的
等于按读者派生），不是常量、不是"我们还没迁完"这种没人会更新的事实；
- **余额**：`docs/DEBTS.json` 是**唯一登记**，Go 侧判据 `TestDebtLedgerMatchesMeasurement`
**自己测量**后与登记比对（第一版我让余额由另一条判据写入 ⇒ **排序依赖**，
Go 同包内按源文件顺序跑，登记那条先跑就读到 0 —— 排序依赖是隐蔽的假绿，已抽成自足函数）；
- **可见性**：`go test` 跑通时**不打印包的输出**，我第一版把余额打在 TestMain 里，
常态运行一个字都看不见 —— 正是 pi 说的"不显形"。所以常态可见的那份打在
electron 套件的 RESULT 行：`RESULT phase=install static=5 debts=7
（static-criteria:5,mails-status-derived:1,gesture-semantics:1） probe=ok`。
2. **豁免从"按文件"改成"按文件 + 次数"**：`migrate.go` 这类比较**上限 2 处**（附理由），
多一处即红。我在读侧清册上自己修过这个洞，豁免那格却退了一格 —— pi 指出得对。
3. **三笔欠账合成一处**：原先各自表达（`RESULT static=5` / `t.Skip` 无余额 /
文档里的到期前提无余额），**没有一处能一眼看全**。现在统一登记在 `docs/DEBTS.json`
（id / 余额 / 到期前提 / 判据位置），两端读同一份：Go 侧比对实测，electron 侧打进 RESULT 行。
还清那天：登记要跟着清 —— 不清则由 `TestDebtLedgerMatchesMeasurement` 报
"**欠账已还清**，但登记还记着 N"（还清是可测事件，这正是那条判据存在的意义）。
|
2026-09-14 17:17:37 +08:00 |
|
|
|
eeb8f277fd
|
test(mails.status): "正当"落成可判约束（只许比 archived）；欠账补一条"还清即转绿"的判据
pi 2026-09-14 的三点接续。
1. **§1「正当」不能只是标注，要是可判的约束**：按文件+计数登记挡得住"新增一处"，
挡不住"**已登记的那一处改变性质**"。已判出来：**任何与 m.status 的比较只允许比
'archived'**（全局属性），与 'read'/'unread' 比较 ⇒ 红（per-reader 属性必须走 mail_reads）。
第一次跑就抓到第三处：`migrate.go` 的 `WHERE m.status = 'read'` ×2 —— 它是**回填**，
职责就是读那个遗留值，所以按文件登记**窄豁免**（allowedCompareExempt，带理由），
而不是"凡是迁移都放行"。
2. **§2 欠账要有"还清即转绿"的判据**：新增 `mail_status_derived_test.go`，三态形状
（与套件探针同族）—— 欠账未清 ⇒ `t.Skip` 并写明还欠什么（**不假红也不假绿**）；
还清 ⇒ 开始实跑并断言"详情路径的 status == 按读者派生的值"，**转绿即可测事件**；
迁一半（只改 GetMailByID 漏 GetThread）⇒ 红。
实测当前状态：`--- SKIP ... 详情路径返回行级 status="read"，而按读者派生说 "unread"`。
**没写成"现在就红"**：恒红的门 = 挂在错误相位的门（CRITERIA.md §11 已为它付过学费）。
另按他的更正把 `migrate.go` 的理由写准：不是"跑过即结束"，而是
**"全新安装/空库路径必须存在"**（措辞会影响下一个人敢不敢删它）。
3. **§3 (b) 的语义契约补归属**：归属 = dsh（鸿蒙侧实现者），WebUI 侧不需改动；
落点 = 跨端对齐判据那一族（形状与"预设清单逐项一致"同构，比语义不比数值）；
**如实标注当前未建**及原因（鸿蒙侧还没有日历页/手势代码 ⇒ 此时"两端逐项相同"只有一端存在，
建出来就是假判据）；到期前提 = P6 第 3 步出现手势代码时立即建，此前是**登记的欠账**。
|
2026-09-14 17:11:36 +08:00 |
|
|
|
b7f624bc45
|
fix(已读/手势): 读侧也拒绝空读者；mails.status 读者/写者登记成"新增即红"；阈值契约显式选 (b)
pi 2026-09-14 的三条裁定，逐条落地。
1. **§2 读侧守卫**（他只钉了写侧，读侧是另一半，而且更隐蔽）：`reader` 在查询里是**过滤条件**，
空串不写坏数据也不报错，只会**算出一个错误的数** —— `unreadFor('')` 的
`NOT EXISTS(... reader_name = '')` 恒真 ⇒ `CountUnread(ctx,"")` 把**所有**邮件算成未读
（用户看到"全都没读"），`ListInbox(...,"read")` 恒空。
二选一里选 **①报错**（当前没有任何调用方需要"汇总"语义；选②就要立刻定义"汇总"是什么，
而那是个还不存在的需求 —— 将来要就新增一个名字里带汇总的函数，别让空串偷偷兼职）。
`requireReader` 装到 `ListInboxScoped`/`CountUnread`/`CountUnreadInSession`，
判据两条：空 reader 三个入口都**必须报错**且**不返回数**；正例防止写成"一律拒绝"。
变异验证：撤掉 `CountUnread` 的守卫 → `CountUnread("") 必须报错，实际返回 0`。
2. **§1 `mails.status` 收口**：先做他要求的第 1 步（枚举读者，他没有 shell）。
枚举结果：**没有**"零功能读者"那条路 —— 行级值仍会进邮件 JSON（`GetMailByID`、
`GetThread` 都 select 它），`migrate.go` 的两处是**一次性回填**（正当），
`unreadFor`/`readStateFor` 只用它判 `archived`（正当，且已注明"不再作为未读判据"）。
所以走第三步：**登记欠账 + 增量判据**。
- 「只为兼容保留」**没有**当结语：`mail_status_readers_test.go` 是一张**机器检查的清册**，
按**文件 + 次数**登记（repo.go 13 / thread.go 1 / migrate.go 4），
**新增一处读取就红**并强制当场回答"这处合不合规"；写入点同样登记
（多一处 `UPDATE mails SET status` 就红）。
- **第一次跑就抓到第二处写入**：`MarkAllInboxReadForSession`（整会话批量已读）里还有一句
`UPDATE mails SET status='read'`，我原先只看到 `MarkMailRead` 那一处 ——
这正是"新增即红"的价值：靠人 grep 会漏，靠判据不会。
- 收口路径（写进判据注释）：行级 `'read'` 迁到 `markReadFor`；
但在"详情/线程仍返回行级 status"两处读者迁移**之前**不能只删写入
—— 那会让 JSON 里的 status 永远是 unread，是另一种错误事实。
变异验证：在已允许的文件里新增一处读取 → 清册对不上，红。
3. **§3 阈值契约显式选 (b)**：不要求数值一致（`40px`/`600ms` 在触摸屏与鼠标、手机与大屏上
的人体工学合理值天然不同，强行同值会两边都不舒服），契约改钉**语义层**（左滑/右滑=什么、
边界是否回弹、"快滑"是感知档）。并写清推论：选了 (b) ⇒ **鸿蒙不得引用 WebUI 的三个数**
（引了就等于偷偷选了 (a)，还是"我抄的那一份"那种）。
|
2026-09-14 17:08:31 +08:00 |
|
|
|
863b583838
|
fix(已读/文档): 空 reader 报错（把约定变成做错会红）；P6 方案补分支声明与可验收性；"与 X 一致"入册
pi 2026-09-14 对 P6 方案的五条，逐条处理（都不改方向）。
1. **§4 已读按读者的强制点** —— 他说得对，但实际情况比他担心的更靠前也更靠后：
HTTP 层取的是 `user.Username`（**不是请求参数**，所以根本不可能"省略 reader"），
但 **repo 函数本身接受空串**：`MarkMailRead(ctx, id, reader)` 会照写一行
`reader_name=''` —— 不属于任何人，却会让"未读"统计出偏差，而且没有任何东西会红。
已加守卫（空/纯空白 → 报错，不兜底）＋判据（不仅"不许插垃圾行"，且**必须返回错误**；
另含正例，防止把守卫写成"一律拒绝"）。变异验证：撤掉守卫 → `空 reader（""）必须报错`。
顺带一条给他的更正：同一个函数结尾还有 `UPDATE mails SET status='read'`（**行级**全局写），
所以"按读者"这个性质只对**用 `mail_reads` 派生的数据**成立（`CountUnread`/`ListInbox` 是），
读 `mails.status` 的客户端仍然是邮件级语义 —— 两件事在同一个函数里，容易被看漏。
2. **§2 手势阈值**：核实结果 —— **WebUI 侧没有被任何判据钉住**（`CalendarView.tsx:204`
裸字面量 `Math.abs(dx) < 40 || Math.abs(dx) < Math.abs(dy) * 1.5 || !fast(600ms)`）。
所以撤掉"与 WebUI 一致"的写法，改标 **「待两边对齐」**（文档两处），并把他给的推广写成
规范 `CRITERIA.md` §12：**凡"与 X 一致"的判据，前置条件是 X 侧那个值自己有判据钉住**，
否则测的是"我抄的那一份" —— 与"两张表各缺一半时必须按 id 联接"同一族。
3. **§1 分支声明（最要紧的一条）**：写进 P6 分期段 —— 本步实现的是**窄屏那条**
（**容器自身带圆角 + 那一层能裁剪**）；宽屏那条（起始侧/结束侧分开给）**不适用**，
因为它的理由是"中间是分隔线、四角全给会露底色"，而手机是单栏、中间没有分隔线。
并写死这句：**"给对边"是跟着"中间有没有分隔线"来的，不是无条件的三件套。**
同时核实并写清现状：鸿蒙侧**还没有日历页**（全 ets 树无任何 calendar 提及）⇒ P6 是整页新建。
4. **§3 可验收性**：P6 三步各加一列 —— 第 1、2 步**本工作区可验收**（读 `.ets` 层结构），
并明确"**第 2 步不需要设备，不许登记成 `static` 欠账**"（那会虚增余额）；第 3 步
**必然进欠账**（要设备：能装、能点），到期前提见探针表。
5. **§5 路由**：不再把 WebUI 改动挂成"等 pi"（他这条链上没有 shell）。按他给的三级路由执行：
优先在鸿蒙侧引用**已有令牌**解决；必须动 WebUI 时找 gui-lab 或按先例自己改。
|
2026-09-14 17:03:16 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
1619399470
|
fix(gateway): 已读改为**按读者**记录 —— 修掉"别人读掉，我就看不到"
用户报的那句 dsh 自述（"收件箱列表未展示它，直接按 mail_id 读取成功"）不是插件问题，
是网关的已读模型：`mails.status` 是**邮件级**的一个列，任何收件人读掉，对所有收件人
（含抄送）都变成已读 —— 全库没有任何按人记录已读的表，我查过 schema 与迁移文件。
实测复现（两个人类用户、一封共享邮件，排除 Agent 干扰）：
gui-lab 读掉 → gui-lab 未读清空（应当）→ **jianf 的未读也没了**（错误）
而 jianf 的 `status=all` 里仍在 ⇒ 是已读语义问题，不是送达问题。
线上那封信正是这个形状：`jianf → dsh` 抄送 pi/opencode/zcode/homeagent，**pi 最先
回复（= 它读过了）** ⇒ 这封对 dsh 也变成 read ⇒ dsh 的 `read_inbox`（默认 unread）
返回空 ⇒ 它只能按提示词里的 mail_id 兜。
三个受害面：① Agent 的 `read_inbox` 拿不到信（换一个不兜的模型就变成"正文是空的"）；
② 人类的未读被抄送的 Agent 读掉；③ ★ 桥的补投判据 `pending_mails = CountUnread` 归零
⇒ SSE 漏过或进程重启时那封信**不再补投**（静默丢信）。
改动：
- 新表 `mail_reads(mail_id, reader_name, read_at)`，未读 = 这张表里没有该读者的行。
- 判据收敛到一处（repo 的 `unreadFor` / `readStateFor`），六处读写点全部改用它：
单封已读、批量标已读、权限决策（只记**决策人**）、`ListInbox`（过滤 + 返回的
status 都按读者算）、`CountUnread`、`CountUnreadInSession`、会话列表未读计数。
- 一次性回填补历史：`mails.status='read'` 记到**主收件人**名下（唯一可用的推断），
用 `app_meta` 里的标记守住 —— 不能每次启动都跑，那会把"某抄送方读过"按主收件人
写成已读，正是这次要修的错。实测：`done rows=207`。
- `mails.status` 保留为"有人读过 / 已归档"的冗余列，**不再是判据**。
★ 顺带挖出并修掉一个真 bug：`CountUnreadInSession` 用的是 PG 专有语法
（`cc_list @> $3::jsonb`），而线上是 SQLite ⇒ 那条 SQL **语法错误**
（`unrecognized token: "@"`），调用点又是 `unread, _ :=`（吞错）⇒
**会话列表的未读数一直是 0**。现已改用仓库既有的方言助手 `db.CCHas`。
实测：happy-pixel 会话现在 `unread_count=5`（修复前恒 0）。
判据：新增 `internal/repo/readstate_test.go`（5 条：按读者未读、会话内计数、
批量标已读、归档对所有人可见性、权限决策只记决策人）。
**扰动验证**：把 `unreadFor` 退回旧语义 → 4 条判据全红；恢复 → 绿。
全量 server 10 包全绿。文档同步：API.md 的「标记已读」段 + PLUGIN-CONTRACT 的 T-1.4。
线上复验：同一受控实验 —— gui-lab 读掉后，**jianf 的未读仍在且 status=unread** ✅
|
2026-09-13 14:25:44 +08:00 |
|
|
|
0b5fabfd49
|
fix(repo): /api/v1/agents 带出 mode_enforcement —— 列表接口静默少了一个事实
# 现象
`/api/v1/agents` 对全部四个 Agent 返回 `mode_enforcement: ""`，
而库里四个值一直是正确的（pi=native / dsh=partial / opencode=advisory /
homeagent=advisory）。这是全功能演练 Phase A 的前置检查抓到的。
# 根因
`ListAgents` 的 SELECT 里没有 `mode_enforcement`，Scan 自然也没扫它。
这与「SELECT 加了列但没加进 Scan」（列数不匹配，直接报错）**不是**一回事：
少取一列不报任何错，只是安静地少一个事实。而「这个 Agent 到底能不能真的拦住
危险操作」是使用者在派活前必须知道的事 —— 缺了它，advisory 档会被当成 native
档用。
# 修法
SELECT 补上 `COALESCE(NULLIF(mode_enforcement, ''), 'advisory')`，与
`permission_mode.go` 同一套兜底（那里也这么写，说明空串确实可能出现）。
# 测试
`repo/agent_mode_list_test.go`：三档各一条 + 一条空串（脏数据），断言**值真的
传出来**而不是「函数没报错」；另加反向对照确认行真的被查到了（避免一个都没查到
也能过）。
反向验证过判据非空转：把修复退掉，测试立刻失败。
|
2026-09-12 11:19:52 +08:00 |
|
|
|
a696b2a141
|
fix(handler): 回信的 to_workspace 从会话 workspace 继承 —— 修「每封邮件多一条会话」
# 现象（生产实测）
在 DSH 界面上观察到的：每处理一封邮件就多出一条独立会话。
# 根因
`to_workspace` 是插件唯一能知道「这个任务该在哪个目录干活」的入口，而它取的是
**地址里的 path 位**。Agent 之间的回信、以及人在对话页点回复，地址里通常没有
path 位 —— 平台下发的 `reply_address` 就是这个形状（`FormatAddress(replyTo, "", alias)`）。
空着传下去的后果是可观测的：插件只能自己拼一个临时目录，于是**每封邮件落在一个
不同的空目录**里；DSH / opencode 按 cwd 给会话分组，界面上就成了「每处理一封邮件
就多出一条未分组会话」，而模型在那个空目录里什么项目文件也看不到。
实测取证：
- 线上 5 个兜底目录 `~/.dsh/mail-sessions/mail-*` **全部是空的**（0 条目）
- 全天 journalctl 里**没有任何**相关告警（代码用的是 `ctx.logger.warn`，
而同一文件别处明确写着 DSH 的 logger 不进 journalctl）→ 完全静默
- 走兜底的那条会话（8e982e96）里，`dsh → opencode` 那封 `to_workspace` 有值，
而 `opencode → dsh` 的回信 **to_workspace 全为空** —— 而该会话自身的
`sessions.workspace` 一直是有值的
# 修法
会话的 workspace 才是权威来源（见 models.SessionWorkspace 的注释）：回信本来就是
回给**那条会话**的，而那条会话知道自己属于哪个项目。规则抽成纯函数
`resolveToWorkspace(addrPath, sessionWorkspace, toIsHuman)`：
1. 地址里写了 path → 照用（人的明确意图优先）
2. 没写且收件方是**人** → 保持空（人没有工作目录；填了前端会拼出
`gui-lab@/path.别名` 这种错地址，ToHuman 字段就是为此加的）
3. 没写且收件方是 Agent → 用会话的 workspace
**改的是 `to`，不是只改建库那一行**：同一个值还进投递载荷（`to_workspace` /
`self_address`）。改一处另一处不改，会出现「API 读到的与插件推到的不是同一个
目录」——那正是本项目一直在治的静默不一致。
`notify/mail.go` 只加了一段注释说明 reply_address 的 path 位为何**刻意留空**
（它的语义是「**发件人**该在哪儿干活」），免得后人以为那是漏填。
# 测试
- `handler/toworkspace_test.go`：6 条规则用例 + 1 条**反向对照**
（固定其他输入只翻转 toIsHuman，要求结果必须不同 —— 防止该参数被忽略后
「给人也填 path」静默回归）
- `repo/session_workspace_test.go`：锁住**列名与真实 schema**。这个查询读不到时
按设计返回空串，与「这条会话没有工作目录」无法区分 → 列名写错的功能表现是
「看起来还在跑，只是工作目录永远继承不到」
|
2026-09-12 11:19:19 +08:00 |
|
|
|
dc7bf57ceb
|
fix(calendar): 农历提醒按本地公历日推进，修正凌晨跨 UTC 日期错一天
# 现象
全量服务端测试稳定失败：
--- FAIL: TestStaleLunarRecurringDoesNotFlood
calendar_test.go:869: 农历日从 21 变成 20
不是随机失败，也不是测试写错 —— 是产品逻辑的真实缺陷。
# 根因
SQLite 的 DSN 带 `_timezone=UTC`（为了让 `expires_at > NOW()` 这类字符串比较
同一时间轴，见 db.sqliteDSN 的注释）。因此从库里 Scan 出来的 `event_time` 是
UTC 时刻的表示。
对公历重复规则，这无关紧要 —— `AddDate` 操作的是同一时刻的另一种表示。
但**农历换算直接读取 Year/Month/Day**：
本地 2025-09-12 07:00 (+0800) → 存库 → 读出 UTC 2025-09-11 23:00
农历(本地) = 七月廿一 → 农历(UTC 字段) = 七月二十 ← 少一天
后果：在本地时间 0:00–8:00（+0800）创建的农历提醒，之后每次推进都按前一天
计算，日期永久偏一天；而且只有等到下一次该提醒时才暴露，没有任何报错。
# 修法
在 `AdvanceRecurrence` 里，仅对两条农历规则把 event_time 转回 `time.Local`
再交给 `NextOccurrence`。
只转农历规则而不是无条件转：公历规则不需要，且 UTC 与 Local 表示同一时刻，
`AddDate` 在两者上结果相同 —— 无条件转会掩盖「DSN 时间是 UTC」这个事实，
让后来者更难判断该在哪一层做时区处理。
# 测试
新增 `TestAdvanceRecurrenceLunarUsesLocalCalendarDay`，用**固定日期**
（2025-09-12 07:00 本地）而不是 `time.Now()`，因此任何时刻跑都稳定；
并且它先断言测试前提成立：
- 库里读回的时刻确实与输入跨了不同公历日
- 直接按 UTC 字段做农历换算确实会得到不同的农历日
前提不成立就直接 Fatal —— 否则这个用例可能在某个时区/时段下变成永远通过的
空壳（那正是它要防的那类假绿）。
# 验证
- 新用例与原有的两条农历用例 ×10 连跑全绿（`-count=10`）
- `go vet ./...` 干净；`go test ./... -count=1` 全量通过
- 修复前该用例 5/5 失败，修复后 10/10 通过
|
2026-09-12 08:01:59 +08:00 |
|
|
|
4e32dd3145
|
fix(permission): Agent 不能把审批指派给与任务无关的人
# 漏洞
`POST /permission/request` 的 `to` 字段由 Agent 自由填写，服务端只检查
「这个名字是不是一个合法的人类用户」：
decider := req.To
if isHuman, _ := repo.IsHumanUser(ctx, decider); !isHuman { …回落… }
于是任何 Agent 都能把「是否允许执行 bash」这类危险操作的审批丢给**任意一个
与这条任务无关的人**（例如管理员）。被点名的人看到一封没有上下文的待办，
只能凭猜点头或拒绝。
这跟同一份代码里的另一段注释直接冲突。那段在论证为什么不把权限转给管理员：
管理员对这条 Agent 链的上下文一无所知，既不知道这个 bash 命令在做什么，
也不知道拒绝后 Agent 该怎么绕过去。
这个理由同样适用于「Agent 自己点名一个无关的人」—— 而且更弱：至少管理员还能
查日志，一个随机被点名的用户连从哪查都不知道。两处都指向同一条规则：
**权限应当追溯到最初分配任务的人**，也就是这条线索上的人。
这是静态审计发现的四项之一。当时三桥实测都不传 `to`，所以是潜在面而非活跃
漏洞 —— 但 `to` 是公开的 Agent API 字段，第三方插件照着文档填就会踩上。
# 修法
新增 `repo.IsHumanOnSessionThread(ctx, sessionID, name)`：人类身份 **且**
（会话 owner 或在这条会话的某封邮件里出现过）。
两个来源缺一不可，各有实测场景：
- **只要参与方**会漏掉「会话由 Agent 建立、owner 由平台指派」的会话 ——
那种 owner 可能一封邮件都没收发过，只看邮件会把合法 owner 判成外人，
于是每次审批都回落到线索上随便一个人类。
- **只要 owner** 会漏掉「人在别人的会话里被抄送进来说了话」这种正常协作。
采信与否的处置是**丢弃提示而不是报错**：`to` 只是一个偏好，丢弃后常规解析仍会
给出一个合法人类（owner 或线索上最近的人），实在没有就是既有的 409 —— 无论哪条
分支，都不会把审批送到错的人手上。硬失败则会让 Agent 一次乐观的提示断掉整个
任务，而它并没有做错什么。因为丢弃是静默的，所以**必须留下日志**：
[permission] 忽略不属于本线索的决策人 "jianf"（会话 …, 由 pi 指定）—— 改走常规解析
# 测试
补了这条路径此前**完全缺失**的两层覆盖（审计发现：决策路径
RequestPermission/DecidePermission/ListPendingPermissions 都没有测试）：
- `repo/threadhuman_test.go`：白名单的六种输入（线索上发信/收信的人类、没发过
邮件的 owner、线索外的存在用户、不存在的名字、空串、抄送方），每条都写清
为什么期望这个结果。
- `handler/permission_request_test.go`：**真实 HTTP 层**跑 `RequestPermission`，
断言响应里的 decider 与库里那封权限邮件的 to_name。repo 层 helper 正确但
handler 漏调一次，漏洞就会回来，所以必须有端到端这一层。含纯 Agent 链的
fail-closed 断言（不得退回管理员）。
# 验证
- `go test ./... -count=1` 全绿；`go vet` 干净；`gofmt` 差异行数与改动前完全
相同（8 行，既有的一处空行）—— 即本次改动零新增格式问题
- 真机（workspace 档会话，owner=gui-lab，线索参与者 gui-lab+pi）：
- `to=jianf`（线索外人类）→ decider=gui-lab，库中 to_name=gui-lab，
日志有忽略记录
- `to=gui-lab`（线索内）→ 采纳
- `to=pi`（Agent）→ 忽略，回落 owner
- 已部署（redeploy-gateway.sh 自动项全绿）
|
2026-09-11 23:22:53 +08:00 |
|
