> 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/check-feature-wiring.md).

# Case study: Check feature wiring

Check that new code is reachable from a real entry point, not only from tests. Review pull requests and the default branch with Pharaoh and PR Guard.

A unit test can call a new function successfully while the application never reaches it. Check both the implementation and the production path that should invoke it.

## Identify the expected path

Before reviewing the patch, name the feature's entry point: an API handler, UI action, command, scheduled job or another runtime trigger. Ask your AI:

```
For each newly added exported function in this change, identify the
production path that should reach it. Show the caller and entry point,
then inspect the relevant source. Distinguish test callers from
production callers and identify missing wiring.
```

Verify behavior through that entry point as well as through the function's unit tests. A call path can exist while the feature still receives the wrong input or produces the wrong result.

For example, a new `formatWeeklyDigest` helper can pass its own unit test while an existing `handleRequest` still returns the previous response. Inspect whether the handler imports and calls the helper, then test through the handler. Adding more helper-only tests does not establish that connection.

## Review an unmerged pull request

[PR Guard](/docs/use-pharaoh/pr-guard.md) analyzes pull-request changes on plans that include it. Open the **Pharaoh PR Guard** check in GitHub and inspect the finding's file, function and reference evidence.

| Verdict            | How to use it                                                                                                                 |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| `unreachable`      | Investigate the missing production connection. The detected graph path and production-reference checks did not establish use. |
| `likely_reachable` | A production reference exists without a proved graph path, or the analysis is conservative. Inspect the loading mechanism.    |
| `reachable`        | A detected path reaches the function. Verify its behavior through the intended feature.                                       |
| `allowed`          | An intentional-orphan rule applies. Review whether the allowance still describes the intended use.                            |

Findings are advisory by default. A check's status is not a substitute for behavioral tests or code review.

## Inspect the mapped default branch

For code already present in the completed default-branch map, ask your AI to use `get_unused_code` to check the named functions and explain the returned reachability evidence. Your client exposes the current schema; see the [tool reference](/docs/use-pharaoh/overview.md).

The interactive map does not include an unmerged PR or your local edits. Keep that scope explicit when comparing its results with the patch in your checkout.

## Handle intentional entry points

Framework loading, plugins and public library exports can be legitimate without an ordinary detected caller. Confirm the runtime contract before adding a call or suppressing a finding.

Use the maintained [entry-point and intentional-orphan configuration guide](/docs/use-pharaoh/troubleshooting.md#declare-an-entry-the-detector-cannot-infer) when an explicit declaration is needed. Keep patterns narrow. Follow the [account guide](/docs/use-pharaoh/pricing.md) for current plan availability rather than relying on a price quoted in an article.