packages/review/src/blast-radius.ts's computeBlastRadius defaults to maxNodes: 30, depth: 2. #1005 Phase 2 Item 1 added a Java/Kotlin same-package tier to the call graph (dependency-graph.ts's getCallers), which measurably increases fan-in for popular declared types in JVM codebases — e.g. a real OkHttp dogfood run: Cache's getCallersTransitive(depth: 2) went from 19 edges (not truncated) to 30 edges (truncated) after that change, purely from real same-package callers the call graph could not see before.
A new test (packages/review/test/blast-radius.test.ts, "AC10 ... a very-high-fan-in JVM type seed saturates the default maxNodes at hop 1") pins the CURRENT behavior: once hop-1 fan-in exceeds maxNodes, the walk truncates before reaching hop 2 at all for that seed, even for a hop-1 node that itself has a real, further caller one hop away.
This is a disclosed, not-fixed limitation, not a bug — the existing default trades recall for a bounded walk, and #1005 Phase 2 doesn't change that policy. Filing to ask: should maxNodes/depth be revisited for JVM specifically (or across the board) now that same-package recall has improved and can realistically saturate the budget on real, popular types? This is a policy question for blast-radius.ts's owners (review-engine cost/precision trade-offs), not something to solve inside the same-package tier itself.
packages/review/src/blast-radius.ts'scomputeBlastRadiusdefaults tomaxNodes: 30,depth: 2. #1005 Phase 2 Item 1 added a Java/Kotlin same-package tier to the call graph (dependency-graph.ts'sgetCallers), which measurably increases fan-in for popular declared types in JVM codebases — e.g. a real OkHttp dogfood run:Cache'sgetCallersTransitive(depth: 2)went from 19 edges (not truncated) to 30 edges (truncated) after that change, purely from real same-package callers the call graph could not see before.A new test (
packages/review/test/blast-radius.test.ts, "AC10 ... a very-high-fan-in JVM type seed saturates the default maxNodes at hop 1") pins the CURRENT behavior: once hop-1 fan-in exceedsmaxNodes, the walk truncates before reaching hop 2 at all for that seed, even for a hop-1 node that itself has a real, further caller one hop away.This is a disclosed, not-fixed limitation, not a bug — the existing default trades recall for a bounded walk, and #1005 Phase 2 doesn't change that policy. Filing to ask: should
maxNodes/depthbe revisited for JVM specifically (or across the board) now that same-package recall has improved and can realistically saturate the budget on real, popular types? This is a policy question forblast-radius.ts's owners (review-engine cost/precision trade-offs), not something to solve inside the same-package tier itself.