`CODEBASE_INVENTORY.md` — a map for developers

README explains the project purpose and basic startup for the reader. `CODEBASE_INVENTORY.md` has a different role: quickly showing internal organization, entry points, commands, tests, risk areas, and unexplored places.

An inventory should not be a copy of the code. Its value is compact navigation backed by evidence.

Recommended inventory structure
# CODEBASE_INVENTORY.md

## Stack and technologies
## Main parts of the system
## Entry points
## Running and checks
## Dependencies between modules
## Main runtime flows
## Higher-risk areas
## Open questions

What to record in the map

  • languages, frameworks, and the database;
  • major directories and their responsibilities;
  • HTTP controllers, frontend entry points, and background tasks;
  • commands for running, building, and testing;
  • the locations of tests and configuration;
  • risk areas and questions without confirmation.

Write about responsibility, not every method

Weak descriptionUseful description
orders/ contains 37 filesorders/ handles the cart and order lifecycle
There is a PaymentService classpayments/ handles payment and refunds; duplicate charges are a risk area
There is application.ymlConfiguration defines profiles, thresholds, or external addresses — usage still needs verification

Draft, verify, edit

  1. Ask Claude to create a short draft using fixed sections.
  2. Open the mentioned files and check the claims.
  3. Run key commands and compare the results.
  4. Mark unconfirmed conclusions.
  5. Remove unnecessary details and keep useful references.
  6. Update the inventory after significant project changes.

Higher-risk areas

Highlight areas where an error is costly: payments and refunds, schema migrations, authorization, external integrations, or code with incomplete test coverage. This lets the inventory help plan the next investigation, rather than merely navigate folders.

Canonical lesson source · JavaRush

Open JavaRush material