用途
该原则用于指导内部 API 的替换与清理。当团队已经确定新 API 是更合理的设计时，不应因为仍有内部调用方而保留旧 API，而应在同一轮重构中完成调用方迁移与旧 API 删除。
主要能力
- 明确禁止仅因内部调用方仍存在就保留旧 API 路径。
- 要求先盘点调用方，再迁移它们，随后立即删除旧 API。
- 将临时适配器定位为例外手段，需要设定时限，而不是默认架构。
- 要求更新测试以断言新契约，并删除只保护重构前实现细节的测试。
使用方式
该原则以规则形式给出，适用于在引入新内部 API 时对照执行：先完成调用方清单，逐个迁移到新 API，然后删除旧 API；如需临时适配器，应明确其临时性和截止时间；同步调整测试，使其验证新契约而非旧实现。
适用场景
- 没有外部用户依赖向后兼容。
- 项目能够承受协调一致的破坏性变更。
- 新 API 属于简化或重构计划的一部分。
限制
资料未提供具体的工具、命令、代码示例或自动化检查方式。该原则主要针对内部 API，若存在外部用户依赖向后兼容，则不适用。资料指出，同时保留新旧 API 会带来双路径复杂性、拖慢清理，并使代码库呈现只增不减的状态。