# 2026-10-15 工作日志

## 排查「为什么不会自动创建接续会话」

**用户问**：「为什么现在 不会自动创作接续会话了， 日志达到上限了吗」

**结论：日志没到上限，机制也没坏。真因是「接续会话」这条链只有"叫"没有"自动建"——
建会话得由**会话里的模型**去做，而本机历史上从未建过。**

### 一、日志水位（实测，⛔ 非推测）

- 本会话 `23715e76-a2fd-4d42-8656-21ca3bde10f5` 在 **10-14 的日志 = 5 190 834 B（≈4.95 MiB）**。
  - 软档 `SOFT_BYTES = 5 MiB`（5 242 880 B）⇒ **差 52 KB**；
  - 硬档 `HARD_BYTES = 8 MiB`（8 388 608 B）⇒ **差 3.14 MiB**。
- **10-15 已按天换成新文件**（52 893 B）⇒ 同一会话跨天**从 0 重来**。
- `dsh log` 自诊断：🟢 低于软档（523 B 的 warning.log 只含两条无关告警：
  `CHANNEL_DISCONNECTED`、`PHASE_PLANNING`）。

### 二、机制状态（体检脚本，⛔ 非目测）

`session-rules-check.py --ws <本区>` ⇒ **fail 0 ／ warn 1 ／ ok 14**
唯一 warn ＝ `[C] 此刻无活会话（按需创建属正常）` ⇒ **钩子全在册、在跑，机制没坏。**

三条触发线（均已接线，见两处常量块）：

1、**日志**（`session-log-guard.py`）—— 软 **5 MiB**（开始写交接材料）；硬 **8 MiB**（回收；回收不成 ⇒ 停手 ＋ 建接续会话）。
2、**上下文 token**（`stop-dialog-guard.py`）—— 120 000（轻提示）／220 000（建议收口）／300 000 `BUDGET_FORCE`（强制收口：先落盘、出接续包、再开新会话）。
3、**工具调用**（同上）—— 软 200 `BUDGET_TOOLS`；硬 250 `BUDGET_TOOLS_HARD`（停手 ＋ 建接续会话）。

### 三、真正的答案（源码级）

`session-log-guard.py` 硬档的处置文案**逐字**：

> ③ **建接续会话**（走一次性 automation —— 自动化是**唯一**能开新会话的通道）；
> ⚠️ **钩子开不了新会话** ⇒ 这四步必须由**你自己**做完；本钩子只负责"叫"。

⇒ **「自动创建接续会话」本机从来不存在。** 钩子只负责"叫"，建会话要**会话里的模型**去建一条
一次性 automation（那是唯一通道）。

宿主库佐证（只读查）：`automations` 表里名字/提示含「接续」「交接」的 ⇒ **命中 0 条**
⇒ **历史上从未建过接续会话**。

### 四、两个真的短板（据实报）

1、**日志线基本"叫不动"**：宿主日志**按天分目录**（`logs/<日期>/sdk/conversations/`），
   同一会话跨天换新文件 ⇒ 单日要涨到 8 MiB 才触发硬档；本会话 10-14 跑了一整天只到 **4.95 MiB**。
2、**昨天到过三级、但没有建接续会话**：`.budget-alert-level` 里写着
   `23715e76-…→ 3`（2026-10-14 11:09）⇒ token ≥300 K **或** 工具调用 ≥250 次已命中；
   而那条线（`stop-dialog-guard.py`）的处置也只是**提示我收口**，**同样不自动建**。
   ⇒ **这是执行缺失（该建没建），不是机制缺失。**

### 五、🔴 两处记忆订正（实测推翻旧记）

1、**「工具调用软 200／硬 250 尚未接线」＝ 过期结论**。
   实测 `stop-dialog-guard.py` 已有 `BUDGET_TOOLS = 200`（一级）／`BUDGET_TOOLS_HARD = 250`（三级），
   并在 `t >= BUDGET_FORCE or ncalls >= BUDGET_TOOLS_HARD` 的分支里生效 ⇒ **已接线**。
2、**「宿主库 187 条 ACTIVE `once` 排期 ＋ 7 条 ACTIVE `recurring`」＝ 与实测不符**。
   实测：`deleted_at IS NULL AND status='ACTIVE'` ⇒ **recurring 4 条、once 0 条**
   （4 条为：AI变现日报 ×2、WorkBuddy 日志定时清理、决策线体检）。
   ⇒ 那条"遗留待清理"要么已被清掉，要么当初口径就不是"ACTIVE"（待下次核实时一并查清）。

### 六、沉淀

- 🔴 **「自动」这个词要先证伪再采信**：本轮用户问"为什么不再自动建接续会话了"，
  查源码才发现**根本没有"自动建"这条实现** —— 钩子只叫、建会话要模型动手。
  ⇒ 判据：**凡涉及"某机制会不会自动做 X"，先 grep 出 X 的实现方，看它到底是谁在触发。**
- 🔴 **日志按天分目录 ⇒ 单日阈值要按"单日增量"重算**：设 8 MiB 硬档前，先确认宿主会不会跨天重置。

---

## 第二件：用户选 B 方案 —— 把「必须建接续会话 ＋ 报 id」钉进钩子文案

**用户指令**：「b方案」（我给的 A/B/C 三选一里，B = 只改规则文字，不加自测判据）。

**改了什么**（技能仓提交 `80ddf12`，推送 `2f65609..80ddf12`，1 文件 ＋4 −2）：
`session-mechanism/scripts/hooks/session-log-guard.py` 日志硬档（8 MiB）的处置文案 ——
1、③ 由「**建**接续会话」改为「🔴 **必须建**接续会话」，并加「**建完把 automation id 写进给用户的最后一条回复**」。
2、④ 告知语补上 id：「已登记自动接续（automation id `xxx`），约 N 分钟后自动开新会话，不需要你操作」。

**为什么这句非有不可**（实测缺口，⛔ 不是想当然）：2026-10-14 本会话已到**三级告警**
（`.budget-alert-level` 记 `23715e76…→ 3`），而接续会话**一封都没建** —— 宿主库里名字/提示含
「接续」「交接」的排期命中 **0 条**。根因是钩子只负责"叫"（源码明写「钩子开不了新会话」），
建会话要**会话里的模型**走一次性 automation；少了「必须建 ＋ 报 id」，叫完仍可能没人建。

**⛔ 没动架构文档**：`references/architecture.md` §③ 讲的是接续会话的**命名规范**（标题怎么起），
与本处「是否必须建」**互补、不冲突** ⇒ 属"别处已覆盖"，改它才是半改。

**验收**：全量自测 **PASS 110 / FAIL 0**（确认没有判据锚定改的那两句 —— 今天已因"判据锚点过期"栽过两次）。

## ⚠️ 提交时发现：有另一个会话在并发改同一批文件

`git status` 里除了我这处，还躺着**别人的改动**（我一律没碰）：
- `humanizer-zh/` **整包被删**（LICENSE / README.md / SKILL.md 三个 `D`）；
- `product-planning/SKILL.md` 的「判据来源」被改写成「**只有 `humanizer` 一份**，`humanizer-zh` 已整包删除、不再引用」，
  并把门槛改成「中文自动评分没可信来源 ⇒ 改人工五维评分 ≥45/50」；
- 我操作期间**又新增** 4 项：`product-planning/references/stage-discovery/SKILL.md`、
  `session-mechanism/SKILL.md`、`session-mechanism/references/collab-detail.md`、
  `session-mechanism/references/作业规矩/04-去AI味和说话方式.md`、`改包纪律.md`。

⇒ 判读：另一条线正在做「**去 AI 味**」相关改造（连 `04-去AI味和说话方式.md` 都动了）。
**判据**：提交时**只 `git add` 自己改的那一个文件**，⛔ 不 `git add -A`
（否则把别人半拉的改动一起带进提交）。

- 🔴 **沉淀：技能仓是被多会话共写的** ⇒ 提交动作一律**点名单文件加入**，⛔ 不用 `-A`。
  且"剩余未提交"从 5 项涨到 9 项这件事本身就是信号 —— **看到它变多，就说明有别人在并发改，别顺手带上。**

**事后核实（13:5x）**：那条线**已自行提交**，技能仓现为 `50db906`（HEAD == origin/master，工作区干净）。
它今天共落 3 条：`dec7d9c`（删 humanizer-zh，只留英文版 humanizer）、
`db52965`（去 AI 味判据一律改用英文目录）、`50db906`（每份产出文档开头必须有图）。
⇒ 我提交时"点名单文件、不用 `-A`"是对的：既没抢它的活，也没把半拉子改动带进我的提交。