Skip to content

principle-migrate-callers-then-delete-legacy-apis

Updated 2026-10-01

name: principle-migrate-callers-then-delete-legacy-apis
description: "Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers."
disable-model-invocation: true

When we decide a new API is the right design, migrate callers and remove the old API in the same refactor wave instead of preserving compatibility layers.

Rule:

  • Do not keep legacy API paths only because internal callers still exist
  • Inventory callers, migrate them, and delete the old API immediately
  • Treat temporary adapters as exceptional and time-boxed, not default architecture
  • Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details

When this applies:

  • No external users depend on backward compatibility
  • The project can absorb coordinated breaking changes
  • The new API is part of a simplification or refactor initiative

Keeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.

This is an unofficial Chinese learning site for pstack. It is not affiliated with poteto. Translations follow the pstack/ directory in the cursor/plugins repository. This site does not ship a Chinese plugin. github.com/cursor/plugins