mindnet/docs/06_Roadmap/06_active_roadmap.md

doc_type	audience	status	version	context
roadmap	product_owner, developer	active	2.9.3	Aktuelle Planung für kommende Features (ab WP16), Release-Strategie und Historie der abgeschlossenen WPs nach WP-14/15b/15c/25.

Mindnet Active Roadmap

Aktueller Stand: v2.9.3 (Post-WP25: Agentic Multi-Stream RAG) Fokus: Agentic Orchestration, Multi-Stream Retrieval & Wissens-Synthese.

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-14	Modularisierung & Refactoring	Ergebnis: Aufteilung in domänenspezifische Pakete (database, ingestion, retrieval, graph). Implementierung von Proxy-Adaptern für Abwärtskompatibilität und registry.py zur Lösung von Zirkelbezügen.
WP-15b	Candidate-Based Validation	Ergebnis: Implementierung des Two-Pass Workflows. Einführung des LocalBatchCache und binäre semantische Validierung von Kanten-Kandidaten zur Vermeidung von Halluzinationen.
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 (COSE) und Agraph. Tools: "Single Source of Truth" Editor, Persistenz via URL.
WP-20	Cloud Hybrid Mode & Resilienz	Ergebnis: Integration von OpenRouter (Mistral 7B) & Gemini 2.5 Lite. Implementierung von WP-76 (Rate-Limit Wait) & Mistral-safe JSON Parsing.
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.
WP-15c	Multigraph-Support & Diversity Engine	Ergebnis: Section-basierte Links, Note-Level Diversity Pooling, Super-Edge Aggregation, Provenance Firewall. Transformation zu einem hochpräzisen Multigraphen.
WP-25	Agentic Multi-Stream RAG Orchestration	Ergebnis: Übergang von linearer RAG-Architektur zu paralleler Multi-Stream Engine. Intent-basiertes Routing (Hybrid Fast/Slow-Path), parallele Wissens-Streams (Values, Facts, Biography, Risk, Tech), Stream-Tracing und Template-basierte Wissens-Synthese.

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.

2.2 WP-20 Lessons Learned (Resilienz)

• Quoten-Management: Die Nutzung von Free-Tier Modellen (Mistral/OpenRouter) erfordert zwingend eine intelligente Rate-Limit-Erkennung (HTTP 429) mit automatisierten Wartezyklen, um Batch-Prozesse stabil zu halten.
• Parser-Robustheit: Cloud-Modelle betten JSON oft in technische Steuerzeichen (<s>, [OUT]) ein. Ein robuster Extraktor mit Recovery-Logik ist essentiell zur Vermeidung von Datenverlust.

2.3 WP-14 & WP-15b Lessons Learned

• Performance: Der Pre-Scan (Pass 1) ist minimal invasiv, ermöglicht aber in Pass 2 eine drastische Reduktion der LLM-Kosten, da nur noch binär validiert werden muss, anstatt komplexe Extraktionen durchzuführen.
• Wartbarkeit: Durch die Paket-Struktur können DB-Adapter (z.B. für Qdrant) nun unabhängig von der Business-Logik (Scoring) aktualisiert werden.

---

3. Offene Workpackages (Planung)

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 installiert 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-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-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.8 Stand).

WP-15b – Candidate-Based Edge Validation & Inheritance

Phase: B/E (Refactoring & Semantic) Status: 🚀 Startklar (Ersatz für WP-15 Logik) Ziel: Ablösung der fehleranfälligen "Open-End-Extraktion" durch eine KI-gestützte Validierung menschlicher Vorarbeit zur Steigerung von Speed, Integrität und semantischer Tiefe.

Herausforderung: Der bisherige WP-15 Ansatz litt unter Halluzinationen (erfundene Kantentypen), hohem Token-Verbrauch und dem Verlust physikalisch gesetzter Kanten bei der Chunk-Verteilung.

Anforderungen & Strategie:

1. Hard-Link Integrity: Kanten, die im Markdown-Text eines Chunks stehen, werden zwingend und ohne LLM-Prüfung gesetzt (provenance: explicit).
2. Edge Inheritance: Kanten, die auf Dokument-Ebene (Frontmatter) oder Sektions-Ebene (Heading) definiert sind, werden automatisch an alle zugehörigen Sub-Chunks vererbt, wenn ein semantischer Block aufgrund von Größengrenzen geteilt wurde.
3. Candidate Pool Extraction: Definition eines "Edge-Pools" pro Dokument. Dieser speist sich aus dem Frontmatter und einer speziellen Sektion (z. B. ### Unzugeordnete Kanten).
4. Semantic Validation Gate: Das LLM fungiert als binärer Validator. Es prüft ausschließlich Kanten aus dem Kandidaten-Pool gegen den konkreten Chunk-Inhalt UND eine Zusammenfassung der Ziel-Note (Inhalt, Typ, Kanten-Typ).
5. Registry Enforcement: Strikte Blockade von Halluzinationen. Nur Kanten, die im Pool definiert UND im edge_vocabulary.md vorhanden sind, werden zugelassen.

Lösungsskizze:

• Parser-Update: extract_candidate_pool zur Identifikation aller im Dokument beabsichtigten Links.
• Chunker-Update: Implementierung einer propagate_edges-Logik für "by_heading" und "sliding_window" Strategien.
• Ingestion-Update: Umstellung von _perform_smart_edge_allocation auf einen binären Validierungs-Prompt (VALID/INVALID).

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-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-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.

WP-25: Agentic Multi-Stream RAG Orchestration

Status: ✅ Fertig (v3.0.0)

WP-25a: Mixture of Experts (MoE) & Fallback-Kaskade

Status: ✅ Fertig (v3.0.0)

Ergebnis: Transformation von Mindnet von einer klassischen, linearen RAG-Architektur zu einer Agentic Multi-Stream Engine. Das System agiert nun als intelligenter Orchestrator, der Nutzeranfragen analysiert, in parallele Wissens-Streams aufteilt und diese zu einer kontextreichen, wertebasierten Antwort synthetisiert.

Kern-Features:

1. Intent-basiertes Routing: Hybrid-Modus mit Keyword Fast-Path und LLM Slow-Path
2. Multi-Stream Retrieval: Parallele Abfragen in spezialisierten Streams (Values, Facts, Biography, Risk, Tech)
3. Stream-Tracing: Jeder Treffer wird mit stream_origin markiert
4. Wissens-Synthese: Template-basierte Zusammenführung mit expliziten Stream-Variablen
5. Fehler-Resilienz: Einzelne Stream-Fehler blockieren nicht die gesamte Anfrage

Technische Details:

• Decision Engine v1.0.3: Multi-Stream Orchestrator
• Chat Router v3.0.2: Hybrid Router Integration
• LLM Service v3.4.2: Ingest-Stability Patch
• decision_engine.yaml v3.1.6: Multi-Stream Konfiguration
• prompts.yaml v3.1.2: Stream-Templates

Ergebnis (WP-25a): Transformation von MindNet von einer provider-basierten Steuerung auf eine profilbasierte Experten-Architektur (Mixture of Experts). Jede Systemaufgabe wird einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig definiert.

Kern-Features:

1. Experten-Steuerung: Zentrale Profile-Registry (llm_profiles.yaml) für alle LLM-Aufgaben
2. Rekursive Fallback-Kaskade: Automatische Resilienz bei Provider-Fehlern mit Schutz gegen Zirkel-Referenzen
3. Pre-Synthesis Kompression: Asynchrone Verdichtung überlanger Wissens-Streams vor der Synthese
4. Profilgesteuerte Ingestion: Deterministische Validierung via ingest_validator (Temperature 0.0)
5. Embedding-Konsolidierung: Zentrale Steuerung des Embedding-Modells über embedding_expert Profil
6. Startup-Schutz: Validierung der YAML-Konfigurationen beim Booten

Technische Details:

• LLM Service v3.5.2: Rekursive Fallback-Kaskade
• Decision Engine v1.2.1: Profile-Driven Orchestration
• Ingestion Processor v2.14.0: Profilgesteuerte Validierung
• Embeddings Client v2.6.0: Profil-basierte Modell-Auflösung
• llm_profiles.yaml v1.3.0: Zentrale Experten-Registry
• decision_engine.yaml v3.2.2: Decoupled MoE Logic

Ausblick (WP-25b):

• Prompt-Orchestration & Model-Specific Tuning
• Kontext-Budgeting: Intelligente Token-Verteilung
• Stream-specific Provider: Unterschiedliche KI-Modelle pro Wissensbereich

---

WP-24 – Proactive Discovery & Agentic Knowledge Mining

Status: 🚀 In Planung (Nächster Architektur-Sprung) Ziel: Transformation von Mindnet von einem reaktiven Archiv zu einem aktiven Denkpartner. Das System soll aktiv Wissenslücken schließen und verborgene Querverbindungen in großen Vaults sowie in Chat-Dialogen aufspüren.

Herausforderung:

1. Silo-Effekt: Bei wachsenden Vaults vergisst der Nutzer existierende Notizen und erstellt redundante Inhalte ohne Verknüpfung.
2. Insight-Verlust: Im Chat entstehen wertvolle Synthesen, die momentan im flüchtigen Chat-Log vergraben bleiben.

Lösungsskizze & Strategie:

A. Proactive Discovery (Vault-Scanning)

Das System nutzt die existierende candidate_pool Logik aus WP-15b, befüllt diese jedoch automatisiert:

• Vector Similarity Search: Beim Import einer Note (oder als periodischer Hintergrundprozess) sucht der neue RecommenderService in Qdrant nach den Top-X semantisch ähnlichsten Chunks im gesamten Vault.
• Auto-Injection: Diese Funde werden automatisch als related_to Kandidaten in den candidate_pool der neuen Note injiziert.
• WP-15b Filter: Das LLM validiert diese Vorschläge im zweiten Pass der Ingestion gegen den Kontext. Nur was semantisch wirklich passt, wird als Kante im Graphen persistiert.

B. Agentic Knowledge Mining (Chat-to-Vault)

Integration von Informationen aus dem Dialog direkt in den Graphen:

• Intent Detection: Das Chat-Backend erkennt „notierwürdige“ Informationen (z.B. neue Prinzipien, Strategie-Entwürfe oder Werte-Anpassungen).
• Auto-Drafting: Das LLM nutzt das interview_template, um aus dem Chat-Fragment eine valide Markdown-Datei mit Frontmatter (Status: draft) zu generieren.
• Real-Time Linking: Die neue Datei wird sofort dem „Discovery-Lauf“ (Teil A) unterzogen, um sie mit dem bestehenden Wissensschatz zu vernetzen.
• User Review: Die generierte Notiz erscheint im 00_Inbox Ordner. Der Nutzer muss lediglich den Status auf stable setzen, um die Entdeckungen final zu integrieren.

Erwartete Ergebnisse:

• Eliminierung von Wissens-Silos durch automatische Vernetzung.
• Nahtloser Übergang von der Exploration (Chat) zur Konsolidierung (Vault).
• Vermeidung von Dubletten durch Ähnlichkeits-Warnungen beim Import.

4. Abhängigkeiten & Release-Plan

graph TD
    WP19(Graph Viz) --> WP19a(Discovery)
    WP19a --> WP17(Memory)
    WP15(Smart Edges) --> WP16(Auto-Discovery)
    WP15 --> WP14(Refactoring)
    WP15(Smart Edges) --> WP15b(Candidate Validation)
    WP15b --> WP24(Proactive Discovery)
    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
    WP20(Cloud Hybrid) --> WP15b
    WP24 --> WP23(Multi-Stream Reasoning)