get_architecture hotspots report inflated fan_in that contradicts actual graph in-degree (same-name collision across languages)

[martingarramon]

Version: v0.8.1 (linux-amd64)

Summary

get_architecture reports a hotspot fan_in that does not match the node's real in-degree in the graph. For short identifiers shared across languages (e.g. commit, parse, add), the reported fan_in appears to aggregate by bare name rather than by resolved node — producing large over-counts, and attributing the count to a node that actually has in-degree 0.

Environment

• Mixed Python + TypeScript/JavaScript monorepo, indexed with mode: full.
• Two distinct symbols named commit: a JS arrow function commit (defined in a React page component) and a Python method Store.commit.

Observed

get_architecture →

hotspots: [{ name: "commit", qualified_name: "…/web/src/pages/Editor.commit", fan_in: 234 }, …]

But that JS commit has one local call-site, and querying the graph directly shows it has zero inbound edges:

query_graph:  MATCH (n {name:'commit'})<-[r]-(c)
              RETURN n.qualified_name, count(r)
→ only the Python Store.commit, in_degree 20.
  The JS Editor.commit node returns nothing (in_degree 0).

So fan_in: 234 is not reproducible from CALLS/USAGE edges.

Hotspots whose names are class-qualified Python methods matched their real in-degree correctly (a function reported with fan_in: 46 had graph in_degree 46), so the inflation is specific to short bare names shared across the Python/JS boundary.

Expected

Hotspot fan_in should equal the node's resolved inbound CALLS/USAGE in-degree (the value query_graph / search_code already report per node), not a count aggregated by bare name.

Impact

get_architecture is the first-call "understand this codebase" tool; an inflated headline metric on the wrong node is misleading. The qualitative structure (clusters, layers, routes, languages) is accurate — only the hotspot fan_in figures are affected.

Possibly related to #558 (Class in_degree/out_degree = 0) — both are node-level degree-metric correctness issues.

[DeusData]

Thanks, this is a useful correctness report. The expected invariant is right: get_architecture hotspots should be node/resolved-symbol based, not bare-name aggregates. I’m tracking it under graph query/reporting correctness; the fix should start with a regression fixture containing same-named Python and JS symbols and assert fan_in matches graph in-degree.

[rudi193-cmd]

Additional public repro — willow-2.0 (Python monorepo)

We maintain a fleet structural audit that treats CBM as a discovery instrument and verifies every measurement against source (addendum). Re-checked on v0.8.1, project home-sean-campbell-github-willow-2.0 (~17.8k nodes).

Case A — get_architecture fan_in matches graph in_degree, but both are inflated by bare-name collapse

get_architecture hotspot:

JsonStore.get  fan_in: 789
ledger.append  fan_in: 672

query_graph:

MATCH (m:Method) WHERE m.qualified_name CONTAINS 'JsonStore.get'
RETURN m.qualified_name, m.in_degree
-- → 789 (matches fan_in exactly)

So the hotspot metric is internally consistent with node-level in_degree — but that in_degree itself aggregates every .get() / .append()-shaped call in the repo onto one resolved symbol (F-007 in our ledger). Qualitative architecture (clusters, packages) looks fine; hotspot ranking is misleading for common method names.

Case B — trace_path on bare execute lists cursor.execute callers as inbound to nuke.execute

Only one Function named execute exists (willow.nuke.execute, in_degree: 66). trace_path(function_name="execute", direction="inbound") returns grove_msg.cmd_send and dozens of scripts as callers.

Source for cmd_send — calls cur.execute(...) (Postgres cursor), not nuke.execute:

cur.execute(
    "INSERT INTO grove.messages ...",
    (channel_id, sender, content),
)

This is the same bare-name / receiver-blind resolver class as inflated fan-in, seen from the traversal side.

Links

• Our F-007 write-up + cbm_verify_callers guardrail: sap/cbm_facade.py in willow-2.0
• Related filings from same audit session: query_graph: RETURN DISTINCT … ORDER BY … LIMIT still under-returns on v0.8.1 (regression / incomplete fix for #237) #873–Recursion flags still false-positive on store/delegation calls after #599 (soil.get, _default.check) #876

Happy to attach a minimal query script if useful for a regression fixture.