fix: PM 职责——Bug 生命周期是独立循环，每次审核都检查并推动流转

用户纠正语义：任务流转和 bug 流转是两个独立的循环，PM 要有「添加流转」
的能力。之前写「审核 test 通过后执行 Bug 闭环」太窄，改为「每次审核任何
任务都检查当前迭代 Bug 状态并主动推动流转」。

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 vs 功能 Bug）并正确指派**——部署 Bug（代码问题）+ 功能 Bug → `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；部署 Bug（环境/运维）→ 冒泡人/运维；误报 → `reject_bug`。**Bug 修复后才重新派 deploy_test 部署**（Bug 未修复前不派部署任务，避免「部署失败→立即重部署→再失败」死循环）。审核「修复 Bug」任务通过后，查 `status=fixed` 的 Bug → 含部署 Bug 派「重新部署」给 deploy_test，含功能 Bug 派「复测」给 test。
+- **Bug 生命周期流转（独立循环，工具见 bug-confirm 能力）**：Bug 是**独立于任务链的第二条循环**（open → confirmed → fixing → fixed → verified → closed），你有「添加流转」的能力——**每次审核任何任务时都要检查当前迭代 Bug 状态并主动推动流转**，不只审核 test 时：`list_bugs` 查该迭代 open Bug，**逐个判断根因（部署 Bug vs 功能 Bug）并正确指派**——功能 Bug → `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；部署 Bug（环境/运维）→ 冒泡人/运维；误报 → `reject_bug`。**Bug 修复后才重新派 deploy_test 部署**（Bug 未修复前不派部署任务，避免「部署失败→立即重部署→再失败」死循环）。审核「修复 Bug」任务通过后，查 `status=fixed` 的 Bug → 含部署 Bug 派「重新部署」给 deploy_test，含功能 Bug 派「复测」给 test。
 - **派发「修复 Bug」任务的 description 必须写明**：① bug 清单（id + 标题 + 根因）② **要求 develop 检查所有模块的同类问题，不能只修报出来的那一个**（同类 import 错误/同款写法缺陷往往遍布多个模块，逐一 grep 全仓排查，一次性修完，避免「修一个→部署→又暴露下一个→再回退」的死循环）③ 要求 develop 修完必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed。
 
 ## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）