← pstackCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to pstack
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.2.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"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.",
"included_files": [],
"name": "principle-migrate-callers-then-delete-legacy-apis",
"skill_md_contents": "---\nname: principle-migrate-callers-then-delete-legacy-apis\ndescription: \"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.\"\ndisable-model-invocation: true\n---\n\n# Migrate Callers Then Delete Legacy APIs\n\nWhen 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.\n\n**Rule:**\n- Do not keep legacy API paths alive only because internal callers still exist\n- Inventory callers, migrate them, and delete the old API immediately\n- Treat temporary adapters as exceptional and time-boxed, not default architecture\n- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details\n\n**When this applies:**\n- No external users depend on backward compatibility\n- The project can absorb coordinated breaking changes\n- The new API is part of a simplification or refactor initiative\n\nKeeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.\n"
}SHA-256 of public snapshot: fcce9151023e8a3cbd1cd9027c134e49aa59d9e8fc26338b68a5d5a90d1af129