feat: 部署失败也报 Bug，PM 统一分析根因指派
bug 闭环从「只覆盖功能 bug」扩展为「覆盖所有失败」： - 新增 bug-report 能力（bug_report_capability: report_bug+list_bugs）， deploy_test 部署失败时 report_bug 报部署 Bug（不含 verify/close，避免越权） - deploy_test 角色技能：capability 加 bug_report_capability，部署失败 → report_bug 报 Bug 让 PM 分析 - test 角色技能：冒烟失败也从「不 report_bug」改为 report_bug 报部署 Bug - PM bug-confirm 能力：判断根因细分「部署 Bug（环境/运维→deploy_test，代码→develop）vs 功能 Bug（develop）」 - PM 角色技能：同步 bug 闭环职责 统一原则：任何失败都 report_bug 进 sd_bugs，PM 是唯一分析+指派点。
This commit is contained in:
parent
19bffb4465
commit
e945873fdd
@ -20,15 +20,20 @@ tools: [confirm_bug, reject_bug, reopen_bug, list_bugs]
|
||||
|
||||
审核 test 任务通过后，`list_bugs` 查**当前迭代** `status=open` 的 Bug，**逐个读 title/description 判断根因**，再正确指派。
|
||||
|
||||
### 第一步：判断 Bug 根因（环境问题 vs 功能问题）
|
||||
读每个 Bug 的 title/description，识别根因：
|
||||
- **环境问题**（部署/DB/服务/网络/配置导致）：title/描述含「环境未就绪」「docker 不存在」「MySQL/DB 连不上」「/healthz 000」「服务未启动」「端口冲突」「无法连接」「容器未 healthy」等
|
||||
- **功能问题**（代码/业务逻辑导致）：title/描述含「字段类型错」「金额精度错」「CRUD 逻辑错」「权限/RBAC 校验错」「接口返回错」「字段缺失」「表名不符」「计算错」「状态机流转错」等
|
||||
### 第一步：判断 Bug 根因（部署 Bug vs 功能 Bug）
|
||||
读每个 Bug 的 title/description，识别根因类型：
|
||||
|
||||
**A. 部署 Bug**（deploy_test 部署失败 或 test 冒烟失败报的）——title 含「部署失败」「部署未就绪」「/healthz 000」「端口不可达」「SSH 连不上」「build 失败」「进程起不来」等，再细分根因：
|
||||
- **环境/运维问题**：机器不可达、DNS 未配、网络不通、端口被占用、DB 连不上、磁盘/权限不足 → 交 deploy_test 重部署，或冒泡人/运维处理
|
||||
- **代码问题**：应用入口缺失、模块挂载错、依赖缺失、init 数据错（JSON 解析失败）、表结构错 → 交 develop 修复
|
||||
|
||||
**B. 功能 Bug**（test 用例 fail 报的）——title 含「字段类型错」「金额精度错」「CRUD 逻辑错」「权限/RBAC 校验错」「接口返回错」「字段缺失」「表名不符」「计算错」「状态机流转错」等 → 交 develop 修复
|
||||
|
||||
### 第二步：分类指派
|
||||
- **环境问题 → 交给部署工程师（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
|
||||
- **部署 Bug（环境/运维）→ 部署工程师（agent.deploy_test）**：`review_rollback` 回退 deploy_test（重新部署），或冒泡问题给运维/人；不 confirm、不派发给 develop
|
||||
- **部署 Bug（代码问题）→ 开发工程师（agent.develop）**：`confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop（应用入口/模块挂载/依赖/init 数据等代码问题）
|
||||
- **功能 Bug（零散）→ 开发工程师（agent.develop）**：逐个 `confirm_bug`（open→confirmed），再 `create_tasks` 派发一个「修复 Bug」任务给 develop（description 列出 bug id + 标题 + 描述）
|
||||
- **功能 Bug（系统性，Bug 多/严重/设计缺陷/需求理解错）** → `review_rollback` 回退 develop/design/requirement
|
||||
- **误报/重复/非缺陷** → `reject_bug` 驳回
|
||||
|
||||
> ⚠️ **铁律：只处理当前迭代的 Bug**。list_bugs 已按当前迭代的 iteration_id 强制过滤，其他项目/其他迭代的 Bug 不会查到、也一律不碰（不 confirm/不修复/不关闭）。Bug 必须有 iteration_id 归属，跨迭代/跨项目乱处理是错的。
|
||||
|
||||
@ -0,0 +1,25 @@
|
||||
---
|
||||
name: bug-report
|
||||
description: 上报 Bug 能力——report_bug/list_bugs 工具集（agent.deploy_test/deploy_prod 等部署角色用）。部署失败时据此报 Bug，让 PM 分析由谁处理。完整状态机见 bug 技能。
|
||||
capability: bug_report_capability
|
||||
tools: [report_bug, list_bugs]
|
||||
---
|
||||
|
||||
# 上报 Bug 能力（部署角色：agent.deploy_test / agent.deploy_prod）
|
||||
|
||||
## 职责
|
||||
- `report_bug`：部署失败时上报 Bug，落库 sd_bugs（status=open），title/description 写清失败现象 + 根因线索
|
||||
- `list_bugs`：查自己上报的 Bug 清单（可按 status 过滤）
|
||||
|
||||
## 状态机
|
||||
完整流转见 `bug` 技能（open → confirmed → fixing → fixed → verified → closed）。
|
||||
|
||||
## 部署失败报 Bug 规则
|
||||
部署后验证失败（/healthz 000、端口不可达、SSH 连不上、build 失败、DB 连不上、进程起不来）时：
|
||||
1. 先如实记录真实错误输出（不编造「部署成功」）
|
||||
2. 用 `report_bug` 报一个部署 Bug，title 写「部署失败：{具体现象}」，description 写清失败现象 + 已排查的根因线索（环境/代码/运维）
|
||||
3. 同时 `ask_question` 冒泡问题，让 PM 分析 Bug 由谁处理
|
||||
|
||||
PM 分析部署 Bug 根因后指派：环境问题 → deploy_test 重新部署；代码问题（应用入口缺失/模块挂载错/依赖缺失/init 数据错）→ develop 修复；运维问题（机器不可达/DNS/网络）→ 冒泡人处理。
|
||||
|
||||
> ⚠️ 铁律：只处理当前迭代的 Bug。本能力只负责「上报」，不负责 verify/close（那是 agent.test 的职责）。
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
name: role
|
||||
description: 测试环境部署工程师角色定义。接到部署任务时先 load_skill 加载本技能——本技能规定：部署环境从 env/test.json 读（不写死）、部署前清理旧进程只留 1 个应用进程、应用唯一入口一端口（模块不独立起服务）。不先加载会按写死环境或按模块多进程部署出错。
|
||||
capability: deploy_capability
|
||||
description: 测试环境部署工程师角色定义。接到部署任务时先 load_skill 加载本技能——本技能规定：部署环境从 env/test.json 读（不写死）、部署前清理旧进程只留 1 个应用进程、应用唯一入口一端口（模块不独立起服务）、部署失败 report_bug 报 Bug 让 PM 分析。不先加载会按写死环境或按模块多进程部署出错。
|
||||
capability: deploy_capability, bug_report_capability
|
||||
---
|
||||
|
||||
# 测试环境部署工程师（deploy_test）角色定义
|
||||
@ -31,7 +31,7 @@ capability: deploy_capability
|
||||
|
||||
### 三、部署后验证（硬门禁，附真实输出，不是预期声明）
|
||||
- **健康检查是硬门禁**：`curl -s -o /dev/null -w "%{http_code}" http://{主域名}:{端口}/healthz` **必须实测返回 200**，应用才算部署成功。返回 000 / 超时 / 连接拒绝 / 非 200 一律算部署失败。
|
||||
- **部署失败必须如实记录并冒泡**：/healthz 000、端口不可达、SSH 连不上、进程没起来 → 如实粘贴真实错误输出，**用 ask_question 冒泡问题给 PM/运维，绝不编造「返回 200」「部署成功」**。编造成功会导致 test 冒烟失败 → 反复回退死循环，是严重违规。
|
||||
- **部署失败必须如实记录 + report_bug 报 Bug**：/healthz 000、端口不可达、SSH 连不上、进程没起来 → 如实粘贴真实错误输出，用 `report_bug` 报一个部署 Bug（title 写「部署失败：{现象}」，description 写清失败现象 + 根因线索），让 PM 分析由谁处理（环境问题→重部署，代码问题→develop，运维问题→人），同时 `ask_question` 冒泡。**绝不编造「返回 200」「部署成功」**——编造会导致 test 冒烟失败 → 反复回退死循环，是严重违规。
|
||||
- **检查进程**：`ps -ef | grep {应用名}.py` 只有 1 个应用进程在跑（不是多模块多进程）
|
||||
- **DB 连通**：`mysql ... "SHOW TABLES"` 看到各模块表
|
||||
- **三项（/healthz 200 + 单进程 + DB 表）全部真实通过才交付**；任何一项失败，如实记录 + 冒泡，不 approved。
|
||||
|
||||
@ -10,7 +10,7 @@ capability: task_capability, bug_confirm_capability
|
||||
- 项目计划、任务分配、任务验收
|
||||
- 按 design 阶段设计师的模块清单派发 develop 任务（一个模块一个任务，无依赖并行、有依赖串行 depends_on）
|
||||
- 默认自动推进项目（审核通过→自动创建后续任务→自动分解派发），无需用户指令，暂停才需指令
|
||||
- **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。
|
||||
- **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。
|
||||
|
||||
## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）
|
||||
- requirement：需求是否清晰完整可量化（含部署环境需求是否明确）
|
||||
|
||||
@ -13,8 +13,8 @@ capability: test_plan_capability, test_case_capability, bug_test_capability
|
||||
### 一、冒烟测试（验证系统部署是否正常）
|
||||
- 测什么：/healthz 返回 200、应用端口监听、数据库连通、服务 healthy、应用进程数（单应用单进程）
|
||||
- 目的：确认部署正常，功能测试才能开始
|
||||
- **部署不正常 → 问题交给部署工程师（agent.deploy_test）**：不 report_bug、不硬测、不凭空写"通过"，用问题冒泡（提问题/ask_question）交给 deploy_test 修复，等部署正常后再测
|
||||
- 冒烟失败是部署问题，**不是功能 Bug**，不建 Bug、不落 sd_bugs
|
||||
- **部署不正常 → `report_bug` 报一个部署 Bug**（title「部署失败：{现象}」，description 写清冒烟失败现象 + 是部署/环境根因），让 PM 分析由谁处理（环境问题→deploy_test，代码问题→develop），同时用问题冒泡（提问题/ask_question）交给 deploy_test 修复，等部署正常后再测
|
||||
- 冒烟失败是部署问题，报 Bug 时 description 明确写「部署/环境根因，非功能缺陷」，PM 会据此指派给 deploy_test 而非 develop
|
||||
|
||||
### 二、用例测试（验证系统功能是否正常）
|
||||
- 测什么：design 的每个功能点——CRUD、业务接口、RBAC、数据契约、i18n
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user