feat: develop 接任务先 classify_task 判断来源 + PM 派发修复bug要求查所有代码

1. bug-fix 技能：新增 classify_task 工具到 tools，写明任务来源→bug状态机决策表
2. develop 角色技能：新增「接到任务第一步必做」——先 classify_task 判断来源，
   bug_fix/rework 任务 start_fix→fix_bug，new_dev 不走状态机
3. PM 角色技能：派发「修复 Bug」任务 description 必须要求 develop 检查所有模块
   同类问题（不能只修报出来的），并强制 start_fix+fix_bug

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

@@ -1,17 +1,25 @@
 ---
 name: bug-fix
-description: 修复 Bug 能力——start_fix/fix_bug/list_bugs 工具集（agent.develop 用）。完整状态机见 bug 技能。
+description: 修复 Bug 能力——classify_task/start_fix/fix_bug/list_bugs 工具集（agent.develop 用）。完整状态机见 bug 技能。
 capability: bug_fix_capability
-tools: [start_fix, fix_bug, list_bugs]
+tools: [classify_task, start_fix, fix_bug, list_bugs]
 ---
 
 # 修复 Bug 能力（agent.develop）
 
 ## 职责
+- `classify_task`：**接任务后第一步先调用**，判断任务来源 new_dev(新开发)/bug_fix(修复Bug)/rework(质检重做)，据此决定是否走 bug 状态机
 - `start_fix`：open/confirmed → fixing（记录处理人。open 也可直接修复——PM review_rollback 回退时不走 confirm_bug，bug 停在 open）
 - `fix_bug`：fixing → fixed（附修复说明 fix_description + fix_commit）
 - `list_bugs`：查分配给自己的 Bug
 
+## 任务来源 → bug 状态机决策（核心规则）
+| classify_task 结果 | 含义 | 是否走 bug 状态机 |
+|---|---|---|
+| `bug_fix` | PM 派发的「修复 Bug」任务 | 必须：开始 start_fix → 改代码 → 完成 fix_bug |
+| `rework` | 回退重做（修复导致上游失败的缺陷） | 必须：list_bugs 查对应 open bug → start_fix → 改代码 → fix_bug |
+| `new_dev` | 纯新开发（应用脚手架/模块开发） | 不必；但过程中自己 report 的新 bug 若修了也要 fix_bug |
+
 ## 状态机
 完整流转见 `bug` 技能（open → confirmed → fixing → fixed → verified → closed）。
 修复/回退重做任务里，修完代码必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed，不能只交代码。

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

@@ -6,6 +6,13 @@ capability: feature_dev_capability, bug_fix_capability
 
 # 开发工程师（develop）角色定义
 
+## 接到任务第一步（必做）
+- **先调用 `classify_task` 判断任务来源**（new_dev / bug_fix / rework），再决定后续动作：
+  - `bug_fix`（PM 派发的「修复 Bug」任务）：任务开始先 `list_bugs` 定位 bug → `start_fix` 标记修复中 → 改代码 → 完成时 `fix_bug` 标记 fixed
+  - `rework`（回退重做任务）：修缺陷前 `list_bugs` 查当前迭代 open bug，找出本次要修的 → `start_fix` → 改代码 → `fix_bug`
+  - `new_dev`（纯新开发）：正常开发，不走 bug 状态机
+- **不判断来源直接闷头改代码，是导致 bug 永远 open、PM 派不出重新部署、任务链断的根因**——修复代码和推进 bug 状态是一体的。
+
 ## 职责
 
 ### 应用级 develop（design 自动派生的「应用架构」任务）

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

@@ -11,6 +11,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」任务的 description 必须写明**：① bug 清单（id + 标题 + 根因）② **要求 develop 检查所有模块的同类问题，不能只修报出来的那一个**（同类 import 错误/同款写法缺陷往往遍布多个模块，逐一 grep 全仓排查，一次性修完，避免「修一个→部署→又暴露下一个→再回退」的死循环）③ 要求 develop 修完必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed。
 
 ## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）
 - requirement：需求是否清晰完整可量化（含部署环境需求是否明确）