QaAutomationHub/AGENTS.md

Agentic QE Fleet（混合流水线 v3.0）

当用户在 Codex CLI 中输入以下任一意图时，必须按一条端到端流水线自动执行，不要把中间命令再抛给用户手动运行：

• /qe-fleet run <需求文档>
• /qe-fleet prepare <需求文档>
• /qe-fleet analyze <需求文档>
• /qe-fleet design <需求文档>
• /qe-fleet review <需求文档>
• /qe-fleet export <需求文档>
• /qe-fleet monitor <需求文档> --results <测试结果>
• /qe-fleet status <需求文档>
• /case_generate <需求文档>（向后兼容别名）
• "基于某个需求文档生成测试分析、测试点、测试用例"
• "导出测试用例 Excel"

架构概述

本流水线采用混合架构：

• Python 脚本（fleet_runner.py）: 确定性工作——文档解析、知识激活、需求分析、冲突检测、风险矩阵、测试策略模板、测试数据模板、Playwright/Appium 脚本骨架、附加文件检测、多源注册表、清单管理
• Claude Code Agent（SKILL.md）: 生成式 AI 工作——测试点设计、测试用例编写、用例评审、覆盖率审计、质量裁决

/qe-fleet run 自动执行规则

当用户输入 /qe-fleet run <需求文档> 时，按以下 6 个阶段自动执行：

Phase 1: SCAFFOLD — Python 脚手架生成

python scripts/fleet_runner.py run --scaffold-only --requirement <需求文档路径>

产出 manifest（含 pending_ai 标记）+ 模板 + 脚本骨架 + 附加文件检测 + 多源注册表。

Phase 2: GATE-CHECK — 确认门禁

读取 output/manifests/{BASE_NAME}_analyze.json。若 confirmation_gate.required=true 且 decision_status 不是 confirmed 或 not_required：

• 🛑 阻断，告知确认单路径和阻断原因，不得继续

Phase 3: AI-DESIGN — AI Agent 生成设计产物

并行: data-builder + testpoint-designer → 串行: case-designer

每个 Agent 使用 Claude Code Agent 工具调用，以 agents/ 目录下的 prompt 文件为指令。若目标文件已存在且 >500 字符则跳过。

Phase 4: AI-REVIEW — AI Agent 评审

并行: case-reviewer + coverage-auditor → 串行: quality-gatekeeper

Phase 5: VERDICT — 裁决 + 导出

• PASS/PASS_WITH_FIX → python scripts/fleet_runner.py export --requirement <需求文档路径>
• BLOCKED → 🛑 告知阻断原因，不导出

Phase 6: REPORT — 最终汇总

输出各战区状态、产物路径、质量裁决结果。

子命令自动执行

/qe-fleet prepare

python scripts/fleet_runner.py prepare --requirement <需求文档路径>

/qe-fleet analyze

python scripts/fleet_runner.py analyze --requirement <需求文档路径>

/qe-fleet design

仅执行 Phase 3（AI-DESIGN），前提是 prepare 和 analyze 已完成。若 manifest 未就绪，先执行对应的脚手架命令。

/qe-fleet review

仅执行 Phase 4（AI-REVIEW），前提是设计产物已存在。

/qe-fleet export

python scripts/fleet_runner.py export --requirement <需求文档路径>

/qe-fleet monitor

python scripts/fleet_runner.py monitor --requirement <需求文档路径> --results <测试结果文件>

/qe-fleet status

python scripts/fleet_runner.py status --requirement <需求文档路径>

若用户已经补完确认单，并明确要求"继续""确认后续跑""按确认结论重跑"，优先执行：

python scripts/case_pipeline.py apply-confirmation --requirement <需求文档路径>

约束

• 除非脚本执行失败，否则不要要求用户再手动执行命令
• 所有 bash 命令使用 python（非 python3）
• 若 manifest 中有附加源文件（sources_registry），必须纳入 AI Agent 的输入文件列表
• 若本次改动涉及以下任一范围，必须在结束前执行 python scripts/governance_audit.py auto，并根据结果同步修正 AGENTS.md、.claude/、README.md、docs/ 的滞后内容：
  • scripts/
  • .claude/
  • agents/
  • knowledge_base/01_standards/
  • AGENTS.md
  • README.md
  • fleet_config.yml
• 若只是 requirements/、knowledge_base/02_history/、knowledge_base/03_best_practices/、output/ 下的普通内容更新，不要触发这项治理审计
• 所有测试用例必须使用 knowledge_base/01_standards/test_case_template.md 中定义的唯一表头
• 不允许同时维护 draft_cases.md、final_cases.md
• 最终结果始终覆盖写回 output/test_cases/{BASE_NAME}_测试用例.md
• 分析阶段必须识别关联需求并给出冲突修订建议
• 冲突建议不得停留在抽象描述，必须写清问题、影响范围、建议修订方向
• 测试点/测试用例必须体现 knowledge_base/00_project/project_profile.md 的项目差异化约束
• 若主输入是 .docx/.doc/.pdf，必须使用 prepare 产出的标准化 Markdown 文件，即 normalized_requirement_file
• 各战区产物清单汇总至 output/manifests/{BASE_NAME}.json 统一清单文件
• 若存在同主题技术方案或需求中引用的附加文件，必须结合这些文件补充测试约束
• 测试用例生成前必须先按 knowledge_base/01_standards/review_checklist.md 自检
• 需求有歧义时，必须显式写：

> ⚠️ 待确认：问题、影响范围、建议确认方向

• 不得臆造高风险业务规则
• 历史遗漏场景和历史缺陷必须显式体现在测试点或测试用例中
• 预期结果必须同时覆盖 UI 反馈和数据状态变化
• 若 confirmation_gate 仍未解除，不得伪装成"已完成最终导出"
• 质量裁决 BLOCKED 时，不得导出 Excel