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
+> ⚠️ 待确认：问题、影响范围、建议确认方向
+```
+
+- 对于高风险业务规则，若项目未明确给出，不得基于经验直接写死为真实规则，只能作为风险假设或待确认项输出。

knowledge_base/01_standards/definition_of_done.md

@@ -0,0 +1,86 @@
+# 测试用例完成定义
+
+面向当前仓库的固定流水线，一个测试任务被视为“完成”，不是只看是否产出了文档，而是看产出的测试点和测试用例是否已经达到可评审、可执行、可追溯、可导出的质量门槛。
+
+## 1. 覆盖范围达标
+
+至少覆盖以下维度，不得只覆盖主流程：
+
+- 主流程：核心业务 Happy Path 必须覆盖。
+- 异常流程：参数非法、前置条件不满足、状态不允许、库存不足、余额不足、权限不足、重复操作、超限操作等必须覆盖。
+- 边界条件：最小值、最大值、临界值、空值、默认值、长度边界、数量边界、时间边界、金额边界必须按需求实际场景覆盖。
+- 状态流转：创建、提交、生效、失效、取消、关闭、退款、撤回、恢复等关键状态变化必须覆盖。
+- 规则组合：多条件叠加、互斥、优先级、覆盖关系、兜底规则必须覆盖。
+- 数据校验：展示数据、落库数据、统计口径、列表汇总、详情字段、外部回传字段必须覆盖。
+- 中后台页面：如果需求包含列表、新建、编辑、查看、失效、删除、筛选、选择弹窗等管理能力，除失败态外，正向成功链路和交互细项也必须覆盖。
+- 历史风险：`common_missed_scenes.md`、`historical_defects.md` 中与当前需求相关的高风险场景必须映射到测试点或测试用例。
+- 跨需求影响：`关联与冲突.md` 中识别出的关联规则、潜在冲突、修订建议，必须至少落一条可验证测试点或用例。
+- 项目差异化：`project_profile.md` 中的业务边界、禁用能力、特殊限制、风控要求必须体现。
+
+## 2. 风险覆盖达标
+
+对于高风险模块，测试用例必须体现风险导向，而不是平均用力。
+
+- P0/P1 业务规则必须覆盖正向、逆向、边界、互斥、并发或幂等中的关键场景。
+- 资金、库存、优惠、权益、订单状态等资损类风险，必须覆盖结果一致性校验。
+- 涉及角色隔离、数据隔离、门店隔离、组织隔离的需求，必须覆盖权限与越权场景。
+- 涉及外部系统、回调、异步任务、延迟生效、重试补偿的需求，必须覆盖时序异常与重复触发场景。
+
+## 3. 用例设计质量达标
+
+每条用例必须满足以下要求：
+
+- 原子性：一条用例只验证一个主验证点，避免多个核心断言混在一条用例里。
+- 可执行：前置条件、步骤、测试数据明确，执行人无需猜测。
+- 可验证：预期结果必须同时覆盖 UI/接口反馈和数据状态变化。
+- 可定位：失败后能大致判断是前端展示、后端规则、数据落库、异步处理还是外部依赖问题。
+- 可复现：步骤中要包含关键账号、角色、商品、金额、券、积分、库存、时间或状态等必要数据。
+- 类型准确：`类型` 字段必须使用标准枚举，且与用例真实目的匹配。
+- 术语一致：术语表达必须与生效术语文件一致，不混用平台券、商家券、店铺券等概念。
+- 模块清晰：`模块` 字段应使用层级路径表达，例如 `平台端-营销管理-商家优惠券`。
+
+## 4. 测试点到用例的映射达标
+
+- 每个高价值测试点都应被至少一条用例承接。
+- 历史缺陷防御点、漏测清单项、冲突修订项不得只停留在测试点层，必须在用例层落地。
+- 如果某类测试点因为当前范围不做用例，必须明确写出原因，不能静默遗漏。
+
+## 5. 待确认项处理达标
+
+- 需求存在缺失、冲突、口径不明时，必须显式写出：
+
+```md
+> ⚠️ 待确认：问题、影响范围、建议确认方向
+```
+
+- 待确认项影响主流程、金额、库存、权限、状态流转、优惠规则时，不得擅自臆造高风险业务规则。
+- 对待确认项，至少要补一条“确认后需重点回归”的提醒性测试点或备注。
+
+## 6. 非功能与稳健性覆盖达标
+
+以下场景按风险选择，不要求机械凑数量，但高风险需求不能缺失：
+
+- 幂等：重复提交、重复支付、重复领券、重复核销、重复回调。
+- 并发：多人抢占、库存竞争、优惠领取竞争、重复操作竞争。
+- 弱网与超时：请求超时、接口重试、页面重复点击、异步结果延迟返回。
+- 兼容与稳定性：分页、排序、筛选、导入导出、大数据量、长名称、特殊字符。
+- 权限与审计：无权限、低权限、跨组织、跨门店、跨商家操作及日志留痕。
+- 展示状态：若多个业务状态会影响 C 端资格、弹窗或按钮展示，需拆分到可定位的独立用例，不得用一条模糊负向用例笼统代替。
+
+## 7. 评审与产物达标
+
+- `output/analysis/{BASE_NAME}_分析.md`、`output/test_points/{BASE_NAME}_测试点.md`、`output/test_cases/{BASE_NAME}_测试用例.md` 必须完整存在。
+- 测试用例表头必须严格符合 `test_case_template.md` 的唯一规范。
+- 测试用例文件必须可通过 `verify` 校验，并可成功 `export` 为 Excel。
+- 评审阶段必须对照本 DoD、历史缺陷、关联冲突报告、项目画像进行检查；未达标时应直接修正原文件，不另起草稿。
+
+## 8. 默认判定原则
+
+如果产物满足以下任一情况，则不能视为完成：
+
+- 只有主流程，没有异常、边界、状态流转或冲突防御场景。
+- 用例步骤泛化，没有可执行的数据。
+- 预期结果只有“提示成功/失败”，没有数据状态校验。
+- 历史缺陷、漏测清单、项目差异化约束未落入测试点或用例。
+- 明显存在待确认问题，但未显式标记。
+- Markdown 表格不规范，导致后续 `verify` 或 `export` 无法通过。

knowledge_base/01_standards/review_checklist.md

@@ -0,0 +1,105 @@
+# 测试用例评审清单
+
+这份清单服务于当前仓库的测试用例生成与自审流程，用于把 `definition_of_done.md` 中的原则拆成可逐项检查的执行项。
+
+使用原则：
+
+- `testcase-designer` 在写入最终用例前，必须先按本清单自检并直接修正。
+- `testcase-reviewer` 在评审阶段，必须按本清单逐类检查并直接修正阻断项。
+- 发现问题时，优先修正源用例，不输出额外草稿文件。
+
+## 1. 阻断项
+
+以下任一项不满足，都不能视为通过：
+
+- 表头不是标准唯一表头。
+- Markdown 表格格式错误，可能导致 `verify` 或 `export` 失败。
+- 只有主流程，没有异常、边界、状态流转或冲突防御场景。
+- `预期结果` 只写页面提示，没有数据状态校验。
+- `测试步骤`、`测试数据` 过于抽象，执行人无法直接操作。
+- 需求存在明显待确认项，但未显式标注 `> ⚠️ 待确认：...`。
+- 历史缺陷、漏测场景、项目差异化约束、关联冲突修订没有落到测试点或用例。
+
+## 2. 结构与格式检查
+
+- 是否严格使用唯一表头顺序：
+  - `用例编号`
+  - `模块`
+  - `用例标题`
+  - `优先级`
+  - `类型`
+  - `前置条件`
+  - `测试步骤`
+  - `测试数据`
+  - `预期结果`
+  - `备注`
+- `类型` 是否使用允许枚举：`功能测试`、`性能测试`、`兼容性测试`、`易用性测试`、`安全性测试`、`冒烟测试`、`回归测试`、`其他`。
+- `模块` 是否采用层级路径写法，例如 `平台端-营销管理-商家优惠券`。
+- `用例编号` 是否稳定、可读、与模块归属一致。
+- `备注` 是否只承载待确认项、来源说明、AI 修正原因等必要信息，而不是堆重复内容。
+
+## 3. 覆盖性检查
+
+逐个模块检查以下维度是否都有体现；若不适用，需能说明原因：
+
+- 主流程
+- 异常流程
+- 边界条件
+- 状态流转
+- 规则组合、互斥、优先级
+- 幂等与并发
+- 权限与越权
+- 弱网、超时、异步或回调异常
+- 历史缺陷防御
+- 跨需求冲突防御
+- 项目差异化高风险约束
+- 如果需求包含中后台 CRUD/配置页，是否覆盖了列表字段、查询/重置、查看只读、新建/编辑/删除/失效、操作栏权限与状态映射、端间数据隔离。
+- 如果需求包含中后台 CRUD/配置页，除失败态和限制态外，是否显式覆盖了新建成功、编辑成功等正向主链路。
+- 如果需求包含“选择商品/优惠券/奖品/门店”等弹窗或选择器，是否覆盖了刷新、搜索、字段展示、分页、排序、单选/多选反馈和归属范围差异。
+- 如果需求包含“未开始/进行中/已结束/已失效”等状态对 C 端展示或资格判断有影响，是否按状态拆成独立可定位用例，而不是笼统合并。
+
+## 4. 单条用例质量检查
+
+每条用例至少检查以下问题：
+
+- 是否只验证一个主验证点，避免多个关键断言混杂。
+- 前置条件是否完整，是否缺账号、角色、商品、库存、金额、券、积分、订单状态等必要上下文。
+- 测试步骤是否按执行顺序书写，是否存在“正常操作”“提交并校验”等笼统描述。
+- 测试数据是否具体，而不是“输入合法金额”“选择一张优惠券”这类泛化表达。
+- 预期结果是否同时包含 UI/接口反馈和数据状态变化。
+- 失败后是否能大致定位到前端、后端、规则、数据、异步链路或外部依赖。
+
+## 5. 风险场景检查
+
+以下高风险场景应按需求实际风险决定是否覆盖，涉及则不应缺失：
+
+- 金额计算、优惠分摊、退款分摊、实付金额一致性
+- 库存扣减、回滚、超卖、重复扣减
+- 优惠叠加、互斥、门槛校验、适用范围校验
+- 权益发放、核销、回退、重复使用
+- 外部回调、重复通知、延迟通知、补偿重试
+- 角色越权、数据越权、跨门店/跨商家/跨组织访问
+
+## 6. 追溯与来源检查
+
+- 关键测试点是否能追溯到需求、历史缺陷、漏测清单、营销规则、项目画像或冲突修订。
+- 对历史缺陷补充的用例，`备注` 是否标注了合理来源，例如 `[AI修正: 补充历史缺陷防御]`。
+- 对冲突修订补充的用例，`备注` 是否标注了修正原因，例如 `[AI修正: 冲突修订]`。
+
+## 7. 待确认项检查
+
+- 是否存在需求缺失、规则冲突、口径不明但被直接当成事实写进用例的情况。
+- 对资金、库存、权限、状态流转、营销规则相关的不确定规则，是否避免了臆造。
+- 待确认项是否写清楚问题、影响范围和建议确认方向。
+
+## 8. 优先级检查
+
+- P0 是否真正对应核心主流程、核心资损风险或关键状态流转。
+- P1 是否覆盖主要功能、关键异常、重要边界。
+- P2 是否承载次要异常、兼容性、补充性验证，而不是把高风险场景错误下沉到 P2。
+
+## 9. 评审结论规则
+
+- 若存在阻断项，必须直接修正原文件后再结束。
+- 若存在覆盖盲区但当前需求范围确实不支持，应显式写出原因，不得静默遗漏。
+- 若修正了已有用例或新增了防御用例，应在 `备注` 中保留必要的 `AI修正` 说明。

knowledge_base/01_standards/terminology.md

@@ -0,0 +1,114 @@
+# 业务术语表
+
+> 本文件定义了项目中长期稳定、跨商城场景高频出现的核心业务术语。AI 在生成分析、测试点和测试用例时必须优先使用这些词汇，禁止混用口语化同义词。
+>
+> 使用原则：
+> 1. 先使用本术语表中的标准词。
+> 2. 若需求文档使用了不同但已明确的项目术语，以需求文档为准。
+> 3. 对于行业内存在多种解释的术语，生成结果中应尽量写全称，避免简称歧义。
+> 4. 私域、分销、储值、CRM 等可选领域术语不放在本文件常驻输入中，由流水线按需求内容自动识别后补充加载。
+
+## 1. 角色与业务主体
+
+- **平台端**: 平台总部或品牌总部使用的管理后台，用于统一管理店铺、商品、营销、订单、会员、数据等能力。
+- **商家端**: 商家、门店、代理商或直营网点使用的经营后台，用于管理本商家可见范围内的商品、订单、营销和资产。
+- **用户端**: C 端消费者使用的前台，包括 App、H5、小程序、PC 商城等购买入口。
+- **店铺**: 面向用户提供商品或服务经营能力的业务主体，可理解为商家经营单元。
+- **门店**: 线下经营或履约单元，可能具备独立库存、独立配送范围、独立核销能力。
+- **供应商**: 提供商品、履约或货源支持的上游主体，可能影响供货价、库存和发货链路。
+- **运营人员**: 负责配置商品、活动、价格、运费、会员权益等后台能力的业务角色。
+- **客服**: 负责处理订单咨询、退款、售后、补单、异常协查等问题的后台角色。
+
+## 2. 商品与库存
+
+- **SPU**: 标准产品单位，表示一类商品的抽象定义，如“iPhone 15”。
+- **SKU**: 库存量单位，表示商品的最小可售规格，如“iPhone 15 黑色 256G”。
+- **商品规格**: 用于区分 SKU 的销售属性组合，如颜色、尺码、套餐版本。
+- **可售库存**: 当前可用于下单扣减的库存数量，不等于物理库存。
+- **锁定库存**: 用户下单后暂时占用、待支付或待确认释放的库存。
+- **回滚库存**: 订单取消、支付失败或超时关闭后，系统释放此前锁定库存的动作。
+- **超卖**: 实际成功售卖数量超过可售库存的异常情况。
+
+## 3. 购物与订单
+
+- **购物车**: 用户临时存放待购买商品的列表，不代表价格、库存、优惠结果最终已锁定。
+- **结算页**: 用户提交订单前的确认页面，用于展示最新商品、价格、库存、运费、优惠和实付信息。
+- **提交订单**: 用户确认购买并生成订单的动作，通常意味着进入待支付或待确认状态。
+- **订单**: 用户购买商品或服务形成的业务单据，是支付、履约、退款、售后的核心载体。
+- **子订单**: 拆单后形成的订单明细单元，常见于多商家、多仓、多履约场景。
+- **订单状态**: 订单在生命周期中的阶段标识，如待支付、待发货、待收货、已完成、已取消。
+- **订单关闭**: 因超时未支付、风控失败、系统取消等原因终止订单继续流转。
+- **逆向流程**: 订单创建后的反向处理链路，如取消、退款、退货退款、换货、补偿。
+
+## 4. 支付与资金
+
+- **待支付订单**: 已成功创建但尚未完成付款的订单状态。
+- **支付单**: 订单在支付环节生成的资金请求单据，用于对接三方支付或内部资金系统。
+- **支付流水**: 记录支付请求、支付结果、渠道单号、金额等信息的资金明细。
+- **支付方式**: 用户完成付款所使用的资金渠道，如微信支付、支付宝、余额、积分抵现。
+- **实付金额**: 用户最终实际支付的金额，通常等于应付金额减去各类可抵扣权益后的结果。
+- **原路退回**: 退款时按原支付方式、原资金路径退还用户资产的处理方式。
+- **挂账**: 订单生成但尚未完成付款，系统已形成应收记录但未完成资金入账的状态。
+- **资损**: 因金额计算错误、优惠错误、重复退款、库存超卖等问题导致平台或商家资产损失。
+
+## 5. 营销与优惠
+
+- **优惠券**: 可在满足条件时抵扣订单金额或给予折扣的营销权益。
+- **平台券**: 由平台统一发放和承担成本的优惠券，通常作用于平台范围内指定商品、店铺或活动。
+- **商家券**: 由商家或店铺发放和承担成本的优惠券，通常只在指定商家范围内可用。
+- **品类券**: 只对指定商品类目或商品范围生效的优惠券。
+- **满减券**: 订单或商品金额达到门槛后才可生效的优惠券。
+- **折扣券**: 以打折方式生效的优惠券，而非固定金额抵扣。
+- **优惠门槛**: 优惠生效所需满足的条件，如满 100 可减 20。
+- **适用范围**: 某个优惠可生效的商品、类目、店铺、用户、渠道或时间范围。
+- **优惠叠加**: 多种优惠是否允许同时生效的规则。
+- **优惠互斥**: 多种优惠不能同时生效，只能按优先级或选择规则命中其一。
+- **试算**: 在正式提交前，根据当前商品、用户、活动、券、积分等条件预估优惠和实付结果的过程。
+- **优惠分摊**: 将订单级优惠按规则分配到商品、子单、退款项上的计算过程。
+- **一口价**: 以固定成交价覆盖常规价格和营销计算链路的促销方式。
+- **满减送**: 满足金额或件数条件后，给予减价、赠品或附加权益的活动方式。
+- **限时折扣**: 在指定时间内生效的临时价格优惠活动。
+- **秒杀**: 在短时间窗口内以强时效、强库存约束进行的促销活动。
+- **拼团**: 通过多人组团满足条件后生效的营销活动。
+
+## 6. 会员与权益
+
+- **会员**: 具备等级、成长值、标签、专属价格或专属权益的用户身份。
+- **会员等级**: 用于区分会员权益范围的层级，如普通会员、VIP、SVIP。
+- **会员价**: 针对会员身份生效的专属销售价格或折扣规则。
+- **会员权益**: 会员可享受的专属能力，如会员价、包邮、积分加速、专属券等。
+- **积分**: 可用于兑换、抵现、成长或运营激励的虚拟权益资产。
+- **积分抵现**: 将积分按兑换比例折算为订单可抵扣金额的能力。
+- **余额**: 用户在平台或商家体系内预存或结余的可消费资金。
+
+## 7. 履约、售后与核销
+
+- **履约**: 订单支付后到商品或服务完成交付之间的执行链路，如发货、配送、自提、到店消费。
+- **发货**: 商家或仓库将商品交给物流或配送体系的动作。
+- **签收**: 用户确认收到商品或系统确认妥投的状态。
+- **售后**: 支付后围绕退款、退货、换货、补寄、补偿等问题展开的处理流程。
+- **整单退款**: 针对订单全部商品和全部已支付金额发起的退款。
+- **部分退款**: 针对订单中的部分商品、部分数量或部分金额发起的退款。
+- **退款分摊**: 在部分退款场景下，将优惠、运费、积分等按规则分配到退款项的过程。
+- **核销**: 对券码、提货码、预约码、订单码等进行校验并确认已消费/已使用的动作，常见于到店自提、到店服务、卡券消费场景。
+- **核销码**: 用于完成核销动作的识别码、二维码、条形码或数字口令。
+
+## 8. 风控、权限与系统能力
+
+- **风控拦截**: 系统判定交易、账号或操作存在风险后自动阻断继续执行的行为。
+- **权限控制**: 根据角色、数据范围、组织关系等限制用户可见、可操作范围的机制。
+- **越权**: 用户访问或操作了其本不应拥有权限的数据或功能。
+- **幂等性**: 同一业务请求被重复提交时，系统结果保持一致，且不会重复扣款、重复创建、重复退款或重复扣减资源。
+- **并发**: 多个请求或多个用户在同一时间窗口内对同一资源发起操作的情况。
+- **限流**: 为保护系统稳定性，对请求频率或并发量做出的限制。
+- **降级**: 当依赖异常或系统压力过大时，关闭部分非核心能力以保证核心链路可用的处理策略。
+- **回调**: 外部系统处理完成后主动通知本系统结果的机制，常见于支付、退款、物流等链路。
+- **审计日志**: 用于记录关键操作人、操作时间、操作对象和变更结果的可追溯日志。
+
+## 9. 术语使用约束
+
+- **订单关闭** 与 **退款成功** 不是同义词，关闭订单不代表资金已经退回。
+- **优惠券使用** 与 **核销** 不是同义词；商城下单抵扣通常描述为“使用优惠券”或“优惠券抵扣”，到店消费确认才更常用“核销”。
+- **挂账** 只在涉及应收记录或账务状态时使用；普通商城待支付场景优先写“待支付订单”。
+- **平台券**、**商家券**、**店铺券** 不应混写；若项目内三者含义不同，必须以项目需求或项目画像中的定义为准。
+- **退款**、**退货退款**、**换货**、**售后关闭** 不应混写，生成用例时要按实际逆向类型写全称。

knowledge_base/01_standards/terminology_optional_saas.md

@@ -0,0 +1,38 @@
+# 可选业务术语表（SaaS 扩展域）
+
+> 本文件只在需求文档、项目画像或关联需求明确涉及对应领域时才应纳入上下文。不要将这些术语默认用于所有商城项目。
+
+## 1. 渠道、导购与分销
+
+- **导购**: 负责客户触达、商品推荐、线索转化或门店服务的经营角色，常见于门店零售和私域运营场景。
+- **导购关系**: 用户与某个导购之间建立的归属或服务关系，常影响业绩归因、客户分配和权限范围。
+- **分销员**: 参与商品推广并按规则获得佣金的推广角色，可能是员工、店主、团长或普通用户。
+- **推广员**: 泛指承担推广职责并按规则归因或结算收益的角色，不一定等同于分销员。
+- **佣金**: 按推广、成交、拉新等规则计算并结算给导购、分销员或渠道方的收益。
+- **佣金结算**: 按订单状态、售后状态、结算周期等规则确认佣金是否可提现、可结算的过程。
+- **渠道活码**: 用于区分投放渠道、推广来源或归属关系的可追踪二维码/链接能力。
+
+## 2. 会员资产与储值
+
+- **储值余额**: 用户预先充值后留存在平台或商家体系中的可消费余额。
+- **礼品卡**: 预付型权益资产，可按卡号、卡密或账户绑定方式消费或抵扣。
+- **会员储值**: 面向会员体系提供的充值、赠送、消费、退款、冻结、解冻等余额管理能力。
+- **赠送金额**: 商家在储值、活动或运营场景下额外发放给用户的不可提现或有限制可用金额。
+- **可用余额**: 当前允许参与消费、抵扣或退款计算的余额，不一定等于账户总余额。
+- **冻结余额**: 因退款、风控、提现审核或待确认交易而暂时不可用的余额。
+
+## 3. 私域客户与 CRM
+
+- **企微客户**: 通过企业微信建立联系并沉淀在私域中的客户对象。
+- **客户标签**: 用于识别客户属性、分层、偏好、生命周期的标签集合。
+- **客户分群**: 按标签、行为、渠道、消费能力等规则聚合出的客户集合。
+- **客户归属**: 客户在组织、门店、导购、渠道之间的归属关系，常影响可见范围和业绩归因。
+- **生命周期**: 客户从拉新、激活、转化、复购到流失或召回的阶段划分。
+- **召回活动**: 面向沉默、流失或未转化客户进行再次触达和转化的运营活动。
+- **社群**: 围绕微信、企微或其他私域载体形成的客户经营集合，常关联群发、标签、活动、导购归属。
+
+## 4. 使用约束
+
+- **导购**、**分销员**、**推广员**、**渠道** 不应默认视为同一角色，必须按项目组织关系和结算规则区分。
+- **储值余额**、**赠送金额**、**礼品卡余额** 不应混写；三者通常具有不同的消费、退款、提现和过期规则。
+- **企微客户**、**会员**、**普通用户** 不一定是同一身份对象；若项目中存在账号打通或未打通，必须以需求定义为准。

knowledge_base/01_standards/test_case_template.md

@@ -0,0 +1,87 @@
+# 测试用例编写规范
+
+## 1. 用例结构标准
+所有生成的测试用例必须遵循以下字段结构：
+
+| 字段 | 说明 | 示例 |
+| :--- | :--- | :--- |
+| **用例编号** | 唯一标识，建议使用稳定英文缩写，格式 `端_模块_子模块_编号` | `PLT_MKT_MC_001` |
+| **模块** | 功能归属模块，建议使用层级路径表达 `端-一级模块-二级模块` | `平台端-营销管理-商家优惠券` |
+| **用例标题** | 简明扼要，动宾结构 | `验证使用有效优惠券下单成功` |
+| **优先级** | P0(核心流程), P1(主要功能), P2(次要/异常) | `P0` |
+| **类型** | 用例类型，必须使用团队枚举 | `功能测试` |
+| **前置条件** | 执行前必须满足的状态 | `用户已登录，购物车有商品` |
+| **测试步骤** | 分步骤描述操作，清晰无歧义 | `1. 点击结算 2. 选择优惠券` |
+| **测试数据** | 具体的输入数据（如有） | `优惠券码: TEST100` |
+| **预期结果** | 对应步骤的系统反馈，包含 UI 和数据 | `1. 订单金额减少100元 2. 跳转支付页` |
+| **备注** | 待确认项、历史缺陷来源或 AI 修正说明 | `[AI修正: 补充历史缺陷防御场景]` |
+
+## 2. 编写原则
+- **原子性**：一个用例只验证一个主要功能点。
+- **独立性**：用例之间尽量不依赖（除前置条件外）。
+- **可重复性**：预期结果必须明确，不能模棱两可。
+- **可追溯性**：每条用例应能追溯到需求条目、历史缺陷或团队规则。
+
+## 3. 类型字段规范
+
+- `类型` 必须从以下枚举中选择其一：
+  - `功能测试`
+  - `性能测试`
+  - `兼容性测试`
+  - `易用性测试`
+  - `安全性测试`
+  - `冒烟测试`
+  - `回归测试`
+  - `其他`
+- 默认优先使用 `功能测试`，不要滥用 `其他`。
+- 涉及权限绕过、抓包篡改、越权访问、敏感数据校验的场景，优先标记为 `安全性测试`。
+- 涉及 RT、吞吐、并发容量、性能基线的场景，标记为 `性能测试`。
+- 核心链路首轮冒烟验证可标记为 `冒烟测试`。
+- 来自历史缺陷或确认后的重点回归链路，可标记为 `回归测试`。
+
+## 4. 模块字段规范
+
+- **推荐层级**：`端-一级模块-二级模块`，必要时可扩展到 `端-一级模块-二级模块-功能点`。
+- **推荐示例**：
+  - `平台端-营销管理-平台优惠券`
+  - `平台端-营销管理-商家优惠券`
+  - `商家端-营销活动-商家优惠券`
+  - `用户端-下单结算-平台券使用`
+- **生成规范**：Markdown 表格中的 `模块` 列统一写 `-` 连接的层级路径，不直接写 `|`，避免表格分列风险。
+- **读取与导出规范**：脚本在读取 Markdown 和导出 Excel 时，会将模块路径自动标准化为 `|` 连接形式，例如：
+
+```text
+平台端-营销管理-商家优惠券
+-> 平台端|营销管理|商家优惠券
+```
+
+- **兼容说明**：历史数据如果已经使用 `平台端\|营销管理\|商家优惠券` 或 `平台端|营销管理|商家优惠券`，当前脚本仍可兼容读取。
+- **编号建议**：`用例编号` 不要直接使用中文模块路径，建议使用稳定英文缩写，例如：
+
+```text
+PLT_MKT_PC_001   # 平台端|营销管理|平台优惠券
+PLT_MKT_MC_001   # 平台端|营销管理|商家优惠券
+MCH_MKT_MC_001   # 商家端|营销活动|商家优惠券
+```
+
+## 5. 唯一表头
+
+最终 Markdown 表格必须严格使用以下表头顺序：
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+
+## 6. 云效导出映射
+
+- Excel 导出默认按团队云效字段模型输出：
+  - `标题`
+  - `编号`
+  - `目录`
+  - `创建时间`
+  - `前置条件`
+  - `步骤描述`
+  - `预期结果`
+  - `优先级`
+  - `类型`
+  - `URL`
+- Markdown 中的 `测试数据` 会在导出时自动并入 `步骤描述`，避免字段丢失。

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`：控制是否手动指定优惠券。

knowledge_base/03_best_practices/marketing_activity_cases.md

@@ -0,0 +1,52 @@
+# 营销活动类优秀用例范式
+
+> 适用于平台端/商家端活动配置、列表管理、状态流转、C 端资格展示与领取发放类需求。
+> 重点不是照抄标题，而是学习以下覆盖结构：后台正向成功链路、后台失败/限制链路、选择弹窗交互、端间数据隔离、C 端状态拆分、领取幂等与并发。
+
+## 推荐覆盖框架
+
+1. 后台列表能力
+- 列表字段
+- 默认排序与分页
+- 搜索、筛选、重置、空结果提示
+- 状态与操作栏映射
+
+2. 后台配置能力
+- 新建成功
+- 编辑成功
+- 时间/名称/奖品等失败态
+- 失效、删除、查看只读
+
+3. 选择弹窗能力
+- 刷新
+- 搜索
+- 字段展示
+- 分页
+- 排序
+- 单选/多选反馈
+- 数据归属范围
+
+4. C 端资格与展示
+- 进行中时展示
+- 未开始/已结束/已失效分别不展示
+- 老用户/未登录分别不展示
+- 奖品展示与后台一致
+- 广告等弹窗优先级
+
+5. 发放与稳健性
+- 领取成功
+- 幂等防重
+- 超时重试
+- 并发领取
+- 失败日志
+- 端间/角色间隔离
+
+## 示例用例
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| MKT_ACT_001 | 平台端-营销管理-活动配置 | 验证平台端新建合法营销活动可保存成功 | P0 | 功能测试 | 平台运营账号已登录；存在 1 个符合条件的活动资源；当前无时间冲突活动 | 1. 点击新建活动<br>2. 填写活动名称、时间、资源配置<br>3. 点击确定保存<br>4. 返回列表并进入详情查看 | 活动名称=春季促销；开始时间=明天 10:00；结束时间=后天 10:00 | 1. 页面提示创建成功<br>2. 列表新增活动记录且字段展示正确<br>3. 详情页展示与保存内容一致<br>4. 后台主表和资源明细表正确落库 | 示例 |
+| MKT_ACT_002 | 平台端-营销管理-资源选择弹窗 | 验证资源选择弹窗支持刷新搜索分页排序和单选反馈 | P1 | 功能测试 | 平台运营账号已登录；资源池存在多条可用与不可用资源 | 1. 打开资源选择弹窗<br>2. 点击刷新<br>3. 按名称搜索<br>4. 切换分页和排序<br>5. 选择 1 条资源并确认返回 | 关键字=春季；分页项=10/20；目标资源=RES_1001 | 1. 刷新、搜索、分页、排序行为正确<br>2. 列表字段展示完整<br>3. 不符合条件资源不可选或不展示<br>4. 选中后页面正确回填资源信息 | 示例 |
+| MKT_ACT_003 | 商家端-营销管理-活动列表 | 验证商家端列表字段和状态按钮映射正确 | P1 | 功能测试 | 商家端存在未开始、进行中、已结束、已失效四类活动；商家账号已登录 | 1. 进入活动列表<br>2. 逐条核对活动字段和操作栏<br>3. 对比不同状态按钮 | 活动A=未开始；活动B=进行中；活动C=已结束；活动D=已失效 | 1. 列表字段完整且内容正确<br>2. 未开始/进行中/已结束/已失效的操作按钮按规则展示<br>3. 不出现错态按钮或越权操作入口 | 示例 |
+| MKT_ACT_004 | 用户端-首页-活动弹窗 | 验证活动未开始时首页不展示活动弹窗 | P1 | 功能测试 | 存在 1 条未开始活动；用户满足基础资格；当前无其他进行中活动 | 1. 用户进入首页<br>2. 观察首页弹窗<br>3. 查询资格检查结果 | 活动开始时间=当前时间后 1 小时 | 1. 首页不展示活动弹窗<br>2. 资格检查返回无可领取活动或活动未开始<br>3. 页面不提前曝光活动入口 | 示例 |
+| MKT_ACT_005 | 用户端-首页-活动领取 | 验证同一用户重复点击领取时仅成功一次 | P0 | 回归测试 | 用户满足资格；存在进行中活动；前端可模拟快速重复点击 | 1. 打开活动弹窗<br>2. 1 秒内连续点击领取 3 次<br>3. 查询权益结果和发放日志 | 用户ID=USER_1001；重复点击次数=3 | 1. 页面最多提示 1 次成功<br>2. 用户仅获得 1 份权益<br>3. 发放日志仅有 1 条成功记录<br>4. 其余请求被幂等拦截 | 示例 |

knowledge_base/03_best_practices/payment_flow_cases.md

@@ -0,0 +1,9 @@
+# 支付模块优秀用例范例
+
+> 请参考以下用例的颗粒度、数据具体化方式以及“UI + 数据状态”双重预期写法。
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| PAY_01_001 | 用户端-交易链路-支付 | 验证正常支付流程成功 | P0 | 冒烟测试 | 用户已登录，购物车存在可售商品 | 1. 选择商品点击购买<br>2. 在收银台选择支付宝支付<br>3. 完成支付授权 | 用户A；商品SKU-001；支付方式=支付宝 | 1. 页面跳转支付渠道并返回成功页<br>2. 订单状态变更为“待发货”<br>3. 支付流水生成且金额与订单实付一致 | 示例 |
+| PAY_01_002 | 用户端-交易链路-支付 | 验证支付超时后订单自动取消 | P1 | 功能测试 | 用户已登录，已成功创建待支付订单 | 1. 进入待支付订单详情页<br>2. 不做支付，等待 30 分钟 | 订单号=ORDER-10001 | 1. 页面提示订单已超时取消<br>2. 订单状态变更为“已取消”<br>3. 预占库存回滚 | 示例 |
+| PAY_01_003 | 用户端-交易链路-支付 | 验证支付渠道返回余额不足时可切换支付方式 | P1 | 功能测试 | 用户已登录，存在待支付订单 | 1. 选择银行卡支付<br>2. 模拟支付渠道返回“余额不足”<br>3. 切换到支付宝支付 | 订单号=ORDER-10002；银行卡返回码=BALANCE_NOT_ENOUGH | 1. 页面提示余额不足<br>2. 订单仍保持待支付状态<br>3. 用户可继续选择其他支付方式完成支付 | 示例 |