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/02_history/common_missed_scenes.md

@@ -0,0 +1,43 @@
+# 容易漏测场景清单
+
+> AI 在生成测试点时，**必须**对照此清单进行自我检查，确保没有遗漏以下场景：
+
+### 1. 数据与边界
+- [ ] **空值/Null**：输入框为空、接口返回 null 时，页面是否崩溃。
+- [ ] **超长字符**：输入超过数据库字段长度的字符（如 256 个字符）。
+- [ ] **特殊字符**：Emoji 表情、SQL 注入字符、HTML 标签。
+- [ ] **金额精度**：金额计算是否出现 `0.0000001` 的精度丢失问题（特别是分期计算）。
+
+### 2. 网络与交互
+- [ ] **弱网/断网**：提交请求瞬间断网，是否有重试机制或友好提示。
+- [ ] **重复提交**：快速多次点击“提交”按钮（防抖/幂等性检查）。
+- [ ] **超时处理**：接口响应超过 30 秒，前端是否有 Loading 状态或超时提示。
+- [ ] **页面切换**：在支付密码输入页切换到后台再切回，是否保留状态。
+
+### 3. 状态流转
+- [ ] **逆向流程**：支付后退款、下单后取消、发货后退货、定金转退。
+- [ ] **并发操作**：同一账号在两个设备同时操作；库存仅剩 1 件时两人同时购买。
+
+### 4. 车企商城特有业务
+- [ ] **VIN 码校验**：输入已售 VIN、错误格式 VIN、大小写混用。
+- [ ] **配置器互斥**：选择 A 配件后，B 配件是否自动置灰（如轮毂与轮胎的匹配）。
+- [ ] **价格变动**：用户加购后，后台修改价格，结算页是否实时刷新。
+- [ ] **权益叠加**：车主积分、推荐奖励、官方优惠券三者是否违规叠加。
+
+### 5. 账号与权限
+- [ ] **多端登录**：同一账号在手机 App 和 车机端 同时登录，状态是否同步。
+- [ ] **未登录访问**：直接通过 URL 访问订单详情页，是否拦截跳转登录。
+- [ ] **隐私授权**：首次使用未点击“同意隐私协议”，是否禁止调用定位/相机权限。
+
+### 6. 中后台 CRUD 页面
+- [ ] **列表字段**：列表页展示字段、默认排序、分页项是否与需求一致。
+- [ ] **查询重置**：搜索、筛选、重置、空结果提示是否完整。
+- [ ] **查看只读**：查看态是否真正不可编辑，避免与编辑态混淆。
+- [ ] **正向成功链路**：不要只测“保存失败/限制条件”，还要覆盖新建成功、编辑成功。
+- [ ] **状态与按钮映射**：不同状态下操作栏按钮是否正确展示，是否存在越权或错态操作。
+- [ ] **端间数据隔离**：平台端、商家端、门店端配置数据是否真正隔离，避免串数。
+- [ ] **选择弹窗细粒度**：商品/优惠券/奖品选择弹窗的刷新、搜索、分页、排序、选择反馈是否完整。
+
+### 7. C 端资格与展示状态
+- [ ] **状态拆分**：未开始、进行中、已结束、已失效是否分别验证，而不是合并成一个模糊负向场景。
+- [ ] **门店老用户**：店铺维度老用户不弹窗是否单独覆盖，避免只校验平台维度老用户。

knowledge_base/02_history/historical_defects.md

@@ -0,0 +1,63 @@
+# 历史典型缺陷复盘
+
+> 这些是过去项目中发生过的真实 Bug，生成新用例时，请针对这些逻辑设计防御性测试用例。
+
+### 缺陷 ID: BUG-202310-05
+- **模块**: 购物车
+- **描述**: 商品降价后加入购物车，随后商品恢复原价，结算时依然按降价后的价格计算，导致资损。
+- **根因**: 购物车缓存了价格，结算时未重新从商品中心获取最新价格。
+- **防御用例**: `验证商品加入购物车后，后台修改价格，结算时系统自动更新为最新价格`。
+
+### 缺陷 ID: BUG-202311-12
+- **模块**: 优惠券
+- **描述**: 使用“满100减50”优惠券购买 100 元商品，退货时未扣除优惠金额，导致用户获利。
+- **根因**: 退款逻辑未考虑优惠分摊。
+- **防御用例**: `验证使用优惠券购买多件商品后，部分退款时优惠金额按比例扣除`。
+
+### 缺陷 ID: BUG-202312-07
+- **模块**: 下单接口
+- **描述**: 调用下单接口时，通过篡改请求参数，将商品数量改为负数，系统未做边界校验，使订单总金额变为负数，用户支付后平台产生负向应收，造成资损。
+- **根因**: 下单接口对商品数量仅做了非空校验，未校验正整数及防止整数溢出。
+- **防御用例**: `验证调用下单接口时，传入商品数量为 0、负数、超大整数（如 9999999）时，系统均能拦截并返回错误码，不生成有效订单`。
+
+### 缺陷 ID: BUG-202401-15
+- **模块**: 支付网关
+- **描述**: 用户下单时选择“普通订单”（应付金额 100 元），在调起支付前通过抓包修改支付接口请求参数，将支付类型从“微信支付”改为“全额积分支付”。由于后端未校验订单原始支付方式，积分系统扣除了用户 100 积分（1 积分=1 元），用户实际未付现金即获得商品。日损失积分资产超 10 万。
+- **根因**: 支付接口仅校验了用户积分余额是否充足，未与订单核心表中的支付方式快照做一致性校验。
+- **防御用例**: `验证下单时选择现金支付，支付阶段强制改为积分支付或余额支付时，后端应校验请求支付方式与订单生成时记录的支付方式一致，不一致则拒绝支付`。
+
+### 缺陷 ID: BUG-202401-22
+- **模块**: 并行扣减
+- **描述**: 秒杀活动中，用户通过多线程并发调用下单接口（同一商品 ID，同一用户），由于缺少分布式锁或乐观锁，导致同一件商品被同一用户成功下单 3 次，库存扣减超出实际售卖数量，产生超卖资损。
+- **根因**: 库存扣减 SQL 为 `update stock set count = count - 1 where product_id = ?`，未使用 `and count > 0` 条件，且业务层未做幂等和并发控制。
+- **防御用例**: `验证同一用户对同一限购商品发起 10 次并发下单请求，最终只成功创建 1 个订单，库存扣减 1 件`。
+
+### 缺陷 ID: BUG-202402-03
+- **模块**: 价格计算
+- **描述**: 商品 A 单价 50 元，参与“满 2 件打 8 折”活动。用户将 1 件加入购物车，下单前活动变更为“满 3 件打 7 折”，但前端仍展示旧折扣，提交订单时后端沿用旧活动的价格计算规则，导致用户少付。
+- **根因**: 后端未在订单入库前重新计算促销活动价格，而是信任前端传入的活动 ID 和已优惠金额。
+- **防御用例**: `验证商品促销活动变更后，用户使用旧的活动 ID 提交订单，系统应抛弃前端传入的优惠信息，强制重新计算最新活动价格`。
+
+### 缺陷 ID: BUG-202402-18
+- **模块**: 退款/逆向流程
+- **描述**: 用户使用混合支付（现金 80 元 + 余额 20 元）购买 100 元商品。申请全额退款时，退款逻辑先调用余额退款接口（退还 20 元），然后调用现金退款接口（退还 80 元）。但现金退款接口因网络超时返回失败，系统记录退款失败，但实际上余额的 20 元已退给用户，用户凭空获利。
+- **根因**: 退款流程未使用分布式事务或 TCC 模式，分步调用外部接口出现部分成功时无法回滚。
+- **防御用例**: `验证混合支付全额退款时，若现金退款接口调用失败，系统应能自动回滚已退的余额部分，或保持整体失败状态，绝不出现部分退款成功`。
+
+### 缺陷 ID: BUG-202403-11
+- **模块**: 价格篡改
+- **描述**: 用户将商品加入购物车后，通过浏览器开发者工具修改页面中某个商品的“单价” DOM 元素（从 100 改为 0.01），提交订单时后端未校验单价，直接使用前端传回的 0.01 元创建支付单，用户以 1 分钱买走商品。
+- **根因**: 下单接口设计时错误地将商品单价作为可信任的入参，未从商品中心重新获取真实单价。
+- **防御用例**: `验证所有与金额、价格、数量相关的核心字段（单价、总价、运费等）均不能信任前端传入，下单时后端必须独立从商品库/价格服务中重新获取并计算`。
+
+### 缺陷 ID: BUG-202403-20
+- **模块**: 重复支付
+- **描述**: 用户在支付网关点击“确认支付”按钮后，由于网络延迟前端未收到回调，用户连续点击 3 次，系统生成了 3 个相同的支付请求（同一订单号），三方支付渠道返回 3 个不同的交易单号，且订单系统最终对同一订单进行了 3 次金额累加，多收了用户 2 份钱。
+- **根因**: 支付接口未做幂等性校验，允许同一订单号多次发起支付请求并修改订单状态。
+- **防御用例**: `验证同一订单号在 1 秒内收到 5 次相同支付请求，后端仅处理第一次请求，后续请求直接返回“处理中”或“重复请求”，订单状态不被多次累加`。
+
+### 缺陷 ID: BUG-202404-02
+- **模块**: 积分与现金互转
+- **描述**: 活动期间积分可抵扣现金（100 积分 = 1 元）。用户下单时使用 5000 积分抵扣 50 元，订单总金额 100 元，实付 50 元。后续用户申请全额退款，系统退还了 5000 积分 + 50 元现金，相当于积分被重复退还（原积分未核销），用户用 0 成本套取 50 元现金。
+- **根因**: 退款时未先扣回已使用的积分（或积分已被消耗），而是直接重新发放等额积分。
+- **防御用例**: `验证使用积分抵扣部分现金后，申请退款时应先原路返还积分（若积分未过期）或按比例折算成现金，确保平台不产生额外资产损失`。

knowledge_base/02_history/marketing_rules.md

@@ -0,0 +1,62 @@
+# 营销叠加互斥规定
+
+> 核心业务规则，生成用例时**严禁**违反以下逻辑（以 `/zanmall_order/order/confirm` + `/zanmall_order/order/submit` 当前代码为准）：
+
+1. **优惠券规则（作用域互斥）**:
+   - 同一作用域（同店铺券池 / 平台券池）一次只会生效 **1 张券**，不可多张叠加。
+   - 平台券与店铺券可同时生效（前提各自命中可用条件）。
+   - 套餐商品（`comboId > 0`）不参与优惠券分摊。
+2. **优先级逻辑**:
+   - 用户未手动指定优惠券（`userChangeCoupon != 1`）时，系统默认选择**优惠金额最大**的可用券。
+   - 用户手动指定（`userChangeCoupon = 1`）时，仅按传入 `couponIds` 选择；也可手动不使用优惠券。
+3. **积分与优惠券关系**:
+   - 普通订单中，**优惠券可与积分抵现叠加**（积分开关开启且 `isScorePay = 1`）。
+   - 积分在会员权益阶段之后计算，提交时会单独锁积分。
+4. **一口价互斥**:
+   - 命中一口价（`fixedPriceId != null`）时，不走平台券、会员折扣、积分抵现链路。
+   - 一口价会重算店铺金额并覆盖此前店铺侧优惠计算结果，不与常规营销链路叠加。
+5. **满减送互斥**:
+   - 满减送对以下商品组直接跳过：已命中旧满减、拼团/秒杀/积分类商品、限时折扣、一口价、套餐。
+6. **会员折扣链路差异（配置项）**:
+   - 会员价开关关闭（legacy）时：会员折扣可继续叠加在已优惠商品上。
+   - 会员价开关开启（hybrid）时：已命中营销活动或已使用优惠券的商品不再叠加会员折扣。
+7. **运费规则**:
+   - 运费按“店铺 + 运费模板（含供应商维度）”计算后累加。
+   - 包邮只作用于命中的模板或模板条件，不是“只要有一件包邮就全单免邮”。
+8. **确认单链路顺序（普通路径）**:
+   - 先计算店铺侧营销（折扣/套餐、满减、店铺券等），再处理平台券，再处理会员与积分，再汇总运费。
+   - 若命中一口价，直接进入一口价分支并覆盖店铺金额，不再进入平台券+会员+积分常规链路。
+9. **提交单锁定规则**:
+   - 提交单阶段不会重新“试算”营销组合，按确认单结果执行资源锁定。
+   - 优惠券、积分分别在提交阶段单独锁定，确保与确认单结果一致。
+
+## 关系速查（按当前接口逻辑）
+
+| 活动A | 活动B | 关系 | 条件说明 |
+| --- | --- | --- | --- |
+| 优惠券 | 优惠券（同作用域） | ❌ | 同一券池仅生效 1 张 |
+| 平台券 | 店铺券 | ✅ | 分池计算，可同时生效 |
+| 优惠券 | 套餐商品 | ⬇️ | 套餐商品不参与券分摊，非套餐可用券 |
+| 优惠券 | 积分抵现 | ✅ | 积分开关开启且 `isScorePay=1` 时可叠加 |
+| 会员折扣 | 优惠券 | ⬇️ | legacy 可叠加；hybrid 对已用券商品不叠加 |
+| 满减送 | 旧满减/限时折扣/套餐/一口价/拼团秒杀积分类 | ❌（同商品组） | 命中互斥条件即跳过满减送 |
+| 一口价 | 平台券 | ❌ | 一口价分支跳过平台券链路 |
+| 一口价 | 会员折扣 | ❌ | 一口价分支跳过会员链路 |
+| 一口价 | 积分抵现 | ❌ | 积分在会员链路内计算，一口价整体跳过 |
+| 一口价 | 店铺侧营销结果（满减/店铺券/套餐） | ❌（覆盖） | 一口价重算并覆盖此前店铺优惠汇总 |
+| 提交阶段 | 优惠券锁定 | 执行 | 按确认单结果锁券 |
+| 提交阶段 | 积分锁定 | 执行 | 按确认单结果锁积分 |
+| 运费 | 包邮模板 | ⬇️ | 按店铺+模板累加；仅命中模板免运费 |
+
+## 符号定义
+
+- `✅`：可叠加（同一条 confirm 链路会连续生效，且无显式跳过/覆盖）
+- `❌`：互斥（代码显式跳过，或后置计算覆盖前置结果）
+- `⬇️`：条件叠加（依赖配置开关、活动命中、商品类型、券作用域等）
+
+## 可配置项（影响叠加结果）
+
+- `memberPriceSwitchConfig(enabled/failOpenLegacy)`：控制会员折扣走 legacy 还是 hybrid。
+- `SCORE_CONFIG(shoppingScoreSwitch/useRatioLimit/shoppingUseScoreRatio)`：控制积分抵现开关、比例与上限。
+- `会员权益 rightsType/freeFeeType`：控制会员包邮是否命中。
+- `userChangeCoupon + couponIds`：控制是否手动指定优惠券。