> For the complete documentation index, see [llms.txt](https://pharaoh.so/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pharaoh.so/docs/use-pharaoh/change-impact.md).

# Case study: Trace a code change

Trace what a code change affects before you make it: find production callers, endpoints and cron jobs with Pharaoh's blast radius, then verify in source.

Use this workflow before changing a function's signature, deleting a helper or moving behavior between modules. The result should identify production paths to inspect and the checks needed for the proposed edit.

## Match the map to the source

Confirm the repository is live and its map is ready in [setup](https://mcp.pharaoh.so/setup). Pharaoh's interactive map describes the last completed map of the default branch. Local changes and unmerged branches need separate source inspection; [PR Guard](/docs/use-pharaoh/pr-guard.md) analyzes pull requests separately.

Ask your connected AI:

```
Use get_codebase_map to identify this repository and its modules.
Report the map freshness information returned by the tool. Compare
the mapped revision with the source I am about to change, where
revision information is available. Flag any mismatch or uncertainty.
```

For connection help, follow your [client setup guide](/docs/readme.md). The [tool reference](/docs/use-pharaoh/overview.md) links to current input schemas.

## Ask about the proposed change

Name the function and its defining file. Describe the intended edit so the AI can distinguish affected behavior from unrelated references.

```
Before editing this function, use get_blast_radius to inspect its
production callers and detected entry points within three hops.
Group direct and indirect callers separately. Show the paths that
matter to the proposed change and report any limits or incomplete
analysis signals returned by the tool. Do not edit files yet.
```

If the name matches multiple functions, resolve the target before drawing a conclusion. Expand the depth when the returned paths require it, using the range in the current tool schema.

## Inspect and verify

For example, consider this illustrative call chain. The arrows mean "calls":

```
request handler
  -> buildInvoice
     -> calculateTotal
```

A query about `calculateTotal` should distinguish its direct caller, `buildInvoice`, from the indirectly affected request handler. Inspect both call sites before changing arguments or return types. The diagram explains the workflow; query your own map for actual paths rather than treating it as captured tool output.

Open the defining function and relevant callers in your checkout. Check argument assumptions, return types, permissions and error behavior along the paths you intend to change.

Search separately for tests, configuration and names stored as strings. Production blast-radius results exclude test-file callers. A missing direct test link is not a runtime coverage measurement.

Ask the AI to turn the investigation into a change plan:

```
For each proposed edit, identify the source evidence and affected
behavior. List tests to run or add at the relevant entry points.
Separate verified paths from inferred runtime behavior and remaining
unknowns. Include local changes the hosted map cannot see.
```

Run the relevant compiler and behavioral checks after editing. A detected dependency shows where a change may have consequences; it does not establish that the edit is correct or that every runtime path is represented.

For framework gaps, freshness and entry-point configuration, use [Scope and troubleshooting](/docs/use-pharaoh/troubleshooting.md).