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

knowledge_base/00_project/project_profile.md

@@ -0,0 +1,78 @@
+# 项目画像（通用基线版，请按项目实际情况维护）
+
+> 用途：为本仓库内的测试分析、测试点、测试用例提供“项目差异化约束”。
+>
+> 使用原则：本文件先提供测试行业常用的通用基线，后续项目落地时必须补充项目真实规则；若与正式需求、产品说明、接口文档冲突，以项目最新确认结论为准。
+>
+> 维护要求：当架构、业务模式、风控策略、履约策略、权限模型、计费规则等发生变更时，必须同步更新本文件。
+
+## 1. 项目简介
+
+- 项目名称：待补充
+- 项目类型：默认按中后台系统、交易类系统、会员营销系统、内容平台或工具平台中的一种理解，未明确前不得擅自细化。
+- 目标用户：默认至少包含终端用户、运营人员、客服/审核人员、系统管理员中的部分角色，具体以项目实际为准。
+- 核心业务域：待补充，可从下单、履约、营销、会员、支付、退款、内容发布、审批流等域中选择。
+- 当前版本范围：以本次 `requirements/` 下需求文档为准，未写入需求范围的能力默认不纳入本期。
+
+## 2. 业务边界与禁用能力
+
+- 本项目明确不支持的能力：凡需求文档、接口文档、项目说明中未声明支持的能力，默认按“不支持”处理，不得在测试分析和测试用例中臆造。
+- 受监管或合规限制的流程：涉及支付、退款、发票、实名、隐私数据、权限审批、操作留痕等能力时，默认认为存在合规要求，测试中需覆盖鉴权、留痕、异常拦截和数据保护。
+- 灰度/地域/渠道差异说明：若需求未明确，则默认检查 Web/H5/App/小程序、测试环境与生产配置、不同地域或租户下是否存在规则差异，并将其作为待确认项。
+
+## 3. 核心业务规则（项目级）
+
+- 结算与支付规则：凡涉及金额、折扣、积分、优惠、手续费、税费、退款分摊时，默认要求金额计算可追溯、展示口径一致、前后端结果一致、重复提交不导致重复扣减。
+- 营销与优惠规则：默认检查优惠互斥、叠加优先级、门槛命中、适用范围、失效时间、回滚恢复和异常场景；若项目无营销能力，应在项目化配置中显式写明。
+- 风控与权限规则：默认要求关键操作具备角色限制、越权拦截、二次确认或风控校验；高风险动作失败时不得进入成功态。
+- 状态流转规则：默认所有核心对象都应具备明确状态机约束，禁止跳状态、逆状态、重复终态处理；异常中断后状态应可解释、可恢复、可追踪。
+
+## 4. 技术与集成约束
+
+- 关键依赖系统：默认关注认证中心、用户中心、库存/资源中心、支付网关、消息系统、营销中心、风控系统、文件服务、第三方回调服务等；实际未接入的依赖请在项目化配置中删除。
+- 外部接口约束：默认按存在超时、重试、幂等、限流、熔断、降级、重复回调、乱序回调、部分成功等风险设计测试。
+- 数据一致性策略：若需求未明确，默认按“关键交易结果最终一致、关键扣减与状态更新需具备幂等保护”理解，并将强一致/最终一致边界列入待确认。
+
+## 5. 高风险场景与历史事故
+
+- 资损风险点：重复提交、重复支付、重复退款、优惠多减、金额少收/多收、库存超扣、积分或券未正确回滚、并发下重复创建资源。
+- 可用性风险点：弱网超时、接口抖动、依赖不可用、消息延迟、回调丢失、页面重复点击、前后端缓存不一致、批量操作部分失败。
+- 数据风险点：脏数据兼容、历史数据迁移、空值/默认值污染、精度丢失、跨租户串数据、删除后残留引用。
+- 典型线上事故防御策略：默认对核心链路补充幂等、重试、回滚、补偿、审计日志、告警阈值和人工兜底场景。
+
+## 6. 测试策略偏好（项目定制）
+
+- P0 优先覆盖链路：登录鉴权、核心主流程、金额/资源扣减、状态变更、提交确认、异常回滚、查询展示一致性。
+- 必测异常场景：参数非法、前置条件不满足、重复点击、并发提交、超时重试、依赖失败、权限不足、状态已变化、数据部分缺失。
+- 非功能重点：弱网、超时、高并发、权限隔离、接口幂等、审计日志、性能基线、兼容性、可观测性。
+- 自动化优先级建议：稳定且高频回归的核心主流程、历史缺陷高发链路、金额与状态计算逻辑、关键接口鉴权与幂等校验优先自动化。
+
+## 7. 需求冲突判定口径
+
+- 什么情况下判定为“冲突”：
+  - 同一对象在不同需求中出现相反规则。
+  - 同一阈值、时效、次数、金额口径不一致。
+  - 同一状态机的起点、终点、流转条件描述不一致。
+  - 同一角色权限、数据范围、可见性规则前后不一致。
+  - 新需求声明“沿用旧逻辑”，但实际描述已改变旧规则。
+- 冲突处理优先级规则：
+  - 优先看当前版本正式需求是否显式声明“替换/废弃/继承”旧规则。
+  - 若无显式声明，优先要求补充版本边界、生效范围、影响模块。
+  - 若涉及金额、库存、权益、权限、安全、合规，默认按高风险冲突处理，必须在需求阶段确认。
+- 需求文档修改建议模板：
+  - 建议类型：规则合并 / 版本边界补充 / 阈值统一 / 状态机修正 / 权限口径修正 / 异常处理补充
+  - 建议描述：明确指出当前需求条目、冲突来源条目、冲突点和推荐修订文本方向
+  - 影响范围：说明影响的角色、模块、接口、数据口径、历史兼容逻辑、回归范围
+
+## 8. 通用输出约束（供测试任务直接使用）
+
+- 需求分析必须同时覆盖功能目标、边界、角色、前置条件、状态流转、关键规则、风险与待确认项。
+- 测试点必须同时覆盖主流程、异常流程、边界条件、数据校验、状态流转、权限控制、并发幂等、弱网超时、历史缺陷防御。
+- 测试用例预期结果必须同时覆盖 UI/接口反馈和数据状态变化，不能只写“成功”或“失败”。
+- 若需求存在歧义、缺字段、缺状态、缺口径，必须显式输出：
+
+```md
+> ⚠️ 待确认：问题、影响范围、建议确认方向
+```
+
+- 对于高风险业务规则，若项目未明确给出，不得基于经验直接写死为真实规则，只能作为风险假设或待确认项输出。