变更影响分析

默认只读。先用真实依赖与现有文档证明影响面，再实施；未知项明确标“未验证”。

修改前

依次回答：

1. 代码：入口、直接调用方、下游消费者、生成物和兼容层会受什么影响？
2. 数据：Schema、迁移、历史数据、序列化、缓存和幂等键是否变化？
3. 接口：API、消息、文件格式或 CLI 是否改变？消费者和提供者分别是谁？
4. 测试：哪些成功标准、TEST-ID、契约测试和回归命令应证明变更正确？
5. 文档：是否影响 MAP、ARCHITECTURE、STATUS、LOG、CONTEXT、ADR、CONTRACT、Spec/Plan、TESTS 或 REGRESSION？
6. 发布：部署顺序、兼容窗口、数据恢复、回滚命令和不可逆部分是什么？

证据优先取自真实 import/调用、路由、Schema、配置、生成脚本、git grep、git diff 和可执行测试。不要凭目录名猜依赖。

路由规则

• 架构、数据库、认证、部署拓扑或长期技术策略：检查 context-and-decisions / ADR。
• 跨端接口：先更新 contract-first 管理的唯一契约源，再规划消费者、提供者和联调证据。
• 需求、业务规则、风险或 Bug：让成功标准保留在 Spec/Issue，并用 test-collaboration 关联 TEST-ID。
• Module 行为或下游依赖变化：实施后运行 module-regression；若权责、状态归属、Interface、依赖方向或核心流转改变，同步更新 ARCHITECTURE.md，并确保 MAP 仍能导航到它。
• 数据库迁移、破坏性接口、认证和生产发布：必须写回滚条件、恢复步骤、兼容期和不可逆部分；缺任何一项就标为阻塞，不代替人执行回滚。

输出

小改动在回复中给出：影响对象、证据、所需验证、文档同步和未知项。只有跨模块、高风险或用户明确要求留档时，才把报告写入 docs/impacts/；写文件前先确认，避免制造一次性文档。

实施后对照

完成实现后检查：

1. 实际改动是否解决 Spec/Issue 中的原始问题。
2. 实际 diff 是否超出已声明范围；超出项是否获得授权并补充影响分析。
3. 测试和人工证据是否真正覆盖成功标准，而非只证明命令运行过。
4. CONTEXT、ADR、CONTRACT、TESTS、REGRESSION、MAP、ARCHITECTURE、STATUS 和 LOG 是否按实际变化同步。
5. 是否遗留临时代码、兼容逻辑、迁移尾项或后续 Issue。

默认在交付回复中报告对照结论。只有高风险变更或用户要求正式评审时，才保存到 docs/reviews/。不要创建通用 REFLECTION.md。