Domain Refactor Cutover Strategy

Guides multi-phase domain renames across the monorepo (backend, frontend, shared contracts). Derived from the Phase 4 mc→creator cutover (S1–S4).

When to Use

• Planning a rename that spans DB models, API contracts, backend services, and frontend features.
• Reviewing or extending an in-progress cutover scope branch.
• Deciding whether to add backward-compatibility aliases vs. direct rename.

Core Principles

1. Scope isolation: One branch per scope, one scope at a time. Merge to master before starting the next.
2. Contract-first: Rename shared contracts (@eridu/api-types) before backend consumers, backend before frontend.
3. DB internals last (or never): Prisma model names and DB columns are expensive to rename (migration + backfill). Prefer keeping DB internals stable and renaming at the service/API boundary.
4. No net-new features: Cutover scopes are rename/refactor only. Defer product changes to post-cutover branches.

Phase Ordering