# mindnet v2.2 — Programmplan  
**Version:** 2.2  
**Stand:** 2025-12-06  
**Status:** Aktiv (Fortschreibung von v2.1)   

---

## 1. Programmauftrag

mindnet v2.2 entwickelt ein persönliches, wachsendes KI-Gedächtnis, das:   

- Wissen, Erfahrungen, Werte und Entscheidungen speichert,  
- diese Informationen semantisch verknüpft und rekonstruierbar macht,  
- einen KI-Zwilling aufbaut, der ähnlich argumentiert, entscheidet und reflektiert wie du,  
- über mehrere Kanäle gefüttert wird:
  - Obsidian-Markdown (primäre Quelle),
  - Chat-basierter Agent (mindnet-Assistent),
  - später: Interview-Assistent (strukturierte Dialogerfassung),  
- automatisch neue Zusammenhänge erkennt und vernetzt (Edges, Typen, Hinweise),  
- sich durch Rückmeldungen (Feedback) selbst verbessert (Self-Tuning).

Langfristig soll mindnet als **digitales Gegenüber** funktionieren, das:   

- dich versteht,  
- deine Denkweise reflektiert,  
- deine Werte kennt und verwendet,  
- Entscheidungen begründen kann („Warum?“),  
- Erinnerungen einordnet,  
- und für deine Nachkommen als dialogfähiger Gesprächspartner zur Verfügung steht.

mindnet ist **kein statisches Wissensarchiv**, sondern ein **lebendes, lernendes Gedächtnismodell** mit Fokus auf:

- persönliche Perspektive,  
- erklärbare Begründungspfade,  
- kontinuierliche Erweiterbarkeit,  
- robuste technische Basis (lokal, nachvollziehbar, versioniert).  

---

## 2. Vision

> „Ein persönliches semantisches Gedächtnis, das mit mir wächst, meine Persönlichkeit spiegelt und mir als intelligenter, erklärbarer, lernender Begleiter dient.“   

Kernprinzipien der Vision:

- **Erklärbarkeit:**  
  Jede Antwort muss über Edges, Scores, Werte-Bezüge und Herkunftsnotizen begründbar sein.  

- **Wachstum:**  
  Das System arbeitet von Anfang an mit unvollständigen Daten, kann aber schrittweise dichter werden, ohne dass alte Notizen massenhaft manuell angepasst werden müssen.  

- **Flexibilität (Late Binding):**  
  Semantik wird überwiegend in Konfiguration (z. B. `types.yaml`, Policies, Knowledge-Design) festgelegt, nicht in jeder einzelnen Markdown-Datei.  

- **Autonomie & Self-Healing:**  
  mindnet schlägt fehlende Typen, Relationen und Edges vor (z. B. aus Inline-Relationen, Edge-Defaults, Ähnlichkeitsbeziehungen) und baut damit einen „self-healing graph“ auf.   

- **Lernen & Self-Tuning:**  
  Feedback zu Antworten (gut/schlecht, relevant/nicht relevant) fließt in Score-Gewichte, Policies und ggf. Edge-Struktur ein.  

- **Persönlichkeit:**  
  Entscheidungen werden wert- und erfahrungsbasiert begründet; mittelfristig entsteht ein Persönlichkeitsmodell, das den KI-Zwilling trägt.  

- **Incremental Growth:**  
  Das System muss mit wenigen, heterogenen Notizen starten und sich fortlaufend verdichten können – ohne Retro-Massenmigrationen im Vault.  

---

## 3. Programmziele

### 3.1 Kurzfristig (nächste Monate)

- Automatische Sammlung von Wissen aus Markdown-Vault und ersten Chat-Dialogen.  
- Aufbau eines stabilen Graph-Speichers in Qdrant (`*_notes`, `*_chunks`, `*_edges`).   
- Semantischer und graphbasierter Retriever (WP-04a abgeschlossen, WP-04b/04c in Vorbereitung).   
- Automatisierte Erkennung von Beziehungen:
  - Wikilinks, Inline-Relationen, Callout-Edges, Typ-Defaults.   
- Schrittweises Lernen über Feedback (Score-Tuning, noch „manuell“ konfiguriert). :contentReference[oaicite:8]{index=8}  
- „Mitwachsendes“ Schema ohne Obsidian-Umstrukturierungen:
  - Neues Wissen kann sofort erfasst werden,
  - bestehende Notizen bleiben gültig (Virtual Schema Layer).   
- Technische Basis für die späteren Agenten und den KI-Zwilling:
  - lokaler FastAPI-Dienst,
  - Qdrant als Graph-Backend,
  - konfigurierbarer Retriever (`retriever.yaml`).   

### 3.2 Mittelfristig

- Persönlichkeitsprofil wird stabil erkannt und für Antworten genutzt (Typen, Werte-Notizen, Entscheidungsnotizen).  
- Why-Layer: KI-Assistenz für Entscheidungen mit nachvollziehbarer Argumentation.  
- Interview-Assistent erstellt neue Notes automatisch (strukturierte Dialoge → Markdown).  
- mindnet erzeugt Vorschläge für neue Notes & Edges und bietet einen „Vernetzungs-Assistenten“ für manuell angelegte Notizen.  
- Agenten können über MCP-Tools (`mindnet_query`, `mindnet_subgraph`, `mindnet_store_note`, `mindnet_explain`) auf mindnet zugreifen.   

### 3.3 Langfristig

- KI-Zwilling, der deinen Stil, deine Werte und deine typische Denkweise repräsentiert.  
- Weitgehend autonomes Self-Tuning der Wissensstruktur (auf Basis gespeicherter Feedback-Daten & Policies).  
- Lebenslanges Gedächtnis, das
  - konsistent bleibt,  
  - wächst,  
  - sich weiterentwickelt,  
  - und deine Geschichte für deine Nachkommen erzählbar und erlebbar macht.   

---

## 4. Architekturprinzipien

Die folgenden Prinzipien steuern alle Workpackages und Entscheidungen:   

1. **Late Binding (späte Semantik)**  
   - Struktur und Interpretation werden in Konfigurationen (z. B. `types.yaml`, Policies, `knowledge_design.md`) definiert, nicht direkt in den Vault-Dateien.  
   - Erlaubt spätere Anpassungen ohne manuelle Massenänderungen.

2. **Virtual Schema Layer**  
   - Typen, Regeln, Policies, Edge-Defaults werden im Schema-Layer beschrieben (z. B. `knowledge_design.md`, `mindnet_functional_architecture.md`, `types.yaml`).  
   - Markdown-Dateien benötigen nur minimale, robuste Angaben (Titel, Typ, optionale Properties).

3. **Self-Healing Graph**  
   - Der Graph wird regelmäßig analysiert (Edges, Centrality, fehlende Links).  
   - Automatisierte Jobs ergänzen fehlende Kanten (ähnliche Inhalte, typisierte Standardbeziehungen, Backlinks).  

4. **Deterministische IDs**  
   - Notes, Chunks und Edges erhalten stabile IDs (z. B. UUIDv5, deterministische `note_id`/`chunk_id`/`edge_id`).  
   - Der Graph ist jederzeit wiederaufbaubar (Import-Pipeline idempotent).   

5. **Full Explainability**  
   - Jeder Score, jede Beziehung, jeder Vorschlag muss über:
     - Edges,
     - Scoring-Komponenten (Semantik, Typ, Edge-Bonus, Centrality),
     - Provenienz (Notizen, Chunks, rule_id, confidence) nachvollziehbar sein.   

6. **Persistence First**  
   - Obsidian bleibt die primäre Quelle der Wahrheit.  
   - mindnet ergänzt, schlägt Änderungen vor, schreibt aber nur kontrolliert (z. B. über Rewriter oder Vernetzungs-Assistent mit Freigabe).

7. **Minimalinvasives Schreiben**  
   - Automatische Veränderungen an Markdown-Dateien erfolgen ausschließlich nach expliziter Zustimmung.  
   - Rewriter und Vernetzungs-Assistent arbeiten grundsätzlich im Vorschlagsmodus.

8. **Incremental Growth & Early Value**  
   - Das System muss bereits mit wenigen Notizen und einem kleinen Vault sinnvolle Antworten liefern (Retrieval-MVP).  
   - Spätere Erweiterungen (Typen, Policies, zusätzliche Edges) dürfen bestehende Notizen nicht „ungültig“ machen, sondern ergänzen sie.  
   - Feedback-Mechanismen werden früh eingeführt, auch wenn sie anfangs noch nicht vollautomatisch ausgewertet werden.

9. **Observability & Testbarkeit**  
   - Jeder Importlauf, jede Retriever-Anfrage und jede Policy-Änderung soll prüfbar sein (Logs, Traces, Tests, Reports).   

---

## 5. Programmstruktur (Phasenmodell)

    Phase A – Fundament & Import
    Phase B – Semantik, Graph & Lernen
    Phase C – Persönlichkeitsmodell & KI-Zwilling
    Phase D – Agenten, MCP & Interaktion
    Phase E – Review, Refactoring, Dokumentation   

Alle Workpackages sind einer Phase zugeordnet; einige Workpackages (z. B. WP-03, WP-04a) sind bereits abgeschlossen und bilden heute die Basis für alle weiteren Schritte.

---

## 6. Workpackages – detaillierte Übersicht

### Legende Aufwand / Komplexität

- Aufwand: Niedrig / Mittel / Hoch  
- Komplexität: Niedrig / Mittel / Hoch  

Die Status-Ampel zeigt den aktuellen Stand gemäß Programmfortschritt. :contentReference[oaicite:18]{index=18}  

---

### WP-01 – Wissensdesign (abgeschlossen)

**Phase:** A  
**Status:** 🟢 abgeschlossen  

**Ziel:**  
Grundlegendes Schema für mindnet festlegen (`knowledge_design.md`), inkl.:   

- Note-Typen (z. B. `concept`, `experience`, `project`, `decision`, `value`, `principle`, `person`, `event`, etc.).  
- Standard-Properties (Titel, Typ, Tags, Status, Zeitstempel, Referenzen, Policies).  
- Grundstruktur von Edges (z. B. `belongs_to`, `references`, `depends_on`, `similar_to`, `related_to`, `influenced_by`).  
- Abbildung zentraler Lebens-Bereiche, Rollen und Wissenskategorien.

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Mittel  

**Erreichte Ergebnisse / Funktionsumfang:**  

- `knowledge_design.md` in Version 1.5 definiert:
  - Zielarchitektur,  
  - Collections,  
  - Identitätsmodell,  
  - zentrale Typen und Edges. :contentReference[oaicite:20]{index=20}  
- Das Dokument beschreibt klar:
  - wie Wissen fachlich strukturiert wird,  
  - welche Typen und Relationen in mindnet „erwartet“ werden,  
  - wie spätere Erweiterungen (neue Typen, zusätzliche Edge-Arten) ohne Retro-Migration möglich sind.  

**DoD:**  

- Schema ist konsistent beschrieben.  
- Grundtypen und Edge-Arten sind definiert und im Code konzeptionell verankert (z. B. via `types.yaml`).  
- Das Dokument dient als Referenz für alle folgenden WPs.

---

### WP-02 – Chunking & Hash-Strategie (abgeschlossen)

**Phase:** A  
**Status:** 🟢 abgeschlossen  

**Ziel:**  
Festlegen und implementieren einer robusten Chunking-Strategie und einer Hash-Logik zur Änderungs­erkennung.  

**Umfang (fachlich & technisch):**   

- Text in semantisch sinnvolle Chunks teilen (Heading-/Block-aware).  
- Parallelhaltung von:
  - `text` (Chunk-Kern ohne Overlap),
  - `window` (Chunk-Fenster mit Overlap für Embeddings).  
- Hash-Modi zur Änderungs­erkennung (Body / Frontmatter / Full, canonical vs. none).  
- Unterstützung eines „Baseline-Modus“ (mehrere Hash-Signaturen), um spätere Modus-Wechsel zu ermöglichen, ohne alle Notizen als „geändert“ zu sehen.

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Mittel/Hoch  

**Erreichte Ergebnisse / Funktionsumfang:**  

- Implementierte Chunker-Logik mit Ziel-Längen, Overlap und Nachbarschaft (`neighbors_prev`, `neighbors_next`).  
- Tests zur Überprüfung der Rekonstruktion von Notiz-Bodies aus Chunks (`verify_chunks_integrity.py`, `check_chunks_window_vs_text.py`).   
- Hash-Konfiguration über ENV-Variablen + Option `--baseline-modes`.  
- Roundtrip-Tests für Vault → Qdrant → Export-Vault (keine ungewollten Veränderungen an Inhalten).  

**DoD:**  

- Chunking stabil, deterministisch, überprüft.  
- Hash-Strategie ermöglicht sichere Änderungs­erkennung ohne Mass-Diffs bei Konfigurationswechsel.  

---

### WP-03 – Import-Pipeline & Edge-System v2 (abgeschlossen)

**Phase:** A/B  
**Status:** 🟢 abgeschlossen  

**Ziel:**  
Durchgängige Import-Pipeline von Markdown → Notes/Chunks/Edges in Qdrant mit deterministischen IDs, typbasierten Defaults und erklärbarem Edge-Modell.   

**Umfang:**  

- Parser (robust gegenüber Zeichensatzfehlern, Frontmatter/Body-Erkennung, Sonderfälle wie Silverbullet-Dateien).  
- Bau von Note-Payloads (`note_payload`):  
  - Typ-Vererbung (`retriever_weight`, `chunk_profile`, `edge_defaults`).  
- Bau von Chunk-Payloads (`chunk_payload`):  
  - `text`, `window`, Nachbarn, Typ-Information.  
- Edge-System:
  - Strukturkanten (`belongs_to`, `next`, `prev`),  
  - explizite Wikilinks (`[[Note]]` → `references`),  
  - Inline-Relationen (`[[rel:depends_on Note]]`),  
  - Callout-Edges (`> [!edge] related_to: [[Note]]`),  
  - typbasierte Standardkanten aus `types.yaml` (`edge_defaults`).   
- Idempotente Upserts in Qdrant (Notes/Chunks/Edges).  

**Aufwand / Komplexität:**  
- Aufwand: Hoch  
- Komplexität: Hoch  

**Erreichte Ergebnisse / Funktionsumfang:**  

- Vollständige E2E-Import-Pipeline incl. Tests (`run_e2e_roundtrip.sh`, `compare_vaults.py`, `validate_edges`, `edges_full_check`).   
- deterministische ID-Vergabe für Notes/Chunks/Edges.  
- vollständiges Edge-Modell gemäß Facharchitektur (`mindnet_functional_architecture.md`). :contentReference[oaicite:26]{index=26}  
- Exporte zurück nach Markdown (Export-Pipeline) ermöglicht Roundtrip-Vergleich.  

**DoD:**  

- Importer generiert stabile Notes/Chunks/Edges für gesamten Vault.  
- Edge-Invarianten (`belongs_to == #Chunks`, `next/prev` konsistent) erfüllt.  
- Roundtrip: Exportierte Vault-Version stimmt inhaltlich mit originalem Vault überein (bis auf bewusst ausgeschlossene Dateien).  

---

### WP-04a – Retriever & Graph-Scoring (abgeschlossen)

**Phase:** B  
**Status:** 🟢 abgeschlossen  

**Ziel:**  
Aufbau eines hybriden Retrievers, der Semantik (Embeddings), Typwissen (`retriever_weight`) und Graph-Informationen (Edges, Centrality) zu einem erklärbaren Score kombiniert.   

**Umfang:**  

- Retriever-Modul (`app/core/retriever.py`):  
  - Vektorsuche über `*_chunks`,  
  - Zusammenführung von Chunk-Treffern mit Note-Metadaten,  
  - Aufbau eines Subgraphen (Nachbarn über Edges, Centrality-Berechnung).  
- Scoring-Formel:
      semantic_score
      retriever_weight
      edge_bonus
      centrality_bonus
- Konfiguration über `config/retriever.yaml` (Gewichte, Parameter). :contentReference[oaicite:28]{index=28}  
- FastAPI-Endpoint `/query` mit Rückgabe:
  - Trefferliste,
  - Teil-Scores,
  - Begründung (inkl. Edge-Kontext).

**Aufwand / Komplexität:**  
- Aufwand: Hoch  
- Komplexität: Hoch  

**Erreichte Ergebnisse / Funktionsumfang:**  

- Hybrides Scoring-Modell mit konfigurierbaren Gewichten (`semantic_weight`, `edge_weight`, `centrality_weight`).  
- Nutzung von `retriever_weight` aus `types.yaml` in Score-Berechnung.   
- Graph-boni aus echten Edges (explizit, Inline, Typ-Defaults, Strukturkanten).  
- Funktionsfähiger `/query`-Endpoint mit Testcases (inkl. Relations-Showcase-Vault).  
- Basis für spätere Self-Tuning-Mechanismen (Logging von Scores, Konfiguration in `retriever.yaml`).  

**DoD:**  

- `/query` liefert nachvollziehbare Ergebnisse mit sichtbarem Einfluss von:
  - Typprioritäten,  
  - Edge-Struktur,  
  - Centrality.  
- Scoring ist rein konfigurierbar (Konfig-Change → Score-Veränderung ohne Code-Änderung).  

---

### WP-04b – Explanation Layer (geplant)

**Phase:** B  
**Status:** 🟡 geplant  

**Ziel:**  
Treffererklärungen liefern, die für dich (Mindmaster) und spätere Nutzer verständlich sind (Why-Layer).  

**Umfang:**  

- Erklärungsschicht über dem Retriever:
  - Aufschlüsselung des Scores pro Treffer,
  - Ketten von Edges (Pfade) als Begründungsgraph,
  - Markierung relevanter Chunks / Notizen.  
- Darstellung von:
  - verwendeten Typen,  
  - Edges und deren `rule_id` / `confidence`,  
  - Centrality-Beiträgen.  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Hoch  

**DoD (Zielbild):**  

- API-Endpoint (z. B. `/query/explain`), der eine strukturierte Erklärung in JSON liefert.  
- Mindestens ein Beispiel, in dem Score-Änderung nachvollziehbar auf Policies/Edges zurückgeführt werden kann.  

---

### WP-04c – Feedback Logging & Bewertungsdaten (geplant)

**Phase:** B  
**Status:** 🟡 geplant  

**Ziel:**  
Grundlage für Self-Tuning schaffen, indem Queries, Antworten und Bewertungen systematisch protokolliert werden.  

**Umfang:**  

- Logging von:
  - Query-Texten,
  - verwendeten Policies/Config-Versionen,
  - Trefferlisten (Scores, Edges),
  - Feedback (z. B. „hilfreich“, „irrelevant“, „falsch“).  
- Persistente Speicherung (z. B. in einer separaten Sammlung oder Datei-basiert).  
- Bereitstellung von Auswertungs-Skripten (Statistiken, Ranking-Qualität).  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Mittel/Hoch  

**DoD (Zielbild):**  

- Vollständiger Feedback-Trail für ausgewählte Test-Sessions.  
- Exportfähige Datenbasis zur späteren Optimierung der Retriever-Parameter.  

---

### WP-05 – Persönlichkeitsmodell (geplant)

**Phase:** C  
**Status:** 🟡 geplant  

**Ziel:**  
Aufbau eines expliziten Persönlichkeitsmodells, das Werte, Prinzipien, prägende Erfahrungen und wiederkehrende Entscheidungsstrategien abbildet.  

**Umfang:**  

- Identifikation und Typisierung relevanter Notes:
  - `value`, `principle`, `life_event`, `milestone`, `decision`.  
- Aufbau eines Modells, das:
  - typische Begründungsmuster erkennt,
  - Wertprioritäten identifiziert,
  - langfristig in Scoring & Antwort-Formulierung einfließt.  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Mittel  

**DoD (Zielbild):**  

- Dokumentiertes Persönlichkeitsmodell (z. B. YAML/Markdown), das konkrete Wert-/Prinzipien-Strukturen beschreibt.  
- Basis-Integration in den Retriever (z. B. Wert-Bezüge in Explanation-Layer).  

---

### WP-06 – Decision Engine (geplant)

**Phase:** C  
**Status:** 🟡 geplant  

**Ziel:**  
Entscheidungsunterstützung auf Basis von Wissen, Persönlichkeit und Zielen – inklusive nachvollziehbarer Begründung.  

**Umfang:**  

- Identifikation typischer Entscheidungssituationen (z. B. beruflich, familiär, gesundheitlich).  
- Integration von:
  - fachlichem Wissen,  
  - Erfahrungen (Vergangenheitsentscheidungen),  
  - Persönlichkeitsmodell.  
- Ableitung von Entscheidungs-Templates / Heuristiken.  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Hoch  

**DoD (Zielbild):**  

- Prototypischer „Decision-Assistant“, der für definierte Szenarien begründete Empfehlungen gibt.  
- Erklärungen referenzieren konkrete Notes/Edges.  

---

### WP-07 – Interview-Assistent (geplant)

**Phase:** C  
**Status:** 🟡 geplant  

**Ziel:**  
Dialogbasierter Erfassungs-Assistent, der strukturierte Interviews führt und daraus konsistente Markdown-Notizen generiert.  

**Umfang:**  

- Design von Interview-Flows (z. B. für Lebensereignisse, Projekte, Werte-Workshops).  
- Konvertierung von Dialogtranskripten in typisierte Notes (inkl. Typ, Tags, erste Edges).  
- Integration mit Vault-Struktur (Ablagepfade, Namenskonventionen).  

**Aufwand / Komplexität:**  
- Aufwand: Niedrig/Mittel  
- Komplexität: Mittel  

**DoD (Zielbild):**  

- Mindestens ein produktionsnaher Flow (z. B. „Erzähle mir von einem prägenden Ereignis“).  
- Automatische Erzeugung von Markdown-Notizen, die vom Importer direkt verarbeitet werden können.  

---

### WP-08 – Self-Tuning v1/v2 (geplant)

**Phase:** B/C  
**Status:** 🟡 geplant  

**Ziel:**  
Aufbau eines Self-Tuning-Mechanismus, der auf Basis von Feedback-Daten Vorschläge für Retriever- und Policy-Anpassungen macht.  

**Umfang:**  

- Auswertung der Feedback-Daten (WP-04c).  
- Regel-basierte Anpassungs-Vorschläge:
  - Gewichte in `retriever.yaml`,  
  - Typ-Prioritäten,  
  - Edge-Provenance-Gewichte.   
- Optionale halbautomatische Übernahme (Freigabe durch Mindmaster).  

**Aufwand / Komplexität:**  
- Aufwand: Hoch  
- Komplexität: Hoch  

**DoD (Zielbild):**  

- Mindestens ein in der Praxis getesteter Tuning-Zyklus:
  - Feedback sammeln,
  - Vorschlag generieren,
  - Anpassung vornehmen,
  - Qualitätsgewinn nachweisen.  

---

### 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/Guides für:
  - Analyse des Vault-Status (Typen, Edges, Lücken),  
  - Empfehlungen für minimale Anpassungen (z. B. Typ-Setzung, Basis-Tags),  
  - optional automatisierte Ergänzung von Properties (mit Freigabe).  
- Unterstützung eines „wachsenden Systems“:
  - erste Notizen liefern sofort Mehrwert im Retriever,  
  - später können Typen und Edges ergänzt werden, ohne alte Notizen zu brechen.  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Niedrig/Mittel  

**DoD (Zielbild):**  

- Dokumentierter Onboarding-Prozess für Produkt-Vault.  
- Mindestens ein erfolgreicher Durchlauf mit deinem realen Vault (Pilot).  

---

### WP-10 – Chat-Interface & Writeback (geplant)

**Phase:** D  
**Status:** 🟡 geplant  

**Ziel:**  
Chat-basierter mindnet-Agent, der sowohl Fragen beantwortet als auch neue Notizen erzeugen/aktualisieren kann (Writeback Richtung Vault).  

**Umfang:**  

- Chat-Frontend (z. B. in deiner bestehenden LLM-Umgebung).  
- Anbindung an:
  - `/query` (Retriever),
  - MCP-Tools (WP-13),
  - Import-/Export-Routinen.  
- Funktionen:
  - Antworten aus mindnet-Wissen,  
  - Vorschlag neuer Notes/Edges,  
  - optionales Schreiben ins Vault (Markdown-Erzeugung, Rewriting nur mit Freigabe).  

**Aufwand / Komplexität:**  
- Aufwand: Hoch  
- Komplexität: Hoch  

**DoD (Zielbild):**  

- Du kannst im Chat:
  - Fragen an dein Wissensnetz stellen,  
  - neue Gedanken/Erinnerungen erfassen,  
  - Vorschläge für Ablage & Vernetzung als Markdown-Notizen erhalten.  

---

### WP-11 – Knowledge-Builder & Vernetzungs-Assistent (geplant)

**Phase:** D  
**Status:** 🟡 geplant  

**Ziel:**  
Assistent, der manuell erstellte oder importierte Notizen analysiert und Vorschläge für Typen, Edges und Einordnung macht.  

**Umfang:**  

- Analyse neuer/aktualisierter Notes:
  - mögliche Typen,
  - passende Tags,
  - potenzielle Relationen zu bestehenden Notes.  
- Vorschläge:
  - Inline-Relationen,  
  - Wikilinks,  
  - Typ-Zuweisung.  
- Optional: Generierung konkreter Patch-Vorschläge für Markdown-Dateien (Diff-basiert).  

**Aufwand / Komplexität:**  
- Aufwand: Hoch  
- Komplexität: Hoch  

**DoD (Zielbild):**  

- Mindestens ein produktionsnaher Workflow, bei dem ein neuer Eintrag:
  - erstellt wird,  
  - analysiert wird,  
  - Vernetzungs-Vorschläge liefert,  
  - und nach Freigabe in den Vault zurückgeschrieben wird.  

---

### WP-12 – Knowledge Rewriter (Soft Mode, geplant)

**Phase:** C/D  
**Status:** 🟡 geplant  

**Ziel:**  
Optionaler Assistent, der vorhandene Notes „aufräumt“, zusammenfasst oder reorganisiert – ausschließlich mit expliziter Freigabe. :contentReference[oaicite:31]{index=31}  

**Einschränkungen:**  

- Änderungen an Markdown-Dateien nur nach Freigabe.  
- Kein „silent overwrite“ existierender Inhalte.  

**Aufwand / Komplexität:**  
- Aufwand: Niedrig/Mittel  
- Komplexität: Mittel  

**DoD (Zielbild):**  

- Rewriter generiert Vorschläge (neue Versionen) inklusive Diffs.  
- Nach Freigabe werden Notes konsistent aktualisiert:
  - IDs, Edges und Typen bleiben konsistent oder werden sauber mitaktualisiert.  

---

### WP-13 – MCP-Integration & Agenten-Layer (geplant)

**Phase:** D  
**Status:** 🟡 geplant  

**Ziel:**  
mindnet als MCP-Server bereitstellen, damit Agenten/LLMs standardisierte Tools nutzen können (z. B. in deiner n8n- und LLM-Umgebung).   

**Umfang:**  

- MCP-Server mit Tools wie:
  - `mindnet_query`,
  - `mindnet_subgraph`,
  - `mindnet_store_note`,
  - `mindnet_explain`.  
- Sichere Konfiguration (lokal, authentifiziert, logging-fähig).  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Mittel  

**DoD (Zielbild):**  

- Lokaler MCP-Server läuft und ist aus einem LLM-Client nutzbar.  
- Tools liefern konsistente Ergebnisse (aligned mit FastAPI-Endpoints).  
- Sicherheits- und Loggingkonzept dokumentiert.  

---

### WP-14 – Review / Refactoring / Dokumentation (geplant)

**Phase:** E  
**Status:** 🟡 geplant  

**Ziel:**  
Aufräumen, dokumentieren, stabilisieren – insbesondere für Onboarding Dritter und Langfrist-Betrieb.   

**Deliverables (Beispiele):**  

- konsolidierte technische Architektur (`mindnet_technical_architecture.md`),  
- fachliche Architektur (`mindnet_functional_architecture.md`),  
- Identity-Modell (`identity_model.md`),  
- API-Spezifikation (`api_spec.md`),  
- MCP-Integration (`mcp_integration.md`),  
- aktualisiertes Handbuch (`Handbuch.md`).  

**Aufwand / Komplexität:**  
- Aufwand: Mittel  
- Komplexität: Niedrig/Mittel  

**DoD (Zielbild):**  

- Aktueller Stand ist sauber dokumentiert.  
- Wichtige Designentscheidungen sind nachvollziehbar festgehalten.  
- Onboarding einer dritten Person (z. B. Entwickler:in) ist mit Dokumentation möglich.  

---

## 7. Abhängigkeiten (vereinfacht, aktualisiert)

    WP01 → WP02 → WP03 → WP04a
    WP04a → WP04b → WP04c → WP08
    WP03 → WP05 → WP06 → WP07
    WP03 → WP09
    WP01/WP03 → WP10 → WP11 → WP12
    WP03/WP04 → WP13
    Alles → WP14   

Diese Struktur bleibt gegenüber v2.1 unverändert, ist aber jetzt explizit an den bereits implementierten Stand (WP-03, WP-04a) angepasst.

---

## 8. Laufzeit- & Komplexitätsindikatoren (unverändert, ergänzt)

| WP    | Aufwand        | Komplexität      |
|-------|----------------|------------------|
| WP04b | Mittel         | Hoch             |
| WP04c | Mittel         | Mittel/Hoch      |
| WP05  | Mittel         | Mittel           |
| WP06  | Mittel         | Hoch             |
| WP07  | Niedrig/Mittel | Mittel           |
| WP08  | Hoch           | Hoch             |
| WP09  | Mittel         | Niedrig/Mittel   |
| WP10  | Hoch           | Hoch             |
| WP11  | Hoch           | Hoch             |
| WP12  | Niedrig/Mittel | Mittel           |
| WP13  | Mittel         | Mittel           |
| WP14  | Mittel         | Niedrig/Mittel   | :contentReference[oaicite:35]{index=35}  

Für WP01–WP04a gilt: Aufwand/Komplexität wie in v2.1; Status jetzt explizit „abgeschlossen“ mit beschriebenem Funktionsumfang.

---

## 9. Programmfortschritt (Ampel, aktualisiert)

| WP    | Status |
|-------|--------|
| WP01  | 🟢     |
| WP02  | 🟢     |
| WP03  | 🟢     |
| WP04a | 🟢     |
| WP04b | 🟡     |
| WP04c | 🟡     |
| WP05  | 🟡     |
| WP06  | 🟡     |
| WP07  | 🟡     |
| WP08  | 🟡     |
| WP09  | 🟡     |
| WP10  | 🟡     |
| WP11  | 🟡     |
| WP12  | 🟡     |
| WP13  | 🟡     |
| WP14  | 🟡     | :contentReference[oaicite:36]{index=36}  

---

## 10. Governance & Versionierung

- Versionierung über Gitea (Branches, Tags, Releases).  
- Jede wesentliche Änderung an Architektur/Schema:
  - eigener Commit,
  - kurze Doku (z. B. in `CHANGELOG.md` oder Projekt-Notiz).  
- Jedes Workpackage erhält ein eigenes Chat-Fenster mit dediziertem Prompt (WP-Hand-Over).   
- Programmleitung verantwortet:
  - Konsistenz von Fach- und Technikdokumenten,  
  - Abhängigkeiten und Priorisierung,  
  - Freigabe von Meilensteinen,  
  - Sicherstellung, dass Änderungen mit dem langfristigen Ziel (KI-Zwilling) vereinbar sind.  

---

## 11. Executive Summary (unverändert, präzisiert)

mindnet v2.2 ist so aufgesetzt, dass:

- du **schrittweise** Wissen erfassen kannst (Obsidian + Chat + später Interview-Assistent),  
- die Struktur **mitwächst**, ohne Retro-Massenarbeit im Vault,  
- ein **hybrider Retriever** qualitativ hochwertige, erklärbare Antworten liefert,  
- ein **Self-Healing- und Self-Tuning-Mechanismus** vorbereitet ist, der auf Feedback aufsetzt,  
- ein **Persönlichkeitsmodell** und eine **Decision Engine** entstehen,  
- langfristig ein **KI-Zwilling** aufgebaut wird, der deine Werte, Erfahrungen und Denkweise spiegelt,  
- die technische Architektur (FastAPI, Qdrant, YAML-Policies, MCP-Integration) lokal, nachvollziehbar und erweiterbar bleibt.   

Dieser Programmplan bildet die konsolidierte Grundlage (v2.2) für alle weiteren Arbeiten.  
Er integriert die bisherigen Ergebnisse (WP-01 bis WP-04a) und die zusätzlichen Anforderungen aus der späteren Planung (Feedback-basiertes Tuning, wachsendes System, Chat-/Interview-Eingabe, Vault-Writeback) in ein einheitliches, versionierbares Dokument.