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