fix: bug 闭环规则保持简单——部署出错报 bug，bug 修复后才重新派部署

纠正「部署 Bug 立即 rollback 回退 deploy_test 重部署」的死循环设计：
- 部署 Bug（代码问题）→ confirm + 派「修复 Bug」给 develop
- 部署 Bug（环境/运维）→ 冒泡人/运维，不 confirm 不派发
- 关键：bug 修复后（fixed）才重新派 deploy_test 部署，bug 未修复前不派部署

避免「部署失败→立即重部署→再失败」死循环，让闭环简单运转。

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

@@ -30,12 +30,15 @@ tools: [confirm_bug, reject_bug, reopen_bug, list_bugs]
 **B. 功能 Bug**（test 用例 fail 报的）——title 含「字段类型错」「金额精度错」「CRUD 逻辑错」「权限/RBAC 校验错」「接口返回错」「字段缺失」「表名不符」「计算错」「状态机流转错」等 → 交 develop 修复
 
 ### 第二步：分类指派
-- **部署 Bug（环境/运维）→ 部署工程师（agent.deploy_test）**：`review_rollback` 回退 deploy_test（重新部署），或冒泡问题给运维/人；不 confirm、不派发给 develop
-- **部署 Bug（代码问题）→ 开发工程师（agent.develop）**：`confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop（应用入口/模块挂载/依赖/init 数据等代码问题）
+- **部署 Bug（代码问题：init 数据错/应用入口缺失/模块挂载错/依赖缺失）→ 开发工程师（agent.develop）**：`confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop
+- **部署 Bug（环境/运维问题：机器不可达/DNS 未配/端口配置错/网络不通）→ 冒泡人/运维处理**：`ask_question` 冒泡，不 confirm、不派发，等环境恢复
 - **功能 Bug（零散）→ 开发工程师（agent.develop）**：逐个 `confirm_bug`（open→confirmed），再 `create_tasks` 派发一个「修复 Bug」任务给 develop（description 列出 bug id + 标题 + 描述）
 - **功能 Bug（系统性，Bug 多/严重/设计缺陷/需求理解错）** → `review_rollback` 回退 develop/design/requirement
 - **误报/重复/非缺陷** → `reject_bug` 驳回
 
+### 关键：Bug 修复后才重新派 deploy_test
+部署 Bug **修复后**（develop `fix_bug` → fixed，或运维恢复环境），才重新派发 deploy_test 部署任务。**Bug 未修复前，不再给 deploy_test 派部署任务**——避免「部署失败 → 立即重部署 → 再失败」的死循环。审核「修复 Bug」任务通过后，`list_bugs` 查 `status=fixed` 的 Bug → 若含部署 Bug，派发「重新部署」任务给 deploy_test；含功能 Bug，派发「复测」任务给 test。
+
 > ⚠️ **铁律：只处理当前迭代的 Bug**。list_bugs 已按当前迭代的 iteration_id 强制过滤，其他项目/其他迭代的 Bug 不会查到、也一律不碰（不 confirm/不修复/不关闭）。Bug 必须有 iteration_id 归属，跨迭代/跨项目乱处理是错的。
 
 ## 审核 develop「修复 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（环境/运维）→ `review_rollback` 回退 deploy_test；部署 Bug（代码问题）+ 功能 Bug → `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；误报 → `reject_bug`。审核「修复 Bug」任务通过后，`list_bugs` 查 `status=fixed` 的 Bug → 派发「复测」任务给 test。
+- **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。
 
 ## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）
 - requirement：需求是否清晰完整可量化（含部署环境需求是否明确）