feat: PM 审核 Bug 时判断根因（环境 vs 功能）并正确指派

PM 审核 test 时，对 open Bug 逐个读 title/description 判断根因：
- 环境问题（部署/DB/服务/网络）→ review_rollback 回退 deploy_test，不 confirm
- 功能问题（代码逻辑）→ confirm_bug + 派发「修复 Bug」任务给 develop
- 误报 → reject_bug

正确指派：环境问题交部署工程师，功能问题交开发工程师。

skills_library/pipelines/sdlc_general/common/bug-confirm/SKILL.md

@@ -17,9 +17,19 @@ tools: [confirm_bug, reject_bug, reopen_bug, list_bugs]
 完整流转见 `bug` 技能（open → confirmed → fixing → fixed → verified → closed）。
 
 ## 闭环触发（审核 test 交付通过时）
-审核 test 任务通过后，`list_bugs` 查**当前迭代** `status=open` 的 Bug，分类处理：
-- **零散 Bug**（单点缺陷，不影响整体）→ 逐个 `confirm_bug` 确认，然后 `create_tasks` 派发一个「修复 Bug」任务给 develop（description 列出 bug id + 标题 + 描述），让 develop 逐个修复。Bug 闭环不打断任务链。
-- **系统性缺陷**（Bug 多/严重、设计有缺陷、需求理解错、部署有问题）→ `review_rollback` 回退到 develop/deploy_test/design，不逐个 confirm。
+
+审核 test 任务通过后，`list_bugs` 查**当前迭代** `status=open` 的 Bug，**逐个读 title/description 判断根因**，再正确指派。
+
+### 第一步：判断 Bug 根因（环境问题 vs 功能问题）
+读每个 Bug 的 title/description，识别根因：
+- **环境问题**（部署/DB/服务/网络/配置导致）：title/描述含「环境未就绪」「docker 不存在」「MySQL/DB 连不上」「/healthz 000」「服务未启动」「端口冲突」「无法连接」「容器未 healthy」等
+- **功能问题**（代码/业务逻辑导致）：title/描述含「字段类型错」「金额精度错」「CRUD 逻辑错」「权限/RBAC 校验错」「接口返回错」「字段缺失」「表名不符」「计算错」「状态机流转错」等
+
+### 第二步：分类指派
+- **环境问题 → 交给部署工程师（agent.deploy_test）**：`review_rollback` 回退 deploy_test（或冒泡问题给 deploy_test 修环境），**不 confirm、不派发给 develop**——环境问题不是代码缺陷
+- **功能问题（零散）→ 交给开发工程师（agent.develop）**：逐个 `confirm_bug`（open→confirmed），再 `create_tasks` 派发一个「修复 Bug」任务给 develop（description 列出 bug id + 标题 + 描述）
+- **功能问题（系统性，Bug 多/严重/设计缺陷/需求理解错）** → `review_rollback` 回退 develop/design/requirement
+- **误报/重复/非缺陷** → `reject_bug` 驳回
 
 > ⚠️ **铁律：只处理当前迭代的 Bug**。list_bugs 已按当前迭代的 iteration_id 强制过滤，其他项目/其他迭代的 Bug 不会查到、也一律不碰（不 confirm/不修复/不关闭）。Bug 必须有 iteration_id 归属，跨迭代/跨项目乱处理是错的。
 

skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md

@@ -10,7 +10,7 @@ capability: task_capability, bug_confirm_capability
 - 项目计划、任务分配、任务验收
 - 按 design 阶段设计师的模块清单派发 develop 任务（一个模块一个任务，无依赖并行、有依赖串行 depends_on）
 - 默认自动推进项目（审核通过→自动创建后续任务→自动分解派发），无需用户指令，暂停才需指令
-- **Bug 闭环**（审核 test 通过后执行，工具见 bug-confirm 能力）：`list_bugs` 查该迭代 `status=open` 的 Bug —— 零散 Bug → 逐个 `confirm_bug` + `create_tasks` 派发一个「修复 Bug」任务给 develop（description 列出 bug id+标题+描述）；系统性缺陷 → `review_rollback` 回退 deploy_test/develop/design。审核「修复 Bug」任务通过后，`list_bugs` 查 `status=fixed` 的 Bug → 派发「复测」任务给 test。
+- **Bug 闭环**（审核 test 通过后执行，工具见 bug-confirm 能力）：`list_bugs` 查该迭代 `status=open` 的 Bug，**逐个判断根因（环境问题 vs 功能问题）并正确指派**——环境问题（部署/DB/服务/网络）→ `review_rollback` 回退 deploy_test，不 confirm；功能问题（代码逻辑）→ `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；误报 → `reject_bug`。审核「修复 Bug」任务通过后，`list_bugs` 查 `status=fixed` 的 Bug → 派发「复测」任务给 test。
 
 ## 应遵守的规范（审核/派发前先 load_skill 加载对应全文，不要凭记忆瞎写）
 - `project-directory-spec`：各阶段交付件落点路径（检查交付件是否在正确位置）