investigation: Evaluate TypeScript migration for data-intensive layers

[smithrashell]

Summary

Recent regressions (like strategySuccessRate returning object vs number, missing standardProblemsMap) were data shape mismatches between services and their callers. These would be compile-time errors in TypeScript.

Starting Point

JSDoc annotation analysis shows these folders already have documentation that can be converted to TypeScript interfaces:

Folder	JSDoc Annotations	Priority
shared/services	310	High - most data transformations
shared/db	291	High - data layer contracts
shared/utils	155	Medium
app/services	2	Low - needs docs first

Scope

• Evaluate allowJs: true approach for incremental adoption
• Test converting one high-churn file (e.g., sessionService.js) as proof of concept
• Identify which existing JSDoc is still accurate vs outdated
• Document migration approach for future files

Expected Benefits

• Catch data shape mismatches at compile time (not runtime)
• IDE autocomplete for service return types
• Refactoring confidence when extracting helpers
• Self-documenting code replacing potentially stale JSDoc

Out of Scope

• Full project conversion (this is evaluation only)
• Converting UI components (lower value)
• Converting test files

Reference

Discussion noted that ~40-60% of recent regressions were data shape issues that TypeScript would catch.