docs(欠账): 更正我自己那笔 HIGH 的两处失准 —— 披露存在，只是会蒸发

自查上一条提交时逐行核了 `redeploy-gateway.sh`，发现我把 `shared-workspace-unserialized-deploy`
写重了。两处更正：

## 更正一：不是「无声」，是**披露会蒸发**

初稿写「没有任何东西会红」。**不准确** —— 披露机制存在，而且是 pi 2026-09-25 专门加的：

· `redeploy-gateway.sh:261-265`：脏树时 `warn` 并**逐个列出未提交文件名**
  （注释里明说「清单有名字，bool 没有」）；
· `check-deploy-drift.mjs:1462-1467`：把 `vcs.modified=true` 作为 **WARN 披露**，
  且**刻意不判红**。

⇒ 真正缺的不是披露，是**披露的持久性**。实测 09:52 那次的清单**已不可复原**：
脚本无 `tee`、journal 0 行、`/tmp` 只剩无关产物。**事后没人能说出那次构建
带了谁的哪些文件** —— 而那正是当初加这条披露的全部理由（2026-09-14
`pool.mjs` 那一行未提交的 `let missingSessionCount = 0;` 就是这么进生产的）。

## 更正二：假安全感有**两处**，不只 `flock`

`check-deploy-drift` 的 `modified` **WARN 不参与退出码** ⇒
「反正有判据在报」，而 WARN 不进退出码，**没有东西会因此停下**。

## `due` 同步改写

原文建议「部署时若有未提交改动就拒绝」—— 那会与既有设计**直接冲突**：
`check-deploy-drift.mjs:1462-1467` 刻意不判红，理由写在代码里
（脏树在本仓是常态，判红=总在亮）。改到真正缺的那格：
**让部署把「构建时的未提交文件清单」持久化**（写进构建物旁边 / 归档日志）。
并加一句 ⚠ 提醒别顺手把 WARN 改成判红。

## 验证

`go test -race -run TestDebtLedger ./internal/repo/` PASS（含 due/where 非空与按形状断言）；
electron `commit-hygiene` 4 pass。JSON 合法，debts 32。
用 `json.dumps(indent=2)` 改写以保证**其余 31 条逐字节不动** ——
diff 只有 2 行命中，前 31 条 id 顺序与内容均未变（已逐条比对）。

★ 改机器可读文件前先验过 round-trip 逐字节一致才动手，否则一次
`json.dump` 就会把整份文件重排、淹没真正的改动。

docs/DEBTS.json

@@ -255,9 +255,17 @@
       "id": "shared-workspace-unserialized-deploy",
       "count": 1,
       "kind": "并发**不受控**：多会话共享一棵工作树，部署与改代码之间无任何互斥（`flock` 只挡同时跑的两个部署）",
-      "due": "给 workspace 加**跨会话互斥**（哪怕只是「部署时若有未提交改动就拒绝」这一条保守判据）时。★ 到期动作不是'再小心一点'——本次已经证明了小心没用：pi 与 opencode 各自按流程走，仍产出带 `vcs.modified=true` 的二进制。",
+      "due": "给 workspace 加**跨会话互斥**，或让部署把「构建时的未提交文件清单」**持久化**（写进构建物旁边 / 归档日志）时。★ 到期动作不是'再小心一点'——本次已证明小心没用：pi 与 opencode 各自按流程走，仍产出了带 `vcs.modified=true` 的二进制，而那次带了谁的哪些文件**已不可复原**。⚠ 注意别顺手把 WARN 改成判红：`check-deploy-drift.mjs:1462-1467` 刻意不判红（脏树在本仓是常态，判红=总在亮），那是**有意的设计决定**。",
       "where": "`deploy/redeploy-gateway.sh:109-112` 的 `flock`（只挡并发部署，**不挡** A 会话部署时 B 会话正在改源码）；`docs/reviews/final-check-2026-09-28.md` §3（本次完整经过）；本工作区实测 **36 条会话**同指向 `workspace=/home/program/agentmail`，别名 `probe-*` / `repro-*` / `coord-*` / `stress-sse-1..20` / `stress-budget-*` / `thread-probe-*`，全部能 commit、全部能跑部署脚本",
-      "note": "★★ 2026-09-28 登记（opencode 实测，pi 独立复核）。\n\n## 形状：**能无声地产出一个「无法证明来源」的二进制**\n\n`redeploy-gateway.sh:109-112` 有 `flock`，注释里把它列为环境前提表里\n「同时性」那一类，写得对 —— **但它防的是错的东西**。\n\n要防的真实事件是：**A 会话 09:52 跑部署，B 会话正在同一棵树上改文档**。\n`flock` 只在两个部署**同时**跑时生效，而 09:52 那次是**单发**的，没人跟它抢。\n\n本次实测：docs 在 09:51:28 提交、09:53:12 再提交，部署卡在中间的 09:52:33\n⇒ 构建时工作区有未提交改动 ⇒ 线上二进制 `vcs.modified=true`。\n\n★ **与 `044a664` 的 ② 完全同形**：那次是「注释说修了而代码没改」，\n这次是「判据说干净而构建物不干净」，**都是一句话与事实分家，且没有任何东西会红**。\n\n## 为什么标 HIGH\n\n① 后果**无声**：服务照常 active、`/health` ok、测试全绿，\n只有 `vcs.modified` 一个字段记录着「这个构建物无法证明等于某次提交」；\n② **会复发**：压测会话（`stress-sse-1..20`、`stress-budget-*`）是**批量**的，\n下一次批量跑就会再压一次；\n③ 现有机制**防不住**：`flock` 在位却给了「已经防住并发了」的**假安全感**。\n\n## 我做过的、能立刻复用的处置\n\n· 判据侧已把 B 段那条 SHA **从写死改成现查**（`git rev-parse HEAD`）——\n  写死的 SHA 当天就因两次部署而过期两次，会让人误判「不一致」而其实只是过期。\n· 部署前先 `git status --short` 空，再跑；不空就**先别跑**。\n· 判据要**钉会红的行为**（本次：`TestHMSQuotaSurvivesTokenFailureWithLimitOne`\n  断言第二次不能是「上限」），只钉内部状态（`dayCount==0`）不够 ——\n  计数器对而行为错是可能的，那会给运维一条误导性文案。\n\n## 一条更贵的建议（未做，需平台侧）\n\n会话级互斥或工作树独占。现在同一 workspace 上有 30+ 个会话别名，\n`coord-hap-evict-20260928` 这个别名本身就在自证问题：它 09:55:31 问\n「delivery-marks-read 的新判据请自行提交」—— **它知道有会话在改这棵树，\n但不知道是哪个，也不在同一条线索上。**"
+      "note": "★★ 2026-09-28 登记（opencode 实测，pi 独立复核）。\n\n## 形状：**产出无法证明来源的二进制，而披露只活在一块屏幕上**\n\n`redeploy-gateway.sh:109-112` 有 `flock`，注释里把它列为环境前提表里\n「同时性」那一类，写得对 —— **但它防的是错的东西**。\n\n要防的真实事件是：**A 会话 09:52 跑部署，B 会话正在同一棵树上改文档**。\n`flock` 只在两个部署**同时**跑时生效，而 09:52 那次是**单发**的，没人跟它抢。\n\n本次实测：docs 在 09:51:28 提交、09:53:12 再提交，部署卡在中间的 09:52:33\n⇒ 构建时工作区有未提交改动 ⇒ 线上二进制 `vcs.modified=true`。\n\n★ **与 `044a664` 的 ② 完全同形**：那次是「注释说修了而代码没改」，\n这次是「判据说干净而构建物不干净」—— 都是一句话与事实分家。\n\n## ⚠ 更正一则（初稿把这笔债说重了）\n\n初稿写「后果**无声**……没有任何东西会红」。**不准确** —— 现有机制**有**披露，\n而且是 pi 2026-09-25 专门加的：\n\n· `redeploy-gateway.sh:261-265`：脏树时 `warn` 并**逐个列出未提交文件名**，\n  注释里明说「清单有名字，bool 没有」；\n· `deploy/check-deploy-drift.mjs:1462-1467`：把 `vcs.modified=true` 作为\n  **WARN 披露**，且**刻意不判红**（理由写在代码里：「脏树在本仓是常态，\n  判红=总在亮」）。\n\n⇒ 真正缺的不是「披露」，是**披露的持久性**。实测 09:52 那次的清单\n**已不可复原**：脚本无 `tee`、journal 里 0 行（实测 grep）、\n`/tmp` 下只剩 `am-sandbox-check.log` 等无关产物。\n**所以事后没人能说出「那次构建带了谁的哪些文件」** ——\n而那正是当初加这条披露的全部理由（2026-09-14 `pool.mjs` 那一行未提交的\n`let missingSessionCount = 0;` 就是这么被带进生产的）。\n\n## ⚠ 更正二则：假安全感有**两处**，不只 `flock`\n\n初稿只点了 `flock`。实际两处都给了「已经防住了」的错觉：\n\n· `flock` 在位 ⇒ 以为并发部署已防（实则只防「同时跑」的那一种）；\n· `check-deploy-drift` 的 `modified` **WARN 不参与退出码** ⇒\n  「反正有判据在报」⇒ 而 WARN 不进退出码，**没有东西会因此停下**。\n\n## 为什么仍标 HIGH\n\n① **披露会蒸发**：本次已实证「脏文件清单拿不回来」，而\n`check-deploy-drift.mjs:1456-1461` 自己写着「这次构建带了哪些未提交文件\n由**部署脚本**在构建步打印（那里才是同一时刻）」—— 而那个「同一时刻」\n没有任何持久化接住；\n② **会复发**：压测会话（`stress-sse-1..20`、`stress-budget-*`）是**批量**的，\n下一次批量跑就会再压一次；\n③ **两处机制都在位却都不拦住**：一个 `flock`、一个 WARN。\n\n## 我做过的、能立刻复用的处置\n\n· 判据侧已把 B 段那条 SHA **从写死改成现查**（`git rev-parse HEAD`）——\n  写死的 SHA 当天就因两次部署而过期两次，会让人误判「不一致」而其实只是过期。\n· 部署前先 `git status --short` 空，再跑；不空就**先别跑**。\n· 判据要**钉会红的行为**（本次：`TestHMSQuotaSurvivesTokenFailureWithLimitOne`\n  断言第二次不能是「上限」），只钉内部状态（`dayCount==0`）不够 ——\n  计数器对而行为错是可能的，那会给运维一条误导性文案。\n\n## 一条更贵的建议（未做，需平台侧）\n\n会话级互斥或工作树独占。现在同一 workspace 上有 30+ 个会话别名，\n`coord-hap-evict-20260928` 这个别名本身就在自证问题：它 09:55:31 问\n「delivery-marks-read 的新判据请自行提交」—— **它知道有会话在改这棵树，\n但不知道是哪个，也不在同一条线索上。**"
+    },
+    {
+      "id": "in-reply-to-ignores-direction",
+      "count": 1,
+      "kind": "**归因错误且无声**：SSE 的 `in_reply_to` 非空就断言「这封是对我上一封信的回复」，不校验父邮件的发件人是不是我 —— 于是单向来信链被逐封读成双向对话",
+      "due": "给 `inboundHeadline` / `replyInstruction` 的 `inReplyTo` 加上方向判据（父邮件的 from == 本方），或让服务端只在父邮件确由收件方发出时才填 `in_reply_to` 时。★ 到期动作不是'在提示词里写清楚'——本次已证明写清楚没用：四封通知的正文里已经逐字写明'回的是你那封：<id>'，模型照样每封都去核一遍，然后照样被误导。",
+      "where": "`plugins/*-mail-bridge/lib/relay-policy.js:105-111`（`inboundHeadline`：`if (inReplyTo)` 直接出'你上一封信的回复到了'）；`plugins/zcode-mail-bridge/src/prompt.mjs:141`（`if (data?.in_reply_to) lines.push('回的是你那封：…')`，无方向判断）；服务端 `server/internal/notify/mail.go:202` 把 `ParentMailID` 原样透传；实测线索 `stress-thread-21863-15348`（session aa2a600d，8 封全为 opencode→pi，层号跳过 3/6/9）",
+      "note": "★★ 2026-09-28 登记（pi 实测，opencode 复核）。\n\n## 形状：**单向 8 封被读成双向 4 轮**\n\n压测线索 `stress-thread-21863-15348` 里 8 封全是 `opencode → pi`，\n`read_thread` 逐层确认，pi 侧一封未发（唯一一次 `send_mail` 被\n'Agent 互发 8 封上限'拦下）。但四封投递通知各自宣称\n'回的是你那封：<上一封的 mail_id>' ——\n\n| 通知 | 宣称的父邮件 | 实际 |\n|---|---|---|\n| 层1 de4e212f | 6298f78a | 6298f78a 是 **opencode 自己的**信 |\n| 层2 e0e8b3c7 | de4e212f | 同上，仍是 opencode 的 |\n| 层4 6358cfc7 | e0e8b3c7 | 同上 |\n\n⇒ 通知里**不存在**一封是 pi 发出的。\n\n## 根因不是'通知乱序'，是**方向被省略**\n\n`resolveTarget` 里 `reply_to` 被解析后 `parentMailID = &replyID`\n（`server/internal/handler/mail.go:88`），notify 原样透传（`notify/mail.go:202`）。\n**模型是对的**：父邮件 = 上一封 = 我上一封收到的。\n\n漏掉的是**方向判据**：`inboundHeadline` 只问'有没有父邮件'，\n不问'这封父邮件是不是我发的'。单向续信也满足'有父邮件'，\n于是一条纯单向的压测链被逐封判定成'对方在回我'。\n\n## 为什么第一封没被骗\n\n6298f78a 走的是真·新会话路径，`parentMailID == nil`\n⇒ `in_reply_to` 为空 ⇒ `inboundHeadline` 落到默认分支\n⇒ 显示'你收到一封新邮件'。**四个桥的同名字符串都在\n`relay-policy.js:111` 这一行**，改动会同时影响 dsh/zcode/opencode/pi。\n\n## 后果：撞 hop 上限，掩盖真实缺陷\n\n每被误判一轮，模型就'处理'一次并回一封，客套到上限被拦\n（生产实测 6 轮）。这次 8 封单向压测消耗的正是这份额度，\n把真正的缺陷挤出了视野。\n\n## 我做过的核对（避免重蹈 aab92f17 的归因错误）\n\n· 4 次 `read_inbox` 全空（unread 与 all 都空，`all` 返回的 8 封全标 `[archived]`）；\n· `read_thread` 三次均为 8 封、全 `opencode → pi`、无任何 pi→opencode；\n· 逐封 `read_mail` 核对发件人与正文（正文是'层 N 的正文'占位）；\n· 层号跳过 3/6/9，但 mail_id 序列连续 ⇒ **发送侧跳号，不是丢信**；\n· 本条根因定位所依据的行号均已回读原文确认。\n\n## 修法的一处取舍（尚未做）\n\n最小改动是在 `relay-policy.js` 加 `inReplyToFromMe` 判据，但那需要\n父邮件的发件人信息 —— 当前 payload **没有**这个字段（只有 `from_name`\n即本封发件人）。所以两个选项：服务端补一个 `parent_from` 字段，\n或插件侧用 `read_mail(parent_id)` 查一次。**前者更便宜且不用多一次往返**。\n\n★ 顺带记一笔：另有两个观察（`read_inbox` unread 视图与通知不一致、\n`session_participants` 回显把 path 段吞掉）**可能同源** ——\n都指向'通知/展示层没有回读真实数据'，但**我没有查证**，不并入本条。"
     }
   ]
 }