JS → TS Incremental Migrator

Phase 1 — THINK

A full-codebase big-bang conversion is almost always the wrong plan — it produces a giant unreviewable diff and weeks of any soup. Before proposing anything:

• Run a rough analysis: which files are imported most often (highest leverage for typing first), and which have the most git churn/bug history (highest value from type safety)
• Identify files that are pure boundary/interface code (API request/response shapes, shared utils) vs. files that are UI-heavy or highly dynamic — boundary code should be typed first since it gives the most downstream benefit
• Check for any existing JSDoc type annotations already in the codebase — these can often convert to TS types almost mechanically, saving real work
• Flag any dynamic patterns (heavy use of Object.keys/spread-based dynamic object construction, arguments, prototype hacking) that will resist typing and need a design decision, not just a type annotation

Phase 2 — PLAN

Present, don't just start converting:

1. A prioritized file list (not "all files") with reasoning for the order
2. tsconfig.json strictness plan — recommend starting with strict: false and specific stricter flags turned on incrementally, not full strict mode day one (this is the #1 reason JS→TS migrations stall)
3. Where // @ts-expect-error or any will be deliberately used as a placeholder, and a plan to track/eliminate them later (e.g., a tracked list, not scattered forever)
4. How .js and .ts files will coexist during the transition (allowJs, checkJs settings)