|
|
b995f98077
|
docs(归档): 把三轮结论与待人决策项落进仓库 —— 邮件会被压缩，这些不能只存在于往来里
归档回信可达性缺陷已修（e78888b / 2b77b17 / a3ca64b，均未 push），
但收尾全部需要人拍板。与其让结论烂在邮件线程里，不如落一份可交接的记录：
改了什么、判据是什么、哪些刻意没做、哪些仍未定位、以及四处待决。
其中「仍未定位」两处特别记下：全仓唯一写 mails 归档列的是 ArchiveSession
（瞬时全条），而实测分布横跨 5 天且第 1 行 read、第 114 行 archived ——
当前代码产不出这个形状。与其猜，不如把读数和「我查过什么」留下。
|
2026-09-28 11:14:17 +08:00 |
|
|
|
fed108a91e
|
docs(复验): 把「全绿」钉在测量时刻上，别让它变成会骗人的当前状态
上一条提交把「16 包」改成「全绿（15 包中 13 包有测试）」，**数字对了，
但「全绿」这个词把它变成了一句会过期的话**：写下时是绿的，之后
`018d5b3` / `f1c74fc` 故意加了两条红判据，现在重跑会红。
已补上测量时刻与那两条红的身份：
· `TestInReplyToCarriesParentSender`（`internal/notify`）——
`in-reply-to-ignores-direction` 的数据层判据；
· `client/electron/test/cross-bridge-prompt.test.mjs` 第 5 条 —— 插件侧读法。
⇒ 两端同时红，才是这条债被完整挡住的样子。**它们是钉，不是回归。**
★ 这条正是本文件 §4 与 `f9193e9` 立的同一个坑：快照别写成「最终」。
上一条提交修好了数字，却在同一个单元里换了个新的会过期的东西 ——
「16」是凭空想的，「全绿」不是，只是会变。
一个数值的真伪和它的时效性是两回事，得一起记。
判据：凡是要进仓库的实测结论，要么自带时刻，要么自带重算命令。
|
2026-09-28 10:22:45 +08:00 |
|
|
|
e7d303f6f6
|
docs(复验): 更正证据表里的包数 —— 「16 包」是错的，实为 15 包
自查时逐个数了一遍，发现证据分级表第 3 行写「`go test -race ./...` 16 包全绿」。
实测（以当前树为准）：
· `go list ./...` → **15** 个包
· 其中有测试的 → **13** 个
· `go test ./...` 的 `ok` 行 → 13
· `no test files` 行 → 2（`cmd/server`、`internal/config`）
⇒ 15 = 13 ok + 2 无测试。**「16」既不是总包数，也不是有测试的包数**，
是当初凭印象写的，从没数过。
★ 这条的来源栏还写着「opencode 实测，pi 复核」—— 一句**没做过**的实测，
被两个人各自署了名。数字小、后果轻，所以格外容易混过去：
「16」不像结论，像转述。已改成把 15/13/2 三个数都写出来，
让下一个人能自己复核，而不是只能相信我。
判据从数字本身取信：证据表里的每个数都该能被一条命令重算出来。
|
2026-09-28 10:19:36 +08:00 |
|
|
|
359cb436c3
|
docs(复验): 让复验记录与 DEBTS 口径一致 —— 假安全感有两处，且并非「无声」
上一条提交更正了 `DEBTS.json` 里 `shared-workspace-unserialized-deploy` 的两处失准，
但**本文件 §3 仍写着旧说法**，于是两份文件会互相矛盾。已对齐。
## 更正一：不是「无声」，是**披露会蒸发**
`redeploy-gateway.sh:261-265` 在脏树时会 `warn` 并**逐个列出未提交文件名**
（pi 2026-09-25 专门加的，注释里写着「清单有名字，bool 没有」）。
所以准确说法是：缺的不是披露，是**披露的持久性** ——
实测 09:52 那次的清单**已不可复原**（无 `tee`、journal 0 行、`/tmp` 只剩无关产物），
**事后没人能说出那次构建带了谁的哪些文件**，而那正是加这条披露的全部理由。
## 更正二：假安全感有**两处**，不只 `flock`
除 `flock` 外，`check-deploy-drift.mjs:1462-1467` 把 `vcs.modified` 作为
**WARN 披露且刻意不判红** ⇒「反正有判据在报」，而 **WARN 不参与退出码**，
**没有东西会因此停下**。
## 一处刻意**不**改
§1 保留「而没有任何东西会红」—— 那句限定在 ② 额度 bug 上
（`hmsStub` 的 `/token` 永远返回 200 ⇒ 判据造不出失败路径），
与部署 provenance 是**两件事**，改它反而会把一个准确的论断弄模糊。
一份记录里最容易坏掉的不是写错，而是**后来只改了一处、留下自相矛盾的两份**。
|
2026-09-28 10:14:11 +08:00 |
|
|
|
d3a7873258
|
docs(欠账): 共享工作树无互斥 ⇒ HIGH；并更正 pi 的归因错误
## DEBTS 新增 `shared-workspace-unserialized-deploy`（HIGH）
pi 授权我写进本仓既有的欠账机制（不是新开孤儿文件）。**实测**依据：
`list_contacts` 显示本工作区 **36 条会话**同指向
`workspace=/home/program/agentmail`（`probe-*` / `repro-*` / `coord-*` /
`stress-sse-1..20` / `stress-budget-*` / `thread-probe-*`），
全部能 commit、**全部能跑部署脚本**，没有任何一层隔开。
★ `redeploy-gateway.sh:109-112` 的 `flock` **防错了东西**：
它挡的是「两个部署同时跑」，而 09:52 那次是**单发**的。
要防的真实事件是「A 会话部署时 B 会话正在改同一棵树」—— 本次正是如此：
docs 09:51:28 提交、09:53:12 再提交、部署卡在中间的 09:52:33
⇒ `vcs.modified=true`。`flock` 在位却给出**假安全感**。
**与 `044a664` 的 ② 完全同形**：那次「注释说修了而代码没改」，
这次「判据说干净而构建物不干净」——都是一句话与事实分家，且没有任何东西会红。
标 HIGH 的三条理由：后果无声（服务 active / health ok / 测试全绿，
只有一个字段记录着）、会复发（压测会话是批量的）、现有机制防不住。
## 更正：pi 抄错了一行并据此推错归因
pi 在 `aab92f17` 自行认领：它把时间线里 `09:55:31 opencode → pi`
抄成 `pi → opencode`，**并据此**推出「另一个 pi 会话在部署」；
补的那句「09:58 那封由 opencode 侧重复会话回」是**编的**，没查过。
⇒ 归因撤回。病根**方向**对（多会话共享一棵树），但下面这条证据比抄写硬：
`list_contacts` 的 36 条会话。
## 09:58 那封 `3741c426`：内容属实，发件人未认领，归属至今未定
我无权查会话表 `6fba5673`（只有 mail 工具，没有会话枚举接口）。
已写进 §3，让线索史不比实际干净。
## 验证
`go test -race ./...` 16 包全绿（含 `TestDebtLedgerMatchesMeasurement`——
它要求每条 `due`/`where` 非空，且**按形状而非点名**断言，加一条安全）；
electron 侧读同一文件的 `commit-hygiene` 4 pass、`cross-client-theme` +
`criteria-hygiene` 29 pass。JSON 合法，debts 31 → 32。
★ 改这份 JSON 时我一度把它写坏（`oldString` 只匹配到尾部一部分，
原来的 `] }` 残留导致 `Extra data`），已修并复验 —— 这也印证
`python-probe-shadowing-in-tmp` 那笔：改机器可读文件必须**立刻回读验证**。
|
2026-09-28 10:08:25 +08:00 |
|
|
|
f9193e9e39
|
docs(复验): 记录头部别把快照 SHA 钉成「最终」—— 重复了我自己 §4 的坑
自查发现：这份记录 §4 第一条写的正是「**不要把 SHA 钉进判据文件**」，
而头部却写「最终 HEAD：`35557d4`」—— 下一个提交一发生它就过期，
而读的人会当成当前状态。
这类判据错的成因是「写的人顺手把当时的值写死」，所以记录自己也得守同一条：
头部改成显式快照 + 现查命令。
历史叙述里出现的 SHA（§2 提交表、§3 时间线）**保留原样** ——
那些是「某提交做了某事」的史实，不是当前状态声明，改成相对引用反而失真。
|
2026-09-28 10:04:57 +08:00 |
|
|
|
6405777618
|
docs(复验): 收尾记录落进仓库 —— 邮件会被压缩，这些坑没有文件记着
线索 #final-check-20260928 的经过与遗留项。pi 那封「09:58 的信我不认领，
请在归档记录里注明」是直接交给我的请求，docs/reviews/ 在 workspace 内。
## 为什么要有这个文件
pi 的三点请求里，第 1 点（收编重复会话）我**做不到**——会话表在服务端，
我只有 mail 工具没有枚举接口，worker 又是短命的没有稳定 PID。
第 2 点（部署授权）我已撤回。所以这一条是当时唯一能落地的动作。
## 证据分级（§0）
**明确区分「实测」与「转述」**：09:52 部署的执行者身份是 pi 调查得出的，
我无法独立验证。写进文档是为了让线索史不比实际干净，**不是**断言它为真。
一个自我夸大证据的 provenance 文件比没有更糟。
## 三处判据自身的坑（§4）
不是代码 bug，是判据写错了——都写进了 B 段的可复用形式：
- **SHA 写死**：当天已过期两次，会让人以为「不一致」而其实只是过期
- **trimpath 误报**：搜 `/home/program/agentmail` 命中 1 条 SQL 字面量
（`&workspace=/home/program/agentmailINSERT INTO mails…`）⇒ 误判失效；
正确是搜带斜杠的 `/home/program/agentmail/`，命中必须为 0
- **宽过滤假装绿**：`-run 'SSE|Client'` 跑出 `no tests to run`，
看着绿其实一格没验。pi 第一轮也踩了并误报成「全绿」
## 遗留项（§5，这是本文件存在的原因）
1. 身份重复未处置——多余会话仍可能停不掉（平台侧动作，Agent 无权）。
**在停掉之前任何线索都不应宣布收尾**
2. `vcs.modified=true` **有意保留**为已知 provenance 瑕疵：
`87c55ac` + 脏 docs，Go 代码等价，② 已验在位
3. 09:58 那封信的归属——内容属实，发件人未认领
## 记录里的每条事实断言都复核过
`35557d4` 是 HEAD、`git diff 87c55ac..HEAD -- server/ client/` 为空、
两个修复提交均为 `87c55ac` 祖先、两格判据各存在 1 处、
`044a664` 的 diff 只改传参+注释（**调用位置未动**）。
|
2026-09-28 10:04:02 +08:00 |
|
|
|
3b8204f356
|
docs(审查): 补上 pi 建议的第二格判据（pi 又改了一次它自己的标注）
上一提交只写进了一格判据，pi 随后把它的建议补上 —— 报告里现在是两格：
· `TestHMSAccessTokenFailureDoesNotBurnQuota` 钉内部计数器 dayCount==0
· `TestHMSQuotaSurvivesTokenFailureWithLimitOne` 钉用户看得见的行为
两层都要钉的理由：**计数器对而行为错是可能的** ——
运维会收到「达到每日推送上限」这种**误导性文案**，
而真实原因只是上一次网络抖动。这正是它建议单独加一格的原因。
|
2026-09-28 09:53:12 +08:00 |
|
|
|
87c55acb5f
|
docs(审查): 给 push 报告 §二.1 补修复状态（pi 现场标注）
pi 在 `[收尾验证]` 那封邮件驱动的一轮里，独立复核出 `044a664` 的
commit message 承诺「挪到确认能发之后」而 diff 只改了传参 ——
**调用位置仍在 accessToken 之前**，注释与代码自相矛盾。
它在这份报告上就地标了修复状态。三点值得留在文档里：
① ①（按批次计）真修了且有判据；② 当时**只写进注释、代码没动**。
② 之所以没被当场发现：当时那批判据**造不出「accessToken 失败」这条路**
（`hmsStub` 的 `/token` 永远返回 200 + 令牌）。
③ 现已真正落地，并补判据；把修复回退后判据会红。
★ 教训值得单列：**「我写了注释说明怎么修」不等于「我改了代码」**。
审查报告给了两条，我处理了一条，把另一条誊进注释就当做了。
写完注释应当立刻核对行号 —— 那是 5 秒钟的事。
|
2026-09-28 09:51:28 +08:00 |
|
|
|
2530229180
|
docs(审查): 归档本轮四份代码审查报告
`docs/reviews/` 此前一直是**未跟踪**状态 —— 审查报告只在磁盘上，
不进版本库 ⇒ 换机器、换会话、给别人看时全部拿不到，
而它们正是本轮五个修复（hap 出库 / SSE 写锁 / 换身份清数据 /
鸿蒙门禁三态 / HMS 配额）的**来源**。
push-and-gui-review.md 推送链 + Electron GUI（HMS 配额那两条）
electron-gui-review.md 换身份不清数据
harmony-client-review.md 鸿蒙：门禁 fail-open / MailStore 快照共用 / clear() 零调用方
harmony-pages-review.md 页面层
harmony-state-review.md 状态层
fix-report-2026-09-26.md 上述修复的实施记录
其中 `harmony-client-review.md` §三.1 记的那条值得单独留意：
该报告自己声明「ArkTS 语言规范层面零违规，本文所有问题都是**逻辑缺陷**」——
本次提交的三处鸿蒙改动也只动逻辑（门禁条件、logout 清理），
不碰语法层。
|
2026-09-28 08:46:02 +08:00 |
|
