/knowledge dashboard UX: 6 compounding gaps make populated knowledge graph feel empty (Research hidden, task-titles, no summaries, wrong dates, no grouping, 0 edges)

[nbost130]

Summary

After running KnowledgeHarvester.ts harvest --backfill across multiple projects (per workflow that resolves issue #1170), the resulting /knowledge and /knowledge/graph dashboard pages are technically functional but feel empty / unhelpful. After populating 26 real knowledge entries from real session work, the UX is still effectively unusable for browsing — the page reads as "you have nothing here" even though you have substantial content.

This is a single composite issue covering six distinct UX gaps that compound. Each is small individually; together they make the dashboard fail at its job.

State of /knowledge after a real harvest

Verified via real-Chrome read of the dashboard against a populated KNOWLEDGE/ (19 Ideas + 7 Research, 26 total entries with frontmatter, provenance, valid harvested_from: pointers).

PEOPLE     0
COMPANIES  0
IDEAS      19    ← only useful column
BLOGS      0
BOOKMARKS  0

/api/knowledge returns totalNotes: 26 (correct: 19 Ideas + 7 Research). /api/wiki returns totalIdeas: 19 but omits Research entirely from stats. The dashboard reads /api/wiki, so Research is invisible.

Six gaps

Gap 1: Research category invisible

/api/wiki stats schema has totalPeople, totalCompanies, totalIdeas, totalBlogs, totalBookmarks — no totalResearch. The /knowledge page surfaces only those five. 27% of my knowledge entries (7/26) are completely hidden.

Fix: add totalResearch to the stats schema and Research card to the dashboard. Knowledge skill already lists Research as a first-class domain (KNOWLEDGE_DOMAINS = ["People", "Companies", "Ideas", "Research"] in Tools/KnowledgeHarvester.ts:55).

Gap 2: Entry titles describe TASKS, not INSIGHTS

Auto-harvested entries get the source ISA's task field as their title. That field describes what the work was, not what knowledge would be retrieved by reading the entry.

Examples from my actual harvest:

• "Fix N+1 queries and add code splitting" — what the task was
• "Build tmux save guard and tmuxp session configs" — what the task was
• "Match HSA unpaid claims to fresh Tiller export with provider verification" — what the task was

What would actually be useful as knowledge titles:

• "Lazy-loading anti-pattern: Suspense boundaries break AnimatePresence exits"
• "tmuxp config gotcha: nested-shell PATH inheritance"
• "HSA reimbursement matching: vendor-name normalization is the load-bearing step"

This is a fundamental limit of what auto-harvest can extract from session task names. The fix isn't in the dashboard — it's a content-quality consideration that should propagate to: (a) better LLM-summarization in the harvester to derive insight-titles from ISA body content, OR (b) explicit "this is for retrieval, here's the title and summary you'd want to see" in the ISA Format spec, OR (c) a dashboard "edit title + summary" affordance for in-place upgrade.

Gap 3: No summaries or previews

Each entry on the dashboard renders as: <type-label> | <title> | <date>. To know what's in any entry you have to click through. For 19 entries that's 19 clicks just to triage your own knowledge.

Fix: show first-paragraph or first-bullet summary inline. The harvested file frontmatter could carry a summary: field; harvester populates it from a body extract or LLM summarization.

Gap 4: Wrong dates

Every entry shows May 3 because that's when the harvester wrote them. The actual underlying work happened across March and April. So time-based scanning ("what was I thinking about in early April?") is broken — everything looks like today.

Fix: display the source-session date, not the harvest date. The harvested_from: field already has the session slug which is timestamp-prefixed (YYYYMMDD-HHMMSS_...). Parse and surface that.

Gap 5: No grouping or filtering

Flat list of 19 entries. Even though entries derive from 4 distinct projects (MemberOS infra, ithildin/Carson plumbing, financial reconciliation, top-level Mac systems), there's no visual or filter affordance for "show me my MemberOS knowledge" or "show me my Finance knowledge."

Fix: harvester could derive a source_project: field from the harvested_from: path and surface it as a filter chip / group header on the dashboard.

Gap 6: /knowledge/graph shows 0 edges across 67 nodes

The graph view at /knowledge/graph does render — 67 nodes (48 system-docs + 19 Ideas), categorized correctly. But edges: 0. The graph is a node cloud, not a graph.

Root cause: auto-harvested entries have no wikilinks in their body (the harvester writes title + frontmatter + an empty ## Verification section, no body content with [[...]] links). The KNOWLEDGE/README.md contract says "Entries follow a frontmatter contract, link to one another via wikilinks" — auto-harvest doesn't create those wikilinks.

Fix combinations:

• Harvester derives candidate cross-links from shared tags (entries with tag overlap → suggested wikilinks)
• Harvester populates body with extracted content (not just empty section), giving the graph something to link
• Or: surface this honestly in the UI ("0 edges — auto-harvested entries don't include cross-links; use Knowledge skill add for typed connections")

Browse vs search ergonomics

The deeper UX question: is /knowledge meant to be browseable, or only searchable?

If browseable, gaps 1-6 above make it unusable. Even after content is populated, a user cannot scan and learn what they have.

If searchable, the page should make search prominent (it does have a ⌘K Search... button) and de-emphasize the browseable list. Empty People/Companies/Blogs/Bookmarks cards reading "0" should perhaps be hidden when empty rather than dominating the page.

Either pivot would help. Currently the page tries to be both and fails at both.

Suggested fix priorities

1. Quick wins (~1-line changes each):

   • Add totalResearch to /api/wiki stats schema
   • Render Research card on dashboard
   • Use source-session date (parse from harvested_from:) instead of harvest date

2. Medium (~50-line changes):

   • Inline summary preview (requires harvester to populate summary: field; ~30 lines in harvester + display change)
   • Project grouping/filter (derive from harvested_from: path)

3. Bigger UX choice:

   • Browse vs search emphasis (see "Browse vs search" above) — pick one and lean in

4. Auto-classification quality (separate, file alongside KnowledgeHarvester writes directly to KNOWLEDGE/<domain>/ — bypasses _harvest-queue/ curation step described in README #1171):

   • The harvester's title-keyword heuristic places ideas-shaped content in People/Companies. In one sample run: 2 of 5 entries misclassified. The _harvest-queue/ curation gate (KnowledgeHarvester writes directly to KNOWLEDGE/<domain>/ — bypasses _harvest-queue/ curation step described in README #1171) addresses this; until that lands, the dashboard is showing genuinely-misclassified content.

Verified locally

All findings reproduced against a real harvest of 26 entries spanning 4 projects. Real-Chrome verification via Interceptor confirms each gap. Will not file separate issues for each — they compound and warrant a coordinated UX response.

Related

• Pulse v5.0.0: TELOS dashboard never reads user data — useTelosData hook is a stub #1167 useTelosData hook stub — sibling pattern (dashboard rendered fixture instead of real)
• KnowledgeHarvester is single-PAI-instance — per-project memory dirs (~/.claude/projects/<slug>/memory/) invisible without PAI_DIR override #1170 KnowledgeHarvester per-project discovery — prerequisite for any user with multi-project work to even reach this state
• KnowledgeHarvester writes directly to KNOWLEDGE/<domain>/ — bypasses _harvest-queue/ curation step described in README #1171 KnowledgeHarvester _harvest-queue/ curation — fixes Gap 6 partially (less misclassification leakage) and changes the harvest UX flow

This issue is the "what does the user actually see after #1170 + #1171 are resolved?" question.

[danielmiessler]

This one aged well — the knowledge schema was since rebuilt (typed frontmatter, required summaries and relationship links across the whole archive), which fixes the content-quality half of your list. The dashboard's Research blind spot you flagged is still real though, so this stays acknowledged until the wiki module catches up. Thanks for breaking the six gaps apart so cleanly.