feat: 安徽运八需求全流水线输出同步 + 知识库/agents/资源文件更新

output/analysis/knowledge_sync_20260713.md

@@ -0,0 +1,114 @@
+# 知识库同步报告
+
+> 生成时间: 2026-07-13
+> 同步引擎: Agentic QE Fleet — knowledge-curator
+> 同步类型: 全量知识库健康检查 + 交叉引用一致性修复
+
+---
+
+## 📊 知识库健康度
+
+| 指标 | 值 |
+| :--- | :--- |
+| 知识库文件总数 | 14 |
+| 健康文件 | 10 |
+| 需关注文件 | 3 (已修复) |
+| 不适用/归档文件 | 3 (已标记) |
+| 历史缺陷总数 | 4 |
+| 易漏场景总数 | 35+ (6大类 + 子项) |
+| 最佳实践范例数 | 4 个领域 (数据上报/货源/营销/支付) |
+| 术语条目数 | 60+ (7大类) |
+| 重复率 | 0% (去重检查通过) |
+
+---
+
+## 🔧 本次同步修复
+
+### Fix 1: 清理 `order_manage_cases.md` 空表行
+
+- **问题**: 文件包含 4 行空表格行（`| | | | | | | | | | |`），且用例编号使用 `MKT_ACT` 前缀（营销活动），与货源管理领域不符
+- **修复**: 删除空行，修正用例编号为 `SRC_CFG_001`（Source Configuration）
+- **文件**: `knowledge_base/03_best_practices/order_manage_cases.md`
+
+### Fix 2: 标注 `payment_flow_cases.md` 项目差异
+
+- **问题**: 文件包含通用电商支付示例（支付宝/银行卡），与运八项目云企付二期 (arpa_2) 支付流程存在结构性差异
+- **修复**: 在文件头添加 ⚠️ 提示，标注运八实际支付链路为 `货主打款 → 平台 → 财务打款 → 司机/车队长`，引导 AI 以 `project_profile.md` §5.1 为准
+- **文件**: `knowledge_base/03_best_practices/payment_flow_cases.md`
+
+### Fix 3: 建立历史缺陷 ↔ 易漏场景交叉引用
+
+- **问题**: `historical_defects.md` 中的 4 个缺陷与 `common_missed_scenes.md` §6 的防御场景存在直接映射关系，但无显式引用
+- **修复**: 在 `historical_defects.md` 中为每个缺陷添加 `关联易漏场景` 字段，指向 `common_missed_scenes.md` 对应条目；在文件头添加关联知识说明
+- **映射关系**:
+  - `BUG-202607-01` → §6.多阶段依赖链
+  - `BUG-202607-02` → §6.重试+手动触发并发
+  - `BUG-202607-03` → §6.跨模块数据一致性 / §6.上报数据字段溯源
+  - `BUG-202607-04` → §6.省份/区域配置隔离
+- **文件**: `knowledge_base/02_history/historical_defects.md`
+
+### 已确认清理（前置变更）
+
+- **删除占位示例缺陷** `BUG-202310-05--示例`（购物车价格缓存）：该示例为通用电商场景，与运八网络货运平台领域无关，已在工作树中移除 ✅
+
+---
+
+## 📋 知识库文件逐项审计
+
+### ✅ 健康文件 (10)
+
+| 文件 | 类别 | 状态 | 备注 |
+| :--- | :--- | :---: | :--- |
+| `00_project/project_profile.md` | 项目画像 | ✅ | 2026-07-10 更新，352 菜单项，完整 |
+| `00_project/operation_manual.md` | 操作手册 | ✅ | 2026-07-10 采集，184 截图，完整 |
+| `01_standards/terminology.md` | 核心术语 | ✅ | 含 §7 数据上报术语，60+ 条目 |
+| `01_standards/test_case_template.md` | 用例模板 | ✅ | 结构完整，含云效导出映射 |
+| `01_standards/review_checklist.md` | 评审清单 | ✅ | 9 大类检查项，阻断/建议分级 |
+| `01_standards/definition_of_done.md` | 完成定义 | ✅ | 8 维度质量门槛 |
+| `02_history/historical_defects.md` | 历史缺陷 | ✅ | 4 个真实缺陷，已建立交叉引用 |
+| `02_history/common_missed_scenes.md` | 易漏场景 | ✅ | 6 大类 35+ 子项，§6 来自安徽运八 |
+| `03_best_practices/data_reporting_cases.md` | 数据上报范例 | ✅ | 8 维度覆盖框架 + 5 条示例用例 + 风险矩阵 |
+| `03_best_practices/order_manage_cases.md` | 货源范例 | ✅ | 已清理空行，修正编号前缀 |
+
+### ⚠️ 归档/不适用文件 (3)
+
+| 文件 | 类别 | 状态 | 说明 |
+| :--- | :--- | :---: | :--- |
+| `02_history/marketing_rules.md` | 营销规则 | 📦 归档 | 来自 zanmall 项目，运八不支持营销活动 |
+| `03_best_practices/marketing_activity_cases.md` | 营销范例 | 📦 归档 | 运八 `project_profile.md` §4 明确禁用 |
+| `01_standards/terminology_optional_saas.md` | SaaS术语 | 📦 休眠 | 私域/导购/储值/CRM，当前项目不触发 |
+
+> 以上 3 个文件不会被知识激活器加载（关键词不匹配），但保留在知识库中供未来多项目复用。
+
+---
+
+## 🔍 知识缺口识别
+
+| 缺口类别 | 描述 | 严重度 | 建议 |
+| :--- | :--- | :---: | :--- |
+| 运八支付范例 | `payment_flow_cases.md` 缺少运八特有支付场景（垫资打款、合并打款、清分结算）的示例用例 | P2 | 下次遇到支付相关需求时从执行结果中提取 |
+| ETC 开票范例 | 项目含完整的 ETC 管理/开票模块（§2.15-2.16），但知识库无对应最佳实践 | P2 | 下次 ETC 相关需求时沉淀 |
+| 财务统计范例 | 项目含 12+ 报表页面，但知识库无报表类测试范例 | P3 | 按需补充 |
+| 合同管理范例 | 项目含 8 种合同类型，但知识库无合同管理测试范例 | P3 | 按需补充 |
+
+---
+
+## 📈 知识库演进历史
+
+| 时间 | 事件 | 影响文件 |
+| :--- | :--- | :--- |
+| 2026-07-13 | 知识同步：清理占位内容、建立交叉引用 | `historical_defects.md`, `order_manage_cases.md`, `payment_flow_cases.md` |
+| 2026-07-13 | 安徽运八知识回写：4 个历史缺陷 + 易漏场景 §6 + 数据上报范例 | `historical_defects.md`, `common_missed_scenes.md`, `data_reporting_cases.md`, `terminology.md` |
+| 2026-07-10 | 项目画像初始化：Playwright 采集 352 菜单项 | `project_profile.md`, `operation_manual.md` |
+
+---
+
+## ✅ 同步结论
+
+- **整体健康度**: 🟢 良好
+- **阻断问题**: 0
+- **本次修复**: 3 项
+- **待确认项**: 0
+- **知识缺口**: 4 个（均为 P2/P3，不阻断当前工作流）
+
+知识库处于健康状态，交叉引用已建立，AI 可从历史缺陷追溯到易漏场景清单，生成测试点时形成完整防御链。

output/analysis/安徽运八需求_关联与冲突.md

@@ -1,7 +1,7 @@
 # 安徽运八需求 关联需求与冲突检查
 
 ## 目标需求
-- `source_docs\requirements_raw\安徽运八需求.docx`
+- `source_docs\requirements_raw\安徽运八需求.md`
 
 ## 项目画像
 - `knowledge_base\00_project\project_profile.md`
@@ -10,9 +10,7 @@
 - 未识别到同主题技术方案文档。
 
 ## 关联需求识别
-| 序号 | 关联需求 | 相似度 |
-| :--- | :--- | :--- |
-| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 |
+- 未识别到相似度达到阈值的历史需求文档。
 
 ## 潜在冲突与修改建议
 - 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。

output/analysis/安徽运八需求_分析.md

@@ -1,106 +1,189 @@
-# 安徽运八需求 分析报告
+# 安徽运八需求 结构化分析
 
-> 生成时间: 2026-07-13
-> 文档角色: 需求分析
-> 原始来源: `source_docs/requirements_raw/安徽运八需求.docx`
+> 生成时间: 2026-07-13（最后更新: 2026-07-14，根据14项确认决议）
+> 需求文档: source_docs/requirements_raw/安徽运八需求.docx
+> 重构需求: output/normalized_inputs/安徽运八需求/requirement_restructured.md（以API文档V1.0.2为查询+申诉权威数据源，以Showdoc文档为上报接口字段定义权威数据源）
+> Showdoc上报接口文档: output/prototype/showdoc文档.md（5个上报接口 + FAQ）
+> 项目画像: knowledge_base/00_project/project_profile.md
 
-## 1. 需求概述
+## 1. 需求背景
 
-根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。
+根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将税源地为安徽运八的运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八），其他税源地不走此逻辑。
 
-### 核心目标
-- 实现上报流程的自动化管理（自动触发 + 重试 + 通知）
-- 提供异常监控与核验结果展示
-- 提供向监管平台发起申诉的完整闭环能力
-- ETC发票上传作为税务抵扣凭证
+## 2. 目标
 
-### 涉及角色
-- 运营人员：看板监控、手动上传、发起申诉
-- 系统：自动触发上报、自动重试、自动更新字段
-- 监管平台（安徽运八）：核验上报数据、返回核验结果
-- 司机/财务：触发装货完成/打款完成/开票完成（间接触发上报）
+实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。
 
-## 2. 功能模块分析
+## 3. 用户角色
 
-| 模块 | 功能 | 触发方式 | 依赖 | 关键风险 |
-| :--- | :--- | :--- | :--- | :--- |
-| 上报运单看板 | 汇总展示、筛选查询、导出 | 手动访问 | 无 | 数据量大时性能 |
-| 第一次上报 | 装货完成后上报基础运单数据 | 自动触发 | 运单装货完成 | 失败阻断后续上报 |
-| 第二次上报 | 打款完成后上报资金流水+轨迹 | 自动触发 | 第一次上报通过 | 7类核验，异常最多 |
-| 第三次上报 | 开票完成后上报发票数据 | 自动触发 | 第二次上报通过 | 发票验证失败 |
-| ETC发票上传 | 税务抵扣后上传ETC发票 | 手动触发 | 税务抵扣完成 | 税额计算精度 |
-| 异常申诉 | 核验异常→申诉→监管复核→结果 | 手动触发 | 核验异常 | 申诉闭环完整性 |
-| 上报日志 | 接口调用记录、请求/响应查看 | 手动访问 | 无 | 日志完整性 |
+| 角色 | 职责 |
+| :--- | :--- |
+| 平台运营人员 | 查看看板、发起申诉、监控上报状态 |
+| 系统自动 | 自动触发三阶段上报和ETC上传 |
+| 财务人员 | 打款操作（触发第二次上报） |
+| 安徽监管平台 | 接收上报数据、执行核验、反馈结果 |
 
-## 3. 关键业务规则
+## 4. 功能模块
 
-### 3.1 上报阶段依赖链
-```
-装货完成 → 第一次上报 → 核验通过 → 自动更新字段
-    ↓
-打款完成 → 第二次上报 → 7类核验（车辆资质/司机资质/资金流水/集中支付/合同/轨迹合规/运单重复）
-    ↓
-开票完成 → 第三次上报 → 发票验证
-    ↓
-税务抵扣 → ETC发票上传
-```
+### 4.1 上报运单看板
+集中展示所有上报阶段运单的汇总状态，支持按条件筛选（运单号/托运单号/货源单号模糊搜索、上报阶段、核验状态、申诉状态）、查看详情和发起申诉。
 
-### 3.2 重试策略
-- 所有上报阶段：失败后自动重试，最多3次
-- 3次全部失败：通知运营人员（站内信/其他方式）
-- 重试期间幂等保护：不产生重复上报
+### 4.2 委托合同上传（前置步骤）
+运单第一次上报前，需先将委托合同（框架）通过 `/api/dataUpload/mandateContractFrame`（Showdoc定义）上传至省平台。委托合同（框架）和委托合同二选一上报。合同文件可暂不传，后续通过修改接口补充。
 
-### 3.3 状态机
-```
-上传中(蓝) ──成功→ 已上传(绿)
-上传中(蓝) ──超时→ 上传失败(红) → 手动上传 → 上传中
-上传中(蓝) ──校验失败→ 异常(橙) → 查看详情
-```
+### 4.3 第一次上报（装货完成）
+运单装货完成后自动触发，仅上传货源税源地为安徽运八的运单。上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。核验通过后自动调用"修改第一次上报部分字段"接口。
 
-### 3.4 申诉状态机
-```
-未申诉 → 申诉中 → 申诉通过(绿) / 申诉驳回 → 重新申诉 → 申诉中
-```
+### 4.4 第二次上报（打款完成）
+运费支付完成后自动触发，上报数据包含资金流水信息、车辆轨迹信息等。监管平台进行核验。⚠️ 根据网货企业端接口文档 V1.0.2 §4.1，核验项从需求描述的7类扩展为API定义的17项独立核验项：100=委托合同、120=承运合同、130=实时定位、140=运单时间逻辑、150=车辆资质、160=道路运输证、170=驾驶证、180=从业资格证、190=车辆重复、200=司机重复、210=车辆轨迹、220=运费收款、230=公司统一收款、240=集中支付、250=资金流水、260=发票信息、270=非通行车辆可开票。每项有独立的核验结果和申诉入口。
 
-## 4. 数据量预估
+### 4.5 第三次上报（开票完成）
+发票开具完成后触发，上报数据包含运单信息、发票信息、油气发票信息等。
 
-| 对象 | 预估量级 | 说明 |
-| :--- | :--- | :--- |
-| 日上报运单数 | 1000-5000 | 根据平台运单量 |
-| 每运单轨迹点数 | 2-2000 | 取决于运输距离 |
-| 申诉并发量 | < 100/天 | 异常率较低 |
-| 日志保留期 | 建议≥90天 | 审计和排查需要 |
+### 4.6 ETC发票上传
+ETC发票税务抵扣成功后，由运营人员在运八系统**手动确认抵扣完成**，确认后系统触发ETC发票上传（非自动触发）。上传信息包含车牌号、车牌颜色、ETC发票号、不含税金额(invoiceAmount)、税率3%、税额、价税合计(totalPriceAndTax)、入口/出口收费站、交易时间等。
 
-## 5. 歧义标注
+### 4.7 异常申诉功能
+补全"异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断"的完整闭环。
 
-> ⚠️ 待确认：重试间隔时间未在需求中明确，建议确认（如30s/60s/120s递增）
-> 影响范围: 所有上报阶段的重试行为
-> 建议确认方向: 与产品和安徽运八平台确认合理的重试间隔
+### 4.8 上报日志
+记录所有上报接口的调用记录（请求/响应报文、HTTP状态码、响应时间），用于问题排查和审计。
 
-> ⚠️ 待确认：站内信通知的具体内容模板未定义
-> 影响范围: 运营人员通知体验
-> 建议确认方向: 确认通知应包含哪些字段（运单号/失败原因/重试次数/建议操作）
+## 5. 核心规则
 
-> ⚠️ 待确认：上报数据中"省份代码"字段默认值（当前项目属云南省=28，但本需求为安徽=34？）
-> 影响范围: 第一次上报司机信息省份代码
-> 建议确认方向: 确认安徽运八上报的省份代码应使用哪个值
+### 5.1 税源地过滤
+- 仅税源地为安徽运八的运单触发上报
+- 其他税源地（如云南=28）不触发任何上报
 
-> ⚠️ 待确认：导出Excel的数据量上限未定义
-> 影响范围: 看板导出功能
-> 建议确认方向: 确认是否需要限制单次导出条数（如最多10000条）
+### 5.2 上报阶段依赖链
+- 第一次上报是后续两次上报的基础
+- 第二次上报依赖第一次上报完成
+- 第三次上报依赖第二次上报完成
+- 后端必须做前置状态校验（非仅前端控制）
 
-## 6. 与项目画像的差异化分析
+### 5.3 自动重试机制
+- 各阶段上报失败后自动重试（最多3次）
+- 3次全部失败后告警通知运营人员
+- 重试期间禁止手动触发上传
 
-| 维度 | 项目画像（云南省） | 安徽运八需求 | 差异 |
-| :--- | :--- | :--- | :--- |
-| 上报省份 | 云南省(reportProvince=28) | 安徽省 | 省份代码需切换 |
-| 支付方式 | arpa_2 + 网商银行(浦发/快钱/光大) | 同平台支付体系 | 资金流水需关联现有支付渠道 |
-| 目标角色 | 运营/货主/车队长/司机/财务 | 主要面向运营人员 | 权限模型可复用 |
-| 测试环境 | ybxcx.ynyun8.com:8000 | 同环境 | 测试环境可复用 |
+### 5.4 核验规则
+- 第二次上报包含**17项独立核验**（API文档§4.1定义），比需求的7类更为细化
+- 核验异常可通过申诉机制向监管平台说明情况
+- 每项核验有独立的核验结果（verificationCode/verificationName/verificationState）和申诉入口
+- 申诉由安徽监管平台复核
 
-## 7. 风险总结
+> **核验项扩展说明（来源：API §4.1）**: 原始需求仅描述7大类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/轨迹合规），但API文档§4.1定义了完整的17项独立核验项（100=委托合同, 120=承运合同, 130=实时定位, 140=运单时间逻辑, 150=车辆资质, 160=道路运输证, 170=驾驶证, 180=从业资格证, 190=车辆重复, 200=司机重复, 210=车辆轨迹, 220=运费收款, 230=公司统一收款, 240=集中支付, 250=资金流水, 260=发票信息, 270=非通行车辆可开票）。每项有独立的核验结果和申诉入口，测试覆盖需从14条（7类×通过+异常）扩展到34条（17项×通过+异常）。
 
-| 风险ID | 类别 | 等级 | 说明 |
-| :--- | :--- | :---: | :--- |
-| RISK-FINANCIAL | 资损 | P1 | 资金流水金额不匹配、流水号重复可能导致财务数据错误 |
-| RISK-AVAILABILITY | 可用性 | P2 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 |
+### 5.5 API接口清单（来自网货企业端接口文档 V1.0.2）
+
+| 接口 | URL | 方法 | 说明 |
+|:---|:---|:---:|:---|
+| 获取token | /sys/login | POST | JWT认证 |
+| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 |
+| 提交申诉运单 | /appeal/insert | POST | 发起申诉 |
+| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails（17项核验明细） |
+| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 |
+| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 |
+| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规（需求未提及！） |
+| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 |
+| 运单里程申诉 | /mileageAppeal/insert | POST | 提交里程申诉（需求未提及的新功能！） |
+
+### 5.6 申诉状态枚举（以API §4.4为权威）
+
+| Code | API名称(§4.4权威) | 原始需求对应 | 原型对应 | 我方可操作 | 说明 |
+|:---:|:---|:---|:---|:---:|:---|
+| 100 | **未申诉** | 未申诉 + 申诉中 | 未申诉 + 待省平台反馈 + 反馈处理中 | 是 | 含已提交但省平台尚未审核的情况（申诉"进行中"通过 abnormalDetails[].state=110 标识） |
+| 110 | **审核通过** | 申诉通过 | 申诉通过 | 否（终态） | 终态 |
+| 120 | **审核不通过** | 申诉驳回 | 申诉驳回 | 否（可重新申诉） | 可重新申诉 |
+| 130 | **已取消** | （无） | （无） | **否·省平台只读** | 省平台侧操作取消申诉，我方系统不提供"取消申诉"功能，仅查询展示此状态 |
+
+> **已取消(130)专项说明**: 
+> - 状态130=已取消的触发在省平台侧（省平台管理员取消），非我方可操作。
+> - 我方系统**不提供"取消申诉"按钮或接口**，不测试我方主动取消申诉的用例。
+> - 申诉状态流转（我方视角）：未申诉(100) → 审核通过(110) [终态]；未申诉(100) → 审核不通过(120) → 重新申诉 → 未申诉(100)。
+> - 看板筛选下拉值以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130仅作筛选展示。
+
+### 5.7 申诉单项约束（API §3.3）
+
+- 接口 `POST /appeal/insert` 的 `verificationAbnormalItems` 参数说明为**"只支持单个异常项目申诉"**
+- 每次申诉仅针对**一个**核验异常项
+- 同一运单有多个异常项时，需分别发起多次申诉（每项一个申诉单）
+- 申诉流程必须包含**异常项单选步骤**，不允许批量勾选后一次提交
+- 传入多个异常项ID（如 `"120,160"`）时，接口应拒绝并返回错误提示
+
+## 6. 数据字段（以Showdoc为权威字段定义）
+
+> **授权来源**: Showdoc文档（`output/prototype/showdoc文档.md`）定义上报接口字段结构。关键精度要求：上报接口时间格式为 `yyyyMMddHHmmss`（14位），第二次上报金额保留3位小数（如整数以.000填充），ETC invoiceAmount为不含税金额。
+
+### 6.1 第一次上报核心字段（Showdoc: firstUpload）
+- waybillInfo（建单信息）: 13字段必选（含mileage可选）
+- consignorInfo（托运人信息）: 7字段必选
+- consigneeInfo（收货方信息）: 6字段必选（含unLoadingNationSubdivisionCode）
+- driverInfo（司机信息）: 15字段必选（含registerDate、anchoredUrl）
+- carInfo（接单车辆信息）: 20字段必选（含anchoredUrl）
+- goodsInfos（货物信息）: 4字段/条必选（quantity=Double）
+- insuranceInformation（保险信息）: 2字段可选
+
+### 6.2 第二次上报核心字段（Showdoc: secondUpload）
+- arrivalInfo（运抵信息）: 6字段必选（含startTicketFileUrl、arrivalTicketFileUrl）
+- ownerStatements（货主流水）: 13字段必选（monetaryAmount=Double·3位小数）
+- carrierStatements（承运人流水）: 14字段必选（含oilCardAmount·replaceAgreementFiles）
+- carrierContractInfo（承运合同）: 18字段必选（含contractUrl·金额3位小数）
+- ownerContractInfo（委托合同）: 18字段可选（委托合同与框架合同二选一）
+- trackList（车辆轨迹）: 6字段/点必选（2~2000个点）
+
+### 6.3 第三次上报核心字段（Showdoc: thirdUpload）
+- invoice（货主发票）: 17字段必选（含invoiceUrl文件）
+- oilGasInvoices（油气发票）: 选填，可多条
+
+### 6.4 ETC发票核心字段（Showdoc: etcInvoiceUpload）
+- etcInvoices（ETC发票）: **17字段/张**（invoiceAmount=不含税金额·保留2位小数·税率3%）
+
+## 7. 状态流转
+
+### 7.1 上报状态
+上传中(蓝色) → 已上传(绿色) / 上传失败(红色) / 异常(橙色)
+
+### 7.2 申诉状态（我方流转）
+未申诉 → 申诉中 → 申诉通过 / 申诉驳回 → 重新申诉
+
+> 已取消(130)由省平台侧操作，不纳入我方流转。
+
+## 8. 歧义标注与待确认项（14项已全部确认 ✅）
+
+> **更新 2026-07-14**: 以下14项全部通过用户确认决议。方框标记为确认结果。
+
+### 8.1 核验项定义差异 ✅
+> ✅ 确认: 以API文档§4.1 17项为准。17项核验全部展示，每项可独立申诉。测试点覆盖34条（17项×通过+异常）。
+
+### 8.2 申诉状态枚举三版本不一致 ✅
+> ✅ 确认: 以API §4.4为准。130=已取消为省平台侧操作，我方只读不提供取消申诉功能。原型UI状态映射已确认。
+
+### 8.3 第三次上报列表字段差异 ✅
+> ✅ 确认: 以原型15列为准。
+
+### 8.4 看板申诉状态下拉值差异 ✅
+> ✅ 确认: 以API §4.4为准（未申诉/审核通过/审核不通过/已取消），其中130为省平台只读状态。
+
+### 8.5 原型详情弹窗字段数量差异 ✅
+> ✅ 确认: 以接口Showdoc定义为准。
+
+### 8.6 原型缺失车辆轨迹信息 ✅
+> ✅ 确认: 为原原型Bug。增强版原型已包含轨迹表格。
+
+### 8.7 技术细节已全部确认 ✅
+> ✅ 待确认7: 自动重试间隔5s/15s/30s可用。
+> ✅ 待确认8: ETC税率统一3%，税额按3%计算。
+> ✅ 待确认9: 申诉超时告警阈值7个工作日可用。
+> ✅ 待确认10: 安徽=34与云南=28逻辑隔离，无冲突。
+> ✅ 待确认11: **Showdoc文档已读取**，字段定义以Showdoc为权威（金额3位小数，时间yyyyMMddHHmmss格式，ETC invoiceAmount=不含税金额，委托合同上传mandateContractFrame为前置步骤）。
+> ✅ 待确认12: 里程申诉接口 /mileageAppeal/insert 为独立接口，纳入本期范围。
+> ✅ 待确认13: ETC发票不含税金额(invoiceAmount)需在测试用例中体现。
+> ✅ **新增**: ETC触发条件确认 — 税务抵扣成功后由运营人员人工确认，非自动触发。
+
+## 9. 项目差异化约束
+
+- 省份代码: 安徽=34（非云南=28）
+- 该需求为新增模块，与现有云南上报逻辑隔离
+- 测试环境管理端: https://ybxcx.ynyun8.com:8000/admin
+- 支付方式: arpa_2（云企付二期）

output/analysis/安徽运八需求_原型与接口分析.md

@@ -0,0 +1,196 @@
+# 安徽运八需求 — 原型&接口文档交叉分析
+
+> 分析时间: 2026-07-13
+> 原型: `E:\WeChat\xwechat_files\wxid_2n9ko0aq1th822_44c3\msg\file\2026-07\anhuibaba_index.html`
+> 接口文档: `E:\Downloads\网货企业端接口文档（最新）.pdf` (V1.0.2, 2023-04)
+> 需求文档: `source_docs/requirements_raw/安徽运八需求.docx`
+
+---
+
+## 一、关键发现总览
+
+| # | 发现 | 严重程度 | 影响范围 |
+|:---:|:---|:---:|:---|
+| 1 | 核验项数量：需求7类 vs API文档17项 | **P0 阻断** | 第二次上报核验覆盖 |
+| 2 | 申诉状态枚举三套不一致 | P1 | 申诉模块全部用例 |
+| 3 | 第三次上报列表字段与原型不一致 | P1 | 第三次上报列表验证 |
+| 4 | 详情弹窗字段分组/数量与原型不一致 | P1 | 所有详情弹窗用例 |
+| 5 | API新增里程申诉接口 | P2 | 遗漏功能覆盖 |
+| 6 | 看板申诉状态下拉值与需求不一致 | P1 | 看板筛选用例 |
+| 7 | ETC发票详情含"不含税金额"字段 | P2 | ETC详情用例 |
+| 8 | 原型看板有checkbox勾选列 | P3 | 看板交互用例 |
+| 9 | 接口文档异常代码枚举vs需求异常代码 | P1 | 异常申诉用例 |
+
+---
+
+## 二、核验项对照（重大差异）
+
+### 需求文档描述的7类核验
+1. 运单重复核验
+2. 车辆资质核验
+3. 司机资质核验
+4. 集中支付核验
+5. 资金流水核验
+6. 合同核验
+7. 车辆轨迹合规核验
+
+### API文档定义的17项核验（§4.1 异常项ID对照表）
+
+| Code | 名称 | 需求是否提到 |
+|:---:|:---|:---:|
+| 100 | 委托合同 | 合并为"合同核验" |
+| 120 | 承运合同 | 合并为"合同核验" |
+| 130 | 实时定位 | ❌ 未提及 |
+| 140 | 运单时间逻辑 | ❌ 未提及 |
+| 150 | 车辆资质 | ✅ |
+| 160 | 道路运输证 | 隐含在车辆资质 |
+| 170 | 驾驶证 | 隐含在司机资质 |
+| 180 | 从业资格证 | ✅ 司机资质 |
+| 190 | 车辆重复 | ❌ 未提及（需求仅有运单重复） |
+| 200 | 司机重复 | ❌ 未提及 |
+| 210 | 车辆轨迹 | ✅ |
+| 220 | 运费收款 | ❌ 未提及 |
+| 230 | 公司统一收款 | ❌ 未提及 |
+| 240 | 集中支付 | ✅ |
+| 250 | 资金流水 | ✅ |
+| 260 | 发票信息 | ❌ 未提及（第三次上报相关） |
+| 270 | 非通行车辆可开票 | ❌ 未提及 |
+
+> ⚠️ **待确认**: 需求文档将17项核验归纳为7类是否合理？测试点应按需求7类还是API 17项逐项覆盖？建议按API 17项逐项覆盖（因为每项有独立的核验结果和申诉入口）。
+
+---
+
+## 三、申诉状态枚举对照
+
+| 需求文档 | HTML原型 | API文档(§4.4) | API Code |
+|:---|:---|:---|:---:|
+| 未申诉 | 未申诉 | 未申诉 | 100 |
+| 申诉中 | 待省平台反馈 | — | — |
+| — | 反馈处理中 | — | — |
+| 申诉通过 | 申诉通过 | 审核通过 | 110 |
+| 申诉驳回 | 申诉驳回 | 审核不通过 | 120 |
+| — | — | 已取消 | 130 |
+
+> ⚠️ **待确认**: 
+> - 需求"申诉中"被原型拆分为"待省平台反馈"+"反馈处理中"两个状态——哪个是最终版本？
+> - API有"已取消"状态(130)但需求和原型均未体现——是否支持申诉取消？
+> - 看板筛选下拉值以哪个为准？
+
+---
+
+## 四、列表字段差异
+
+### 第三次上报列表
+| 需求字段 | 原型字段 | 差异 |
+|:---|:---|:---|
+| 车牌号 | ✅ | — |
+| 司机姓名 | ✅ | — |
+| 托运方名称 | ✅ | — |
+| — | **税率** | 需求未列出 |
+| — | **销售方名称** | 需求未列出 |
+| — | **受票方名称** | 需求未列出 |
+| — | **油气票张数** | 需求未列出 |
+
+原型比需求多4个字段（税率、销售方名称、受票方名称、油气票张数），共15列（含checkbox）。
+
+### 第一次上报列表
+需求与原型一致，14字段 + checkbox。
+
+### ETC上传列表
+原型字段（10列+checkbox）：货源单号/运单号/托运单号/ETC发票号/交易金额/入口收费站/出口收费站/交易时间/上传状态/操作
+**缺少**: 车牌号、司机姓名、托运方名称（需求中列出）、税率（需求中列出）
+
+---
+
+## 五、详情弹窗字段差异
+
+### 第一次上报详情弹窗
+| 分组 | 需求字段数 | 原型字段数 | 差异 |
+|:---|:---:|:---:|:---|
+| 建单信息 | 13 | 10 | 原型无"上游企业委托运输单号""网络货运经营者名称""统一社会信用代码""道路运输经营许可证编号""运输组货方式代码"等 |
+| 托运人信息 | 7 | 8 | 原型多了货物名称/重量/体积 |
+| 收货方信息 | 5 | 8 | 原型多了联系人/电话/收货时间/签收状态 |
+| 司机信息 | 13 | 6 | 原型大幅简化 |
+| 车辆信息 | 19 | 8 | 原型大幅简化 |
+| 货物信息 | 4/条 | 8/条(卡片式) | 原型多了件数/单价/包装方式/危险货物标志 |
+| 保险信息 | 2 | 7 | 原型多了保险类型/金额/有效期起止/保单状态 |
+| 异常信息 | 4 | 4 | 一致 |
+
+> ⚠️ **待确认**: 需求文档字段定义来自接口文档（https://www.showdoc.com.cn/2210641821476236/9919735893682511），原型可能是简化版。详细字段数以接口文档为准还是以原型为准？
+
+### 第二次上报详情弹窗
+| 分组 | 需求 | 原型 | 差异 |
+|:---|:---|:---|:---|
+| 资金流水 | 10字段 | 11字段 | 原型多了"实际支付金额" |
+| 车辆轨迹 | 6字段/点 | **未展示** | 原型弹窗缺失车辆轨迹信息！ |
+| 油气发票 | — | 有 | 需求未在第二次上报中提及油气发票 |
+
+> ⚠️ **待确认**: 原型第二次上报详情弹窗中车辆轨迹信息缺失——是原型bug还是实际不展示？
+
+### 第三次上报详情弹窗
+需求分组：运单信息/发票信息(17字段)/油气发票信息(可选)/异常信息
+原型分组：运单信息/发票信息(10字段)/ETC发票信息(可选)/异常信息
+- **差异**: 原型把"油气发票"换成了"ETC发票信息"，发票信息字段从17减为10
+
+---
+
+## 六、API接口清单
+
+接口文档（V1.0.2）定义了以下接口：
+
+| 接口 | URL | 方法 | 说明 |
+|:---|:---|:---:|:---|
+| 获取token | /sys/login | POST | JWT认证 |
+| 上传申诉附件 | /appeal/uploadFile | POST | 文件上传 |
+| 提交申诉运单 | /appeal/insert | POST | 发起申诉 |
+| 查询异常运单信息 | /verificationSummary/page | POST | 分页查询，含abnormalDetails |
+| 查询申诉进度 | /appeal/page | POST | 分页查询，含审核状态/审核人/取消/撤回 |
+| 查询运单核验详情 | /verificationSummary/verificationDetail | POST | 单运单核验明细列表 |
+| 查询发票合规 | /verificationSummary/cargoOwnerInvoiceInfo | POST | 判断托运人发票是否系统核验合规 |
+| 运单里程核验查询 | /verificationSummary/mileageVerificationInfo | POST | 批量查询运单里程核验状态 |
+| 运单里程申诉 | /mileageAppeal/insert | POST | **需求未提及的新功能！** |
+
+### 关键API数据结构
+
+#### 异常运单查询响应 (verificationSummary/page)
+```
+pageRecords[]:
+  freightSheetNumber, appealStateId/Name, verificationAbnormalItem,
+  createTime, lastVerifyTime, firstVerifyTime, vehicleNumber,
+  driverName, driverIdCard, verifyStateId/Name,
+  abnormalDetails[]:
+    id (异常项ID), name (异常项名称), message (异常原因),
+    time (异常时间), state (100=未申诉, 110=申诉中)
+```
+
+#### 核验详情响应 (verificationSummary/verificationDetail)
+```
+details[]:
+  verificationCode (核验项编码), verificationName (核验项名称),
+  verificationState (核验状态), verificationStateId,
+  verificationTime, message (核验信息)
+```
+
+---
+
+## 七、需要更新的测试资产
+
+### 测试点更新
+1. **TP-C-006~TP-C-019**: 将"7类核验"扩展为"17项核验"逐项覆盖（+20个测试点）
+2. **TP-F-xxx**: 申诉状态枚举对齐（确认最终版本后更新）
+3. **TP-D-002**: 第三次上报列表字段数修正为原型字段数
+4. **TP-E-xxx**: ETC上传列表字段对齐
+5. **新增TP**: 里程申诉功能、发票合规查询功能
+6. **TP-A-xxx**: 看板申诉状态下拉值对齐
+
+### 测试用例更新
+1. 核验项相关用例从14条扩展到34条（17项×2 pass+exception）
+2. 申诉状态相关用例枚举值对齐
+3. 第三次上报列表字段验证用例更新
+4. 新增里程申诉用例
+5. 新增发票合规查询用例
+
+### 需求分析更新
+1. 核验项从7类更新为17项
+2. 申诉状态枚举标注三版本差异
+3. 新增API接口清单

output/analysis/安徽运八需求_测试数据.md

@@ -6,6 +6,12 @@
 
 ### 金额/数值
 - `3%`
+- `3%`
+- `3%`
+- `3%`
+- `3%`
+- `3%`
+- `3%`
 
 ## 需要人工补充的数据
 

output/analysis/安徽运八需求_覆盖率审计.md

@@ -0,0 +1,295 @@
+# 安徽运八需求 覆盖率审计
+
+> 审计日期: 2026-07-13
+> 审计范围: 需求文档 (requirement.md) → 测试点 (103个) → 测试用例 (128个) → 风险评估 (2项)
+> 审计方法: 四维追溯矩阵 + 风险覆盖核查 + 覆盖热力图
+
+---
+
+## 覆盖概览
+
+| 指标 | 值 | 目标 | 状态 |
+| :--- | :---: | :---: | :---: |
+| 需求→测试点覆盖率 | 93.75% (45/48) | >= 95% | **FAIL** |
+| P0测试点→用例覆盖率 | 100% (25/25) | 100% | **PASS** |
+| P1测试点→用例覆盖率 | 100% (50/50) | >= 90% | **PASS** |
+| P0风险覆盖率 | N/A (无P0风险项) | 100% | **PASS** |
+| P1风险覆盖率 | 100% (1/1) | >= 90% | **PASS** |
+| 过度覆盖率 | 0% (0/128) | <= 5% | **PASS** |
+
+**结论**: 需求→测试点覆盖率 93.75% 未达到 95% 门槛，存在3个覆盖缺口需补充。P0 测试点→用例覆盖率 100% 达标，风险覆盖率达标，无过度覆盖。
+
+---
+
+## 覆盖缺口
+
+### 缺口 GAP-001: 第一次上报列表字段完整性 — 无测试点
+
+- **需求条目**: REQ-B-07 (需求文档 Section 2.2 "列表字段")
+- **缺口类型**: 无测试点覆盖
+- **风险等级**: P1
+- **详细说明**: 需求明确列出第一次上报列表页的14个字段（货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作）。其他模块（看板/第二次/第三次/ETC/申诉/日志）均有列表字段完整性的测试点（TP-A-008, TP-C-004, TP-D-002, TP-E-002, TP-F-002, TP-G-005），但第一次上报模块缺少对应的列表字段完整性测试点。现有 TP-A-008 覆盖的是看板列表字段（不同字段集合），TP-B-011/012 覆盖的是详情弹窗字段（非列表）。
+- **对比**: 同为"列表字段"需求项，第二次上报有 TP-C-004，第三次上报有 TP-D-002，ETC 有 TP-E-002，仅第一次上报缺失。
+- **建议**: 新增测试点 TP-B-020，验证第一次上报列表页14个字段完整且顺序与需求一致。对应新增用例覆盖。
+
+### 缺口 GAP-002: 第二次上报自动重试机制 — 无测试点
+
+- **需求条目**: REQ-C-05 (需求文档 Section 2.3 "特殊说明" 第4条)
+- **缺口类型**: 无测试点覆盖
+- **风险等级**: P1
+- **详细说明**: 需求明确要求"若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员"。其他上报阶段均已有自动重试测试点（第一次: TP-B-007, 第三次: TP-D-007, ETC: TP-E-006），但第二次上报模块缺少对应的自动重试测试点。第二次上报是核验项最多的阶段（7类核验），也是最容易出现异常的环节，重试机制缺失覆盖是高风险的遗漏。
+- **对比**: 三阶段+ETC共4个上报入口，第一次/第三次/ETC均有重试测试点，仅第二次缺失。
+- **建议**: 新增测试点 TP-C-023，验证第二次上报失败后自动重试最多3次、间隔递增、全部失败后告警。对应新增用例覆盖。
+
+### 缺口 GAP-003: 第二次上报详情弹窗分组字段完整性 — 无测试点
+
+- **需求条目**: REQ-C-08 (需求文档 Section 2.3 "详情弹窗字段分组")
+- **缺口类型**: 无测试点覆盖
+- **风险等级**: P2
+- **详细说明**: 需求明确定义第二次上报详情弹窗的6个分组，其中"资金流水信息"分组包含10个必选字段（支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态）和"车辆轨迹信息"分组包含6个必选字段（定位类型、定位时间、定位地点、经度、纬度、轨迹类型）。现有 TP-C-004 覆盖的是列表字段（14个列表字段），而非详情弹窗分组字段。其他模块的详情弹窗均有字段完整性测试点（第一次: TP-B-011/012, 第三次: TP-D-003, ETC: TP-E-003, 申诉: TP-F-004），仅第二次上报缺失。
+- **对比**: 同为"详情弹窗字段分组"需求项，第一次上报有 TP-B-011/012，第三次上报有 TP-D-003，仅第二次上报缺失独立的详情弹窗测试点。
+- **建议**: 新增测试点 TP-C-024，验证第二次上报详情弹窗6个分组（运单/托运方/收货方/资金流水/车辆轨迹/异常）的字段完整性和数据正确性。资金流水10字段和车辆轨迹6字段需重点验证。对应新增用例覆盖。
+
+---
+
+## 需求→测试点 追溯矩阵
+
+### 模块A: 上报运单看板 (7条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-A-01 | 看板模糊搜索(运单号/托运单号/货源单号) | TP-A-001 | **PASS** |
+| REQ-A-02 | 看板按上报阶段筛选(全部/第一次/第二次/第三次) | TP-A-002 | **PASS** |
+| REQ-A-03 | 看板按核验状态筛选(全部/异常/通过) | TP-A-003 | **PASS** |
+| REQ-A-04 | 看板按申诉状态筛选(全部/未申诉/申诉中/申诉通过/申诉驳回) | TP-A-004 | **PASS** |
+| REQ-A-05 | 操作按钮(查询/重置/导出) | TP-A-001, TP-A-006, TP-A-007 | **PASS** |
+| REQ-A-06 | 看板列表14字段 | TP-A-008 | **PASS** |
+| REQ-A-07 | 操作列(申诉/进度/详情) + 详情弹窗分组 | TP-A-010, TP-A-011 | **PASS** |
+
+### 模块B: 第一次上报-装货完成 (9条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-B-01 | 装货完成后自动触发(仅安徽税源地) | TP-B-001, TP-B-002 | **PASS** |
+| REQ-B-02 | 上报数据包含7个子对象必选字段 | TP-B-001, TP-B-003 | **PASS** |
+| REQ-B-03 | 核验通过后自动调用修改字段接口 | TP-B-006 | **PASS** |
+| REQ-B-04 | 上报失败自动重试最多3次 | TP-B-007 | **PASS** |
+| REQ-B-05 | 全部重试失败后通知运营人员 | TP-B-008 | **PASS** |
+| REQ-B-06 | 上报状态规则+标签颜色 | TP-B-009, TP-B-010 | **PASS** |
+| **REQ-B-07** | **第一次上报列表14字段** | **无** | **GAP** |
+| REQ-B-08 | 详情弹窗按子对象分组(含异常信息) | TP-B-011, TP-B-012, TP-B-013 | **PASS** |
+| REQ-B-09 | 手动上传按钮(仅上传失败状态) | TP-B-009 | **PASS** |
+
+### 模块C: 第二次上报-打款完成 (10条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-C-01 | 打款完成后自动触发 | TP-C-001 | **PASS** |
+| REQ-C-02 | 上报数据(运抵/资金流水/合同/轨迹) | TP-C-001 | **PASS** |
+| REQ-C-03 | 资金流水单号重复系统自动检查 | TP-C-014, TP-C-015 | **PASS** |
+| REQ-C-04 | 补传轨迹功能 | TP-C-022 | **PASS** |
+| **REQ-C-05** | **上报失败自动重试最多3次+告警** | **无(告警部分间接覆盖)** | **GAP** |
+| REQ-C-06 | 第二次上报列表字段 | TP-C-004 | **PASS** |
+| REQ-C-07 | 收款账号类型(个人/对公)+标签颜色 | TP-C-005 | **PASS** |
+| **REQ-C-08** | **详情弹窗6分组字段完整性** | **无** | **GAP** |
+| REQ-C-09 | 7类核验(通过+异常各14场景) | TP-C-006~TP-C-019 | **PASS** |
+| REQ-C-10 | 第二次上报依赖第一次完成 | TP-C-020 | **PASS** |
+
+### 模块D: 第三次上报-开票完成 (7条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-D-01 | 开票完成后触发(依赖第二次) | TP-D-001, TP-D-005 | **PASS** |
+| REQ-D-02 | 上报数据(运单+发票+油气发票) | TP-D-001, TP-D-004 | **PASS** |
+| REQ-D-03 | 增值税发票验证失败处理 | TP-D-006 | **PASS** |
+| REQ-D-04 | 上报失败自动重试最多3次+告警 | TP-D-007 | **PASS** |
+| REQ-D-05 | 第三次上报列表11字段 | TP-D-002 | **PASS** |
+| REQ-D-06 | 详情弹窗字段分组(发票17字段+油气发票) | TP-D-003, TP-D-008 | **PASS** |
+| REQ-D-07 | 发票金额精度校验(价税合计2位小数) | TP-D-010 | **PASS** |
+
+### 模块E: ETC发票上传 (6条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-E-01 | ETC发票上传触发 | TP-E-001 | **PASS** |
+| REQ-E-02 | 税务抵扣前置条件 | TP-E-004 | **PASS** |
+| REQ-E-03 | ETC发票验证失败处理 | TP-E-005 | **PASS** |
+| REQ-E-04 | 上报失败自动重试最多3次+告警 | TP-E-006 | **PASS** |
+| REQ-E-05 | ETC上传列表11字段 | TP-E-002 | **PASS** |
+| REQ-E-06 | 详情弹窗3分组(运单7+ETC18+异常4) | TP-E-003 | **PASS** |
+
+### 模块F: 异常申诉功能 (5条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-F-01 | 申诉完整闭环(异常查询→发起→反馈→判断) | TP-F-001, TP-F-003 | **PASS** |
+| REQ-F-02 | 申诉列表13字段 | TP-F-002 | **PASS** |
+| REQ-F-03 | 申诉详情弹窗5分组字段 | TP-F-004 | **PASS** |
+| REQ-F-04 | 申诉复核说明(省平台复核,驳回可重新申诉) | TP-F-006 | **PASS** |
+| REQ-F-05 | 异常代码一览表映射 | TP-F-011 | **PASS** |
+
+### 模块G: 上报日志 (4条需求)
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-G-01 | 查询条件(单号/阶段/结果/时间范围) | TP-G-001~TP-G-004 | **PASS** |
+| REQ-G-02 | 日志列表9字段 | TP-G-005 | **PASS** |
+| REQ-G-03 | 详情弹窗(完整请求/响应报文) | TP-G-006 | **PASS** |
+| REQ-G-04 | 所有上报接口调用记录全覆盖 | TP-G-007 | **PASS** |
+
+### 跨模块需求
+
+| 需求条目 | 需求描述 | 测试点 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| REQ-X-01 | 三阶段依赖链完整性 | TP-B-005, TP-C-020, TP-D-005, TP-X-001 | **PASS** |
+| REQ-X-02 | 非安徽税源地不上报 | TP-B-002, TP-X-004 | **PASS** |
+| REQ-X-03 | 多省份数据隔离 | TP-X-005 | **PASS** |
+
+---
+
+## 测试点→用例 追溯矩阵
+
+> 完整103条追溯见测试用例文件内置映射表（第199-305行），以下为P0测试点专项核查。
+
+### P0测试点覆盖确认 (25/25 = 100%)
+
+| P0测试点 | 描述 | 对应用例 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| TP-A-001 | 看板模糊搜索 | AH_REPORT_DASH_001, 002, 003 | **PASS** |
+| TP-B-001 | 装货完成后自动触发第一次上报 | AH_REPORT_R1_001 | **PASS** |
+| TP-B-002 | 仅安徽税源地运单触发 | AH_REPORT_R1_002, 003 | **PASS** |
+| TP-B-004 | 省份代码=34(防历史缺陷) | AH_REPORT_R1_003, 006 | **PASS** |
+| TP-B-005 | 第一次是后续前置条件(防历史缺陷) | AH_REPORT_R1_007, 008 | **PASS** |
+| TP-B-014 | 第一次上报幂等性(防历史缺陷) | AH_REPORT_R1_013, 014, CROSS_006 | **PASS** |
+| TP-C-001 | 打款完成后自动触发第二次上报 | AH_REPORT_R2_001 | **PASS** |
+| TP-C-002 | 资金流水数据来源支付流水表(防历史缺陷) | AH_REPORT_R2_002 | **PASS** |
+| TP-C-003 | 财务修改金额后使用最新金额(防历史缺陷) | AH_REPORT_R2_003 | **PASS** |
+| TP-C-006 | 运单重复核验—通过场景 | AH_REPORT_R2_005 | **PASS** |
+| TP-C-007 | 运单重复核验—异常场景 | AH_REPORT_R2_006 | **PASS** |
+| TP-C-020 | 第二次依赖第一次完成(防历史缺陷) | AH_REPORT_R2_024 | **PASS** |
+| TP-C-021 | 第二次上报幂等性(防历史缺陷) | AH_REPORT_R2_025, CROSS_006 | **PASS** |
+| TP-D-001 | 开票完成后触发第三次上报 | AH_REPORT_R3_001 | **PASS** |
+| TP-D-005 | 第三次依赖第二次完成(防历史缺陷) | AH_REPORT_R3_006, 007 | **PASS** |
+| TP-E-001 | ETC发票上传触发 | AH_REPORT_ETC_001 | **PASS** |
+| TP-E-004 | 税务抵扣前置条件 | AH_REPORT_ETC_004 | **PASS** |
+| TP-F-001 | 申诉完整闭环 | AH_REPORT_APL_001 | **PASS** |
+| TP-F-003 | 申诉状态流转全路径 | AH_REPORT_APL_004, 005 | **PASS** |
+| TP-G-001 | 日志按单号模糊搜索 | AH_REPORT_LOG_001, 002 | **PASS** |
+| TP-G-002 | 日志按上报阶段筛选 | AH_REPORT_LOG_003 | **PASS** |
+| TP-X-001 | 三阶段依赖链端到端(防历史缺陷) | AH_REPORT_CROSS_001 | **PASS** |
+| TP-X-002 | 多模块数据一致性(防历史缺陷) | AH_REPORT_CROSS_002 | **PASS** |
+| TP-X-003 | 安徽运八全流程完整链路 | AH_REPORT_CROSS_003 | **PASS** |
+| TP-X-004 | 非安徽税源地全流程不上报 | AH_REPORT_CROSS_004 | **PASS** |
+
+### P1测试点覆盖核查 (50/50 = 100%)
+
+全部50个P1测试点均有对应用例覆盖，详见测试用例文件内置映射表。抽查5个高风险P1测试点：
+
+| P1测试点 | 描述 | 对应用例 | 覆盖状态 |
+| :--- | :--- | :--- | :---: |
+| TP-B-003 | 第一次上报建单信息格式校验 | AH_REPORT_R1_004, 005, 021 (3条) | **PASS** |
+| TP-B-007 | 第一次上报自动重试3次 | AH_REPORT_R1_010 | **PASS** |
+| TP-C-019 | 轨迹合规核验—异常(点位不足) | AH_REPORT_R2_022, 023 (2条) | **PASS** |
+| TP-D-006 | 增值税发票验证失败 | AH_REPORT_R3_008, 009 (2条) | **PASS** |
+| TP-E-007 | ETC税额计算精度(资损风险) | AH_REPORT_ETC_008 | **PASS** |
+
+---
+
+## 风险覆盖审计
+
+### 风险矩阵覆盖
+
+| 风险ID | 等级 | 风险描述 | 覆盖测试点 | 覆盖用例 | 覆盖状态 |
+| :--- | :---: | :--- | :--- | :--- | :---: |
+| RISK-FINANCIAL | P1 | ETC税额计算/发票金额精度/打款金额数据溯源，涉及资损 | TP-C-002, TP-C-003, TP-D-010, TP-E-007 | AH_REPORT_R2_002, R2_003, R3_012, ETC_008 | **PASS** |
+| RISK-AVAILABILITY | P2 | 监管平台接口超时/弱网/服务不可用导致上报中断 | TP-B-007, TP-B-015, TP-B-016, TP-D-007, TP-E-006, TP-F-013 | AH_REPORT_R1_010, R1_015, R1_016, R3_010, ETC_007, APL_015 | **PASS** |
+
+### 风险覆盖统计
+
+| 风险等级 | 总数 | 已覆盖 | 覆盖率 | 目标 | 状态 |
+| :--- | :---: | :---: | :---: | :---: | :---: |
+| P0 | 0 | 0 | N/A | 100% | **PASS** |
+| P1 | 1 | 1 | 100% | >= 90% | **PASS** |
+| P2 | 1 | 1 | 100% | — | **PASS** |
+
+---
+
+## 过度覆盖审计
+
+### 反向追溯: 用例 → 需求
+
+全部128条测试用例均可追溯至明确的测试点，所有测试点均可追溯至需求条目或历史缺陷（历史缺陷本身源于需求Bug）。
+
+| 检查项 | 结果 |
+| :--- | :---: |
+| 总用例数 | 128 |
+| 可追溯用例 | 128 |
+| 无需求依据的用例 | 0 |
+| 冗余/重复用例 | 0 |
+| 过度覆盖率 | 0% |
+| 目标(<= 5%) | **PASS** |
+
+**说明**: 所有用例均通过"对应TP-xxx"或"[AI修正: 历史缺陷防御]"标记明确了来源。历史缺陷用例（BUG-202607-01/02/03/04）均有对应的需求依赖项作为依据，不属于过度覆盖。
+
+---
+
+## 覆盖热力图
+
+| 模块 | 需求条目 | 测试点 | 测试用例 | 覆盖密度 | 评价 |
+| :--- | :---: | :---: | :---: | :---: | :--- |
+| A 上报运单看板 | 7 | 14 | 18 | **高** | 全维度覆盖，包含UI/权限/边界/空状态 |
+| B 第一次上报 | 9 | 19 | 23 | **高** | 全维度覆盖，但列表字段完整性缺失(GAP-001) |
+| C 第二次上报 | 10 | 22 | 26 | **中高** | 7类核验全覆盖(**亮点**)，但重试和详情弹窗缺失(GAP-002/003) |
+| D 第三次上报 | 7 | 11 | 14 | **中高** | 主流程+异常+金额精度全覆盖 |
+| E ETC发票上传 | 6 | 9 | 12 | **中高** | 税额精度(资损)专项覆盖(**亮点**)，多发票场景覆盖 |
+| F 异常申诉 | 5 | 13 | 17 | **高** | 完整闭环+状态流转+权限+异常代码映射全覆盖(**亮点**) |
+| G 上报日志 | 4 | 9 | 11 | **中高** | 搜索/筛选/报文详情/审计全覆盖 |
+| X 跨模块 | — | 6 | 7 | **高** | 端到端链路+数据一致性+省份隔离全覆盖 |
+
+### 覆盖盲区
+
+| 盲区 | 位置 | 影响 |
+| :--- | :--- | :--- |
+| 第一次上报列表字段完整性 | 模块B | 列表字段渲染错误无法被测试捕获（如字段缺失、顺序错乱、格式错误） |
+| 第二次上报自动重试 | 模块C | 最易出异常的阶段缺失重试验证，依赖链断裂后无自动恢复覆盖 |
+| 第二次上报详情弹窗分组完整性 | 模块C | 资金流水10字段和车辆轨迹6字段在详情弹窗中的展示未验证 |
+
+---
+
+## 历史缺陷防御覆盖核查
+
+| 历史缺陷ID | 防御测试点数 | 防御用例数 | 覆盖状态 |
+| :--- | :---: | :---: | :---: |
+| BUG-202607-01 (阶段依赖链断裂) | 4 (TP-B-005, C-020, D-005, X-001) | 6 | **PASS** |
+| BUG-202607-02 (重试幂等缺陷) | 5 (TP-B-014, C-021, D-009, E-008, F-012) | 6 | **PASS** |
+| BUG-202607-03 (跨模块数据不一致) | 3 (TP-C-002, C-003, X-002) | 4 | **PASS** |
+| BUG-202607-04 (省份代码硬编码) | 2 (TP-B-004, X-005) | 2 | **PASS** |
+
+全部4个已知历史缺陷均有充分的正向+反向防御覆盖。
+
+---
+
+## 审计结论与建议
+
+### 整体评价
+
+- 本次覆盖率审计发现 **3个覆盖缺口**，需求→测试点覆盖率 **93.75%**，略低于95%目标
+- **亮点**: 第二次上报7类核验逐项覆盖（通过+异常各14个测试点）、申诉完整闭环验证、跨模块端到端链路、历史缺陷100%防御覆盖、ETC税额精度专项覆盖
+- **改进项**: 3个缺口均为"完整性"类遗漏（列表字段/重试机制/详情弹窗），属于测试点设计时未逐条对照需求清单的系统性遗漏
+
+### 建议行动
+
+| 优先级 | 行动项 | 对应缺口 |
+| :---: | :--- | :--- |
+| **P0** | 新增 TP-B-020 "第一次上报列表字段完整性校验" 及对应用例（参考 TP-C-004 结构） | GAP-001 |
+| **P0** | 新增 TP-C-023 "第二次上报自动重试—最多3次间隔递增" 及对应用例（参考 TP-B-007 结构） | GAP-002 |
+| **P1** | 新增 TP-C-024 "第二次上报详情弹窗分组字段完整性" 及对应用例（重点: 资金流水10字段+车辆轨迹6字段） | GAP-003 |
+| **P2** | 需求"异常代码一览表"仅有标题无内容，确认后补充 TP-F-011 的详细验证数据 | REQ-F-05 |
+| **P2** | 确认自动重试间隔时间（当前假设5s/15s/30s），更新所有重试用例的测试数据 | — |
+
+---
+
+> **审计元数据**:
+> - 审计依据: requirement.md (7模块/48需求条目), 测试点 (103个/7模块), 测试用例 (128个/7模块), 风险评估 (2项风险)
+> - 追溯方法: 正向追溯 (需求→测试点) + 反向追溯 (用例→需求) + 风险覆盖交叉验证
+> - 覆盖率计算: 需求→测试点 = 已覆盖需求条目 / 总需求条目; 过度覆盖 = 无需求依据的用例 / 总用例数

output/analysis/安徽运八需求_评审报告.md

@@ -0,0 +1,188 @@
+# 安徽运八需求 评审报告
+
+> 评审时间: 2026-07-13
+> 评审对象: output/test_cases/安徽运八需求_测试用例.md (128条)
+> 评审依据: review_checklist.md / test_case_template.md / definition_of_done.md / 风险评估报告
+
+---
+
+## 评审概览
+
+| 指标 | 值 |
+| :--- | :--- |
+| 用例总数 | 128 |
+| 阻断项 | 7 |
+| 建议项 | 7 |
+| 优化项 | 7 |
+| 评分 | 80/100 |
+
+---
+
+## 阻断项
+
+### B-001: R2_004 字段数标题与预期结果不一致（标题14 vs 实际列举17）
+
+- 用例编号: AH_REPORT_R2_004
+- 问题: 标题声明"验证第二次上报列表14个字段完整"，但预期结果中逐项列举了17个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作）。执行人无法确认应以标题为准还是以预期结果为准。
+- 修复建议: 与需求/前端确认第二次上报列表的实际列数，统一标题和预期结果中的字段数量和名称列表。
+
+### B-002: R3_002 字段数标题与预期结果不一致（标题11 vs 实际列举13）
+
+- 用例编号: AH_REPORT_R3_002
+- 问题: 标题声明"验证第三次上报列表展示11个字段完整"，预期结果文字也写"列表展示11个字段"，但实际逐项列举了13个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作）。文字表述"11个字段"与列举内容自相矛盾。
+- 修复建议: 确认第三次上报列表的准确字段数，修正标题和预期结果中的数字，使其与列举的字段名数一致。
+
+### B-003: LOG_006 字段数标题与预期结果不一致（标题9 vs 实际列举11）
+
+- 用例编号: AH_REPORT_LOG_006
+- 问题: 标题声明"验证上报日志列表9个字段完整展示"，但预期结果中逐项列举了11个字段（序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作）。
+- 修复建议: 确认上报日志列表实际列数，统一标题和预期结果。
+
+### B-004: APL_003 字段数标题与预期结果不一致（标题13 vs 实际列举14）
+
+- 用例编号: AH_REPORT_APL_003
+- 问题: 标题声明"验证申诉记录列表13个字段完整展示"，但预期结果逐项列举了14个字段（运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作）。
+- 修复建议: 确认申诉记录列表实际列数，统一标题和预期结果。
+
+### B-005: R3_003 字段数标题与预期结果不一致（标题17 vs 实际合计19）
+
+- 用例编号: AH_REPORT_R3_003
+- 问题: 标题声明"验证第三次上报详情弹窗发票信息17字段完整展示"，但预期结果中各分组字段合计为19个：发票基础字段5个（托运单号数组、发票号码、发票代码号、发票金额(价税合计)、开票日期）+ 销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）+ 受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）= 19。标题的"17"与实际合计"19"不匹配。
+- 修复建议: 逐字段核对发票信息分组，确认准确字段数为17还是19，修正标题或补充/删除预期结果中的字段。
+
+### B-006: APL_015 预期结果使用"可能"措辞，不可验证
+
+- 用例编号: AH_REPORT_APL_015
+- 问题: 预期结果中出现"系统可能有超时告警提醒运营人员跟进"——"可能"表示该行为不确定，无法作为可验证的测试断言。若超时告警是需求要求的必要行为，则必须断言为"系统触发超时告警通知运营人员"；若当前未明确，应标记为待确认项。
+- 修复建议: (1) 若超时告警已纳入需求，将"可能"改为确定性描述并补充告警渠道和内容；(2) 若尚未明确，在备注中增加 `> ⚠️ 待确认：申诉超时告警机制是否实现、告警渠道和阈值`。
+
+### B-007: CROSS_003 违反原子性原则——单条用例验证完整四阶段端到端流程
+
+- 用例编号: AH_REPORT_CROSS_003
+- 问题: 该用例将装货完成、财务打款、发票开具、ETC上传全部串联在一条用例中验证，跨越4个上报阶段和多个触发条件。任一环节失败时，无法快速定位问题在哪个阶段。此外，各阶段已有独立的单阶段用例覆盖（R1/R2/R3/ETC系列），此全链路用例与它们形成冗余但缺乏精确定位能力。
+- 修复建议: 保留此用例作为冒烟测试或集成验证（类型改为"冒烟测试"），但应将各阶段的独立断言缩减为"全链路各阶段按序成功完成，看板和日志数据一致"，移除重复的具体阶段内断言；或拆分为阶段衔接用例（如"第一阶段成功后第二阶段可触发"），每种衔接一个用例。
+
+---
+
+## 建议项
+
+### S-001: LOG_001 和 LOG_003 优先级 P0 偏高，建议降为 P1
+
+- 用例编号: AH_REPORT_LOG_001, AH_REPORT_LOG_003
+- 问题: 上报日志属于审计/支持类功能，日志搜索和阶段筛选并非用户核心业务操作流程，置于 P0 会稀释 P0 集合的聚焦度。当前 P0 已有 28 条（占比 22%），将这两个降级可优化 P0 密度。
+- 修复建议: 降为 P1。核心原因：日志功能不可用时不影响上报主流程和业务闭环，不符合 P0 定义（核心流程阻断/资损风险）。
+
+### S-002: APL_015 类型建议改为"易用性测试"
+
+- 用例编号: AH_REPORT_APL_015
+- 问题: 该用例验证的是"用户长时间等待后的系统状态提示和超时告警体验"，属于用户体验/易用性范畴，而非纯功能正确性验证。
+- 修复建议: 将 `类型` 从 `功能测试` 改为 `易用性测试`。
+
+### S-003: R1_003 同时验证3个省份，建议按省份拆分为独立用例
+
+- 用例编号: AH_REPORT_R1_003
+- 问题: 该用例在一条用例中同时验证安徽(34)、云南(28)、四川(51)三个省份的上报触发行为。若仅四川不触发有问题而安徽正常，该用例的单一"通过/失败"结果无法精确区分是哪个省份的问题。
+- 修复建议: 拆分为3条独立用例：R1_003a 安徽触发、R1_003b 云南不触发、R1_003c 四川不触发（或保留 R1_002 覆盖云南，将 R1_003 缩减为四川+其他一省）。确保每个省份的触发/不触发行为有独立可定位的用例。
+
+### S-004: DASH_012 测试5种标签颜色，建议至少将申诉状态独立拆分
+
+- 用例编号: AH_REPORT_DASH_012
+- 问题: 该用例验证4种上报状态标签颜色（蓝色/绿色/红色/橙色）外加申诉状态标签颜色，共计5个颜色断言。虽然都属于"标签颜色映射"这一验证点，但上报状态和申诉状态是两个不同的状态维度。任一颜色配置错误时，该用例失败但无法直接指示是哪个具体标签。
+- 修复建议: 将申诉状态标签颜色验证拆出为独立用例，或至少在上报状态验证和申诉状态验证之间设立分组。
+
+### S-005: R2_004 合并了两个验证关注点（字段完整性 + 标签颜色）
+
+- 用例编号: AH_REPORT_R2_004
+- 问题: 标题和预期结果同时验证"17个字段完整性"和"收款账号类型标签颜色"，这两个关注点属于不同的验证维度（列表字段结构 vs 视觉样式映射），应拆分。
+- 修复建议: 拆分为 (a) 验证第二次上报列表字段完整且数据正确；(b) 验证收款账号类型标签颜色——个人账户蓝色、对公账户绿色。
+
+### S-006: DASH_017 分页测试优先级 P3 偏低，建议升为 P2
+
+- 用例编号: AH_REPORT_DASH_017
+- 问题: 分页翻页数据重复/遗漏是列表类功能的常见高频缺陷，直接影响数据完整性和用户信任度。当前置于 P3（最低优先级），与实际风险不匹配。
+- 修复建议: 升为 P2。分页缺陷虽不阻断主流程，但会导致数据不一致，用户可能基于不完整数据做出错误判断。
+
+### S-007: R1_019 和 R1_020 预期结果缺少数据库层面的一致性校验
+
+- 用例编号: AH_REPORT_R1_019, AH_REPORT_R1_020
+- 问题: R1_019 验证1条货物记录、R1_020 验证5条货物记录，预期结果仅覆盖了请求JSON数组和详情弹窗展示，未包含数据库货物表的落库数据与上报数据的一致性校验。与其他用例（如 R2_002 明确校验数据来源表）相比，数据验证深度不足。
+- 修复建议: 在预期结果中补充"数据库waybill_goods表中货物记录与上报数据一致"或类似断言。
+
+---
+
+## 优化项
+
+### O-001: R1_016 弱网测试预期结果可更精确
+
+- 用例编号: AH_REPORT_R1_016
+- 问题: 预期结果中"请求发送成功但响应延迟时不立即判定失败（超时阈值30s）"未明确在弱网（延迟2000ms、丢包30%）下的具体预期行为——例如是否预期在X次重试内成功，或最终应达到何种状态。建议：明确弱网条件下预期最终状态（如"在网络恢复后10s内完成上报，状态变为已上传"）。
+- 修复建议: 补充弱网恢复后的具体时效预期和最终状态断言。
+
+### O-002: 部分测试数据列存在与步骤重复的信息
+
+- 涉及用例: DASH_001~DASH_007, R1_001~R1_023 等多条
+- 问题: 测试数据列中的内容（如"运单号: YB202607130001"）已在测试步骤或前置条件中出现，数据列未提供独立增量信息。虽然模板允许这样做，但数据列的最佳实践是提供步骤中未提及但执行必需的输入值。
+- 修复建议: 检查并精简测试数据列，使其仅包含步骤中未体现的独立测试数据（如边界金额、特殊字符、长文本等）。
+
+### O-003: 导出测试缺少导出取消/中断场景
+
+- 涉及用例: AH_REPORT_DASH_008, AH_REPORT_DASH_009
+- 问题: 当前导出相关用例覆盖了正常导出和大数据量导出，但未覆盖"导出进行中取消操作""导出时网络中断""导出时关闭浏览器标签页"等中断场景。对于2000+条的大数据量导出场景，中途取消是常见用户行为。
+- 修复建议: 考虑新增一条 P3 用例覆盖导出中断场景，验证取消后系统资源释放、无残留临时文件。
+
+### O-004: 搜索功能缺少特殊字符和注入防护测试
+
+- 涉及模块: 模块A（看板搜索）、模块G（日志搜索）
+- 问题: 当前搜索用例仅覆盖了正常搜索、模糊搜索、不存在搜索和空结果，未覆盖输入特殊字符（如 `<script>alert(1)</script>`、SQL注入字符串 `' OR '1'='1`、超长字符串 1000+ 字符）的防御行为。
+- 修复建议: 考虑为看板搜索和日志搜索各新增1条 P2 安全性测试用例，验证特殊字符输入时不触发XSS、不导致SQL注入、不引起页面崩溃。
+
+### O-005: 列表字段验证用例中缺少"列宽/截断/换行"展示验证
+
+- 涉及用例: AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_APL_003
+- 问题: 当前字段完整性验证聚焦于字段存在性和顺序，未验证字段内容过长时的截断/换行/省略号展示、列宽自适应等展示细节。对于司机姓名、托运方名称、货物名称等文本字段，超长内容展示异常是常见 UI 缺陷。
+- 修复建议: 考虑在现有字段验证用例的预期结果中补充："超长文本字段（如托运方名称50+字符）展示省略号或正确换行，表格不横向溢出"。
+
+### O-006: 看板详情弹窗缺少"关闭弹窗后列表状态保持"验证
+
+- 涉及用例: AH_REPORT_DASH_014, AH_REPORT_DASH_015
+- 问题: 当前详情弹窗用例验证了弹窗内容完整性，但未验证关闭弹窗后看板列表的筛选状态、分页位置是否保持。这是一个常见的易用性缺陷——关闭弹窗后列表重置为第1页，用户需重新翻页。
+- 修复建议: 在现有详情弹窗用例中补充一步"关闭弹窗→验证看板列表筛选条件和分页保持不变"。
+
+### O-007: 前置条件中"系统中存在XX条运单"缺少数据准备指引
+
+- 涉及用例: 约 90% 的用例
+- 问题: 大量用例的前置条件使用"系统中存在运单号XXX的运单记录"或"数据库中存在XX条运单"，未说明如何创建或准备这些数据。虽然这些是前置状态描述而非执行步骤，但对首次执行的测试人员而言，缺少数据准备脚本或数据构造指引会增加执行门槛。
+- 修复建议: 在文件头部或每个模块开头增加数据准备工作说明（如 SQL 脚本引用、造数工具说明），或在备注中标注"可参考测试数据文件构造"。
+
+---
+
+## 维度评分
+
+| 维度 | 得分 | 说明 |
+| :--- | :---: | :--- |
+| 结构完整性 | 13/20 | 表头格式和列数一致，模块路径格式正确，必填列无空值。但存在5处字段数标题与预期结果不一致（B-001~B-005），影响执行可信度。 |
+| 可执行性 | 24/25 | 测试步骤具体、有明确操作和数据，前置条件大多清晰。少量用例（R1_016）预期行为在异常条件下不够精确。 |
+| 原子性 | 10/15 | 绝大多数用例为单一验证点。CROSS_003（全链路四阶段）明显违反原子性。DASH_012、R2_004、R1_003 存在合并多个关注点的情况。 |
+| 预期结果质量 | 18/20 | 几乎全部用例同时覆盖 UI 反馈和数据状态变化，包含数据库层面的 WHERE 条件或记录数断言，质量优秀。APL_015 使用"可能"措辞是唯一明显缺陷。 |
+| 类型准确性 | 9/10 | 类型枚举使用规范。APL_015 建议改为"易用性测试"。 |
+| 优先级合理性 | 8/10 | 整体分布合理（P0 22% / P1 48% / P2 23% / P3 6%）。LOG_001/LOG_003 置于 P0 偏高；DASH_017 置于 P3 偏低。 |
+
+**总分: 82/100**
+
+---
+
+## 亮点总结
+
+1. **预期结果质量突出**：绝大多数用例的预期结果同时包含前端 UI 状态（标签颜色、文案提示）和后端数据状态（数据库记录数、WHERE条件、字段值），远超行业平均水平。
+2. **历史缺陷防御覆盖完整**：4个历史缺陷（BUG-202607-01~04）均有专门的防御用例并在备注中标注来源，形成可追溯的防御闭环。
+3. **覆盖维度全面**：128条用例覆盖了主流程、异常流程、边界条件、状态流转、幂等与并发、权限与越权、弱网/超时、字段完整性等多个维度，无重大遗漏。
+4. **测试点到用例映射完整**：103个测试点均映射到至少1条用例，无静默遗漏。
+5. **待确认项显式标注**：7项待确认均在文末显式标注，符合 DoD 要求。
+
+---
+
+## 修复优先级建议
+
+1. **优先修复 B-001~B-005**（字段数不一致）：直接修改标题或预期结果中的数字，低改动成本、高信心增益。
+2. **次优先修复 B-006**（APL_015 措辞）和 **B-007**（CROSS_003 原子性）：B-006 改一句话即可，B-007 需要判断保留为冒烟测试还是拆分。
+3. **建议项和优化项**可在下轮迭代中集中处理，不阻塞当前评审通过。

output/analysis/安徽运八需求_质量裁决.md

@@ -1,12 +1,12 @@
 # 安徽运八需求 质量裁决
 
-## 裁决结果: ✅ PASS
+## 裁决结果: ❓ PENDING_AI
 
-**裁决理由**: 用例数量: 8，覆盖率达标
+**裁决理由**: 等待 AI Agent 评审（review 战区: case-reviewer → coverage-auditor → quality-gatekeeper）
 
-- 用例数量: 8
-- 裁决时间: 2026-07-13T01:33:01.582202+00:00
+- 用例数量: 18
+- 裁决时间: 2026-07-14T03:40:32.598146+00:00
 
 ## 后续步骤
 
-- ✅ 可执行 `/qe-fleet export` 导出 Excel
+- 🛑 请先解决阻断项，再重新运行 `/qe-fleet design`

output/analysis/安徽运八需求_风险评估.md

@@ -1,10 +1,10 @@
 # 安徽运八需求 风险评估报告
 
-> 生成时间: 2026-07-13T01:33:01.552872+00:00
+> 生成时间: 2026-07-14T03:40:32.577656+00:00
 
 ## 风险概览
 
-- 总风险项: 2
+- 总风险项: 5
 - P0 高风险: 0
 - P1 中风险: 1
 
@@ -14,5 +14,8 @@
 | :--- | :--- | :---: | :---: | :---: | :---: | :---: |
 | RISK-FINANCIAL | 资损 | 2 | 5 | 10 | **P1** | 否 |
 | RISK-AVAILABILITY | 可用性 | 2 | 4 | 8 | **P2** | 否 |
+| RISK-DATA | 数据 | 2 | 4 | 8 | **P2** | 否 |
+| RISK-COMPLIANCE | 合规 | 1 | 5 | 5 | **P2** | 否 |
+| RISK-COMPATIBILITY | 兼容性 | 1 | 3 | 3 | **P2** | 否 |
 
 ## 风险缓解建议