代码修改影响分析（Code Change Impact）

AI 说明

目的：对任何代码改动做系统性影响分析，回答两件事——这次改动是否解决了它该解决的问题、它会牵连谁。不判代码质量与规范（那是 code-review），不做运行时取证与修复实施（那是 debug）。

功能：先按改动性质分流策略（缺陷修复 / 行为等价优化 / 能力新增 / 契约变更 / 数据与状态变更），再定位改动的意图与根因，然后用统一的四维影响面（调用链 / 条件路径 / 数据流 / 执行场景）叠加策略专属增量，产出影响面清单、回归风险分级与测试建议。

使用场景：用户提供改动（diff / commit / 已合入代码）要求评估风险时；修复合入前需要影响面与回归风险背书时；被 debug 调用做修复前方案评估或修复后影响质检时；被 code-review / challenger 调用补齐影响面清单时；被 auto-review 的「影响面缺口」出口提示时（契约面改动 / 被改符号 ≥3 处引用 / 跨 ≥2 模块——此入口只提示不自动执行）。

核心原则

先定改动性质，再定分析重点：同一个四维骨架，不同性质的改动要加压的地方不同——不区分就会"用查 Bug 的力气查重构"
意图与影响优先：先搞清"它想解决什么"，再判断"解决了吗"；局部正确不代表安全，判断关键在"会影响什么"
横向+纵向双重覆盖：纵向追溯调用链（谁调用了被改的代码），横向展开条件路径（不同参数/状态下是否都安全）
假设可验证：每个影响结论都要给出可验证手段（跑哪个测试、查哪个模块、复现哪个场景）
最小化交互：自主推理影响面，仅在关键信息缺失时提问
专家资产复用：分析前主动查询专家团与解决方案，复用已知坑、实现导航加速诊断
证据不足转排错：静态推理不足以支撑根因或影响结论时，转 debug 用运行时证据取证，不凭推理定罪（详见「与 debug 的互引」）
容错迭代：用户纠正后快速更新分析

策略路由

五类策略，可多选叠加（一次改动常混合多类，如"新增接口 + 改表" = 能力新增 + 数据与状态变更）。

策略	启用信号（命中即启用）	策略文件
缺陷修复	issue / bug / 缺陷 / 故障 / 崩溃 / 异常 / 报错 / 回归 / 修复	strategies/defect-fix.md
行为等价优化	性能优化 / 重构 / 提取 / 合并 / 拆分 / 简化 / 清理 / 精简 / 依赖升级 / 降级依赖 / 换实现	strategies/behavior-equivalent.md
能力新增	新增 / 增加 / 支持 / 上线 / 新接口 / 新字段 / 新页面 / 新配置 / 开关 / 灰度 / 下线 / 移除（页面、入口、开关）	strategies/capability-add.md
契约变更	签名 / 参数 / 返回值 / 异常类型 / API 路由 / DTO / 事件格式 / 公共类 / 中间件 / 删除 / 移除 / 下线 / 废弃（接口、方法、字段、事件、配置项）	strategies/contract-change.md
数据与状态变更	表结构 / 字段 / 索引 / 迁移 / 缓存键 / 枚举 / 状态机 / 配置默认值 / 删表 / 删列 / 字段废弃	strategies/data-state.md

识别规则：

契约变更优先级最高：只要签名、返回值、异常类型、API 路由、事件格式变了，无论改动动机是什么，必须同时启用契约变更——它决定调用方语义是否还成立，漏掉就是漏掉整条调用链
未命中任何策略 → 按通用四维（3.1~3.4）全量执行，不额外加压
策略只改"增量必查项"与"维度优先级"，不改流程骨架：禁止把策略写成另一套步骤——分析仍是 Step 0~7 的既有流程，策略文件只回答"这类改动额外必查什么、哪些维度要升级、不做什么"
删除类信号按对象分流：删除 / 移除 / 下线 / 废弃 不是契约变更的专属——删接口/方法/字段/事件 → 契约变更；删表/列/缓存键/枚举值 → 数据与状态变更；删页面/入口/开关 → 能力新增（按"旧路径未破坏"反向核）。一次删除常需并发启用其中两项以上

输出（Step 0 末尾给出，让用户可纠偏）：

🎯 启用策略
━━━━━━━━━━━━━━━━
- ✅ 契约变更（命中：方法签名新增必填参数）
- ✅ 数据与状态变更（命中：orders 表新增 status 字段）
- ➖ 未启用：缺陷修复 / 行为等价优化 / 能力新增
- 顺序：契约变更优先（决定调用方语义），再数据与状态变更

执行流程

Step 0：上下文收集

改动描述：用户报告的现象 / 需求 / 优化动机（有复现步骤、报错日志、需求 ID 更好）
改动代码：git diff、commit hash、或直接粘贴
被改代码上下文：读取被修改文件的完整内容，理解函数/类/模块的完整职责
影响面取数准备：确认数据来源可用（代码索引是否存在、符号查询是否可用），取数规则见 3.0；实际取数在 Step 3 执行。若上游（code-review / debug / challenger）已给出影响面清单，直接复用并只补缺口，不重推
策略识别：按上面的策略路由表判定，可多选；输出启用策略
资产复用查询（专家团 + 解决方案）：调用 use_skill("expert-solution-workflow") 查询被修改模块的相关经验、解决方案或记忆（如业务专家资产包；查询失败或不可用，忽略此步骤继续）。如有，加载相关资产（已知坑、实现导航、架构知识）——"已知坑"助快速定位根因，"实现导航"助理解影响范围
强关联关系查询：调用 use_skill("ki-memory-lookup") 检索被改模块的强关联关系（跨模块契约/业务耦合），识别"改这里牵动了哪些其他模块"（查询失败或无可用记录，忽略继续）
决策记忆查询：调用 use_skill("ki-memory-lookup") 的决策记忆策略查被改模块的历史决策，核对其「重新评估触发条件」是否已满足；满足则说明该决策应重新评估，作为影响面分析的补充输入（查询失败或无可用记录，忽略继续）

如果只有改动描述没有代码，先进入 Step 1 做意图与根因诊断，帮助定位后再对方案做影响分析；若定位需要运行时证据，调用 use_skill("debug") 取证并修复——其 Step 4 根因结论可直接作为本 skill Step 1 输入，完成后回到本 skill 做质检。全部转交时机见「与 debug 的互引」。

Step 1：改动意图与根因分析

先回答"这次改动想解决什么"。不同策略的落点不同：

策略	本步要产出什么
缺陷修复	根因链：现象 → 直接原因 → 间接原因 → 根本原因
行为等价优化	等价性目标：改前外部行为是什么、哪些允许变、哪些必须不变
能力新增	意图与覆盖：新增能力要满足的需求、与既有能力的边界
契约变更	旧契约与新契约：调用方此前依赖的语义（类型/空值/异常/时序）
数据与状态变更	数据语义：字段/状态的含义、合法值域、历史数据的迁移口径

1.1 定位核心问题

直接原因是什么？（如：空指针、类型错误、边界条件遗漏、契约不匹配）
为什么会出现？（如：缺少校验、设计遗漏、外部依赖变化、需求未覆盖）
链条：直接原因 ← 间接原因 ← 根本原因，一层层往下挖，不满足于第一层

1.2 评估根因的严重度

本小节仅启用缺陷修复策略时必填（含外部依赖变化导致的缺陷）；纯能力新增、行为等价优化、数据变更没有"根因"可挖，跳过本表，在 1.3 把「根因类型」改写为改动性质（新增 / 等价变更 / 数据迁移）。

根因类型	风险等级	说明
系统性缺陷	🔴 高	设计层面问题（如缺少错误处理机制、接口契约不明确），同类问题可能广泛存在
实现遗漏	🟡 中	某个边界条件或异常路径未覆盖
外部依赖变化	🟡 中	上游接口/数据格式变更导致
单点疏忽	🟢 低	纯编码疏忽（如拼写错误、类型写错）

关键判断：根因是系统性的还是单点的？系统性缺陷意味着同类问题可能存在于其他位置，必须标记出来。

证据不足时转交：若静态推理无法唯一定位根因（多假设难定夺），或结论缺运行时支撑，调用 use_skill("debug") 取证，拿到证据后回填本 Step，不凭推理定罪。

1.3 输出

## 🔍 改动意图与根因

**改动类型**：[启用的策略]

**意图链（🕸 文字树，自上而下）**：
现象 / 动机：[用户看到的问题，或要达成的目标]
│
▼
直接原因 / 直接手段：[什么代码行为导致了这个现象]
│
▼
间接原因 / 间接影响：[B]
│
▼
根本原因 / 根本目标：[C]　← 根因（缺陷修复）/ ← 目标（其余策略）

**根因类型**：[系统性缺陷 / 实现遗漏 / 外部依赖变化 / 单点疏忽]
（非缺陷修复类改动，此行改写为 **改动性质**：能力新增 / 等价变更 / 数据迁移）

**同类风险排查**（仅系统性缺陷时）：

- 同样的模式在哪些地方也存在？
- [列出可能受同类问题影响的位置]

🕸 文字树语法：不另造，沿用 performance-analysis/reference.md §9.4.3 的「最小共享语法（4 条）」（骨架 │+▼ / 分支 ├─ └─；节点挂状态与数字；并行串行不混标；只画结构类信息、节点 ≤15、层级 ≤4、不画决策路径与审批流）。本 skill 的领域标记词：← 根因 / ← ❌ 确定受影响 / ← ⚠️ 需检查 / ← 待验证。清单与判定仍用表格。

Step 2：改动方案评估

有了意图与根因，评估这次改动是否对症。

2.1 评估维度

检查维度	问自己
意图达成	改动是否解决了它声称要解决的问题，还是只处理了表面症状？
覆盖完整性	是否覆盖了所有触发场景？（缺陷：所有触发路径；新增：所有需要贯通的链路）
方案级别	是"打补丁"还是"修正设计"？
改动范围	有没有搭车变更（顺手做的优化/清理/重构）？这些是否被意图授权？

2.2 判定四档

情况 A：对症

解决了根因/达成了意图，方案合理，范围与意图匹配。

情况 B：治标不治本

只处理了表象，根因仍在。建议：更根本的思路。

情况 C：改动过度

引入了不必要的复杂度，或改变了不应改变的行为（含未授权的搭车变更）。建议简化/拆分。

情况 D：改动不足

该改的没改全——如新增字段没有消费方、改了写入没改读取、修了主路径没修异常路径。建议补齐清单。

## 🩹 改动方案评估

**改动内容**：[简述做了什么]

**判定**：[A / B / C / D]

**理由**：[为什么这样判断]

**如果是 B / C / D**：
- 根因 / 意图：[XXX]
- 建议的调整：[YYY]
- 当前改动的局限：[ZZZ]

B / D 的落地：更深层或补齐性的实施默认交 use_skill("debug") 走最小修复闭环（修复 + 回归验证），完成后回到本 skill 质检——本 skill 只给出思路与缺口清单；由本 skill 直接落地的唯一例外见 Step 7 选择 1。

Step 3：影响范围分析（核心步骤）

3.0 取数要求

不满足取数要求的结论，最高只能标 ⚠️ / [需确认]，不得标 ✅ / ❌。

清单必须来自真实查询：调用方、被调方、受影响模块、受影响页面，一律来自符号查询与代码索引，禁止从 diff 目测推断。查询手段按仓库既有规则执行，本 skill 不重复规定工具选择
索引优先（仓库有 .fe-index/ 时最省）：use_skill("index-lookup") 读 .fe-index/INDEX.md 匹配被改文件——后端查 tables.md（表 → 模块反向）与 modules/*.md（被依赖 + 事件/命令耦合），前端查 apis/*.md（接口 → 页面）。索引给的是候选影响面清单，逐条仍要回源码确认（无索引 / 未命中 / 过期 → 按原流程，不阻塞）
回源码确认：查询结果一律视为候选，逐条读源码确认后才可定级
覆盖不全必须补齐：查询结果明显少于源码所见（如只返回 1 个调用方但 grep 见到 5 处）时，视为覆盖不全，用 grep 补齐；禁止据此断言"没有影响"

3.1 纵向影响：调用链分析

沿调用链向上追溯，分析改动对每个调用方的影响：

调用方	调用位置	调用方式	是否受影响	影响说明
`function_A()`	`file_a.py:42`	直接调用	✅/⚠️/❌	[改动对调用方的影响]
`function_B()`	`file_b.py:100`	间接调用	✅/⚠️/❌	[二级调用方是否受影响]
`ClassName.method()`	`file_c.py:88`	继承覆盖	✅/⚠️/❌	[子类实现是否受影响]

影响级别：

✅ 无影响：调用方不依赖被修改的行为
⚠️ 需检查：可能受影响，建议人工确认（含取数不完整的项）
❌ 确定受影响：调用方行为会因改动而改变，必须相应调整

3.2 横向影响：条件路径分析

参数空间枚举：

参数/条件组合	改动前行为	改动后行为	语义是否一致
`param=A`	[原行为]	[新行为]	✅/⚠️/❌
`param=B`（边界）	[原行为]	[新行为]	✅/⚠️/❌
`param=空/None`	[原行为]	[新行为]	✅/⚠️/❌
`param=异常值`	[原行为]	[新行为]	✅/⚠️/❌

关键问题：

是否在某些路径上改变了返回值语义（类型、含义、空值处理）？
是否在正常路径生效但异常路径不生效（或相反）？
是否改变了副作用（日志、缓存更新、状态变更）？

3.3 深度影响：数据流分析

检查维度	分析内容
返回值变化	类型/空值/含义是否变化？调用方是否按旧语义消费？
副作用变化	是否新增/移除 I/O、缓存写入、状态变更、事件触发？
异常传播	异常类型或抛出时机是否变化？调用方处理是否匹配？
全局状态	是否影响全局变量、配置项、单例状态？

3.4 执行场景分析

场景	改动前行为	改动后行为	语义一致性
正常执行	[行为]	[行为]	✅/⚠️/❌
首次执行/初始化	[行为]	[行为]	✅/⚠️/❌
重复执行	[行为]	[行为]	✅/⚠️/❌
高并发执行	[行为]	[行为]	✅/⚠️/❌
降级/容错	[行为]	[行为]	✅/⚠️/❌
外部依赖失败	[行为]	[行为]	✅/⚠️/❌

3.5 叠加策略增量

四维的默认优先级：调用链（3.1）🔴、条件路径（3.2）🟡、数据流（3.3）🟡、执行场景（3.4）🟡——无策略加压时按此执行。

四维跑完后，按 Step 0 启用的策略，逐个套用其「增量必查」表（见 strategies/*.md），把结论并入对应表格。策略文件的「维度优先级调整」表只列需要说明的维度（升降必须标出；标「不变」表示该项本策略无需额外加压、仅作确认）；标为 🔴 的维度必须给出明确结论，不得留空。

待验证项的运行时验证：标注 [需确认] 或 ⚠️ 的项，建议调用 use_skill("debug") 用运行时证据验证（构造复现/插桩观察）。凡能用复现验证的影响结论，不凭静态推理定论。

3.6 输出影响分析报告

## 📊 影响范围分析

### 调用链影响

**🕸 影响链文字树**（树看结构：谁牵动谁、几层；**判定与说明仍看下方表**，树的级别标记须与表一致；调用方 ≥2 或有二级调用方时必画）：

```text
`update_status()`（被改动函数）
├─ `handler()`（api.py:42）　← ❌ 确定受影响
│  └─ `dispatch()`（router.py:88）　← ⚠️ 需检查
└─ `scheduler()`（cron.py:100）　← ⚠️ 需检查
   └─ （无下游）
```

| # | 调用方 | 位置 | 影响级别 | 说明 |
|---|--------|------|----------|------|
| 1 | `handler()` | `api.py:42` | ❌ 确定受影响 | 返回值从 `dict` 变为 `dict 或 None`，调用方需增加判空 |
| 2 | `scheduler()` | `cron.py:100` | ⚠️ 需检查 | 使用了返回值，但已有判空 |
| 3 | `test_foo()` | `test_api.py:55` | ✅ 无影响 | 测试直接调用，无依赖 |

### 条件路径影响

| 参数条件 | 改动前 | 改动后 | 一致性 | 说明 |
|----------|--------|--------|--------|------|
| `user_type="admin"` | 返回全量 | 返回全量 | ✅ | 行为不变 |
| `user_type=None` | 抛 TypeError | 返回空列表 | ⚠️ | 语义变化，调用方可能依赖旧行为 |

### 数据流影响

- **返回值**：[变化及影响]
- **副作用**：[变化及影响]
- **异常传播**：[变化及影响]
- **全局状态**：[变化及影响]

### 场景覆盖

| 场景 | 影响 | 说明 |
|------|------|------|
| 正常执行 | ✅ | 行为符合预期 |
| 高并发 | ⚠️ | 移除了锁检查，并发下可能出问题 |

### 策略增量结论

[按启用策略，逐条列出 strategies/*.md 要求的增量必查项及结论]

Step 4：回归风险评估

影响级别 → 风险等级的映射（同一影响项只计一次，不重复计数）：

影响级别（Step 3）	风险等级（本步）	含义
❌ 确定受影响	🔴 高危	确定会导致其他功能异常，合入前必须处理
⚠️ 需检查（含取数不全）	🟡 中危	可能影响，需人工确认或运行时验证
✅ 无影响	🟢 低危	几乎无影响

## 🚨 回归风险评估

### 风险总览

| 风险等级 | 数量 | 说明 |
|----------|------|------|
| 🔴 高危 | N | 确定会导致其他功能异常 |
| 🟡 中危 | N | 可能影响，需人工确认 |
| 🟢 低危 | N | 几乎无影响 |

### 高危风险详情

**[R1] 风险名称**
- 影响范围：[受影响的功能/模块]
- 触发条件：[什么时候会出问题]
- 影响表现：[用户会看到什么]
- 修复建议：[如何避免这个回归]

### 未被覆盖的同类风险

如果根因是系统性的（或策略为契约变更 / 数据与状态变更），列出**本次改动未覆盖的同类问题**：

- `file_x.py:line_y`：同样的模式，同样的风险
- `module_z/xxx.py`：相同的外部依赖处理，可能同样有问题

**同类风险的确认**：上述位置是否真被触发，交 `use_skill("debug")` 逐个复现确认；**未确证的只标「疑似同类」**，不计入确定风险。

Step 5：测试建议

## 🧪 测试建议

### 必须补充的测试

| 测试场景 | 优先级 | 原因 | 建议测试类型 |
|----------|--------|------|--------------|
| [场景1] | P0 | [没有这个测试，回归风险高] | 单元/集成/E2E |
| [场景2] | P1 | [建议补充以提升覆盖] | 单元/集成/E2E |

### 回归测试检查清单

- [ ] 调用方 `function_A()` 的现有测试是否仍然通过？
- [ ] 边界条件 `param=None` 是否被测试覆盖？
- [ ] 异常路径 `xxx_fails` 是否被测试覆盖？
- [ ] 并发场景下的行为是否被验证？
- [ ] [按策略追加，见 strategies/*.md 的必测清单]

本节只到"该测什么、为什么"；需要用例、断言与落盘位置都齐的结构化测试计划时交 test-planner。

Step 6：输出完整报告

# 代码修改影响分析报告

## 📋 基本信息
- **改动描述**：[用户原始描述 / 需求 ID]
- **启用策略**：[缺陷修复 / 行为等价优化 / 能力新增 / 契约变更 / 数据与状态变更]
- **改动内容**：[摘要]
- **影响文件**：[文件列表]
- **分析时间**：[时间]

## 🔍 改动意图与根因
[Step 1 输出]

## 🩹 改动方案评估
[Step 2 输出]

## 📊 影响范围分析
[Step 3 输出，逐节填入下列子节]
### 调用链影响
### 条件路径影响
### 数据流影响
### 场景覆盖
### 策略增量结论

## 🚨 回归风险评估
[Step 4 输出]

## 🧪 测试建议
[Step 5 输出]

## 📝 总结与行动项

| 优先级 | 行动项 | 关联影响 |
|--------|--------|----------|
| P0 | [必须做的事] | R1, R2 |
| P1 | [建议做的事] | C1 |
| P2 | [可选的增强] | - |

## ⚖️ 结论
- **意图达成**：是 / 否 / 部分
- **合入建议**：可合入 / 补齐后合入 / 建议重做

Step 7：后续步骤

分析报告已完成，请选择后续步骤：

1. 🩹 实施修复/补齐 — 默认交 debug 走最小修复闭环（修复 + 回归验证）；单点封闭改动可由本 skill 直接落地
2. 🔬 转 debug 取证 — 影响项标注 [需确认]、同类风险待复现确认，或根因缺运行时证据
3. 🧪 发起 challenger 质疑 — 对分析报告本身做二次审查，检查遗漏或误判
4. 🔎 转 code-review — 需要评代码质量、规范、架构（本 skill 只判意图与影响面，不做质量评审）

请选择 [1 / 2 / 3 / 4 / 无需后续]

选择 1：实施修复 / 补齐

默认交 use_skill("debug") 走最小修复闭环，完成后回到本 skill 复检影响面
例外：改动单点、影响面封闭（无跨模块调用方）、且用户明确要求由本 skill 直接落地时，可实施；实施后仍须回本 skill 复检
修复完成后自动进入 writing-pipeline（auto-review → 视复杂度触发 challenger）

选择 2：转 debug 取证

调用 use_skill("debug")，把待验证项（复现条件/插桩点/需确认的调用方）交给它取证
取证结论回填报告，更新风险等级与测试建议后，再让用户选择是否修复

选择 3：发起 challenger 质疑

调用 use_skill("challenger") 对本次分析报告做二次审查
质疑聚焦：根因是否找对、影响面是否遗漏、风险评估是否过度/不足、策略是否选错
质疑结果反馈后，用户可选择更新报告或直接进入修复

选择 4：转 code-review

调用 use_skill("code-review")：本 skill 已给出"会牵连谁"，code-review 补"改得对不对"
两边都做过时，把影响面清单作为 code-review 的输入，避免它重复推导

与 code-review 的分工（并列 · 双向指认）

两个 skill 都能回答"改了什么会影响什么"，分工按问句切，不按工具切：

	`code-review`	本 skill
回答的问题	这次改得对不对、够不够好	这次改会牵连谁
影响面的用法	服务于发现问题的抽样推理（维度 0.6~0.9）	交付本身的穷举清单
输出	分级问题清单（P0/P1/P2）	影响面清单 + 回归风险分级 + 测试建议
触发时机	拿到 diff 求评审	改动已定/已合入，求风险背书
不做	不产出穷举影响面清单（抽查为主）	不判代码质量、不给重构与规范建议

互补不重复：一次任务既要评审又要影响面时，先 code-review（发现问题）再本 skill（划定影响）；或并行，但影响面清单只由本 skill 产出
可互相转交：本 skill 发现"质量本身有问题"→ 转 code-review；code-review 发现"影响面超出抽样范围"→ 转本 skill 补齐清单

与 debug 的互引（取证与落地）

完整分工与双向接力全景以 debug skill 为 SSOT，本节只定义本 skill 转交 debug 的场景。

时机	触发条件	动作
无改动代码	只有描述，且定位意图/根因需运行时证据	转 debug 取证修复；其 Step 4 根因结论直接作为本 skill Step 1 输入
Step 1 证据不足	静态推理无法唯一定位根因，或多假设难定夺	转 debug 复现/插桩取证，证据回填后再继续
Step 2 情况 B / D	更深层修复或补齐清单需要落地	实施交 debug 最小修复闭环，完成后回本 skill 复检
Step 3 影响项待验证	标注 `[需确认]` 或 ⚠️ 需检查	转 debug 用运行时证据验证，不凭静态推理定论
Step 4 同类风险	列出的同类位置是否被真实触发	逐个交 debug 复现确认；未确证只标「疑似同类」

方向不对称提示：debug 修复完成后默认可转本 skill 质检（单向强依赖）；本 skill 转 debug 是条件触发——仅当结论缺运行时证据、或需要落地修复时才转，静态可定论的不转，避免无谓的排错开销。

互转终止规则：同一问题在两侧往返各限一次（本 skill → debug → 本 skill 后停止互转），输出「阻塞清单」请用户补充信息或人工介入。完整规则以 debug skill 为 SSOT。

行为边界

分析阶段不改代码：分析过程只输出报告；仅当用户在 Step 7 明确选择"实施修复/补齐"后，方可按该节的例外条件落地
修改权：修复/补齐实施默认交 debug；仅"单点 + 影响面封闭 + 用户明确要求"时由本 skill 落地，落地后必须复检
不判代码质量与规范：代码质量、规范、架构合理性交 code-review；本 skill 只判"意图是否达成、范围是否匹配、会牵连谁"——Step 2 的判定是影响分析的基准，不是质量评审
不做需求完整性：新增能力的"该不该有、需求覆盖全不全"交 requirement-mining / negative-requirement；本 skill 只查"新增的东西链路走通了吗、有人消费吗"
不替代测试：测试建议用于指导，实际测试仍需编写和执行
推理可追溯：每个影响结论必须关联到具体调用链、条件路径或数据流推理
不确定性标注：无法确认的影响标 [需确认]，取数不全的标 ⚠️
意图与影响优先：分析影响前必须先找到改动意图与根因，否则影响分析缺乏基准
专家资产优先：专家团存在相关模块资产时，优先利用已知坑与实现导航，减少重复调研
不编造调用关系：调用关系必须来自实际查询并回源码确认，不允许凭空推测

需求管理集成

当项目配置了 .requirements/config 且 storage_path 指向有效目录时，独立使用的分析完成后自动执行集成操作（被其他 skill 调用时跳过，由调用方统一集成）：

获取需求上下文：分析前，如果关联了 REQ-ID，先读取需求信息作为参照：

req list --id {REQ-NNN} --deps

写入分析报告到需求目录后，调用 req update 注册文档关联：

req update {REQ-NNN} \
  --docs add review/code-change-impact.md,review --changelog "完成代码修改影响分析"

错误处理：
- 需求 ID 不存在或未关联 REQ → 跳过集成，不影响分析本身
- 文件锁超时 → 自动重试 1 次，仍失败则告知用户

存储路径映射：

产出物	存储路径	docs 类型
代码修改影响分析报告	`review/code-change-impact.md`	`review`

兼容旧路径：本 skill 重命名前为 bug-impact-analysis，历史报告位于 review/bug-impact-analysis.md。同一需求内只保留一份报告、路径保持一致——新需求一律写 review/code-change-impact.md 并登记该路径；若该需求已有旧路径文档，则在旧路径上追加并登记旧路径，不改名、不新开第二份。

code-change-impact

SKILL.mdskills/code-change-impact/SKILL.md