Implement a migration

A migration moves the implementation from API A to API B — a framework upgrade, a version bump, a library replacement, an internal API sunset — while the behavior callers observe holds. The implementation moves; the contract does not. Migrations fail in two ways, both producing a diff that looks finished: the permanent half-migration (some callsites on the old API, some on the new, indefinitely) and the phantom completion (old-API callsites still alive in dynamic dispatch, registries, or generated code that a text search of the call syntax never reached). This guide adds the migration discipline on top of the base implement-task rules. These are conventions the review packet inspects — nothing enforces them at edit time.

Plan the transformation first — the workspace's change plan covers baseline, waves, and rollback; this guide is the execution half. One discipline covers both kinds: an internal API replacement and a framework/language/library upgrade differ only in trigger, not method. If the new API is meant to behave differently, that is a rewrite — relabel before proceeding.