Work through architecture questions in order.

Find cycles, boundary leaks, misplaced packages, and internals that have become part of the public architecture by accident.

• Find cyclic package dependencies

  Detect the dependency loops that block refactoring before they compound. Navigate from the graph directly to the class breaking the cycle.

• Inspect cycle edges in the matrix

  Use the Package Matrix to read the directional edges that keep a cycle group alive after the graph has found the loop.

• Review package boundaries

  Inspect dependency traffic across a package boundary and compare it with the direction you intended.

• Find packages that know too much

  Find packages with broad outward dependencies and decide whether they are deliberate coordinators or carrying too much responsibility.

• Find accidental boundary leaks

  Detect where implementation packages are reachable from outside their intended module boundary.

• Packages in the wrong place

  Identify packages that don't belong where they are: the wrong layer, the wrong module, or the wrong abstraction level for their actual dependency direction.

• Cycle / tangle reduction

  Work through a backlog of dependency cycles methodically over multiple sprints, tracking progress as the problem graph shrinks.

• Leaky internals

  Map broad JVM-public package surfaces, then inspect the classes and callers behind the score.

• Find hermit packages

  Find package or source-folder nodes with no visible dependencies, then decide whether each one is obsolete, externally wired, or deliberately independent.

• Audit individual cycle groups

  Step through every cycle group in the project one at a time and decide what to do with each.

Decide where effort pays off by looking at coupling pressure, stability, abstraction, complexity, size, and the parts of the architecture other packages depend on.

• Identify risky hotspots

  Find packages where complexity, size, and architectural reach overlap, then reveal which nearby candidates actually depend on one another.

• Understand subsystem coupling

  Plot subsystems in metric space to see which parts of the architecture are stable, which are under pressure, and where coupling is highest.

• Show me the backbone

  Find the high-fan-in packages most of the codebase leans on: load-bearing surfaces with the widest consumer blast radius.

• Stable but too concrete

  Find widely used packages with a mostly concrete public surface and decide whether that contract is deliberate or too exposing.

• Zone of Pain

  Map incoming-dominated, mostly concrete package surfaces and decide which ones need a narrower contract.

• Zone of Uselessness

  Investigate highly abstract, outgoing-dominated packages and verify whether their contracts have a useful role.

• Hard-to-change packages

  Find the packages where even small changes cause outsized ripple effects through the codebase.

• Ticking time bombs

  Catch packages juggling too many outgoing dependencies before the next dependency change turns broad coupling into regression work.

Turn live investigation into an Architecture Report the team can use: recurring project-health reviews, boundary reviews, and focused evidence for the decision at hand.

• Audit a module boundary

  Do a thorough structural review of one module: what flows in, what flows out, package cycles inside, and how cohesive the implementation is.

• Project architecture health review

  Run a repeatable multi-lens review that turns live structural evidence into decisions and the next investigation.