Merge pull request #1997 from pikasTech/docs/subagent-concurrency

docs: 要求主动维持子代理并发窗口

.agents/skills/unidesk-subagent/SKILL.md

@@ -42,6 +42,15 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
   - Artificer 已被证明确实不可用时，先创建独立 issue 和泛化问题域 MDTODO，再派一个原生子代理修复 Artificer；紧急且边界独立的业务任务可以暂时派原生子代理，但不得把临时 fallback 固化为长期调度入口；
   - Artificer 恢复后，原生子代理必须在 clean commit、PR 或只读报告 checkpoint 停止继续扩展；主代理通过原 issue、MDTODO 和 session 传递接续上下文，再由 Artificer 接替尚未完成的工作；禁止两个执行面共享可写 worktree、重复提交或并发修改同一任务；
   - 管理性、决策性文档仍由主代理负责，不为了满足 Artificer 优先规则而外包治理决策。
+- 子代理并发必须从用户原始任务的依赖图出发主动扩展：
+  - 主代理先识别串行定锚项、已就绪任务和后续依赖，再计算当前可安全派发集合；
+  - 串行定锚完成后，应立即并发派出所有低耦合、可独立验收且具备独立 worktree/branch/issue/PR 的已就绪任务，直到达到可用执行槽、运行面资源预算或真实依赖边界；
+  - 存在两个及以上已就绪任务时，长期只运行一个子代理属于调度失败：
+    - 主代理必须补派；
+    - 无法补派时，在当前 anchor 中写明具名依赖、共享文件冲突、运行面容量或权限阻塞；
+    - 每个任务终态和依赖变化后重新计算可安全派发集合；
+  - 主代理自己的审核、规划和等待不计入子代理并发量；不得用一个长期任务加主代理活动宣称已经并行；
+  - 不得为了凑并发拆出无独立价值的日志采集、重复调查、重复实现或审核代理；并发量服从原始任务边界和成功率，不服从固定数字。
 - 子代理并行只用于成功率高、耦合度低、能放进独立 worktree/branch/issue/PR 的任务；共享架构方向、公共契约和同文件高冲突修改先串行定锚。
 - 子代理产出的审核默认由主代理直接完成：
   - 用户允许子代理实施、要求并行或启用多轮审查，不等于允许调度审核子代理；
@@ -76,7 +85,11 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
   - 当前用户任务只要派出过子代理：
     - 主代理就必须保持任务进行中；
     - 等待本轮全部子代理进入真实终态；
-    - 不得把 task 创建成功、dispatch 成功、`running`、已提交 commit 或已创建 PR 当作主代理可以结束的交付点。
+    - 不得把 task 创建成功、dispatch 成功、`running`、已提交 commit 或已创建 PR 当作主代理可以结束的交付点；
+    - 等待期间仍要维护并发窗口：
+      - 任一子代理终态、依赖解除或新任务就绪后，立即重新计算可安全派发集合；
+      - 还有独立已就绪任务时及时补派，避免并发窗口退化为长期单任务等待；
+      - 只有具名依赖、共享写入边界、运行面容量或权限阻塞时才允许保持较低并发，并把理由写入主线 anchor。
   - 子代理返回后，主代理必须继续完成职责范围内的收尾：
     - 完成必要的纠偏和 post-task；
     - 审核 PR 并执行获授权的合并；

.agents/skills/unidesk-subagent/references/gh-workflow.md

@@ -10,6 +10,13 @@
 - 高耦合任务先串行定锚：公共类型/契约、source-of-truth、请求治理 authority、共享 runtime policy、同一大文件或同一状态机的修改，应先由主代理或一个子代理形成基线，其他子代理基于基线继续。
 - 任务要按成功率分层：调查、工具增强、业务修复、验证、PR review、上线 closeout 可以并行，但“修同一个根因的两套实现”通常不应并行。
 - 主代理需要持续调度，而不是把多个子任务排队串行执行。用户明确要求并行且任务在不同 worktree 时，应同时派发能并行的子任务，并通过 issue/PR 状态汇总。
+- 主代理必须维护可安全并发窗口：
+  - 从原始任务建立依赖图，区分串行定锚、已就绪任务和等待依赖任务；
+  - 每次定锚完成、子代理终态或依赖变化后重新计算已就绪集合，并立即补派低耦合任务；
+  - 并发目标是 `min(已就绪独立任务数, 可用执行槽, 运行面安全容量)`，不硬编码固定数量；
+  - 当两个及以上任务已就绪却长期只有一个活跃子代理时，必须视为调度缺口并补派，不能把主代理活动计入子代理并发；
+  - 只有具名依赖、共享文件冲突、权限或运行面容量阻塞时才降低并发，并把原因和下一次重算触发点写入主线 anchor。
+- 并发不能靠重复调查、同根因的多套实现、无独立验收价值的日志采集或默认审核代理虚增；每条并发线都必须有独立 issue、worktree、交付物和验收入口。
 - 派发 CI/CD 或运行面调优子任务时，主代理不要在 prompt 或评论里反复解释历史；用 issue/comment 链接引用既有结论，把下一步限定为可由子代理自主真实触发的单步 gate，并要求子代理在该 gate 内小闭环调优到通过后再提交 PR。
 
 ## 模型与思考等级
@@ -86,8 +93,9 @@ Prompt 至少包含以下字段，按任务裁剪：
 1. 建立计划：列出可并行任务、串行依赖和每个子代理交付物。
 2. 为每个执行型子代理先创建子 issue，把任务正文写进子 issue。
 3. 使用 `$mdtodo-edit` 把子 issue 登记到泛化问题域 ITEM/SUBITEM 并标记进行中；登记失败时停止派单。
-4. 同时派发低耦合子任务；Artificer 的 `create task`、`apply` 和 `dispatch` 均只能发生在 MDTODO 登记之后；共享契约先派一个基线任务。
-5. 轮询子代理结果：子 issue comment、PR、验证摘要、阻塞。
+4. 计算当前可安全并发窗口并同时派发全部已就绪的低耦合子任务；共享契约先派一个基线任务。
+   - Artificer 的 `create task`、`apply` 和 `dispatch` 均只能发生在 MDTODO 登记之后。
+5. 轮询子代理结果：子 issue comment、PR、验证摘要、阻塞；任一任务终态或依赖变化后立即重新计算窗口并补派，不能退化为长期单任务等待。
 6. 对每个 PR 做架构 review、bounded diff、preflight 和必要本地验证。
 7. 按依赖顺序合并；合并后同步目标 worktree。
 8. 触发受控 CI/CD 或让明确授权的子代理上线；主代理核对 closeout。