# 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)