| 123456789101112131415161718192021222324252627282930 |
- ---
- description: 任何方案都必须从改动点反向推演全部影响面并写入「反向影响推演」小节，禁止只验证局部
- alwaysApply: true
- ---
- # 反向影响推演（强制）
- ## 硬性要求
- 方案在**交付给用户或落地之前**，必须从**改动点**出发**反向**推演所有可能受影响的地方，并在方案中写出**「反向影响推演」**小节。
- **禁止**只为修好触发问题的那一条路径就宣布完成。
- ## 每个改动点至少反查这六类
- 1. **代码调用面**：该方法/类/常量/SQL 片段的**全部**调用方（实际检索，不靠印象）。
- 2. **数据契约面**：被改的表/列/枚举值/JSON 字段，还有**哪些模块**在读写（KPI SQL、看板、查询页、监控、诊断证据、ChatBI、导出）。
- 3. **多数据源面**：同一条链路上的**其它来源**是否也会走到（T8 / 165 MES·WMS / 自建单 / 我方标准 API 入站），某源缺字段时行为如何。
- 4. **多租户 / Domain 面**：租户投影、`tenant_id`、`domain` 过滤是否仍然成立。
- 5. **运行面**：迁移脚本、启动期 DDL、种子数据、定时任务、缓存、部署配置。
- 6. **验证面**：是否有守卫测试能卡住回归；没有就补。
- ## 小节写法
- 列出「已核查的面 → 结论」，结论只能是三种之一：**无影响** / **需同步改（列出文件）** / **需你决策（列出选项）**。
- 不得用「应该不影响」「大概没问题」代替实际检索结果。
- ## 反例与正例
- - ❌ 改 `mdp_std_inv_trans.trans_type` 的映射语义，只验证 S5 库存页正常 → 交付。
- - ✅ 同一改动先反查：S3/S5/S6/S7 的 KPI SQL、S8 监控、智慧诊断证据 SQL、ChatBI、进出存查询页、`mdp_std_inv_trans_unmapped` 隔离与告警、T8 与 165 两个来源各自的字段可得性，逐条给出结论，再交付。
|
