采样第二组对照：连「写大文件」也不是充分因（本轮写了 135KB+146KB，内存峰值仅 260MB 且被 GC 收回）⇒ 定性修正为「高振幅锯齿 + 回收时机随机」；三次观测并排入库

.workbuddy/memory/2026-10-09.md

@@ -249,6 +249,17 @@
 - 产出：`daemon-内存观察-复现单.md`（三样必采项 ＋ 现成命令 ＋ 判据 ＋ 第一组记录）；采样器 `mem_watch.py` 落**工作区根**（⛔ 不放 `tmp/`，那里会被清理），已起后台采样（5 分钟／20 秒一条 → `tmp/mem-watch-20261009.csv`）。
 - ⛔ 未调 daemon 启动参数、未重启 daemon、未打断任何会话（候选 B 的代价已否掉）。
 
+## 06:46 · 采样跑完：第二组对照**又一次修正结论**（连「写大文件」也不是充分因）
+
+- 采样文件 `tmp/mem-watch-20261009.csv`（06:38:38–06:43:38，20 秒一条）：内存 `191 → 193 → 260 → 196 → 205MB`，rss `450 → 501 → 524 → 443 → 450MB`。
+- 🔴 **`06:39:58` 涨到 260MB、`06:40:58` 掉回 196MB**（GC 收回 64MB），与暴涨组第一轮（609→132）**同型**。
+- 🔴 **该时段会话确实写了同量级大文件**：`ui/mcn-workbench.html` 由 133459 B 改到 **135041 B**（06:39），另有 **146341 B** 的 `_scratch/p1-1440-dom.html` 与 133459 B 的 `.bak-before-gatefix.html`。**内存峰值仍只 260MB 且被收回** ⇒ 上一轮「嫌疑收窄到大文件写入」的结论**被这组数据推翻**。
+- 事件速率：5 分钟 `received` +42087（平均 **8417/分**），比暴涨段的 +9097~+18727/分**更低**。
+- **三次观测并排**：峰值 **609MB（收回）／957MB（未收回被杀）／260MB（收回）** ⇒ 差异更像**随机振幅**，不是某个动作的必然结果。
+- **定性修正**：问题不是「哪个动作撑爆它」，而是 **daemon 内存本来就在高振幅锯齿，能否收回取决于 GC 时机；957MB 那次是「没赶上」的尾部事件**。
+- 已更新：取证报告「要点四」、复现单「结论三／结论四」＋新增「三次观测并排」一节。
+- ⚠️ **下一步要真找因只剩堆快照一条路** —— 再攒曲线点边际收益已经很低。
+
 ## 06:30 · 结果检查第 32 棒 —— 锁已释放，本轮零派活
 
 - 本棒（自动化 `c9779455`，第 32 棒）现取五样：`state.py` 仍不存在、`taskgraph.json` 仍不存在、台账 16 条（15 done ＋ 1 blocked）、`lifecycle`＝进行中、`acceptance` 3 过 ＋ 1 不过。