仓库清理：memory 移出仓库 ＋ 行尾规范化 ＋ 执行会话目录排除 ＋ docs/pm 入库

用户拍板三条（2026-10-15）：「1、memory 不入仓库」「2、A方案」「3、A方案」

1、`memory 不入仓库`（推翻旧口径）：`.gitignore` 增 `.workbuddy/memory/`，
   并把原注释「⛔ 保留 .workbuddy/memory/ 等知识文件」标注作废；已入库的 293 个文件
   用 `git rm -r --cached` 移出索引（⛔ 不动磁盘 —— memory 留在本机照常用，
   只是不再跟仓库走）。连带删掉被新规则覆盖的冗余行 `.workbuddy/memory/.backup-*/`。

2、行尾规范化（A 方案）：新增 `.gitattributes`（`* text=auto eol=lf`）。
   起因：仓里原先没有属性文件、`core.autocrlf=false`，编辑器写成 CRLF 时 git 认为
   "整文件都改了"（实测 49 个文件 24816 增 = 24816 删、内容零变化），污染 diff 且每轮刷屏。

3、执行会话目录排除（A 方案）：`.gitignore` 增 `执行会话/`（内含 160 个文件，
   多为 `_gate-out-第N切片.txt` 这类过程性中间输出）；同时把该入库的 `docs/pm/`
   （ai1net-plugin 产品调研 9 份：1a 需求 / 1b 竞品＋4 份独立分析 / 1c 画像 / 1d 策略 / 1e 场景）入库。

验收：提交前 `git status` 未暂存剩余 0（清理前为 78 项）。

.workbuddy/memory/automations/98f1fd43-04ae-4cc2-a15a-e3bf28460b01/memory.md

@@ -1,30 +0,0 @@
-# 自动化记忆 · 98f1fd43-04ae-4cc2-a15a-e3bf28460b01
-
-## 身份
-- 类型：一次性接续会话（`once` / 10:16 触发），属 §F 白名单「接续会话」免确认。
-- 由来：上一棒 `5f607d3e` 撞满宿主 10 MiB 单会话诊断日志硬上限 ⇒ 09:56:17 `diagnostic-log:dropped` ⇒ 已哑（此后零写入），由本会话把结论交付用户。
-- 线名：多会话协作机制 · 会话哑掉 / 日志根因。
-
-## 本次（2026-10-01 10:16）执行结果
-- 做了什么：跑 `state.py`；读 `.workbuddy/memory/2026-10-01.md` §二十三 / §二十四；整理成给用户的完整答复（三问全覆盖）＋一张「两个时钟」对比图。
-- 三问结论要点：
-  1. Q1 接续会话**已创建**（本单 98f1fd43），但钩子当轮仍报「1 小时内零排期」⇒ 列待查项（⛔ 未断言）；真正原因是**机制缺口**：只做了事后拦截（`_deaf_sids()`），没做事前叫停（§G 36K 钩子侧检测至今待实现；宿主撞顶前零告警）。
-  2. Q2 36K **确实太低**，但错在「量错了对象」：日志 375 KB/分 ⇒ 28 分钟撞顶；上下文 6,100 tok/分 ⇒ 300K 要 47 分钟；日志早 19 分钟，会话死时上下文仅 ≈49~57%。
-  3. Q3 换算基准 1 tok ≈ 63 B 日志；候选表倾向 **80K**（= 日志软 5 MiB），并建议把日志提升为主阈值，写成 5 MiB / 8 MiB 两档阶梯。
-- 交付形态：文本答复（含图表）＋ 待拍板两项（上下文阈值 36K/80K/128K；是否把日志两档写成主阈值）。
-- 只读边界：⛔ 未改任何代码/规则/文档、⛔ 未动生产日志、⛔ 未新建自动化、⛔ 未持锁（无文件改动，无需抢锁）。
-- 遗留：待用户拍板两项 ⇒ 拍板后落到 `CODEBUDDY.md §G` 与 `collabd.py` / 钩子侧检测实现。
-
-## 追加（10:19 用户追问「重点是不是上限问题 / 为什么调这么多工具 / 能否优化」）
-- 本轮只读取证得两条新判据：**单次工具调用 ≈ 37 KB 日志（152 行 × 244 B）** ⇒ **≈283 次工具调用 = 一个会话寿命**；**日志 96.8% 是 `tool_call_update`**。
-- 旁证：宿主 daemon 日志有指纹限流（1 秒 5 条），**会话诊断日志零闸**；`WORKBUDDY_LOG_FILE_LEVEL` 关不掉它。
-- 交付：文字答复 ＋ 泳道图 ＋ 事故链图（含四道缺席防线）；写入 `2026-10-01.md §二十五`。
-- 边界：未改代码/规则/生产日志、未新建自动化、未持锁。
-
-## 追加（10:27–10:35 用户连问三轮，本棒全部答复）
-- **"要直接解决日志上涨过快"** ⇒ 判定性实测：帧只在 **336 / 1694 秒**出现、峰值 **437 帧/秒**、**135 帧/次** ⇒ **日志量 ∝ 调用次数，与挂钟时间无关**；唯一直接杠杆＝压调用次数（第二杠杆＝压 135 这个系数，待验证）。
-- **"哪有那么多工具要调用"** ⇒ 逐条拆穿：`state.py` **27 次**、`export PATH` **18 次**（shell 不共享）、同一份日志读 **12 次**、技能重读 ~25 次、探针脚本 **29 个**（写+跑+删）⇒ **重复开销 ≥110 次（~4 成）**；12 轮承载 264 次 ⇒ **平均 22 次/轮**；**"文件乱"占比很小**（Grep 仅 11 次）。
-- **新线索**：丢行 ↔ 零轮转（4 条会话对照）⇒ 记入接续包 §1.5（⛔ 未结论）。
-- 交付：接续包新增 **§1.5 / §1.6**（下一棒必读）＋ 记忆 `§二十七 / §二十八`。
-- 新解法登记（⛔ 本轮不做）：统一入口压 60 次／`state.py --json` 只在三节点跑／参数化通用探针。
-- 顺带发现：协作程序报的「待处理信号」实为 `tmp/selftest/inbox/READY.md`（自测残留）⇒ 假信号。