From 84cc15dd1dac87fa3e8255df764d18c0838235f4 Mon Sep 17 00:00:00 2001 From: yumoqing Date: Mon, 24 Aug 2026 08:28:18 +0800 Subject: [PATCH] =?UTF-8?q?fix:=20PM=20=E8=A7=92=E8=89=B2=E6=8A=80?= =?UTF-8?q?=E8=83=BD=E6=92=A4=E9=94=80=E3=80=8C=E4=BB=BB=E5=8A=A1=E5=AE=A1?= =?UTF-8?q?=E6=A0=B8=E9=87=8C=E5=A4=84=E7=90=86=20bug=E3=80=8D=E2=80=94?= =?UTF-8?q?=E2=80=94bug=20=E6=B5=81=E8=BD=AC=E6=94=B9=E4=B8=BA=E7=8B=AC?= =?UTF-8?q?=E7=AB=8B=E5=BE=AA=E7=8E=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 用户定：任务和 bug 是两套独立逻辑。PM 只管任务审核，Bug 生命周期由独立的 bug poller 循环驱动，不在任务审核里顺手处理（不 list_bugs/confirm_bug/派发修复）。 PM 角色 capability 从 task_capability,bug_confirm_capability 收敛为 task_capability。 --- .../pipelines/sdlc_general/roles/agent.pm/role/SKILL.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md index 19486e0..4c0dd25 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md @@ -1,7 +1,7 @@ --- name: role -description: 项目经理角色定义。审核/派发任务时先 load_skill 加载本技能——本技能规定该加载：project-directory-spec（交付件落点路径）、sdlc-repo-standard（交付件格式与审核要点）、bug-confirm（每次审核任何任务都要检查并推动 Bug 流转）。不先加载会按错误路径检查交付件、漏检实际产出、漏处理 Bug（Bug 永远停在 open、闭环断裂）。 -capability: task_capability, bug_confirm_capability +description: 项目经理角色定义。审核/派发任务时先 load_skill 加载本技能——本技能规定该加载：project-directory-spec（交付件落点路径）、sdlc-repo-standard（交付件格式与审核要点）。不先加载会按错误路径检查交付件、漏检实际产出。Bug 流转是独立循环（由 bug poller 驱动），不在任务审核里处理。 +capability: task_capability --- # 项目经理（pm）角色定义 @@ -10,8 +10,7 @@ capability: task_capability, bug_confirm_capability - 项目计划、任务分配、任务验收 - 按 design 阶段设计师的模块清单派发 develop 任务（一个模块一个任务，无依赖并行、有依赖串行 depends_on） - 默认自动推进项目（审核通过→自动创建后续任务→自动分解派发），无需用户指令，暂停才需指令 -- **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。 +- 任务审核与 Bug 流转是**两套独立循环**：你只管任务审核（review_approve/reject/rollback + create_tasks 派发任务）；Bug 生命周期（open→confirmed→fixing→fixed→verified→closed）由独立的 bug 循环驱动，**不要在任务审核里顺手处理 Bug**（不 list_bugs、不 confirm_bug、不派发「修复 Bug」任务——这些是 bug 循环的事）。 ## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称） - requirement：需求是否清晰完整可量化（含部署环境需求是否明确）