## 数据完整性缺陷（Critical）

### 触发信号

在以下代码特征出现时启动此检测：
- 同一函数/流程中存在多个写操作（insert/update/delete/save）
- 创建主记录但未处理关联记录（如创建订单未扣库存）
- 删除操作未处理关联数据清理
- 软删除（`deleted_at`、`is_deleted`）相关代码

### 判定流程

1. **识别写操作集合**：`Read` 提取函数内所有写操作，标记每个操作的目标实体（哪个表/集合/资源）
2. **追踪关联关系**：对每个写操作，`find_references` 检查是否存在对应的关联操作：
   - 创建 A → 是否创建/更新了 A 的关联实体 B？
   - 删除 A → 是否清理了 A 的关联数据？
   - 更新 A 状态 → 是否触发了关联操作（审计日志、通知、计数器）？
3. **检查失败路径**：`Read` 检查 catch/rollback 分支是否回滚了所有已执行的写操作，而非仅回滚部分
4. **检查软删除过滤**：对有软删除字段的实体，`find_references` 追踪其查询，确认查询条件中是否过滤了 `deleted_at IS NULL` 或等效条件

### 证据构造

确认缺陷后，输出需包含：
- 写操作集合（列出所有相关的写操作及目标实体）
- 缺失的关联操作（应同步处理但实际遗漏的操作）
- 失败路径分析（异常分支中哪些写操作未被回滚/清理）
- 业务影响（脏数据残留、关联数据泄露、数据不一致的具体后果）

### 排除

- 已通过数据库级联操作保证的关联清理（CASCADE）
- 已有定时任务兜底的异步清理
- 事务范围内的操作（由事务一致性检测项覆盖）
