Orchestrator/.kiro/specs/knowledge-management/BRIEFING.md

Knowledge Management System – Briefing for New Spec Chat

What We Want

A unified personal knowledge management system integrated into the monorepo structure. It replaces the old NoteGraph app and builds on top of the existing monorepo knowledge store infrastructure.

Core idea: Organize, document, and work with notes (markdown, pictures, emails, chats) and additional context (links, Confluence, Jira, Git repos) across all three work contexts (bahn, dhive, privat).

Current State

What Exists

1. Monorepo structure (bahn/, dhive/, privat/, shared/)
2. Knowledge store tooling in shared/tools/monorepo-cli/src/monorepo/knowledge/:
   • store.py – KnowledgeStore with ETL pipeline, YAML index, search
   • artifact.py – Artifact model with YAML frontmatter
   • etl.py – ETL pipeline with incremental processing (content-hash based)
   • index.py – YAML index with progressive disclosure
   • sources/markdown.py – Markdown source strategy
   • migration.py – NoteGraphMigrator (stub)
3. NoteGraph ingestion pipeline in privat/NoteGraph/ingestion/ (partially built):
   • CLI import + watcher
   • OCR extraction (images, PDFs)
   • LLM-powered enrichment (entity detection, wiki-links)
   • Folder routing (meetings, projects, inbox, decisions)
   • OrgMyLife task creation from action items
4. NoteGraph notes structure in privat/NoteGraph/notes/:
   • decisions/, inbox/, meetings/, people/, projects/, templates/
5. Context bridge (shared/tools/monorepo-cli/src/monorepo/bridge.py) for cross-context sharing
6. Wissensdatenbank in bahn/wissensdatenbank/ – the ETL pipeline for DB InfraGO knowledge (Confluence, web, PDFs → processed markdown)

What Doesn't Work

• The NoteGraph app (SilverBullet-based) is not working as a daily driver
• No unified way to capture and organize notes across all 3 contexts
• No integration between the ingestion pipeline and the monorepo knowledge store
• No way to consume Jira, Confluence, email, chat as knowledge sources per context

Inputs to Consider

From NoteGraph Spec (reusable)

• Folder structure: decisions, inbox, meetings, people, projects
• Ingestion pipeline: OCR, LLM enrichment, entity detection, wiki-links
• Model-agnostic LLM provider layer (LiteLLM)
• Auto-reference generation (people, projects → wiki-links)
• TODO extraction → OrgMyLife task creation
• Drop-folder watcher for continuous import
• Git auto-commit for imported notes
• Frontmatter format: title, date, tags, people, projects, source

From Monorepo Knowledge Store (already built)

• YAML-Frontmatter + YAML-Index (progressive disclosure)
• Scope-based folder structure (privat, dhive, bahn, shared)
• Content-hash based incremental processing
• Scope-filtered search (only see what you're authorized for)
• Graph-Verknüpfungen (bidirectional links in YAML frontmatter)
• Context bridge for cross-context sharing with sensitive content filtering

From Wissensdatenbank (pattern to follow for bahn context)

• ETL strategies: confluence_page, confluence_tree, confluence_faq, crawler, sitemap, gitlab_md, file, pdf
• Scope classification (intern, extern, allgemein)
• Incremental processing with source versioning
• Auto-filter and review pipeline
• Chunking for large documents

New Requirements (not yet specced)

• Per-context knowledge folders: bahn/knowledge/, dhive/knowledge/, privat/knowledge/
• Multi-source ingestion per context:
  • bahn: Confluence, Jira, DB GitLab wikis, meeting notes, emails
  • dhive: dhive GitLab, Confluence, project docs, chat exports
  • privat: handwritten notes (reMarkable), personal docs, bookmarks, ideas
• Jira integration: Import issues/comments as knowledge artifacts
• Email/chat import: Extract actionable info from email threads and chat messages
• Picture/scan support: OCR for reMarkable exports, whiteboard photos
• Link management: Save and tag web links as reference material per context
• Agent context injection: When the AI-Orchestrator works on a task, inject relevant knowledge from the context's knowledge folder into the prompt

Architecture Constraints

• Must live within the monorepo context structure
• Must respect security boundaries (no cross-context leakage)
• Must integrate with existing ctx-guard CLI tooling
• Must work with the AI-Orchestrator's knowledge injection (Req 7.4)
• Must support federation (bahn knowledge syncs to bahn team repo)
• Markdown + YAML frontmatter as canonical format (like Wissensdatenbank)
• Progressive disclosure: index → summary → full document

User's Working Style

• Operates across many parallel projects, domains, meetings
• Takes handwritten notes on reMarkable tablet
• Attends many meetings (bahn + dhive)
• Uses Jira (bahn) and GitLab (both) daily
• Wants quick capture and later organization
• Trusts AI-assisted enrichment but wants control over results
• Uses OrgMyLife for task management

Key Questions for the New Chat

1. Should each context have its own knowledge/ folder, or should it all live in shared/knowledge-store/ with scope tags?
2. How to handle the ingestion pipeline: one shared pipeline with context routing, or per-context pipelines?
3. Priority of sources: What to implement first? (Markdown files → Confluence → Jira → email?)
4. How does this relate to the Wissensdatenbank? Is bahn/knowledge just a filtered view of it, or separate?
5. What's the daily workflow? Quick capture → inbox → process → organize?

Files to Reference in New Chat

• #[[.kiro/specs/monorepo-consolidation/design.md]] (knowledge store architecture)
• #[[.kiro/specs/monorepo-consolidation/requirements.md]] (Req 3: Wissensspeicher, Req 5: Kontextbrücke)
• #[[.kiro/specs/notegraph-ingestion/requirements.md]] (ingestion pipeline reqs)
• #[[.kiro/specs/notegraph-ingestion/design.md]] (ingestion architecture)
• #[[privat/NoteGraph/notes/index.md]] (existing folder structure)
• #[[shared/tools/monorepo-cli/src/monorepo/knowledge/store.py]] (implemented knowledge store)
• #[[bahn/wissensdatenbank/README.md]] (ETL pipeline pattern)