chore(工作区): 全量入库 + 补齐 .gitignore（以工作区为准）

- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次）
- .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…），
  目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪
- .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/）
- .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*）
- .gitignore 补：备份件（*.bak-*）
- 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）

.workbuddy/memory/automations/5bd2b593-9c62-403c-86a5-e02d8ded22a2/memory.md

@@ -0,0 +1,47 @@
+# 自动化记忆 · 5bd2b593（接续棒：会话日志「事前叫停」件 1）
+
+## 2026-10-01 12:35–12:50 —— 第 1 次执行（会话 `ee3c2d82`）
+
+**结果**：✅ **落地并在真实会话验收通过**。接续包 §2 件 1「事前叫停钩子」完成。
+
+**做成的**：
+- 新建 `07-scripts/session-log-guard.py`：只读本会话诊断日志字节数（`os.path.getsize`，⛔ 不 grep 内容），
+  软 5 MiB / 硬 8 MiB 分档 emit。⛔ 未重复实现 token／次数档（那些 `stop-dialog-guard.py` 已有）。
+- 注册进宿主 `E:/ProgramData/.workbuddy/settings.json`：`PostToolUse` 新建 ＋ `UserPromptSubmit` 追加。
+  备份 `settings.json.bak-slg-20261001`；**结构比对：丢 0 键 / 改 0 值**。
+- 顺手定域：`preflight-lock.sh` 的 `MECHANISM_RE` 补 `session-log-guard.py` ＋ 一直缺登的
+  `bash-output-guard.py` ＋ `preflight-lock.sh` 自身；库内 `CODEBUDDY.md §A` 改「5 条 hook 入口 ⇒ 7 条」。
+
+**验收（关键：不是本地跑通）**：验收口子文件（`tmp/.session-log-guard.verify.json`，只认本会话 sid）
+⇒ 本会话日志 3.07 MiB ⇒ 下一次工具调用后 **本会话上下文里真的出现了注入的 🔴 提醒**；
+第二次调用**无重复 emit**、自证日志 `EMIT` 行数 = 1 而 `VERIFY-ON` = 2 ⇒ 静默是去抖不是没跑。
+脚本自身 0.5 ms；含解释器单次 ≈49 ms（用 `-S`；⛔ 不许加 `-E`）。
+
+**遗留（喂下一棒）**：
+1. 🔴 §G 档 3「工具调用 200/250 次」**仍未接线** —— `stop-dialog-guard.py` 还是 `BUDGET_TOOLS=80`、
+   token `12万/20万/30万` ⇒ 与 §G 的 200/250・220K **口径不一致**，需专棒统一。
+2. 件 2（压调用次数手法）／件 4（宿主缺陷报告）未做；件 3 已落（§G 已写）。
+3. `docs-sync-check` 22 处不一致 ＋ 9 处仅本地 = **既有欠账**，非本棒引入；按 prompt 明令**未推送**。
+
+**下一棒开机**：跑 `state.py` → 读 `memory/2026-10-01.md §三十九` → 优先做上面「遗留 1」。
+
+## 2026-10-01 13:18 —— 用户追问（同一会话 `ee3c2d82`）
+
+**用户原话**：「就一轮对话 日志就到 4.68 说明 调用工具和日志异常增长的问题还在」。
+
+**结论**：🔴 **用户判断成立**。件 1 只是**报警器**，⛔ 完全不解决"涨得快"。用本会话自证并复核了系数。
+
+**实测（已写进 `memory §四十` ＋ 接续包 §6）**：
+- 每次工具调用 = **144 帧 = 37 KB**（166 次调用 → 6.2 MB）⇒ ✅ 与接续包 §1.5 的 "135 帧/37 KB" **独立吻合**。
+- 🔴 **病根是"调用次数多"**：本会话 8 分钟 166 次（≈20 次/分）vs 参考会话 10.5 次/分 ⇒ 速率翻倍。
+- 🆕 **新发现**：`event-machine:dispatch` 占 **97.8%**，每行 249 B，**只有 requestId ＋ 四个恒 false 布尔位在变**
+  ⇒ 真正有内容的只有 461 行（2.2%）⇒ **件 4（上报宿主）份量应上调**。
+- ✅ 坐实"增长只与工具在跑有关"：活跃 630 KB/分、空闲 34 分钟 **0 行**。
+
+**⚠️ 我犯的错（已更正三处载体：脚本注释 / 接续包 §6 / 日志 §四十）**：
+一度发布「每次调用 ≈400 行 ≈100 KB、比 §1.5 高 2.7 倍」—— 成因是**用估的调用次数（~50）当分母**，
+实际 166 次。🔴 **教训：报系数前分子分母都必须实测**。另撤回一条无支撑推断「命令跑得越久帧越多」
+（§5 已撤回同源结论，我差点写回来）。
+
+**下一棒优先**：① §G 档 3（工具调用 200/250）接线；② **件 2「压调用次数」—— 现在是最高价值的一件**
+（唯一直接杠杆）；③ 件 4 上报宿主。⛔ 本轮未动自动化排期（按用户明令）。