Code analysis

The output is a map: what exists, how it fits together, and where the danger is. A map is judged by whether someone can navigate with it, not by how much of the territory it mentions.

Analysis fails by exhaustiveness — describing every module at equal depth produces a document with the same information density as the source, and no reason to read it. Depth must be unequal, concentrated where the risk and the change is.

1. Read the outside before the inside

Before opening source files, read what the project says about itself and what it demonstrably does: README, entry points, public API or route definitions, configuration, CI pipeline, dependency manifest, and the shape of the test suite.

This gives you the intended architecture. The gap between it and the real one is a finding.

Done when: you can state what the system does, who calls it, and what it calls.