Roadmap: judge modularization and module depth #20

Context

codeheat 0.1.0 shows file-level hotspots and change coupling. The next question it should answer is how well a codebase is modularized: whether changes stay inside modules, whether modules are deep (small stable interface, large implementation), and whether that improves. It should treat monorepos deliberately rather than by accident.

Goal

A release line that lets humans and agents judge module structure from the same report, starting with history-only, language-agnostic signals and adding code-aware ones after.

Milestones

1. Show module cohesion and cross-module coupling, aware of workspace packages #15 — Module view: cohesion and cross-module coupling, aware of workspace packages
2. Compare interface churn with implementation churn to spot shallow modules #16 — Interface churn against implementation churn (deep modules from history)
3. Flag hidden coupling: files that change together without importing each other #17 — Hidden coupling: co-change without an import relation (TS/JS first)
4. Measure module depth as implementation size per exported symbol #18 — Module depth from the code: implementation per exported symbol
5. Show whether hotspots and module cohesion improve over time #19 — Trends: are hotspots and cohesion improving?

1 and 2 need only git data and ship together as the next release. Related: #6 (hub files), #9 (large-monorepo performance).

Acceptance criteria

• Each milestone issue is closed.
• Before 1 and 2 are planned, codeheat 0.1.0 has been run on a few real projects, and what counts as a "module" there is recorded in Show module cohesion and cross-module coupling, aware of workspace packages #15.