Skip to content

fix(dashboard): wire layer + node-type filters into knowledge-graph view#189

Open
patrickloscabos-art wants to merge 1 commit into
Lum1104:mainfrom
patrickloscabos-art:fix/kg-layer-filter
Open

fix(dashboard): wire layer + node-type filters into knowledge-graph view#189
patrickloscabos-art wants to merge 1 commit into
Lum1104:mainfrom
patrickloscabos-art:fix/kg-layer-filter

Conversation

@patrickloscabos-art
Copy link
Copy Markdown

Summary

The Filter panel's per-layer checkboxes and per-node-type checkboxes (article, entity, topic, claim, source) have no visible effect when viewing a knowledge graph. KnowledgeGraphView.tsx only reads the all-or-nothing nodeTypeFilters.knowledge flag — it never consumes filters.layerIds or filters.nodeTypes, even though FilterPanel writes to both and the layer checkboxes are gated on layers.length > 0 (which only fires on graphs that have layers — i.e. knowledge graphs and architecture-layered code graphs).

Repro

  1. Run /understand-knowledge on any Karpathy-pattern wiki with multiple categories in index.md so the resulting graph has 2+ layers.
  2. Open the dashboard, click Filter, scroll to Layers, toggle off all but one layer.
  3. Nothing changes — the full graph is still rendered.

Fix

In understand-anything-plugin/packages/dashboard/src/components/KnowledgeGraphView.tsx:

  • Subscribe to filters from the store.
  • When filters.layerIds.size > 0, build an allow-set of nodes in the selected layers plus their one-hop neighbors (via the edge list). The one-hop expansion is important because analyzer-generated entity and claim nodes typically aren't placed in any layer's nodeIds — a strict layer-membership filter would orphan the picked layer's articles by hiding the entities/claims they reference.
  • Also honor filters.nodeTypes so the per-node-type checkboxes filter the knowledge view, matching their behavior in code/domain views.
  • Preserve the existing nodeTypeFilters.knowledge blanket toggle.

Manual test

On a 191-node / 279-edge knowledge graph with 8 layers:

  • All layers selected (or none, the default): 191 nodes — unchanged.
  • Single layer selected: drops to ~30 nodes (8 articles in the layer + the entities/claims they cite/exemplify/build on), with the subgraph remaining connected.
  • All knowledge node types unchecked: empty view (unchanged blanket behavior).
  • Individual node-type checkbox (e.g. uncheck entity): entity nodes vanish, edges pruned, articles/claims remain.

Test plan

  • Run dashboard against a knowledge graph; verify layer checkboxes hide non-selected layers
  • Toggle individual node-type checkboxes; verify they filter the knowledge view
  • Toggle the knowledge-category checkbox; verify the blanket behavior still works
  • Visit a non-knowledge graph (code/domain); verify nothing regresses

🤖 Generated with Claude Code

The Filter panel exposes per-layer and per-node-type checkboxes that write
to `filters.layerIds` and `filters.nodeTypes`, but `KnowledgeGraphView`
only consumed the all-or-nothing `nodeTypeFilters.knowledge` flag — so
the layer checkboxes and the article/entity/topic/claim/source
checkboxes had no visible effect on knowledge graphs.

This change:

- Reads `filters.layerIds`. When any layer is selected, restricts the
  visible set to nodes in that layer plus one-hop neighbors. The
  neighbor expansion matters because analyzer-generated entity/claim
  nodes aren't placed in any layer's `nodeIds`, so a strict
  layer-membership filter would orphan the picked layer's articles.

- Reads `filters.nodeTypes` so the per-node-type checkboxes
  (article / entity / topic / claim / source) actually filter the
  knowledge view, matching their behavior in code/domain views.

- Preserves the existing `nodeTypeFilters.knowledge` blanket toggle.

Tested by selecting a single layer in a 191-node / 279-edge knowledge
graph: filtered set drops from 191 → ~30 nodes (the layer's articles
plus their referenced entities/claims), and the resulting subgraph
remains fully connected for the picked layer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant