docs: Add JS-to-TS migration test harness implementation plan

[devin-ai-integration]

docs: Add JS-to-TS migration test harness implementation plan

Summary

Adds MIGRATION_TEST_HARNESS_PLAN.md — a comprehensive planning document for a test harness to support and validate the ongoing JavaScript to TypeScript migration. This is a documentation-only change with no code modifications.

The plan proposes five components that extend the existing fitness function infrastructure:

1. Migration Progress Tracker — filesystem-based check that the JS-to-TS ratio never regresses
2. Type Quality Gate — diff-based fitness function blocking new unaccompanied any annotations in TS files
3. any Regression Guard — CI script that tracks total any / eslint-disable count against a stored baseline
4. @ts-ignore / @ts-expect-error Guard — diff-based fitness function blocking new @ts-ignore additions
5. Migration Quality Scorecard — CI job that prints a migration health summary to the GitHub Actions Job Summary

Current state analysis is included: ~92.2% of app/ files are TypeScript (3,932 TS vs 333 JS), with ~399 eslint-disable no-explicit-any comments and ~121 @ts-ignore/@ts-expect-error directives.

Review & Testing Checklist for Human

• Requirements alignment: Verify the five proposed components match the team's actual migration priorities and nothing critical is missing (e.g., should there be a component for tracking PropTypes removal?).
• Baseline numbers: Spot-check the file counts and type-quality metrics in the "Current State Analysis" section against the actual repo. These were generated via automated find/rg commands and may have edge cases.
• Appendix completeness: The per-directory migration table uses "varies" for TS file counts instead of actual numbers — decide if this is acceptable or should be filled in before merge.
• Regex design for any detection: Review the proposed ANY_TYPE_REGEX pattern in Component 2 — consider whether it would produce false positives on legitimate code patterns (e.g., variable names containing "any", string literals, comments).
• IRule interface extension: The plan proposes adding fnFilesystem? to the existing IRule interface for Component 1. Confirm this is an acceptable design direction vs. a separate runner for filesystem-based checks.

No functional test plan needed — this is a planning document only.

Notes

• Link to Devin run: https://app.devin.ai/sessions/1920ad36cf454442999956f947958ca2
• Requested by: @abhay-codeium

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring