# A call that starts in `lib/` and lands in `src/` — documented, not implemented (2026-10-14)
`relations()` only walks contracts that are not vendored, so an arrow whose SOURCE lives in
`lib/` does not exist for the map. The case that brought it up, from the session auditing ascend:
- `CLPoolManager.initialize` → `ProtocolFees._fetchProtocolFee` → an assembly `staticcall` to
`IProtocolFeeController.protocolFeeForPool` → **`AscendFeeController`**, which is ours.
- If that call reverts, `initialize` reverts: the controller is the gate deciding which pools can
exist on the singleton.
So the fact is real and the arrow is missing. It is still not drawn, and the reason is a judgment
about what the map is for, not a limitation:
**That call is the third-party protocol calling in, and the protocol is not ours.** Drawing it
means drawing `CLPoolManager` as a party, and `CLPoolManager` drags its own tree — the pool
manager, its vault, its hooks, everything `lib/` contains. A whole second tree, of code nobody is
auditing, hanging off one true arrow.
What IS worth keeping in view:
- The fact belongs in the audit's notes, not necessarily in the picture: "this contract is called
by the pool manager during `initialize`, and reverting there blocks pool creation".
- If it is ever wanted, the honest shape is a SEPARATE reading — "who calls into us from
outside" — rather than an edge inside the system map. That keeps the dependency tree of `lib/`
out of a diagram of this repository's own code.
- It would also need the `abi.encodeCall` work (shipped in 0.33.0) plus walking vendored
contracts as sources, which is the expensive half.
Related: `docs/address-wiring-notes.md`, for the other family of relations the map cannot see.