docs: add timeout strategy to M2 manager pattern

docs/shared/m2-manager-pattern.md

@@ -170,6 +170,29 @@ M2 模式的威力在于**并行**。你可以同时：
 
 这条来自 2026-03-29 的真实翻车（见下文）。
 
+### 6. Timeout 策略——宁长勿短
+
+M2 管理者给 subagent 分配任务时，timeout 是关键参数。给短了会导致任务超时、重试浪费；给长了浪费资源但至少不会丢失工作。
+
+**经验法则：宁长勿短。**
+
+| 任务类型 | 推荐 Timeout | 示例 |
+|---------|-------------|------|
+| 简单查询/状态检查 | 2-3 分钟 | 检查端口、查看配置 |
+| 安装/配置变更 | 5-10 分钟 | apt install、systemd 配置 |
+| 代码分析+创建+构建 | 15-20 分钟 | 创建新包、重构代码 |
+| 含 Coding Agent 的复杂任务 | 20-30 分钟 | L1 spawn L2 coding agent 写代码+测试 |
+
+!!! warning "真实教训（2026-03-29）"
+    给 CASFA 共享类型包的创建任务只设了 10 分钟 timeout。L1 subagent spawn 了 coding agent（L2），但 coding agent 还在分析代码时 L1 就超时了。正确做法是给 15-20 分钟，让整个 L1→L2 链条有足够时间完成。
+
+**关键原则：** 任务复杂度升维（从 L1 直接执行变成 L1 管理 L2），timeout 也要升维。三层架构的 timeout 应该是：
+
+- L2（coding agent）自身执行时间
+- \+ L1 的分析和验证时间
+- \+ 启动开销和缓冲
+- = 通常是**单层执行时间的 2-3 倍**
+
 ---
 
 ## 反面教材（真实案例）