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/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 中的 `测试数据` 会在导出时自动并入 `步骤描述`，避免字段丢失。