[explorer] add graph debugging information

[northdpole]

Issue

both the original explorer and the cre version do not show WHY the graph is the shape it is, for the sake of debugging we should be albe to know why the graph has the specific shape it has (which are the root cres, the ones after that etc)

[ashutosh-engineer]

@robvanderveer @northdpole Hey I can solve this issue as i reviewed the code structure and potential part that causing the issue.

[PRAteek-singHWY]

Hi maintainers @northdpole @robvanderveer @paoga87 , thanks for opening this — the issue description really resonated after exploring the graph UI.

I noticed that while the force-directed layout is visually rich, it’s currently hard to understand why a given node sits where it does (e.g., whether it’s a root CRE, an intermediate dependency, or a leaf). From a user perspective, the graph answers “what is connected” but not “why it is connected this way”.

Before attempting any implementation, I wanted to ask:

• Is there already semantic information in the backend (e.g., depth, dependency direction, root flags) that could be exposed in the UI?
• Would the goal here be primarily explainability (tooltips, side panels, node role indicators) rather than changing the layout algorithm itself?

I’m very interested in exploring this further and would love guidance on the intended direction before proposing a concrete approach.

[robvanderveer]

@northdpole needs to answer this, as this point is mostly for debugging - not for user information. This is because there is no semantic info for the relations, other than 'is part of' and 'is related'.
Thanks for thinking along Pratkee.

[PRAteek-singHWY]

Thanks @robvanderveer , that makes sense — appreciate the clarification.

Understood that this is primarily a developer-facing debugging concern, and that the graph relations themselves don’t carry semantic hierarchy today.

I’ll wait for @northdpole’s input on the intended direction (e.g., frontend-derived diagnostics vs. backend-supported debug info) before thinking about any concrete approach.

[PRAteek-singHWY]

Hi Sir @northdpole just following up here with a bit more clarity from my side after spending more time in the Explorer graph.

Based on Sir @robvanderveer ’s clarification that this is mainly a developer-facing debugging concern (not user semantics), I tried to think about what would be most useful without changing layout logic or backend data.

My current understanding is that the missing piece is visibility into why the graph ends up in its current shape — for example:
• which nodes are roots vs intermediate vs leaves
• how many incoming/outgoing edges a node has
• why certain nodes end up in earlier or deeper “layers” of the graph

One possible direction would be a frontend-only debug mode, hidden by default, that exposes derived diagnostics (e.g. via tooltips, a small side panel, or a toggle). This would help contributors validate graph generation and debug unexpected layouts, without introducing new semantics into relationships.

Before going any further, I wanted to sanity-check with you:
• does a frontend-derived, debug-only approach align with the intended scope here?
• or would you prefer this to stay even more minimal / internal?

If this direction makes sense, I’m happy to:

1. refine concrete UI options (tooltip vs side panel), or
2. prototype a minimal debug toggle in the Explorer view.

could you please help me with understanding this better

I also have a short design note ready if that’s useful — happy to share.

[Mahaboobunnisa123]

Hi @northdpole, I read through the earlier comments and @robvanderveer’s clarification that this is mainly for developer debugging, not user-facing semantics, and that the relations don’t carry meaning beyond “part of” / “related”. With that in mind, I would like to implement a small “debug mode” in the Explorer (hidden by default, e.g. a toggle or ?debug=1) that shows diagnostics derived from the current graph only: root candidates (nodes with no incoming edges in the loaded subgraph / current focus), In/out degree counts, a computed depth/layer (BFS distance from the selected/focus node) and for a selected node - a simple list of its incoming/outgoing edges (“why it’s connected”). No backend/schema changes, and no changes to the layout algorithm - just extra visibility for contributors when something looks off.
If this matches what you had in mind for this issue, I’m happy to pick it up and open a PR soon. Could you aplease ssign it to me?

[Mahaboobunnisa123]

Im working on this issue and a PR will be ready soon.

[Mahaboobunnisa123]

Hi @northdpole, thank you for the feedback. I will focus on implementing the general connectivity stats and will place the toggle in the main explorer UI so it is available globally. Could you please assign this issue to me? I have my development environment ready and want to ensure there is no duplicate work or collision with other contributors while I work on the implementation. Thanks!