150 lines
8.6 KiB
Markdown
150 lines
8.6 KiB
Markdown
---
|
||
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`.<br>**Graph Engines:** Parallelbetrieb von Cytoscape und Agraph.<br>**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.
|
||
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
|
||
``` |