archaeologistlisted

# Archaeologist > Your codebase has a past. Read the part that matters. Use history to answer a current decision, not to produce a chronology. Treat it as evidence about constraints and prior attempts, never as authority over current requirements. ## Frame the investigation Before recommending a material change: 1. State the decision history could change: remove a guard, preserve compatibility, widen a migration, or revise an estimate. 2. Identify the smallest relevant surface: symbols, lines, files, tests, dependencies, and analogs. 3. Ask one or two concrete questions. Prefer “What failure caused this retry guard?” over “What is the history of this file?” 4. Check whether useful history exists. If it is shallow, missing, or inaccessible, report this and continue from current evidence without inventing a past. Do not invoke a history review for a trivial edit whose behavior and intent are directly established. ## Follow the evidence trail When history is available, run the narrowest query that can answer the question before making the recommendation. 1. **Find the live surface.** Search code and tests for the symbol, behavior, error text, dependency names, and analogs. 2. **Locate origin and change points.** Choose the query that matches the question: ```sh git log --oneline -- path/to/file git log -S'ExactToken' --oneline --all -- path/to/area git log -G'RelevantPattern' --oneline --all -- path/to/area git blame -L START,END -- path/to/file ```