feat: knowledge sync — 安徽运八需求知识沉淀回写知识库

知识库更新:
- historical_defects.md: +4条数据上报领域真实缺陷模式
  (阶段依赖链断裂/重试幂等/跨模块数据不一致/省份代码硬编码)
- common_missed_scenes.md: +11条数据上报专项易漏场景
  (多阶段依赖/第三方核验逐项/重试并发/跨模块一致性/省份隔离等)
- data_reporting_cases.md: 新增数据上报类需求优秀用例范式
  (8大覆盖框架+5条示例用例+7项关键风险点)
- terminology.md: +14条数据上报领域术语

系统修复:
- case_pipeline.py: 注册 data_reporting_cases.md + order_manage_cases.md
- governance_audit.py: 更新 case_generate/AGENTS 关键词期望(旧→新架构)
- AGENTS.md/README.md/.claude: 补全缺失关键词，治理审计通过
- .claude/skills/case_generate/: 创建向后兼容别名 skill

knowledge_base/03_best_practices/data_reporting_cases.md

@@ -0,0 +1,75 @@
+# 数据上报类需求优秀用例范式
+
+> 适用于网络货运平台向省级/国家级监管系统分阶段上报数据的场景（如安徽运八、云南运八等）。
+> 重点不是照抄标题，而是学习以下覆盖结构：多阶段依赖链、第三方核验逐项覆盖、重试幂等、跨模块数据一致性、申诉闭环。
+
+## 推荐覆盖框架
+
+### 1. 汇总看板
+- 列表字段完整性（14+字段）
+- 多条件组合筛选（模糊搜索 + 4级下拉筛选）
+- 排序、分页、导出
+- 空结果提示
+- 不同状态下操作按钮差异化（申诉/进度/详情）
+
+### 2. 多阶段上报依赖链
+- 前一阶段成功后自动触发下一阶段
+- 前一阶段失败/未完成时后续阶段被阻断（**前端+后端双重校验**）
+- 每个阶段的数据完整性验证（子对象分组、必选/可选字段区分）
+- 数据来源溯源验证（上报字段来源于哪个系统模块）
+
+### 3. 自动重试与告警
+- 失败自动重试（3次上限 + 间隔递增）
+- 重试全部失败后通知运营人员（站内信/系统消息）
+- 重试期间手动触发的幂等保护（分布式锁/幂等键）
+- 重试次数与结果的日志完整性
+
+### 4. 第三方核验逐项覆盖
+- 每项核验（车辆资质/司机资质/资金流水/合同/轨迹等）独立设计通过+异常用例
+- 核验异常后可发起申诉
+- 特定异常类型的补充功能（如补传轨迹）
+- 异常代码一览表的覆盖度
+
+### 5. 跨模块数据一致性
+- 上报数据 vs 运单管理模块
+- 资金流水 vs 账户管理/支付流水模块
+- 司机/车辆信息 vs 审核管理模块
+- 发票数据 vs 开票审核模块
+
+### 6. 申诉闭环
+- 异常查询 → 发起申诉 → 跟踪监管反馈 → 合规判断 完整闭环
+- 状态流转：未申诉 → 申诉中 → 申诉通过/驳回 → 重新申诉
+- 处理记录时间线展示
+- 多异常项独立申诉
+- 核验通过时申诉入口隐藏
+
+### 7. 上报日志
+- 按上报阶段/结果/时间范围查询
+- 完整请求/响应报文查看（JSON格式化）
+- 日志分页与字段完整性
+
+### 8. 区域与配置差异化
+- 省份代码根据目标省份动态获取（非硬编码）
+- 行政区划代码与上报目标一致
+- 多省份部署场景下数据隔离
+
+## 示例用例（安徽运八模式）
+
+| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
+| :--- | :--- | :--- | :---: | :--- | :--- | :--- | :--- | :--- | :--- |
+| RPT_FR_001 | 第一次上报 | 装货完成后系统自动触发上报（全字段完整性验证） | P0 | 功能测试 | 1.运单已接单 2.车辆/司机/货物/托运方/收货方信息完整 3.司机确认装货完成 | 1.司机APP确认装货完成 2.回管理端查看上报状态 | 完整运单数据（建单13+托运人7+收货方5+司机13+车辆19+货物+保险） | UI:列表出现该运单，状态:上传中(蓝)→已上传(绿)。数据:请求体含完整子对象，HTTP 200，DB状态更新 | 全字段覆盖 |
+| RPT_SR_001 | 第二次上报 | 资金流水单号重复→系统自动拦截 | P0 | 功能测试 | 系统中已存在相同流水号的记录 | 1.创建新运单打款但流水号重复 2.触发第二次上报 | 重复流水号 | UI:系统提示"流水单号已使用请核实"；上报被阻止。数据:流水号唯一索引生效；接口未被调用 | 幂等保护 |
+| RPT_SR_002 | 第二次上报 | 车辆轨迹合规异常→补传轨迹→重新核验通过 | P1 | 功能测试 | 第二次上报后轨迹合规核验异常 | 1.点"补传轨迹" 2.上传补充GPS点位 3.提交 4.等待重新核验 | 补充轨迹GPS文件 | UI:补传轨迹按钮可见；上传后提示成功等待核验；核验通过后异常消除。数据:补传轨迹追加到原数据；重调核验接口 | 异常恢复 |
+| RPT_AP_001 | 异常申诉 | 核验异常→申诉→驳回→重新申诉→通过 完整闭环 | P1 | 功能测试 | 运单第二次上报核验异常 | 1.发起申诉 2.监管驳回 3.补充材料重新申诉 4.监管通过 | 申诉原因、补充材料 | UI:状态流转完整；处理记录时间线展示。数据:申诉记录完整保留，每次操作有日志 | 闭环验证 |
+| RPT_CM_001 | 通用跨模块 | 第二次上报资金流水与账户管理支付流水数据一致性 | P1 | 功能测试 | 运单已完成打款 | 1.记录账户管理支付流水 2.触发第二次上报 3.核对上报详情资金流水 | 支付金额/流水号/时间/收款方 | UI:上报详情资金流水与账户管理一致。数据:上报请求体资金流水来源于支付流水表，流水号完全匹配 | 跨模块一致性 |
+
+## 关键风险点
+
+| 风险项 | 等级 | 防御措施 |
+| :--- | :---: | :--- |
+| 阶段依赖链断裂 | P0 | 前后端双重校验前置上报状态 |
+| 重试幂等缺陷 | P1 | 分布式锁/幂等键，手动+自动互斥 |
+| 跨模块数据不一致 | P1 | 上报数据实时从源表获取，不使用缓存 |
+| 省份代码硬编码 | P1 | 省份代码从配置中心动态获取 |
+| 资金流水金额不匹配 | P1 | 上报前校验合同金额与实付金额一致性 |
+| 上报接口超时 | P2 | 自动重试+超时告警+异步处理 |