docs: add coding agent delegation principle + case study to M2 article

docs/shared/m2-manager-pattern.md

@@ -230,6 +230,25 @@ M2 管理者给 subagent 分配任务时，timeout 是关键参数。给短了
 - 小任务失败了重试成本低，大任务失败了重试成本高
 - 小任务的中间产出可以被下一个任务复用，大任务失败了什么都没留下
 
+### 8. 协调者决定层级——不让 subagent 自己判断
+
+2026-03-29 下午的教训：一个 subagent 被派去迁移代码文件，按照"超过 10 行必须用 coding agent"的死规则，又 spawn 了一个 coding agent。但 subagent 的 timeout 不够等 coding agent 完成，直接返回了——结果代码没落盘，白跑一趟。
+
+**核心规则：OC（Agent 管理层）永远不直接写代码。写代码的永远是 coding agent。** 区别只是中间要不要加监工（subagent）。
+
+| 任务复杂度 | 层级 | 说明 |
+|-----------|------|------|
+| 简单（改几个文件、明确修改） | L0 → coding agent | 协调者直接派 coding agent，一层搞定 |
+| 中等（需要多步执行和验证） | L0 → subagent → coding agent | subagent 当监工：写 prompt、跑测试、验证结果 |
+| 复杂（需要架构理解和决策） | L0 决策 → subagent 监督 → coding agent 执行 | 协调者做关键决策，subagent 拆步骤，coding agent 写代码 |
+
+**关键：由协调者（L0）根据全局 context 和时间预算决定层级，不要让 subagent 自己按死规则判断。** 协调者比 subagent 更清楚：
+- 这个任务大概需要多久
+- 是否需要中间验证步骤
+- timeout 够不够让 coding agent 完成
+
+**反面教材：** 给 subagent 的 task 里没说"直接执行"，subagent 看到涉及写代码就自动套娃。coding agent 启动了但 subagent timeout 到了先返回，改动全丢。第二次在 task 开头写明"直接执行，不要 spawn coding agent"才解决——但这治标不治本。正确做法是协调者一开始就判断：这个任务够简单，直接 spawn coding agent 就行，不需要 subagent 监工。
+
 ---
 
 ## 反面教材（真实案例）
@@ -303,6 +322,19 @@ Subagent 没理解"不能断现有服务"的约束。任务描述里没有显式
 4. 零停机 = 先立新、再拆旧
 ```
 
+### 案例四：Coding Agent 套娃（2026-03-29 下午）
+
+**场景：** 迁移 Docker 工具代码到新的 npm 包（@otavia/dev-docker）
+
+**错误操作：** 协调者 spawn subagent → subagent 看到"写代码"任务 → 按"10 行以上必须用 coding agent"规则又 spawn coding agent → subagent timeout 不够 → 提前返回 "Coding agent spawned. Yielding to wait for completion." → 代码没落盘
+
+**正确操作：** 
+
+- 方案 A（简单任务）：协调者直接 spawn coding agent，给明确的文件修改指令
+- 方案 B（需要监工）：spawn subagent 并给足 timeout（15-20 分钟），明确允许 spawn coding agent
+
+**教训：** 协调者决定架构层级，subagent 只负责执行。"要不要套 coding agent"这个决策权在 L0，不在 L1。
+
 ---
 
 ## 实战成果对比
@@ -399,6 +431,7 @@ sessions_spawn({
 3. **约束条件**：什么不能做（比如"不能断现有服务"）
 4. **回滚方案**：如果搞砸了怎么恢复
 5. **上下文信息**：相关文件路径、服务端口、依赖关系
+6. **执行方式指令**：明确告诉 subagent 是"直接执行"还是"可以 spawn coding agent"。不要让 subagent 自己判断。
 
 ### 不要写什么