feat: Agentic QE Fleet v2.0.0 - 14-agent quality engineering platform
- 14 specialized AI agents across 5 battle zones (Prepare/Analyze/Design/Review/Monitor) - New: risk-assessor, test-strategist, data-builder, coverage-auditor, quality-gatekeeper, execution-analyst, knowledge-curator - New: fleet_runner.py orchestrator with multi-zone manifest pipeline - New: fleet_config.yml for centralized configuration - New: knowledge activation system (keyword + semantic matching) - New: semantic conflict detection with severity grading (P0-P3) - New: three-tier quality gate (PASS/PASS_WITH_FIX/BLOCKED) - New: monitor zone for test execution analysis and auto knowledge curation - Backward compatible: /case_generate alias, case_pipeline.py preserved - Comprehensive docs: USER_GUIDE.md + MAINTENANCE_GUIDE.md
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
# 子需求冲突确认说明
|
||||
|
||||
这个目录用于沉淀“已有需求继续迭代、子需求补充、规则替代、并行生效”这类场景下的人为确认结论。
|
||||
|
||||
## 为什么需要这个目录
|
||||
|
||||
当前流水线已经能自动做这些事:
|
||||
|
||||
- 识别历史相似需求
|
||||
- 识别部分规则冲突候选
|
||||
- 生成 `output/analysis/{BASE_NAME}_关联与冲突.md`
|
||||
|
||||
但当前流水线还不会自动做这些事:
|
||||
|
||||
- 自动裁决新旧需求到底是“补充 / 替代 / 并行”
|
||||
- 自动回写旧需求和新需求的版本边界
|
||||
- 自动根据确认结论重跑全部受影响需求
|
||||
|
||||
所以,涉及跨需求冲突时,必须把最终业务结论沉淀成文件,而不是只停留在聊天记录或口头确认。
|
||||
|
||||
## 建议使用方式
|
||||
|
||||
1. 新子需求先按正常流程进入 `source_docs/requirements_raw/`
|
||||
2. 运行 `/case_generate ...` 或 `prepare`
|
||||
3. 查看 `output/analysis/{BASE_NAME}_关联与冲突.md`
|
||||
4. 如果存在冲突候选、高风险规则或 `> ⚠️ 待确认`,新增一份确认单
|
||||
5. 确认结论写清后,执行:
|
||||
- `python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径>`
|
||||
6. 重跑完成后,正式维护版 Markdown 会同步到 `requirements/{BASE_NAME}.md`
|
||||
|
||||
## 建议命名
|
||||
|
||||
推荐命名:
|
||||
|
||||
- `decisions/{BASE_NAME}_确认结论.md`
|
||||
- `decisions/{BASE_NAME}_v2_确认结论.md`
|
||||
|
||||
如果一个子需求关联多个旧需求,也可以用主题名而不是单个需求名:
|
||||
|
||||
- `decisions/member_coupon_rule_merge_确认结论.md`
|
||||
|
||||
## 当前状态与目标状态
|
||||
|
||||
当前状态:
|
||||
|
||||
- 确认单是人工维护资产
|
||||
- `prepare` 会把确认门禁写进 manifest
|
||||
- `verify` 和 `export` 会在确认单未写明 `确认状态:已确认` 时阻断
|
||||
- 是否继续重跑,仍然由人工触发
|
||||
- 触发后可由 `apply-confirmation` 自动写维护说明并重跑确认单中的目标需求
|
||||
|
||||
目标状态:
|
||||
|
||||
- 脚本检测到冲突后自动提示进入确认阶段
|
||||
- 已确认时支持更细粒度地自动回写需求源文件,而不只是写维护说明
|
||||
|
||||
在脚本能力补齐前,这个目录的作用是让“冲突裁决”具备可追溯性。
|
||||
@@ -0,0 +1,47 @@
|
||||
# 确认结论模板
|
||||
|
||||
## 1. 基本信息
|
||||
|
||||
- 当前需求:
|
||||
- 关联历史需求:
|
||||
- 确认状态:`待确认 / 已确认 / 已驳回`
|
||||
- 确认日期:
|
||||
- 确认人:
|
||||
|
||||
## 2. 关系判定
|
||||
|
||||
- 关系类型:`补充 / 替代 / 并行`
|
||||
- 判定理由:
|
||||
|
||||
## 3. 生效边界
|
||||
|
||||
- 生效范围:
|
||||
- 失效范围:
|
||||
- 影响模块:
|
||||
- 影响角色:
|
||||
- 影响接口或数据口径:
|
||||
|
||||
## 4. 冲突点
|
||||
|
||||
| 序号 | 当前需求条目 | 历史需求条目 | 冲突类型 | 最终确认口径 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | | | | |
|
||||
|
||||
## 5. 回写要求
|
||||
|
||||
- 是否需要回写当前需求:`是 / 否`
|
||||
- 是否需要回写历史需求:`是 / 否`
|
||||
- 需要补充的版本边界:
|
||||
- 需要补充的替代/继承说明:
|
||||
- 需要补充的兼容策略:
|
||||
|
||||
## 6. 重跑计划
|
||||
|
||||
- 需要重跑的需求列表:`source_docs/requirements_raw/当前需求.docx, requirements/历史需求.md`
|
||||
- 重跑顺序建议:
|
||||
- 是否允许在确认前继续导出:`允许 / 不允许`
|
||||
|
||||
## 7. 备注
|
||||
|
||||
- 待跟进事项:
|
||||
- 风险说明:
|
||||
Reference in New Issue
Block a user