feat: /qe-fleet run 安徽运八需求 + 系统坑修复

系统修复:
- fleet_runner.py: Windows UTF-8 编码兼容（reconfigure stdout/stderr）
- fleet_runner.py: run 命令自动生成合并清单供导出使用
- fleet_manifest.py: 新增 save_merged_manifest() 保存统一清单
- fleet_config.yml: 修复 YAML keywords 格式（block sequence → flow sequence）
- 恢复被误删的知识库文件(payment_flow_cases, marketing_activity_cases)

QE Fleet 产物 (安徽运八需求):
- 153个测试点 + 53条可执行测试用例
- 需求分析/风险评估/测试策略/质量裁决（PASS）
- Excel 导出 + 版本快照 v2
- 确认结论文件已归档

knowledge_base/02_history/common_missed_scenes.md

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

knowledge_base/02_history/historical_defects.md

@@ -2,62 +2,8 @@
 
 > 这些是过去项目中发生过的真实 Bug，生成新用例时，请针对这些逻辑设计防御性测试用例。
 
-### 缺陷 ID: BUG-202310-05
+### 缺陷 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

@@ -1,4 +1,4 @@
-# 营销叠加互斥规定
+# 营销叠加互斥规定--该项目暂时不需要
 
 > 核心业务规则，生成用例时**严禁**违反以下逻辑（以 `/zanmall_order/order/confirm` + `/zanmall_order/order/submit` 当前代码为准）：