docs: add task granularity strategy to M2 manager pattern

docs/shared/m2-manager-pattern.md

@@ -193,6 +193,43 @@ M2 管理者给 subagent 分配任务时，timeout 是关键参数。给短了
 - \+ 启动开销和缓冲
 - = 通常是**单层执行时间的 2-3 倍**
 
+### 7. 任务粒度——拆小比加时间更好
+
+当一个 subagent 任务频繁超时，第一反应不该是加 timeout，而是**检查任务粒度是否太大**。
+
+**经验法则：一个 subagent 任务应该在 5-10 分钟内完成。** 超过这个时间说明粒度太大，应该拆分。
+
+!!! warning "反面教材（2026-03-29）"
+    CASFA Phase 2（创建 @casfa/client-http 包+接入 frontend）作为一个大任务派给 L1，L1 又 spawn L2 coding agent，结果 L1 等不到 L2 完成就超时了。重试两次失败。最终改为让 L1 直接执行（不嵌套 L2），6 分钟搞定。
+
+**正确做法——拆小任务：**
+
+```
+❌ 大任务（一个 subagent）：
+   "创建包 + 写 5 个源文件 + 修改 frontend 8 个文件 + 构建 + 验证"
+
+✅ 拆成 2-3 个小任务：
+   任务 A："分析现有代码，输出包的设计方案（接口定义、文件结构）"
+   任务 B："根据方案创建包，构建通过"
+   任务 C："Frontend 接入新包，typecheck 通过"
+```
+
+**拆分原则：**
+
+| 维度 | 建议 |
+|------|------|
+| 时间 | 每个任务 5-10 分钟可完成 |
+| 范围 | 每个任务只做一件事（分析 OR 创建 OR 接入） |
+| 验收 | 每个任务有独立、可验证的产出 |
+| 依赖 | 前一个的产出是后一个的输入 |
+| 层级 | 如果 L1 需要 spawn L2，这本身就该是一个独立任务 |
+
+**与 timeout 的关系：**
+
+- 小任务 + 短 timeout（5-10 分钟）> 大任务 + 长 timeout（20-30 分钟）
+- 小任务失败了重试成本低，大任务失败了重试成本高
+- 小任务的中间产出可以被下一个任务复用，大任务失败了什么都没留下
+
 ---
 
 ## 反面教材（真实案例）