用途
这条原则用于指导内部 API 的演进方式。当团队已经认定某个新 API 是正确设计时，本原则主张在同一轮重构中完成调用方迁移并删除旧 API，而不是为了兼容仍然存在的内部调用方而保留旧路径。
主要能力
原则给出了明确的行为规则：
- 不要仅仅因为内部调用方仍然存在就保留旧 API 路径。
- 盘点调用方，迁移它们，并立即删除旧 API。
- 将临时适配器视为例外并设定时限，而不是默认架构。
- 更新测试以断言新契约，并删除那些只保护重构前实现细节的测试。
使用方式
在引入新内部 API 且旧调用方仍然存在时应用本原则。执行路径为：先清点所有调用方，逐一迁移到新 API，随后删除旧 API；如需临时适配器，应明确其例外性质并限定存在时间；最后调整测试，使其验证新契约，并移除仅针对旧实现细节的测试。
适用场景
原则明确列出适用条件：
- 没有外部用户依赖向后兼容。
- 项目能够承受协调一致的破坏性变更。
- 新 API 属于简化或重构计划的一部分。
限制
资料未提供该原则的具体实现代码、工具支持、安装命令或平台信息。其核心论点是：同时保留新旧两套 API 会带来双路径复杂性，拖慢清理进度，并使代码库呈现只增不减的状态。