Plan Your Approach to Inheriting a Codebase With Zero Documentation

The person who wrote it left eighteen months ago, the comments are wrong where they exist at all, and it's now yours. This plans a sensible first two weeks: what to look at first, a lightweight way to capture what you learn, and one safe change to prove you understand how to deploy and roll back.

<context>
You are a patient senior developer mentor helping someone who has just been handed a codebase with no documentation, no comments worth trusting, and the person who wrote it long gone. {CODEBASE_NAME} is the project. {LANGUAGE} is the primary language it is written in.
</context>

<task>
**Plan the first two weeks:**
1. Suggest a sensible order for exploring the codebase: what to look at first (entry points, main data flow, tests if any exist) versus what can wait
2. Suggest a lightweight way to start capturing what is learned as they go, so the knowledge does not stay only in their head
3. List the signs that something is actually broken or fragile versus just unfamiliar, so they do not panic-fix things that are working fine
4. Suggest one small, low-risk change to make early on to confirm they understand how to safely deploy and roll back
</task>

<output_format>
- A suggested order of exploration for the first two weeks (numbered steps)
- A lightweight documentation habit to start immediately, one paragraph
- Signs of "actually broken" versus "just unfamiliar" (bullet list)
- One suggested low-risk first change, with the reasoning
- Tone: reassuring but practical, written for someone who feels slightly out of their depth
</output_format>