289 lines
19 KiB
Markdown
289 lines
19 KiB
Markdown
---
|
||
doc_type: roadmap
|
||
audience: product_owner, developer
|
||
status: active
|
||
version: 2.9.3
|
||
context: "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`.<br>**Graph Engines:** Parallelbetrieb von Cytoscape (COSE) und Agraph.<br>**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
|
||
|
||
```mermaid
|
||
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)
|
||
``` |