Stable but too concrete

The problem

You know the package: everyone reaches for it, it reaches for almost nothing, and its public surface is concrete all the way down. Maybe that is exactly the point. A deliberately boring API can be a great foundation. Or maybe twenty callers now know more about the implementation than they should. AtlasArc gives you the shortlist and the evidence to tell the two apart.

Why it matters

When many packages lean on the same concrete surface, a contract change can send edits across the codebase. The risk is not that concrete code exists. It is that a wide caller base may have no narrower seam around the part it actually needs. Find that before the next cross-cutting change turns into a tour of twenty callers.

Where to start

Begin with the Topology Graph.

Step by step

1. Apply the stable-surface starting point.

   Start exploring opens Topology, keeps packages at or above the model's upper-quartile Fan-in, caps Fan-out at the median, enables Hide Isolated, and activates the Abstractness heatmap. You are left with widely used packages that depend on relatively little themselves.

2. Pick the scope you actually care about.

   Clear package scope and use Collapse All to compare the first-class module roots. Then use Expand completely only on the module whose package-level surface you want to inspect.

3. Let concrete surfaces rise to the top.

   Within the surviving high-fan-in shortlist, use the Abstractness heatmap to find packages whose public types are mostly concrete. Those are the candidates, not automatic failures.

4. Follow what callers really touch.

   Select a candidate, inspect its incoming neighbours, and open the concrete dependency evidence behind the important edges. Which public types do callers actually use, and are they relying on implementation details that are likely to vary?

5. Keep the contract or tighten the seam.

   If the concrete API is deliberately stable, keep it and protect it with focused tests. Otherwise narrow what is public, split implementation behind the public API, or introduce an interface at the boundary that genuinely needs one.

Interpreting results

Abstractness is a public abstraction ratio, not a verdict. Concrete is not a synonym for bad. A small, deliberately boring public API can be an excellent dependency. The warning sign is a wide caller base coupled to details that are likely to vary. Do not add an interface just to make the heatmap look better. Add a boundary when it gives callers a smaller, steadier contract.

Export & share

Export the filtered Topology view as PNG once the scope and shortlist tell the story. Pair it with the concrete dependency evidence when you need to explain why one surface should stay deliberately boring and another should be tightened.