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
This commit is contained in:
@@ -30,3 +30,16 @@
|
||||
|
||||
### 5. 展示状态
|
||||
- [ ] **状态拆分**:已结单、运输中、已结算、已完成等状态是否分别验证,而不是合并成一个模糊负向场景。
|
||||
|
||||
### 6. 数据上报与外部系统对接
|
||||
- [ ] **多阶段依赖链**:多个上报阶段存在先后依赖时,每个阶段的阻断/通过状态是否独立验证,前一阶段失败是否真实阻断后续阶段(前后端双重校验)。
|
||||
- [ ] **第三方核验逐项覆盖**:监管平台的每项核验(如7类核验:运单重复/车辆资质/司机资质/资金流水/集中支付/合同/轨迹合规)是否逐项设计通过+异常两条用例,而不是合并为"核验异常"模糊场景。
|
||||
- [ ] **重试+手动触发并发**:自动重试期间运营人员手动触发上报,是否存在并发导致重复上报。
|
||||
- [ ] **跨模块数据一致性**:上报数据是否来源于正确的数据源(如资金流水数据应来源于支付流水表而非运单缓存),各模块间修改是否同步。
|
||||
- [ ] **省份/区域配置隔离**:多省份部署时,省份代码、行政区划代码等地域相关字段是否根据目标省份动态获取,而非使用项目默认值硬编码。
|
||||
- [ ] **上报数据字段溯源**:每个上报字段的取值来源是否明确(来源于运单表/司机审核表/车辆审核表/支付流水表/开票表),修改来源数据后上报是否使用最新值。
|
||||
- [ ] **标签颜色映射**:不同状态对应的标签颜色(如蓝/绿/红/橙)是否每种状态独立验证。
|
||||
- [ ] **详情弹窗分组完整性**:详情弹窗按子对象分组展示时,每组字段是否完整、可选字段为空时展示是否合理。
|
||||
- [ ] **轨迹数据边界**:轨迹点位数量(如2~2000个点)的最小值/最大值/超限值是否分别验证。
|
||||
- [ ] **申诉闭环**:申诉流程的完整闭环(发起→复核→通过/驳回→重新申诉)是否端到端验证,而非仅验证单步操作。
|
||||
- [ ] **操作日志可追溯**:上报接口的调用记录(请求/响应报文、HTTP状态码、响应时间)是否完整可查,用于问题排查。
|
||||
|
||||
@@ -7,3 +7,27 @@
|
||||
- **描述**: 商品降价后加入购物车,随后商品恢复原价,结算时依然按降价后的价格计算,导致资损。
|
||||
- **根因**: 购物车缓存了价格,结算时未重新从商品中心获取最新价格。
|
||||
- **防御用例**: `验证商品加入购物车后,后台修改价格,结算时系统自动更新为最新价格`。
|
||||
|
||||
### 缺陷 ID: BUG-202607-01--上报阶段依赖链断裂
|
||||
- **模块**: 数据上报(安徽运八)
|
||||
- **描述**: 运单第一次上报失败(3次重试全部失败),系统未阻断第二次上报触发,导致第二次上报在第一次上报数据缺失的情况下仍然发出,监管平台返回"上报数据不完整"但系统未正确处理该错误。
|
||||
- **根因**: 上报阶段间的依赖校验仅在前端做了按钮控制,后端接口缺少前置上报完成状态校验。
|
||||
- **防御用例**: `验证第一次上报失败后,后端接口层面拒绝第二次/第三次上报请求,返回明确错误码"前置上报未完成"`。`验证三个上报阶段依赖链的每个节点,后端均做了前置状态校验(前端+后端双重拦截)`。
|
||||
|
||||
### 缺陷 ID: BUG-202607-02--重试幂等缺陷导致重复上报
|
||||
- **模块**: 数据上报(安徽运八)
|
||||
- **描述**: 第一次上报超时后进入自动重试,运营人员在重试期间点击"手动上传",系统同时发出了两次上报请求,导致监管平台侧出现两条重复运单记录,触发"运单重复"核验异常。
|
||||
- **根因**: 手动上传和自动重试共用同一上报接口,但缺少分布式锁或幂等键校验。
|
||||
- **防御用例**: `验证上报重试期间手动触发上传时,系统提示"上报处理中"并拒绝重复提交`。`验证同一运单同一上报阶段在1分钟内只能有一条成功上报记录`。
|
||||
|
||||
### 缺陷 ID: BUG-202607-03--跨模块数据不一致
|
||||
- **模块**: 数据上报(安徽运八)/ 账户管理
|
||||
- **描述**: 财务在账户管理模块修改了打款金额(从10000元调整为9500元),但第二次上报仍然发送了旧的10000元金额,导致资金流水核验"金额不匹配"异常。运单管理、支付流水、上报三个模块的数据不同步。
|
||||
- **根因**: 上报模块在运单装货完成时缓存了合同金额,打款完成后未从支付流水表重新获取实际打款金额,而是使用了缓存的合同金额。
|
||||
- **防御用例**: `验证第二次上报的资金流水数据来源于支付流水表(非运单表/缓存),上报金额与财务实际打款金额一致`。`验证财务修改打款金额后,上报模块能感知数据变更并使用最新值`。
|
||||
|
||||
### 缺陷 ID: BUG-202607-04--省份代码硬编码
|
||||
- **模块**: 数据上报(安徽运八)
|
||||
- **描述**: 系统上线安徽运八时,司机信息中的省份代码仍使用云南省代码"28",而非安徽省代码"34",导致第一批运单的司机资质核验全部异常。
|
||||
- **根因**: 省份代码在代码中硬编码为项目默认值(云南省=28),未根据上报目标省份动态切换。
|
||||
- **防御用例**: `验证安徽运八上报的省份代码为安徽省代码,与项目默认云南代码隔离`。`验证多省份部署场景下,上报数据中省份相关字段(省份代码/行政区划代码)与目标省份一致`。
|
||||
|
||||
Reference in New Issue
Block a user