add worktree & up task、teammate etc

docs/zh/s07-task-system.md

@@ -10,7 +10,19 @@
 
 更根本地说, 内存中的状态对其他智能体不可见。当我们最终构建团队 (s09+) 时, 队友需要一个共享的任务看板。内存中的数据结构是进程局部的。
 
-解决方案是将任务作为 JSON 文件持久化在 `.tasks/` 目录中。每个任务是一个单独的文件, 包含 ID、主题、状态和依赖图。完成任务 1 会自动解除任务 2 的阻塞 (如果任务 2 有 `blockedBy: [1]`)。文件系统成为唯一的真实来源。
+解决方案是将任务作为 JSON 文件持久化在 `.tasks/` 目录中。每个任务是一个单独的文件, 包含 ID、主题、状态和依赖图。完成任务 1 会自动解除任务 2 的阻塞 (如果任务 2 有 `blockedBy: [1]`)。在本教学实现里, 文件系统是任务状态的真实来源。
+
+## Task vs Todo: 何时用哪个
+
+从 s07 起, Task 是默认主线。Todo 仍可用于短期线性清单。
+
+## 快速判定矩阵
+
+| 场景 | 优先选择 | 原因 |
+|---|---|---|
+| 短时、单会话、线性清单 | Todo | 心智负担最低，记录最快 |
+| 跨会话、存在依赖、多人协作 | Task | 状态可持久、依赖可表达、协作可见 |
+| 一时拿不准 | Task | 后续降级更容易，半途迁移成本更低 |
 
 ## 解决方案
 
@@ -132,17 +144,20 @@ class TaskManager:
 
 ## 相对 s06 的变更
 
-| 组件           | 之前 (s06)       | 之后 (s07)                           |
-|----------------|------------------|----------------------------------|
-| Tools          | 5                | 8 (+task_create/update/list/get) |
-| 状态存储       | 仅内存           | .tasks/ 中的 JSON 文件           |
-| 依赖关系       | 无               | blockedBy + blocks 图            |
-| 压缩机制       | 三层             | 已移除 (非本节重点)              |
-| 持久化         | 压缩后丢失       | 压缩后存活                       |
+| 组件 | 之前 (s06) | 之后 (s07) |
+|---|---|---|
+| Tools | 5 | 8 (`task_create/update/list/get`) |
+| 状态存储 | 仅内存 | `.tasks/` 中的 JSON 文件 |
+| 依赖关系 | 无 | `blockedBy + blocks` 图 |
+| 持久化 | 压缩后丢失 | 压缩后存活 |
 
 ## 设计原理
 
-基于文件的状态能在上下文压缩中存活。当智能体的对话被压缩时, 内存中的状态会丢失, 但写入磁盘的任务会持久保存。依赖图确保即使在上下文丢失后也能按正确顺序执行。这是临时对话与持久工作之间的桥梁 -- 智能体可以忘记对话细节, 但始终有任务看板来提醒它还需要做什么。文件系统作为唯一真实来源也为未来的多智能体共享提供了基础, 因为任何进程都可以读取相同的 JSON 文件。
+基于文件的状态能在上下文压缩中存活。当智能体的对话被压缩时, 内存中的状态会丢失, 但写入磁盘的任务会持久保存。依赖图确保即使在上下文丢失后也能按正确顺序执行。这是临时对话与持久工作之间的桥梁 -- 智能体可以忘记对话细节, 但始终有任务看板来提醒它还需要做什么。在本教学实现里, 文件系统作为任务状态真实来源也为未来的多智能体共享提供了基础, 因为任何进程都可以读取相同的 JSON 文件。
+
+但“持久化”成立有前提：每次写入前都要重新读取任务文件，确认 `status/blockedBy` 与预期一致，再原子写回。否则并发写入很容易互相覆盖状态。
+
+从课程设计上看, 这也是为什么 s07 之后我们默认采用 Task 而不是 Todo: 它更接近真实工程中的长期执行与协作需求。
 
 ## 试一试