tighten volume-4 continuity and memory articles

Author: T0UGH

docs/guidebookv2/volume-4/01-why-claude-code-is-not-a-one-turn-reset-system.md

@@ -103,7 +103,7 @@ flowchart TD
     A[同一工作线持续推进] --> B[先分清对象边界]
     B --> C[构造当前可工作的上下文面]
     C --> D[历史膨胀带来治理必要性]
-    D --> E[视图治理与主动减负]
+    D --> E[必须治理当前工作面]
     E --> F[恢复与续接]
     F --> G[继续工作]
 ```

docs/guidebookv2/volume-4/02-why-messages-context-system-prompt-transcript-session-are-not-the-same.md

@@ -31,11 +31,11 @@ tags:
 
 ```mermaid
 flowchart TD
-    A[session\n这条工作线的单位] --> B[transcript\n会话档案中的事件轨迹]
-    B --> C[messages\n最基本的消息材料]
-    D[system prompt\n本轮规则层] --> E[context\n当前可工作的面]
-    C --> E
-    F[system / user context\n消息外的附加条件] --> E
+    A[session<br/>工作线单位] --> A1[回答: 这条线有没有壳]
+    B[transcript<br/>历史档案] --> B1[回答: 过去发生了什么]
+    C[messages<br/>材料单位] --> C1[回答: 系统拿什么表达输入与结果]
+    D[system prompt<br/>规则层] --> D1[回答: 这一轮按什么规则工作]
+    E[context<br/>当前工作面] --> E1[回答: 这一轮怎样真正开工]
 ```
 
 这张图最重要的作用，不是定义名词，而是先回答：**这些对象各自在解决什么问题。**

docs/guidebookv2/volume-4/03-how-the-current-workable-context-is-assembled.md

@@ -30,11 +30,13 @@ tags:
 
 ```mermaid
 flowchart TD
-    A[system prompt] --> D[当前可工作上下文]
-    B[system / user context] --> D
-    C[活动 messages 视图] --> D
-    D --> E[当前 query]
-    E --> F[继续推进当前工作]
+    A[transcript / 历史档案] --> B[不是整段原样送模]
+    C[system prompt] --> F[当前可工作上下文]
+    D[system / user context] --> F
+    E[活动 messages 视图] --> F
+    B --> E
+    F --> G[当前 query]
+    G --> H[继续推进当前工作]
 ```
 
 这里故意没有把 transcript 直接放进图中心，因为 transcript 更像材料库；真正被送进当前 turn 的，是经过选择、拼装和约束后的工作面。

docs/guidebookv2/volume-4/05-overall-map-of-collapse-compaction-projection-restore.md

@@ -94,17 +94,13 @@ compact 往前走了一步。它不只是把当前视图变轻，而是明确引
 
 所以它们不是治理链的尾声装饰，而是卷四总问题的最后闭环。
 
-## 用一张更像读者心智地图的图再压一遍
+## 把这条链再压成一句最短判断
 
-```mermaid
-flowchart LR
-    A[历史不断变长] --> B[当前工作面开始变重]
-    B --> C[projection / collapse\n先调视图]
-    C --> D[compact / compaction\n再重设下一段工作条件]
-    D --> E[restore / recovery\n最后把工作线重新接活]
-```
+如果把后半卷再往下压一步，最该留下来的不是另一个关系图，而是这句：
+
+> **projection / collapse 先调当前工作视图，compact / compaction 再重设下一段工作条件，restore / recovery 最后把这条工作线重新接活。**
 
-如果读者读完整个后半卷，只留下这一张图，其实就够了。因为它逼着我们把四个机制理解成同一条持续工作链上的不同岗位，而不是四个互不相干的功能按钮。
+只要这句站住，读者就不容易把后半卷重新读成功能按钮集合。
 
 ## 代码里的分工，也天然更像一条链
 

docs/guidebookv2/volume-4/07-compact-and-compaction-as-the-active-load-shedding-mechanism.md

@@ -37,7 +37,7 @@ compact 不是被动截断，而是主动做三件事：
 
 这三步合起来，才叫“主动减负”。
 
-## 图：compact 更像重设下一阶段的起跑线
+## 图 1：compact 更像重设下一阶段的起跑线
 
 ```mermaid
 flowchart TD
@@ -49,6 +49,16 @@ flowchart TD
 
 这张图里最关键的不是 summary，而是 **新的活动工作段**。compact 的真正作用，是让系统能够带着更轻但仍可工作的条件继续跑。
 
+## 图 2：compact 前后工作面的对照图
+
+```mermaid
+flowchart TD
+    A[compact 前\n旧活动段越来越重] --> B[boundary 划线]
+    B --> C[retained context 保留关键约束]
+    C --> D[cleanup 清掉旧附着状态]
+    D --> E[compact 后\n新活动段重新开始]
+```
+
 ## boundary 为什么是 compact 的核心，而不是配角
 
 在 `cc/src/services/compact/compact.ts` 的相关逻辑里，`getMessagesAfterCompactBoundary(...)` 这类处理很关键。它说明 compact 的结果不是“历史里多出一条总结消息”，而是：

docs/guidebookv2/volume-4/08-restore-and-session-recovery-how-the-system-resumes-work.md

@@ -27,18 +27,17 @@ tags:
 
 > **卷四真正要解释的，不是系统怎样压短历史，而是它怎样在治理之后把工作线重新接活。**
 
-## 先给卷四卷尾总图
+## 先给恢复链主图
 
 ```mermaid
 flowchart TD
-    A[session 作为持续工作壳] --> B[transcript / state 被保留]
-    B --> C[当前工作面被构造]
-    C --> D[必要时进行视图治理与主动减负]
-    D --> E[restore / recovery]
-    E --> F[工作线重新接活]
+    A[会话档案 / state 仍然存在] --> B[整理出可接的恢复包]
+    B --> C[restore 接回当前 runtime]
+    C --> D[重新组织当前工作面]
+    D --> E[工作线继续推进]
 ```
 
-这张图就是卷四真正想留下的残影：对象边界、当前工作面、治理链、恢复链，本来就是一件事的四个侧面。前面 01 到 07 做的，不是铺设若干功能点，而是在回答：一条工作线怎样不散。08 则必须把这个问题收死。
+这张图就是本篇最该留下的残影：恢复链不是回看过去，而是把一条还能继续工作的线重新接回当前现场。
 
 ## recovery 不是“把旧聊天翻出来”，而是先整理出可接的工作包
 
@@ -87,20 +86,11 @@ flowchart LR
 
 所以 restore / recovery 在卷四里不是“讲完治理以后顺手补一下”的尾声功能，而是这条链最终成立的证据。没有它，前面的 projection、collapse、compact 都只是在说明系统会处理负担；有了它，卷四才能说明系统会把处理过的工作重新接成活线。
 
-## 把 01 到 08 压回一条闭环
+## 把卷四压回一句闭环判断
 
-到卷尾，卷四真正完成的不是 8 篇文章，而是一条闭环：
+到卷尾，卷四真正留下的不是 8 篇文章目录，而是这句：
 
-1. 01 先立住：Claude Code 不是一轮跑完就重来的系统。
-2. 02 再分清：session、transcript、messages、system prompt、context 分别在解决什么问题。
-3. 03 再说明：当前 turn 依赖的是被构造出来的当前工作面，而不是裸历史。
-4. 04 再推出：只要工作线持续变长，原样无限送模就一定会失效。
-5. 05 再给出：projection / collapse、compact / compaction、restore / recovery 是一条连续分工链。
-6. 06 再校正：系统先治理的不是 transcript 本体，而是当前可工作的视图。
-7. 07 再解释：compact / compaction 怎样主动减负并重设下一段工作条件。
-8. 08 最后收束：治理之后，这条线怎样重新接活。
-
-到这里，卷四留下的就不再是一组机制名，而是一张持续工作闭环图：**有工作线，有档案，有当前工作面，有治理，有恢复，所以系统能继续活。**
+> **Claude Code 之所以能持续工作，不是因为它把历史一直背着走，而是因为它会分清对象边界、构造当前工作面、在过重时治理，并在必要时把这条工作线重新接活。**
 
 ## 自然导向后续，但不抢后续职责
 

docs/guidebookv2/volume-4/10-why-working-memory-transcript-and-long-term-memory-are-not-the-same.md

@@ -150,7 +150,7 @@ long-term memory 再往前走了一步。
 ## 把三层放在同一张图里看，误会就会少很多
 
 ```mermaid
-flowchart LR
+flowchart TD
     A[transcript\n保留事件轨迹] --> B[working memory\n组织当前可工作面]
     B --> C[当前任务推进]
     C --> D[long-term memory\n沉淀可复用认识]

docs/guidebookv2/volume-4/11-why-memory-md-and-memdir-are-a-formal-long-term-memory-layer.md

@@ -13,7 +13,7 @@ tags:
 ## 导读
 
 - **所属卷**：卷四：上下文与状态怎么维持系统持续工作
-- **卷内位置**：11 / 11
+- **卷内位置**：11 / 13
 - **上一篇**：[卷四 10｜working memory / transcript / long-term memory 为什么不是一回事](./10-why-working-memory-transcript-and-long-term-memory-are-not-the-same.md)
 - **下一篇**：[卷四 12｜为什么自动记忆提取不是小功能，而是系统持续性的后台 runtime](./12-why-automatic-memory-extraction-is-a-background-runtime-for-system-continuity.md)
 

docs/guidebookv2/volume-4/12-why-automatic-memory-extraction-is-a-background-runtime-for-system-continuity.md

@@ -14,8 +14,8 @@ tags:
 ## 导读
 
 - **所属卷**：卷四：上下文与状态怎么维持系统持续工作
-- **卷内位置**：12 / 12
-- **在长期记忆组中的位置**：04 / 04
+- **卷内位置**：12 / 13
+- **在长期记忆组中的位置**：04 / 05
 - **上一篇**：[卷四 11｜MEMORY.md / memdir 为什么不是普通文件，而是正式长期记忆层](./11-why-memory-md-and-memdir-are-a-formal-long-term-memory-layer.md)
 - **下一篇**：[卷四 13｜长期记忆是按什么边界回注到新 runtime 的](./13-how-long-term-memory-is-injected-back-into-a-new-runtime.md)
 
@@ -150,24 +150,13 @@ flowchart LR
 
 同样地，后台 runtime 并不意味着无边界乱记；相反，正因为它是后台持续链，它才更需要被边界与治理约束。但这篇只点到这里，不把全部策略分支写成白皮书。
 
-## 用一张总图把卷四的收口结构画出来
+## 把这条后台链再压成一句最短判断
 
-```mermaid
-flowchart TD
-    A[卷四前半\n维持当前工作面] --> B[治理 / 压缩 / 恢复]
-    B --> C[同一工作线继续推进]
-    C --> D[长期记忆层已存在]
-    D --> E[自动记忆提取后台持续运行]
-    E --> F[跨任务沉淀并回注长期认识]
-    F --> G[系统持续认识用户与项目]
-```
-
-这张图想留下的不是“卷四后面多了一个新 feature”，而是：卷四到这里，系统持续性终于完整了一圈。
+如果把自动记忆提取再往下压一步，最该留下来的不是卷四总复盘，而是这句：
 
-- 前半圈在处理**当前工作还能不能继续**
-- 后半圈在处理**跨任务认识还能不能继续**
+> **后台持续筛选什么值得留下，沉淀成长期认识，再把这些认识带回新的 runtime，这样系统才能跨任务继续认得用户与项目。**
 
-没有前者，系统会在当前工作里失焦；没有后者，系统每换任务都要重新认识对象。Claude Code 想成为持续工作者，两半都不能少。
+只要这句立住，这篇就已经完成了它最该完成的事：把长期记忆从静态对象层推进成后台运行层。
 
 ## 边界：这篇不再展开什么
 

docs/guidebookv2/volume-4/13-how-long-term-memory-is-injected-back-into-a-new-runtime.md

@@ -172,15 +172,14 @@ tags:
 
 ```mermaid
 flowchart TD
-    A[新 session / 新 runtime 建立] --> B[getUserContext]
-    B --> C[getMemoryFiles]
-    C --> D[getAutoMemEntrypoint -> MEMORY.md]
-    D --> E[getClaudeMds 注入入口索引]
-    E --> F[当前任务继续推进]
-    F --> G[startRelevantMemoryPrefetch]
-    G --> H[findRelevantMemories(query)]
-    H --> I[最多挑少量单条记忆正文]
-    I --> J[relevant_memories attachments 注入]
+    A[新 session / 新 runtime 建立] --> B[启动阶段]
+    B --> C[getUserContext -> MEMORY.md 入口索引]
+    C --> D[先把记忆入口带回当前 runtime]
+    D --> E[运行阶段]
+    E --> F[startRelevantMemoryPrefetch]
+    F --> G[findRelevantMemories(query)]
+    G --> H[最多挑少量单条记忆正文]
+    H --> I[relevant_memories attachments 注入]
 ```
 
 这张图最重要的地方，是把两种“回注”彻底拆开：