Lars
7f707cffb9
All checks were successful
Deploy mindnet to llm-node / deploy (push) Successful in 3s
383 lines
22 KiB
Markdown
383 lines
22 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.---
|
||
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."
|
||
---
|
||
|
||
# Mindnet Active Roadmap
|
||
|
||
**Aktueller Stand:** v2.6.0 (Post-WP15/WP19)
|
||
**Fokus:** Visualisierung, Exploration & Intelligent Ingestion.
|
||
|
||
## 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 nächste Schritt (WP19a) vertieft die Analyse, während WP16 die "Eingangs-Intelligenz" erhöht.
|
||
|
||
| 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 & Visualisierung | 🚀 Aktiv |
|
||
|
||
---
|
||
|
||
## 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-08** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-09** | 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 (COSE) und Agraph.<br>**Tools:** "Single Source of Truth" 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 & Canonical Edges | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?"). |
|
||
| **WP-22** | **Content Lifecycle & Registry** | **Ergebnis:** SSOT via `01_edge_vocabulary.md`, Alias-Mapping, Status-Scoring (`stable`/`draft`) und Modularisierung der Scoring-Engine. |
|
||
---
|
||
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."
|
||
---
|
||
|
||
# Mindnet Active Roadmap
|
||
|
||
**Aktueller Stand:** v2.6.0 (Post-WP15/WP19)
|
||
**Fokus:** Visualisierung, Exploration & Intelligent Ingestion.
|
||
|
||
## 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 nächste Schritt (WP19a) vertieft die Analyse, während WP16 die "Eingangs-Intelligenz" erhöht.
|
||
|
||
| 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 & Visualisierung | 🚀 Aktiv |
|
||
|
||
---
|
||
|
||
## 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-08** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-09** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-08** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-09** | 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 (COSE) und Agraph.<br>**Tools:** "Single Source of Truth" 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 & Canonical Edges | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?"). |
|
||
| **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-08 – Self-Tuning v1/v2 (geplant)
|
||
### WP-08 – Self-Tuning v1/v2 (geplant)
|
||
Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
|
||
**Phase:** B/C
|
||
**Status:** 🟡 geplant (Nächster Fokus)
|
||
|
||
**Ziel:** Aufbau eines Self-Tuning-Mechanismus, der auf Basis von Feedback-Daten (WP-04c) Vorschläge für Retriever- und Policy-Anpassungen macht.
|
||
|
||
**Umfang:**
|
||
- Auswertung der JSONL-Feedback-Daten.
|
||
- Regel-basierte Anpassungs-Vorschläge für `retriever.yaml` und Typ-Prioritäten.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Hoch
|
||
- Komplexität: Hoch
|
||
|
||
### WP-09 – Vault-Onboarding & Migration (geplant)
|
||
|
||
**Phase:** B
|
||
**Status:** 🟡 geplant
|
||
|
||
**Ziel:** Sicherstellen, dass bestehende und neue Obsidian-Vaults schrittweise in mindnet integriert werden können – ohne Massenumbau.
|
||
|
||
**Umfang:**
|
||
- Tools zur Analyse des Vault-Status.
|
||
- Empfehlungen für minimale Anpassungen.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Mittel
|
||
- Komplexität: Niedrig/Mittel
|
||
**Phase:** B/C
|
||
**Status:** 🟡 geplant (Nächster Fokus)
|
||
|
||
**Ziel:** Aufbau eines Self-Tuning-Mechanismus, der auf Basis von Feedback-Daten (WP-04c) Vorschläge für Retriever- und Policy-Anpassungen macht.
|
||
|
||
**Umfang:**
|
||
- Auswertung der JSONL-Feedback-Daten.
|
||
- Regel-basierte Anpassungs-Vorschläge für `retriever.yaml` und Typ-Prioritäten.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Hoch
|
||
- Komplexität: Hoch
|
||
|
||
### WP-09 – Vault-Onboarding & Migration (geplant)
|
||
|
||
**Phase:** B
|
||
**Status:** 🟡 geplant
|
||
|
||
**Ziel:** Sicherstellen, dass bestehende und neue Obsidian-Vaults schrittweise in mindnet integriert werden können – ohne Massenumbau.
|
||
|
||
**Umfang:**
|
||
- Tools zur Analyse des Vault-Status.
|
||
- Empfehlungen für minimale Anpassungen.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Mittel
|
||
- Komplexität: Niedrig/Mittel
|
||
|
||
### 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 (WP15/WP19) 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.6 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. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?").
|
||
**Problem:**
|
||
1. **Statische Gewichte:** Aktuell ist `caused_by` immer gleich wichtig (z.B. 1.2), egal ob der User nach Ursachen oder Definitionen fragt.
|
||
2. **Vokabular-Zwang:** Der Nutzer muss exakte System-Begriffe (`caused_by`) verwenden. Natürliche Synonyme (`führt_zu`, `ausgelöst_durch`) werden als unbekannte Kanten ignoriert oder nicht speziell gewichtet.
|
||
|
||
**Lösungsansätze & Kern-Features:**
|
||
1. **Canonical Edge Mapping (Middleware):**
|
||
* Einführung einer Mapping-Schicht (z.B. in `edges.yaml`).
|
||
* *Funktion:* Normalisiert User-Vokabular (`leads_to`, `triggers`, `starts`) automatisch auf System-Typen (`caused_by`).
|
||
* *Benefit:* Maximale Schreibfreiheit für den Nutzer bei gleichzeitiger System-Konsistenz.
|
||
2. **Dynamic Intent Boosting (Query-Time):**
|
||
* Erweiterung der `Decision Engine`.
|
||
* *Funktion:* Der Router erkennt den Intent der Frage (z.B. `EXPLANATION` für "Warum-Fragen") und injiziert temporäre `edge_weights` in den Retriever.
|
||
* *Beispiel:* Bei "Warum ist das passiert?" wird `caused_by` von 1.2 auf 2.5 geboostet, während `related_to` auf 0.1 sinkt.
|
||
3. **Graph Reasoning:**
|
||
* Der Retriever priorisiert Pfade, die dem semantischen Muster der Frage entsprechen, nicht nur dem Text-Match.
|
||
|
||
### 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 --> WP13(MCP)
|
||
WP04 --> WP13(MCP)
|
||
WP06(Decision Engine) --> WP21(Semantic Routing)
|
||
WP03(Import Pipeline) --> WP21
|
||
WP21 --> WP22(Lifecycle & Registry)
|
||
WP22 --> WP14
|
||
WP15(Smart Edges) --> WP21 |