Implement a migration

DISRESPEC-SPINE: One fact once. No filler, repeated source material, empty sections, or chat restatement; after successful creation return only clickable artifact links, except for blockers, failed creation, incomplete verification, or irreversible-action confirmation.

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 carries the migration discipline standalone. When runs are parallel, isolate each in its own worktree or branch so their writes stay disjoint. These are conventions the review packet inspects — nothing enforces them at edit time.

Plan the transformation first — the 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.