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

output/analysis/新人礼需求_关联与冲突.md

@@ -0,0 +1,16 @@
+# 新人礼需求 关联需求与冲突检查
+
+## 目标需求
+- `source_docs/requirements_raw/新人礼需求.docx`
+
+## 项目画像
+- `knowledge_base/00_project/project_profile.md`
+
+## 关联技术方案
+- `source_docs/technical_solutions/新人礼技术方案.docx`
+
+## 关联需求识别
+- 未识别到相似度达到阈值的历史需求文档。
+
+## 潜在冲突与修改建议
+- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。

output/analysis/新人礼需求_分析.md

@@ -0,0 +1,111 @@
+# 新人礼需求分析
+
+## 背景与目标
+
+本期需求围绕“新人礼”活动能力建设，目标是在平台端和商家端支持配置新人礼活动，并在 C 端针对符合新人条件的用户展示领取入口与发放优惠券奖励，提升新注册用户的首单转化。
+
+技术方案补充了两个关键限制：
+
+- 同一时间仅允许存在 1 个进行中的新人礼活动。
+- 每个新人礼活动仅允许绑定 1 张优惠券，发放结果需落新人礼发放记录表。
+
+## 范围与边界
+
+### 范围内
+
+- 平台端“营销-新人有礼”列表、查询、新建、编辑、查看、失效、删除。
+- 商家端“营销-新人有礼”同构能力。
+- 新人礼活动配置字段校验：活动名称、活动时间、活动奖品、优惠券选择。
+- 优惠券选择范围控制：平台端仅选平台券，商家端仅选本店铺优惠券。
+- C 端首页和门店首页的新人礼弹窗检查与领取。
+- 发放成功后的优惠券入账和发放记录落库。
+- `ua/newGift/check` 与 `ua/newGift/send` 对应的资格校验和发放行为。
+
+### 范围外
+
+- 积分类型新人礼，需求和技术方案均明确“暂不支持”。
+- 下单后退款再重新认定为新人场景，技术方案明确“暂不支持下单后退款场景”。
+- 多奖品、多券组合、多人拼抢同一活动池等扩展玩法。
+
+## 用户角色与前置条件
+
+- 平台运营：维护平台维度新人礼活动。
+- 商家运营：维护店铺维度新人礼活动。
+- C 端用户：登录后触发首页或门店首页新人礼检查与领取。
+- 后端系统：负责活动状态判断、资格校验、优惠券发放、发送日志写入。
+
+前置条件：
+
+- 已存在投放中、未过期、领取方式为“用户领取”的优惠券。
+- 用户已登录，且能获取平台维度与店铺维度的历史下单信息。
+- 发券接口可用，优惠券中心返回的券状态准确。
+
+## 关键业务规则
+
+1. 平台端和商家端都可以配置新人礼活动，但优惠券范围必须与端侧归属一致。
+2. 活动名称最多 50 个字。
+3. 活动开始时间必须大于等于当前时间，结束时间必须大于开始时间。
+4. 活动奖品当前仅支持优惠券，且每个活动仅能关联 1 张优惠券。
+5. 平台维度同一时间仅允许 1 个进行中的平台新人礼活动；店铺维度同一时间每个店铺仅允许 1 个进行中的门店新人礼活动。
+6. 新人判定按订单提交结果范围判断：平台新人礼查询平台范围订单，店铺新人礼查询当前店铺订单；若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单等），仍视为新人。
+7. 用户登录首页时，若存在进行中的新人礼活动且用户未领取过，则展示新人礼弹窗。
+8. 门店首页只对门店新人展示门店新人礼弹窗。
+9. 若同时存在弹窗广告，新人礼弹窗必须先于广告弹窗展示。
+10. 用户点击立即领取成功后，奖励进入“我的优惠券”，同时写入新人礼发放记录。
+11. 活动“已结束”和“已失效”并存时，页面优先展示“已失效”。
+12. 活动失效后状态展示为“已失效”，并支持后续删除。
+13. 用户领取平台新人礼后，若仍满足门店新人条件，允许继续领取门店新人礼。
+
+## 主流程描述
+
+1. 运营在平台端或商家端进入“营销-新人有礼”列表页。
+2. 运营新建活动，填写活动名称、活动时间并选择 1 张符合条件的优惠券。
+3. 系统校验时间、优惠券范围、优惠券状态和活动并存规则，保存活动。
+4. 活动进入“未开始”或“进行中”状态，列表页按状态展示可操作按钮。
+5. C 端用户登录平台首页或门店首页时，调用资格检查接口。
+6. 若存在进行中的匹配活动且用户符合新人条件且未领取过，则展示新人礼弹窗。
+7. 用户点击“立即领取”，系统发放优惠券并记录发放日志。
+8. 发放成功后，用户可在个人中心优惠券列表查看奖励。
+
+## 跨需求关联与冲突修订建议
+
+- 当前未识别到需要纳入本次评审的关联需求，也未发现需要基于历史需求执行的规则冲突修订。
+- 当前无需对历史需求做口径覆盖修订，但仍需重点防御营销类公共风险：
+  - 重复点击导致重复发放。
+  - 前端传参篡改导致越权选券或跨店铺发券。
+  - 状态变更与页面展示不一致。
+
+## 技术方案补充约束
+
+- `ua/newGift/check` 负责资格检查，应重点验证平台维度和店铺维度“新人”判定口径。
+- `ua/newGift/send` 负责发券，应重点验证幂等、防重复领取、失败原因记录和成功落库。
+- 数据模型拆分为主表、礼物关联表、发放记录表，说明测试不能只看页面成功提示，还要覆盖：
+  - `new_gift` 主表活动状态和有效性字段。
+  - `new_gift_detail` 活动与券的绑定关系。
+  - `new_gift_send_log` 发放成功或失败记录。
+- 技术目标给出用户响应 RT 1000ms，应至少对资格检查和领取动作补充性能基线关注。
+
+## 产品确认口径
+
+- 活动并存范围：平台维度同一时间仅允许 1 条进行中的平台活动；店铺维度同一时间每个店铺仅允许 1 条进行中的门店活动。
+- 新人判定口径：若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单），仍视为新人。
+- 状态展示优先级：活动“已结束”和“已失效”并存时，优先展示“已失效”。
+- 平台礼与门店礼关系：用户已领取平台新人礼后，只要满足门店新人条件，仍允许领取门店新人礼。
+
+## 项目差异化测试约束
+
+- 平台端、商家端、C 端是三套角色链路，必须覆盖角色隔离和数据隔离。
+- 这是典型营销发券能力，需重点覆盖越权选券、重复发放、状态错发和资损场景。
+- 预期结果必须同时覆盖 UI 反馈和后台状态变化，特别是活动状态、券领取结果、发放日志。
+
+## 风险点与确认结果
+
+- 风险点：重复点击“立即领取”或接口重试导致同一用户重复发放优惠券。
+- 风险点：商家端错误选择了其他店铺的优惠券，导致跨店资损或越权发券。
+- 风险点：活动失效、已结束、已删除三个状态口径不清，可能导致列表按钮和实际行为不一致。
+- 风险点：平台新人和店铺新人的判定依赖历史订单数据，若口径不清，容易误发或漏发。
+- 风险点：同一时间仅允许 1 个进行中的活动，如果平台端和商家端同时配置活动，范围口径不清会导致规则冲突。
+- 确认结果：平台端和商家端活动可以并存，但约束粒度为“平台一条、每店铺各一条”。
+- 确认结果：未支付取消、超时未付、已退款等最终交易关闭单据不影响新人资格。
+- 确认结果：活动“已结束”和“已失效”同时成立时，页面优先展示“已失效”。
+- 确认结果：已领取平台新人礼的用户，若满足门店新人条件，仍允许继续领取门店新人礼。