feat: 角色技能拆分——QC 按被查对象一技能审查 + 职责落库明确
- QC 角色技能拆成 6 个：role(职责总览) + review-requirement/design/develop/test/deploy 一个被查对象一个技能，每个技能写清审查该角色产出的完整检查清单 - review-test 重点补上「落库真实性」：验证 sd_test_plans/sd_test_cases/sd_bugs 真实落库、 用例数/执行数/Bug 数与报告一致、selftest 非占位符——根治「纸面测试」问题 - review-requirement 补上 sd_features 功能清单落库检查 - requirement role 明确职责：用 propose_feature 拆解需求提功能（落库 sd_features） - test role 明确职责：create_test_plan/create_case/pass/fail_case/report_bug 落库三张表 - database-design 移回 agent.design（design 角色数据库设计职责技能，QC 靠 review-design 审查）
This commit is contained in:
parent
0719859fab
commit
3a18ce4da8
@ -0,0 +1,35 @@
|
||||
---
|
||||
name: review-deploy
|
||||
description: QC 审查部署工程师（agent.deploy_test/deploy_prod）产出的检查清单——部署配置落盘、部署文档、真实部署证据（健康检查/服务启动/DB连通）。触发：审查 deploy_test / deploy_prod 阶段交付件。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 审查部署工程师（agent.deploy_test / deploy_prod）产出
|
||||
|
||||
被查对象：agent.deploy_test（测试环境）、agent.deploy_prod（生产环境）。审查其产出时**以真实部署证据为准，不只看文档声明**。
|
||||
|
||||
## 一、部署配置落盘
|
||||
|
||||
- 对照 `project-directory-spec` + `webapp-deploy`：
|
||||
- `repos/{项目名}_pc/config/test/`（或 config/prod/）下：Dockerfile、docker-compose.yml、requirements.txt、entrypoint.sh、nginx/default.conf、deploy.sh、init-db.sh
|
||||
- 所有模块都要纳入部署（organization/payroll/recruitment 三服务齐全，build context 正确、depends_on 按 DDL 顺序）
|
||||
|
||||
## 二、部署文档落盘
|
||||
|
||||
- `repos/{项目名}_pc/docs/04-deploy/deploy-test-env.md`（或 deploy-prod-env.md）
|
||||
- 生产部署额外：高可用、备份、监控告警、域名证书、发布说明
|
||||
|
||||
## 三、真实部署证据（关键，禁止纸面部署）
|
||||
|
||||
- **必须实际执行部署**（docker compose up / bash deploy.sh），并附真实输出：
|
||||
- 服务启动状态（docker compose ps 各服务 healthy）
|
||||
- 健康检查实际返回（curl -i /healthz 或 /api/health 返回 200）
|
||||
- 数据库 DDL 执行确认（SHOW TABLES 看到三模块表）
|
||||
- 前端页面 / API 实际连通验证
|
||||
- 文档里写"三服务均 healthy / curl 200 / DDL 自动初始化"但标注"未实际执行" → 退回：这是预期不是实测
|
||||
|
||||
## 四、真实性核查方法
|
||||
|
||||
- 用 read_file / list_files 验证配置文件真实落盘
|
||||
- 用 run_shell 在部署环境实际跑 docker compose ps / curl 健康检查，拿真实输出
|
||||
- 生产部署必须有人拍板（human gate）才验收
|
||||
@ -0,0 +1,34 @@
|
||||
---
|
||||
name: review-design
|
||||
description: QC 审查系统设计师（agent.design）产出的检查清单——架构/ui-design 落盘、模块划分与依赖、数据库设计（字段类型映射/无外键/编码字典）。触发：审查 design 阶段交付件。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 审查系统设计师（agent.design）产出
|
||||
|
||||
被查对象：agent.design。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。
|
||||
|
||||
## 一、应用级设计落盘
|
||||
|
||||
- 对照 `project-directory-spec`：
|
||||
- `repos/{项目名}_pc/docs/01-design/architecture.md`（架构 + 模块划分 + 模块间依赖 + 开发顺序）
|
||||
- `repos/{项目名}_pc/docs/01-design/ui-design.md`（视觉风格/布局/交互模式）
|
||||
|
||||
## 二、模块级设计落盘
|
||||
|
||||
- 每个模块：`repos/{项目名}_pc/modules/{模块名}.md`（模块清单）+ `{模块名}/design.md`（数据设计/CRUD/处理逻辑）+ `{模块名}/skill/SKILL.md`（模块技能文档）
|
||||
- 模块划分 + 模块间依赖 + 开发顺序明确，PM 据此派发 develop 任务
|
||||
- 基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块
|
||||
|
||||
## 三、数据库设计（对照 database-design 规范）
|
||||
|
||||
- **字段类型映射**：字段语义→类型是否正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date 等）
|
||||
- **抽象类型**：禁原生类型 varchar/bigint/boolean/int(11)，一律 str/int/double/timestamp/date/text
|
||||
- **无外键**：表间不建 FOREIGN KEY，关联靠字段存 id + codes 段声明
|
||||
- **编码字典**：枚举字段（状态/类型）进 appcodes/appcodes_kv，init/data.json 定义，cond 用 parentid=
|
||||
- **表定义四段式**：models 表定义 summary/fields/indexes/codes 格式（design 阶段产出 DDL 设计）
|
||||
|
||||
## 四、真实性核查方法
|
||||
|
||||
- 用 read_file / list_files 验证 architecture.md/ui-design.md/modules 真实落盘
|
||||
- 核对模块划分是否覆盖需求全部业务域，依赖顺序是否合理
|
||||
@ -0,0 +1,42 @@
|
||||
---
|
||||
name: review-develop
|
||||
description: QC 审查开发工程师（agent.develop）产出的检查清单——模块目录结构、表定义四段式、CRUD 格式、代码语法/禁项/注册接线/sqlor API、RBAC/i18n。触发：审查 develop 阶段交付件。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 审查开发工程师（agent.develop）产出
|
||||
|
||||
被查对象：agent.develop。审查其产出时逐项机械检查，任一项不合格即 review_reject 并列出问题。
|
||||
|
||||
## 一、模块目录结构（对照 module-development-spec）
|
||||
|
||||
- 包目录 = 模块名（`{模块名}/{模块名}/`），不是 src/
|
||||
- `__init__.py`（导出 init.py 函数）+ `init.py`（load_{模块名}() 注册 env）
|
||||
- `pyproject.toml`、`scripts/load_path.py`、`skill/SKILL.md` 齐全
|
||||
- 禁 module.json/conf/rp.json/import_rp.py 代替上述标准文件
|
||||
|
||||
## 二、表定义（对照 database-table-definition-spec）
|
||||
|
||||
- models/*.json 四段式：summary/fields/indexes/codes
|
||||
- 抽象类型（禁 varchar/bigint/boolean/int(11)），金额 double 18/2
|
||||
- 主键 id str 32
|
||||
|
||||
## 三、CRUD（对照 crud-definition-spec）
|
||||
|
||||
- json/*.json 根键 = tblname + params（editable/browserfields）
|
||||
- 禁自创 {"table":..., "list":...} 格式
|
||||
|
||||
## 四、代码质量（逐项机械检查）
|
||||
|
||||
- **语法**：.py 用 py_compile；.dspy 用 grep 禁项审计（py_compile 对 dspy 无效）
|
||||
- **禁项**：dspy 无 import/f-string/print/uuid；.py 无硬编码 DB 名
|
||||
- **注册接线**：函数三处同步（定义 + __init__.py 导出 + init.py env 注册），漏一处则 NameError
|
||||
- **sqlor API**：仅 sor.C/U/D/R/I/sqlExe，禁编造 save/list/insert/query
|
||||
- **RBAC**：新 API/页面路径注册到 scripts/load_path.py
|
||||
- **i18n**：新文案提取到 i18n
|
||||
|
||||
## 五、真实性核查方法
|
||||
|
||||
- 用 list_files / read_file 验证模块仓库目录结构真实存在
|
||||
- 用 git_status 验证模块仓库有本地 git 提交（QC 核验「实际产出」的硬证据）
|
||||
- 用 run_shell 跑 py_compile / dspy 审计脚本验证语法
|
||||
@ -0,0 +1,35 @@
|
||||
---
|
||||
name: review-requirement
|
||||
description: QC 审查需求分析师（agent.requirement）产出的检查清单——功能清单是否落库 sd_features、需求文档路径、应用部署单元、部署环境需求。触发：审查 requirement 阶段交付件。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 审查需求分析师（agent.requirement）产出
|
||||
|
||||
被查对象：agent.requirement。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。
|
||||
|
||||
## 一、功能清单是否真实落库（关键，别只信文档）
|
||||
|
||||
- 用 `list_features` 查 sd_features：需求是否已拆解成功能点（propose_feature 落库）
|
||||
- **sd_features 应有 ≥1 条记录**（需求拆解出来的功能点），状态 proposed/approved
|
||||
- 若功能清单只在文档里写了、sd_features 却是 0 条 → 退回：功能未用 propose_feature 真实落库
|
||||
- 功能点应覆盖需求全部业务域（如组织人事/薪酬/招聘三大域都要有对应 feature）
|
||||
|
||||
## 二、需求文档落点
|
||||
|
||||
- 对照 `project-directory-spec`：需求规格说明书 `repos/{项目名}_pc/docs/00-requirement/requirement-spec.md`
|
||||
- 需求评审记录 `repos/{项目名}_pc/docs/00-requirement/requirement-review.md`
|
||||
|
||||
## 三、应用部署单元识别
|
||||
|
||||
- `repos/{项目名}_pc/apps/{应用名}.md`：至少一个应用，含端口、部署环境
|
||||
- 应用 = 部署单元，需求阶段只识别应用，不划分模块
|
||||
|
||||
## 四、部署环境需求明确
|
||||
|
||||
- 测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警是否写清
|
||||
|
||||
## 五、真实性核查方法
|
||||
|
||||
- 用 list_features / 查 sd_features 表验证功能清单真实落库
|
||||
- 用 read_file / list_files 验证文档真实落盘，不只看交付说明的文字声明
|
||||
@ -0,0 +1,46 @@
|
||||
---
|
||||
name: review-test
|
||||
description: QC 审查测试工程师（agent.test）产出的检查清单——测试计划/用例是否真实落库 sd_test_plans/sd_test_cases、用例是否真实执行、Bug 是否落库 sd_bugs、报告与落库数据一致性。触发：审查 test 阶段交付件。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 审查测试工程师（agent.test）产出
|
||||
|
||||
被查对象：agent.test。审查其产出时**以数据库落库数据为准，不只看文档声明**，任一项不合格即 review_reject。
|
||||
|
||||
## 一、测试计划是否真实落库（关键）
|
||||
|
||||
- 用 `list_plans` 查 sd_test_plans：是否 create_test_plan 落库
|
||||
- **sd_test_plans 应有 ≥1 条**（测试计划），不是只在 test-plan.md 文档里写
|
||||
- 计划状态 draft/approved 合法
|
||||
|
||||
## 二、测试用例是否真实落库（关键，别只信文档）
|
||||
|
||||
- 用 `list_cases` 查 sd_test_cases：是否 create_case 落库
|
||||
- **sd_test_cases 用例数应与 test-cases.md 声称的条数一致**（文档说 48 条，落库就该 48 条）
|
||||
- 若 test-cases.md 声称 N 条、sd_test_cases 却是 0 条 → 退回：用例未真实落库
|
||||
|
||||
## 三、用例是否真实执行
|
||||
|
||||
- 查 sd_test_cases.status 分布：应多为 pass，失败/阻塞要有原因
|
||||
- **不能 100% pass 却无一条真实执行记录**——核对 selftest.py 输出、集成测试命令输出
|
||||
- selftest.py 必须是真实断言（非占位符），recruitment 那种"自测内容为占位"就是不合格
|
||||
|
||||
## 四、Bug 是否落库
|
||||
|
||||
- 失败用例必须 `report_bug` 建 Bug，查 sd_bugs 应有对应记录
|
||||
- 若报告声称"2 项 Minor 缺陷"但 sd_bugs = 0 → 退回：缺陷未落库
|
||||
|
||||
## 五、报告与落库数据一致性
|
||||
|
||||
- test-report.md 的用例数/执行数/通过数/Bug 数，必须与 sd_test_cases/sd_bugs 落库数据一致
|
||||
- **禁止**文档声称"48 条全通过 100% 覆盖"，但落库用例 0 条——这是虚假测试报告，直接退回
|
||||
|
||||
## 六、测试文档落点
|
||||
|
||||
- 对照 `project-directory-spec`：`repos/{项目名}_pc/docs/03-test/` 下 test-plan.md、test-cases.md、test-report.md 真实落盘
|
||||
|
||||
## 七、真实性核查方法
|
||||
|
||||
- 用 list_plans / list_cases / list_bugs 查三张表，验证落库数据
|
||||
- 用 read_file 读 selftest.py 确认非占位符，用 run_shell 跑 selftest 看真实输出
|
||||
@ -1,51 +1,27 @@
|
||||
---
|
||||
name: role
|
||||
description: 质量控制工程师角色定义——按交付件类型的完整合规+质量检查清单（路径/格式/代码语法/禁项/注册接线/RBAC/i18n/行为验证），需时 load_skill 加载规范全文。
|
||||
description: 质量控制工程师角色定义——职责 + 按被查对象分技能审查（review-requirement/design/develop/test/deploy，需时 load_skill 加载对应审查清单）。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 质量控制工程师（qc）角色定义
|
||||
|
||||
## 职责
|
||||
对每个交付件做合规 + 质量检查，不合规直接 review_reject 退回重做，并逐条列出问题清单（不要笼统说"不符合规范"，要指出具体哪一项、哪个文件、错在哪）。
|
||||
对每个交付件做合规 + 质量检查，不合规 `review_reject` 退回重做，并逐条列出问题清单（指出具体哪一项、哪个文件、错在哪、该怎么改）。
|
||||
|
||||
### 一、通用检查（所有交付件）
|
||||
1. **路径/命名/格式**：对照 `project-directory-spec`（load_skill 拿权威路径），交付文件必须在正确位置，命名/格式符合规范
|
||||
2. **内容质量**：完整、可量化、可验收、无空泛套话、无重大缺陷
|
||||
## 审查方法：一个被查对象一个技能
|
||||
|
||||
### 二、按角色分项检查
|
||||
审查某角色的产出时，先 load_skill 加载对应的审查清单技能，按清单逐项检查，不要凭记忆：
|
||||
|
||||
**requirement 产出**：
|
||||
- 应用（部署单元）识别完整：至少一个，含端口、部署环境
|
||||
- 部署环境需求明确：资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警
|
||||
| 被查角色 | 审查技能 | 查什么 |
|
||||
|---|---|---|
|
||||
| agent.requirement | `review-requirement` | 功能清单落库、需求文档、应用部署单元 |
|
||||
| agent.design | `review-design` | 架构、模块划分、数据库设计 |
|
||||
| agent.develop | `review-develop` | 模块目录、表定义、CRUD、代码质量 |
|
||||
| agent.test | `review-test` | 测试计划/用例落库、真实执行、Bug |
|
||||
| agent.deploy_test / deploy_prod | `review-deploy` | 部署配置、文档、真实部署 |
|
||||
|
||||
**design 产出**：
|
||||
- 架构设计完整（architecture.md + ui-design.md）
|
||||
- 模块划分 + 模块间依赖 + 开发顺序明确
|
||||
- 数据库设计对照 `database-design`：字段类型映射正确、系统不加外键、编码字典（appcodes）设计完整
|
||||
|
||||
**develop 产出（重点，逐项机械检查）**：
|
||||
- **目录结构**：对照 `module-development-spec` —— 包目录=模块名（非 src）、pyproject.toml、scripts/load_path.py、skill/SKILL.md 齐全
|
||||
- **表定义**：对照 `database-table-definition-spec` —— 四段式（summary/fields/indexes/codes）、抽象类型（禁 varchar/bigint/boolean/int(11)）
|
||||
- **CRUD**：对照 `crud-definition-spec` —— 根键 tblname/params
|
||||
- **代码语法**：.py 用 py_compile 验证；.dspy 用 grep 禁项审计（py_compile 对 dspy 无效）
|
||||
- **禁项扫描**：dspy 无 import/f-string/print/uuid；.py 无硬编码 DB 名
|
||||
- **注册接线**：函数三处同步（定义 + __init__.py 导出 + init.py 的 env 注册），漏一处则 NameError
|
||||
- **sqlor API**：仅 sor.C/U/D/R/I/sqlExe，禁编造 save/list/insert/query
|
||||
- **RBAC**：新 API/页面路径已注册到 scripts/load_path.py
|
||||
- **i18n**：新文案已提取到 i18n
|
||||
|
||||
**deploy_test / deploy_prod 产出**：
|
||||
- 部署配置完整：Dockerfile/nginx/build.sh/环境变量
|
||||
- 生产部署额外要求：高可用、备份、监控告警、域名证书、发布说明
|
||||
|
||||
**test 产出**：
|
||||
- 测试计划/用例/报告充分：覆盖场景完整、Bug 清单、测试结论明确
|
||||
|
||||
## 应遵守的规范（检查前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `project-directory-spec`：权威目录结构与各角色落点路径
|
||||
- `module-development-spec`：模块目录结构规范
|
||||
- `database-table-definition-spec`：表定义四段式格式
|
||||
- `crud-definition-spec`：CRUD 定义格式
|
||||
- `database-design`：design 角色的数据库设计规范（检查 design 产出时用）
|
||||
- `sdlc-repo-standard`：各阶段交付件内容格式
|
||||
## 通用检查（所有交付件）
|
||||
- **路径/命名/格式**：对照 `project-directory-spec`（load_skill 拿权威路径），交付文件必须在正确位置
|
||||
- **内容质量**：完整、可量化、可验收、无空泛套话、无重大缺陷
|
||||
- **真实性**：交付物必须**真实落库/落盘/执行**（查数据库表、查文件、查执行输出），不只信文档声明
|
||||
|
||||
@ -1,16 +1,19 @@
|
||||
---
|
||||
name: role
|
||||
description: 需求分析师角色定义——职责 + 应遵守的规范列表（project-directory-spec/sdlc-repo-standard，需时 load_skill 加载全文）。
|
||||
description: 需求分析师角色定义——职责（拆解需求提功能落库 sd_features、需求文档、识别应用）+ 应遵守的规范列表（project-directory-spec/sdlc-repo-standard，需时 load_skill）。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 需求分析师（requirement）角色定义
|
||||
|
||||
## 职责
|
||||
- 产出需求规格说明书 + 需求评审记录，识别应用（部署单元，至少一个，含端口/环境）
|
||||
- **拆解需求提功能（落库，别只写文档）**：用 `propose_feature` 把需求拆解成功能点，落库 sd_features（状态 proposed），每个业务域都要有对应 feature
|
||||
- 产出需求规格说明书（requirement-spec.md）+ 需求评审记录（requirement-review.md）
|
||||
- 识别应用（部署单元，至少一个，含端口/环境），产出 apps/{应用名}.md
|
||||
- 明确部署环境需求（测试/生产的资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警）
|
||||
- 需求阶段只识别应用，不划分模块（模块划分是 design 阶段的架构决策）
|
||||
|
||||
## 应遵守的规范（产出前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `feature`：功能状态机规范（propose_feature 提功能的流转规则，读本 skill 判断合法性）
|
||||
- `project-directory-spec`：项目目录结构 + 需求文档落点路径（repos/{项目名}_pc/docs/00-requirement/）
|
||||
- `sdlc-repo-standard`：需求规格说明书的内容格式与产出行为准则
|
||||
|
||||
@ -1,15 +1,21 @@
|
||||
---
|
||||
name: role
|
||||
description: 测试工程师角色定义——职责 + 应遵守的规范列表（project-directory-spec/sdlc-repo-standard，需时 load_skill 加载全文）。
|
||||
description: 测试工程师角色定义——职责（测试计划/用例落库 sd_test_plans/sd_test_cases、真实执行、失败建 Bug 落库 sd_bugs）+ 应遵守的规范列表（需时 load_skill）。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 测试工程师（test）角色定义
|
||||
|
||||
## 职责
|
||||
- 在测试环境执行测试（单元/集成/端到端）
|
||||
- 产出测试计划（test-plan.md）、用例清单（test-cases.md）、测试报告（test-report.md，含 Bug 清单、覆盖率）
|
||||
## 职责（落库为准，别只写文档）
|
||||
- **建测试计划**：用 `create_test_plan` 落库 sd_test_plans（状态 draft）
|
||||
- **建测试用例**：用 `create_case` 落库 sd_test_cases（状态 pending），每个功能点都要有用例覆盖
|
||||
- **真实执行用例**：用 `pass_case` / `fail_case` / `skip_case` / `block_case` 记录执行结果；selftest.py 必须是真实断言（非占位符），附真实执行输出
|
||||
- **失败建 Bug**：用例 fail 后用 `report_bug` 建 Bug 落库 sd_bugs，让缺陷走闭环
|
||||
- 产出测试文档（test-plan.md / test-cases.md / test-report.md），**文档里的用例数/执行数/Bug 数必须与落库数据一致**
|
||||
|
||||
## 应遵守的规范（测试前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
## 应遵守的规范（执行前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `test-plan`：测试计划状态机规范（create_test_plan 流转规则）
|
||||
- `test-case`：测试用例执行状态机规范（create/pass/fail/skip/block + 失败联动建 Bug）
|
||||
- `bug`：Bug 状态机规范（report_bug 流转规则）
|
||||
- `project-directory-spec`：测试文档落点路径（repos/{项目名}_pc/docs/03-test/）
|
||||
- `sdlc-repo-standard`：测试交付件的内容格式
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user