module-map

# module-map

Orient fast in unfamiliar code. The deliverable is a map, not a tour.

## Deliverable

A single response containing, in this order:

1. **One-line summary** of what the area does from a caller's point of view.
2. **Entry points** — every function, route, CLI command, event handler,
   or cron that starts a call chain in this area. File path + symbol.
3. **Core modules** — the two to five modules that contain the real
   logic. One line each describing their role.
4. **Data flow** — ASCII arrows showing the dominant path for the most
   common input. Skip error paths unless they matter architecturally.
5. **External callers** — who outside this area calls in, and through
   which entry points.
6. **Hidden coupling** — anything that looks independent but is not
   (shared singletons, global state, implicit ordering, undocumented
   contracts between files).

## Rules

- Fifteen-second read target. If the map exceeds one screen, cut it.
- Every claim must be backed by a file path. No remembered or inferred
  structure without a grep behind it.
- Do not list every file. Curate. A good map omits deliberately.
- Do not propose changes. Mapping is orientation; refactoring is a
  different skill.
- If the area is too large to map in one screen, segment it and ask the
  user which segment to expand. Do not silently drop half the code.

## Format

```
AREA: <one-line summary>

ENTRY POINTS
- <path>:<symbol>  — <role>

CORE MODULES
- <path>  — <role>

FLOW
<entry> -> <module> -> <module> -> <sink>

CALLERS
- <path>  — uses <entry>

HIDDEN COUPLING
- <description>  (<path>)
```

Use the exact headers. Consistency lets the user scan.