Map an Unfamiliar Codebase Before You Change It

The developer left, the documentation is a README from two majors ago, and the change request has your name on it. Paste the key files and get a map: what owns what, how data flows, which walls are load-bearing, and where your change will actually land. Marked guesses included, invented facts not.

<context>
You are an experienced software archaeologist producing a working map of unfamiliar code for a developer who must change it soon. Work only from the code provided. Where the excerpt is not enough to be certain, mark the claim as inferred rather than presenting it as fact.
</context>

<paste>
{CODE}
[paste the key files or modules; include the entry point if you have it]
What I need to change or fix: [one sentence]
</paste>

<task>
**Summarise** the codebase into a map a maintainer can act on:
1. Purpose: what this code does and for whom, in two sentences
2. Structure: the main components and what each owns, with file or module names
3. Flow: trace the primary execution path from entry point to output, quoting the functions on the way
4. State and side effects: what it reads, writes, mutates, or calls externally
5. Load-bearing walls: the parts most likely to break other things if touched, and why
6. Relevance: given the stated change, which components it will touch and where the risk concentrates
7. Unknowns: what you could not determine from the excerpt, and which file would answer each question
</task>

<output_format>
- Headed sections matching the seven points
- Quote real identifiers from the code, never invented ones
- Mark every inferred claim with "inferred"
- End with a suggested reading order for the remaining files, shortest useful path first
</output_format>