diff --git a/docs/06_Roadmap/06_active_roadmap.md b/docs/06_Roadmap/06_active_roadmap.md index ce4bafe..4a8aa64 100644 --- a/docs/06_Roadmap/06_active_roadmap.md +++ b/docs/06_Roadmap/06_active_roadmap.md @@ -2,119 +2,6 @@ doc_type: roadmap audience: product_owner, developer status: active -version: 2.7.0 -context: "Aktuelle Planung für kommende Features (ab WP16), Release-Strategie und Historie der abgeschlossenen WPs." ---- - -# Mindnet Active Roadmap - -**Aktueller Stand:** v2.7.0 (Post-WP-22) -**Fokus:** Professionalisierung, Content Lifecycle & Graph Intelligence. - -## 1. Programmstatus - -Wir haben mit der Implementierung des Graph Explorers (WP19) und der Smart Edge Allocation (WP15) die Basis für ein intelligentes, robustes System gelegt. Der Abschluss von WP-22 (Content Lifecycle) professionalisiert nun die Datenhaltung und das Vokabular-Management. - -| Phase | Fokus | Status | -| :--- | :--- | :--- | -| **Phase A** | Fundament & Import | ✅ Fertig | -| **Phase B** | Semantik & Graph | ✅ Fertig | -| **Phase C** | Persönlichkeit | ✅ Fertig | -| **Phase D** | Interaktion & Tools | ✅ Fertig | -| **Phase E** | Maintenance & Professionalisierung | 🚀 Aktiv (v2.7.0) | - ---- - -## 2. Historie: Abgeschlossene Workpackages - -Eine Übersicht der implementierten Features zum schnellen Auffinden von Funktionen. Details siehe `99_legacy_workpackages.md`. - -| WP | Titel | Ergebnis / Kern-Feature | -| :--- | :--- | :--- | -| **WP-01** | Knowledge Design | Definition von `types.yaml` und Note-Typen (Project, Concept, etc.). | -| **WP-02** | Chunking Strategy | Implementierung von Sliding-Window und Hash-basierter Änderungserkennung. | -| **WP-03** | Import-Pipeline | Asynchroner Importer, der Markdown in Qdrant (Notes/Edges) schreibt. | -| **WP-04a**| Retriever Scoring | Hybride Suche: `Score = Semantik + GraphBonus + TypGewicht`. | -| **WP-04b**| Explanation Layer | Transparenz: API liefert "Reasons" (Warum wurde das gefunden?). | -| **WP-04c**| Feedback Loop | Logging von User-Feedback (JSONL) als Basis für Learning. | -| **WP-05** | RAG-Chat | Integration von Ollama (`phi3`) und Context-Enrichment im Prompt. | -| **WP-06** | Decision Engine | Hybrid Router unterscheidet Frage (`RAG`) vs. Handlung (`Interview`). | -| **WP-07** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. | -| **WP-10** | Web UI | Streamlit-Frontend als Ersatz für das Terminal. | -| **WP-10a**| Draft Editor | GUI-Komponente zum Bearbeiten und Speichern generierter Notizen. | -| **WP-11** | Backend Intelligence | `nomic-embed-text` (768d) und Matrix-Logik für Kanten-Typisierung. | -| **WP-15** | Smart Edge Allocation | LLM-Filter für Kanten in Chunks + Traffic Control (Semaphore) + Strict Chunking. | -| **WP-19** | Graph Visualisierung | **Frontend Modularisierung:** Umbau auf `ui_*.py`.
**Graph Engines:** Parallelbetrieb von Cytoscape und Agraph.
**Tools:** SSOT Editor, Persistenz via URL. | -| **WP-20** | Cloud Hybrid Mode | Nutzung von Public LLM für schnellere Verarbeitung und bestimmte Aufgaben. | -| **WP-21** | Semantic Graph Routing | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. | -| **WP-22** | **Content Lifecycle & Registry** | **Ergebnis:** SSOT via `01_edge_vocabulary.md`, Alias-Mapping, Status-Scoring (`stable`/`draft`) und Modularisierung der Scoring-Engine. | - -### 2.1 WP-22 Lessons Learned -* **Architektur:** Die Trennung von `retriever.py` und `retriever_scoring.py` war notwendig, um LLM-Context-Limits zu wahren und die Testbarkeit der mathematischen Formeln zu erhöhen. -* **Kanten-Validierung:** Die Edge Registry muss beim Start explizit initialisiert werden (Singleton), um "Lazy Loading" Probleme in der API zu vermeiden. - ---- - -## 3. Offene Workpackages (Planung) - -### WP-19a – Graph Intelligence & Discovery (Sprint-Fokus) -**Status:** 🚀 Startklar -**Ziel:** Vom "Anschauen" zum "Verstehen". Deep-Dive Werkzeuge für den Graphen. -* **Discovery Screen:** Neuer Tab für semantische Suche ("Finde Notizen über Vaterschaft") und Wildcard-Filter. -* **Filter-Logik:** "Zeige nur Wege, die zu `type:decision` führen". -* **Chunk Inspection:** Umschaltbare Granularität (Notiz vs. Chunk) zur Validierung des Smart Chunkers. - -### WP-14 – Review / Refactoring / Dokumentation -**Status:** 🟡 Laufend (Phase E) -**Ziel:** Technische Schulden abbauen, die durch schnelle Feature-Entwicklung entstanden sind. -* **Refactoring `chunker.py`:** Die Datei ist monolithisch geworden (Parsing, Strategien, LLM-Orchestrierung). - * *Lösung:* Aufteilung in ein Package `app/core/chunking/` mit Modulen (`strategies.py`, `orchestration.py`, `utils.py`). -* **Dokumentation:** Kontinuierliche Synchronisation von Code und Docs (v2.7.0 Stand). - -### WP-16 – Auto-Discovery & Intelligent Ingestion -**Status:** 🟡 Geplant -**Ziel:** Das System soll "dumme" Textdateien beim Import automatisch analysieren, strukturieren und anreichern, bevor sie gespeichert werden. -**Kern-Features:** -1. **Smart Link Enricher:** Automatisches Erkennen von fehlenden Kanten in Texten ohne explizite Wikilinks. Ein "Enricher" scannt Text vor dem Import, findet Keywords (z.B. "Mindnet") und schlägt Links vor (`[[Mindnet]]`). -2. **Structure Analyzer (Auto-Strategy):** - * *Problem:* Manuelle Zuweisung von `chunking_profile` in `types.yaml` ist starr. - * *Lösung:* Vorschalten einer Analysestufe im Importer (`chunker.py`), die die Text-Topologie prüft und die Strategie wählt. - * *Metrik 1 (Heading Density):* Verhältnis `Anzahl Überschriften / Wortanzahl`. Hohe Dichte (> 1/200) -> Indikator für `structured_smart_edges`. Niedrige Dichte -> `sliding_smart_edges`. - * *Metrik 2 (Variance):* Regelmäßigkeit der Abstände zwischen Headings. -3. **Context-Aware Hierarchy Merging:** - * *Problem:* Leere Zwischenüberschriften (z.B. "Tier 2") gingen früher als bedeutungslose Chunks verloren oder wurden isoliert. - * *Lösung:* Generalisierung der Logik aus WP-15, die leere Eltern-Elemente automatisch mit dem ersten Kind-Element verschmilzt ("Tier 2 + MP1"), um den Kontext für das Embedding zu wahren. - -### WP-17 – Conversational Memory (Gedächtnis) -**Status:** 🟡 Geplant -**Ziel:** Echte Dialoge statt Request-Response. -* **Tech:** Erweiterung des `ChatRequest` DTO um `history`. -* **Logik:** Token-Management (Context Window Balancing zwischen RAG-Doks und Chat-Verlauf). - -### WP-18 – Graph Health & Maintenance -**Status:** 🟡 Geplant (Prio 2) -**Ziel:** Konsistenzprüfung ("Garbage Collection"). -* **Feature:** Cronjob `check_graph_integrity.py`. -* **Funktion:** Findet "Dangling Edges" (Links auf gelöschte Notizen) und repariert/löscht sie. - -### WP-13 – MCP-Integration & Agenten-Layer -**Status:** 🟡 Geplant -**Ziel:** mindnet als MCP-Server bereitstellen, damit Agenten (Claude Desktop, OpenAI) standardisierte Tools nutzen können. -* **Umfang:** MCP-Server mit Tools (`mindnet_query`, `mindnet_explain`, etc.). - -### WP-20 – Cloud Hybrid Mode (Optional) -**Status:** ⚪ Optional -**Ziel:** "Turbo-Modus" für Massen-Imports. -* **Konzept:** Switch in `.env`, um statt Ollama (Lokal) auf Google Gemini (Cloud) umzuschalten. - -### WP-21 – Semantic Graph Routing & Canonical Edges -**Status:** 🟡 Geplant -**Ziel:** Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. -**Problem:** -1. **Statische Gewichte:** Aktuell ist `caused_by` immer gleich wichtig, egal ob der User nach Ursachen oder Definitionen fragt.--- -doc_type: roadmap -audience: product_owner, developer -status: active version: 2.7 context: "Aktuelle Planung für kommende Features (ab WP16), Release-Strategie und Historie der abgeschlossenen WPs." --- @@ -298,41 +185,4 @@ graph TD WP03(Import Pipeline) --> WP21 WP21 --> WP22(Lifecycle & Registry) WP22 --> WP14 - WP15(Smart Edges) --> WP21 -2. **Vokabular-Zwang:** Der Nutzer muss exakte System-Begriffe verwenden. - -**Lösungsansätze & Kern-Features:** -1. **Canonical Edge Mapping (Middleware):** - * Einführung einer Mapping-Schicht (z.B. in `edges.yaml`). - * *Funktion:* Normalisiert User-Vokabular automatisch auf System-Typen. -2. **Dynamic Intent Boosting (Query-Time):** - * Erweiterung der `Decision Engine`. - * *Funktion:* Der Router erkennt den Intent der Frage und injiziert temporäre Gewichte. -3. **Graph Reasoning:** - * Der Retriever priorisiert Pfade, die dem semantischen Muster der Frage entsprechen. - -### WP-22 – Content Lifecycle & Meta-Configuration -**Status:** ✅ Fertig (v2.7.0) -**Ziel:** Professionalisierung der Datenhaltung durch Einführung eines Lebenszyklus und "Docs-as-Code" Konfiguration. -**Lösungsansätze:** -1. **Status-Logik (Frontmatter):** `stable` vs. `draft` Scoring Modifier. -2. **Single Source of Truth (SSOT):** Die Registry nutzt `01_edge_vocabulary.md` als führende Konfiguration. -3. **Self-Learning Loop:** Protokollierung unbekannter Kanten in `unknown_edges.jsonl`. - ---- - -## 4. Abhängigkeiten & Release-Plan - -```mermaid -graph TD - WP19(Graph Viz) --> WP19a(Discovery) - WP19a --> WP17(Memory) - WP15(Smart Edges) --> WP16(Auto-Discovery) - WP15 --> WP14(Refactoring) - WP03(Import) --> WP18(Health Check) - WP03/WP04 --> WP13(MCP) - WP06(Decision Engine) --> WP21(Semantic Routing) - WP21 --> WP22(Lifecycle/Registry) - WP22 --> WP14 - -``` \ No newline at end of file + WP15(Smart Edges) --> WP21 \ No newline at end of file