tighten volume-6 framing and navigation

Author: T0UGH

docs/guidebookv2/volume-6/01-why-claude-code-multi-agent-is-a-collaboration-runtime.md

@@ -16,6 +16,21 @@ status: draft
 
 # 卷六 01｜为什么说 Claude Code 的多 agent 能力本质上是一层协作 runtime
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：01 / 07
+- **上一篇**：无
+- **下一篇**：[卷六 02｜team 与 teammate runtime 在 Claude Code 里处在哪](./02-where-team-and-teammate-runtime-sit-in-claude-code.md)
+
+卷五已经把“系统怎样长出更多执行者、并把扩展能力写回 runtime”立住了。
+
+卷六往前推进的，不再是对象数量，而是结构判断：
+
+> **当系统已经能长出更多执行者时，为什么 Claude Code 的多 agent 能力不能只理解成“多开几个 agent”，而必须进一步理解成一层协作 runtime？**
+
+这篇只负责立卷六总判断：后面团队对象、成员运行体、mailbox 协议、idle / shutdown 收尾，以及最后的 swarm 收束，为什么都属于同一条协作 runtime 主线。
+
 ## 这篇要回答的问题
 
 卷五已经讲清楚：Claude Code 不只是会调用工具，也不只是能不断接入 skills、MCP、hooks、plugins 这些新能力。系统甚至已经能把 **新的执行者** 正式接进 runtime。
@@ -219,7 +234,7 @@ flowchart TD
 
 ### 第一，不提前把 lifecycle 讲完
 
-本篇只需要说明 team 已经是正式对象，但不能抢讲创建、注册、清理的细部链路。那是下一篇之后要正式展开的对象成立问题。
+这里先把 team 作为正式对象的必要性点出来就够了；创建、注册、清理的完整生命周期，要留给下一篇单独展开。
 
 ### 第二，不提前把 mailbox / shutdown 讲完
 

docs/guidebookv2/volume-6/02-where-team-and-teammate-runtime-sit-in-claude-code.md

@@ -17,6 +17,21 @@ status: draft
 
 # 卷六 02｜Claude Code 的 team / teammate runtime 到底在系统里处在什么位置
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：02 / 07
+- **上一篇**：[卷六 01｜为什么说 Claude Code 的多 agent 能力本质上是一层协作 runtime](./01-why-claude-code-multi-agent-is-a-collaboration-runtime.md)
+- **下一篇**：[卷六 03｜teams 是怎么被创建、注册与清理的](./03-how-teams-are-created-registered-and-cleaned-up.md)
+
+第 01 篇已经先把卷六的总判断立住了：Claude Code 的多 agent 能力，不只是“多开几个 agent”，而是内部已经长出一层协作 runtime。
+
+第 02 篇继续要回答的是：
+
+> **team / teammate runtime 在整套 Claude Code 系统里，到底处在什么位置？**
+
+这篇只负责把位置切清：它既不是最外层产品功能，也不是最底层执行壳，而是夹在 agent runtime 与更高层产品控制结构之间的一层正式协作结构。
+
 ## 这篇要回答的问题
 
 上一篇已经先把卷六的总判断立住了：Claude Code 的多 agent 能力，不只是“多开几个 agent”，而是系统内部已经长出一层协作 runtime。

docs/guidebookv2/volume-6/03-how-teams-are-created-registered-and-cleaned-up.md

@@ -15,6 +15,21 @@ status: draft
 
 # 卷六 03｜team 是怎么被创建、注册和清理的
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：03 / 07
+- **上一篇**：[卷六 02｜team 与 teammate runtime 在 Claude Code 里处在哪](./02-where-team-and-teammate-runtime-sit-in-claude-code.md)
+- **下一篇**：[卷六 04｜InProcessTeammate runtime 是怎么真正跑起来的](./04-how-inprocess-teammate-runtime-actually-runs.md)
+
+前两篇已经把卷六的总判断和系统位置立住了。
+
+第 03 篇现在要把 team 从结构判断继续压回源码对象链：
+
+> **如果 team 真是协作 runtime 里的正式对象，那它到底是怎么被创建、注册和清理的？**
+
+也就是说，这篇只负责证明 team 不是协作说法，而是一类会被创建、会被系统记住、也会被系统统一清理的正式运行时对象。
+
 ## 这篇要回答的问题
 
 前两篇已经把卷六最上面的骨架钉住了：
@@ -45,7 +60,7 @@ status: draft
 ## 主图：team lifecycle 主图
 
 ```mermaid
-flowchart LR
+flowchart TD
     A[teammate 列表] --> B[createTeam]
     B --> C[生成 team.id]
     C --> D[给每个 teammate 写入 teamId]
@@ -217,7 +232,7 @@ flowchart LR
 
 ### 1. 不能把 InProcessTeammateTask 的运行细节讲完
 
-本篇只需要说明 lifecycle 如何为 teammate runtime 铺路，不能把 `query(...)`、mailbox、idle、shutdown 的运行链全部抢写掉。那是下一篇和后面的协议篇要接手的事。
+这里先把 lifecycle 作为对象成立证据写稳就够了；`query(...)`、mailbox、idle、shutdown 的运行链，要留给后面的运行体篇和协议篇继续展开。
 
 ### 2. 不能把 mailbox 协议提前吃掉
 

docs/guidebookv2/volume-6/04-how-inprocess-teammate-runtime-actually-runs.md

@@ -18,6 +18,21 @@ status: draft
 
 # 卷六 04｜InProcessTeammateTask：真正的 teammate runtime 是怎么在同进程里跑起来的
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：04 / 07
+- **上一篇**：[卷六 03｜teams 是怎么被创建、注册与清理的](./03-how-teams-are-created-registered-and-cleaned-up.md)
+- **下一篇**：[卷六 05｜mailbox / idle / shutdown 怎么把闭环合上](./05-how-mailbox-idle-and-shutdown-close-the-loop.md)
+
+第 03 篇已经把 team 从概念推进成正式对象。
+
+第 04 篇接着要回答的是：
+
+> **真正的 teammate runtime，到底是怎么在同进程里被装配成正式运行体，并真正跑起来的？**
+
+这篇只负责把 teammate 从 team 容器里的成员名，推进成带上下文、leader 关系、mailbox 和 shutdown 行为的正式运行体。
+
 ## 这篇要回答的问题
 
 前一篇已经把 team 从协作概念推进成了正式对象：它会被创建、会被注册、会被查询，也会被统一清理。
@@ -257,7 +272,7 @@ flowchart TD
 
 ### 1. 不能把 mailbox / shutdown 全部讲完
 
-这里只能证明 mailbox 与 shutdown 已经是运行体的一部分，具体协议逻辑要留到下一篇之后再展开。
+这里先证明 mailbox 与 shutdown 已经嵌进运行体就够了；具体协议逻辑，要留给下一篇专门展开。
 
 ### 2. 不能把 Local / Remote / Teammate 边界写掉
 

docs/guidebookv2/volume-6/05-how-mailbox-idle-and-shutdown-close-the-loop.md

@@ -18,6 +18,21 @@ status: draft
 
 # 卷六 05｜mailbox + idle / shutdown 协议：teammate 之间是怎么通信和收尾的
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：05 / 07
+- **上一篇**：[卷六 04｜InProcessTeammate runtime 是怎么真正跑起来的](./04-how-inprocess-teammate-runtime-actually-runs.md)
+- **下一篇**：[卷六 06｜local、remote、teammate task 的边界](./06-boundaries-between-local-remote-and-teammate-tasks.md)
+
+第 04 篇已经把 teammate 立成了正式运行体。
+
+第 05 篇现在要继续回答：
+
+> **mailbox、idle、shutdown 为什么不是零碎机制，而是 teammate 协作闭环成立的三段协议？**
+
+这篇只负责把协作协议压实：通信怎样发生、状态怎样回报、退场怎样闭合。
+
 ## 这篇要回答的问题
 
 前一篇已经把 `InProcessTeammateTask` 立成了正式运行体：teammate 不是一个名字，不是 worker wrapper，而是会真的被装进当前 runtime、接进 `query(...)`、持有自己的消息与状态的运行成员。
@@ -336,7 +351,7 @@ Claude Code 现在做成的是这样一条链：
 
 ### 1. 不能把 06 的承载体边界顺手写完
 
-这里可以顺手提醒：teammate 的 stop / idle / shutdown 语义，明显比普通 background task 更重。但不能在本篇里把 `LocalAgentTask`、`RemoteAgentTask` 和 teammate runtime 的系统边界完整切掉，那是下一篇的职责。
+这里先把 teammate 的 stop / idle / shutdown 写成协作协议即可；`LocalAgentTask`、`RemoteAgentTask` 和 teammate runtime 的系统边界，要留给下一篇单独切开。
 
 ### 2. 不能提前把 07 的 swarm 判断收完
 

docs/guidebookv2/volume-6/06-boundaries-between-local-remote-and-teammate-tasks.md

@@ -18,6 +18,21 @@ status: draft
 
 # 卷六 06｜LocalAgentTask、RemoteAgentTask 和 teammate runtime 的边界是什么
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：06 / 07
+- **上一篇**：[卷六 05｜mailbox / idle / shutdown 怎么把闭环合上](./05-how-mailbox-idle-and-shutdown-close-the-loop.md)
+- **下一篇**：[卷六 07｜为什么 Claude Code team 本质上是一种 swarm](./07-why-claude-code-team-is-a-swarm.md)
+
+前五篇已经把对象、运行体和协议三层压住了。
+
+第 06 篇要解决的，是卷六最后一个容易混桶的问题：
+
+> **既然已经有 teammate runtime，为什么源码里还会同时出现 `LocalAgentTask` 和 `RemoteAgentTask`？**
+
+也就是说，这篇只负责切清三类承载体各自服务什么问题：本地执行、远程执行、协作执行，避免把它们混写成一种“agent task 类型”。
+
 ## 这篇要回答的问题
 
 前四篇已经把卷六的骨架立起来了：
@@ -215,7 +230,7 @@ flowchart TD
 
 ### 3. 它更接近卷五的 worker agent 线，而不是卷六的 team member 线
 
-如果要给 `LocalAgentTask` 找更稳的卷内位置，它其实更贴近卷五已经讲过的那条主线：
+更准确地说，`LocalAgentTask` 更贴近卷五已经讲过的那条执行承载主线：
 
 - 主 agent 派出 worker
 - worker 在清晰 scope 内推进

docs/guidebookv2/volume-6/07-why-claude-code-team-is-a-swarm.md

@@ -19,6 +19,21 @@ status: draft
 
 # 卷六 07｜为什么说 Claude Code 的 team 系统本质上是一个 swarm
 
+## 导读
+
+- **所属卷**：卷六：多 agent 协作运行时
+- **卷内位置**：07 / 07
+- **上一篇**：[卷六 06｜local、remote、teammate task 的边界](./06-boundaries-between-local-remote-and-teammate-tasks.md)
+- **下一篇**：卷七入口待接续
+
+到第 07 篇，卷六前面的对象、运行体、协议和边界四层都已经分别立住了。
+
+卷尾真正要回答的，不再是某一个机制怎么实现，而是：
+
+> **为什么这些对象、运行体、协议和边界一旦被重新压回同一张图，Claude Code 的 team 系统就不该再被叫成“team 功能”，而更像一个 swarm？**
+
+这篇只负责把卷六前文重新压回同一条协作 runtime 因果链，把整卷从 team 机制卷收成 swarm runtime 卷。
+
 ## 这篇要回答的问题
 
 到这里，卷六前六篇已经把四条线分别钉住了：