diff --git a/Programmmanagement/Programmplan_V2.1.md b/Programmmanagement/Programmplan_V2.1.md
deleted file mode 100644
index 5cd654b..0000000
--- a/Programmmanagement/Programmplan_V2.1.md
+++ /dev/null
@@ -1,706 +0,0 @@
-# mindnet v2.1 — Programmplan  
-**Version:** 2.1  
-**Stand:** 2025-12-05  
-**Status:** Aktiv  
-
----
-
-## 1. Programmauftrag
-
-mindnet v2.1 entwickelt ein persönliches, wachsendes KI-Gedächtnis, das:
-
-- Wissen, Erfahrungen, Werte und Entscheidungen speichert,
-- semantisch verknüpft und rekonstruiert,
-- einen KI-Zwilling aufbaut, der wie du argumentiert, entscheidet und reflektiert,
-- über Chat, Obsidian und zukünftige Interview-Assistenten gefüttert wird,
-- automatisch neue Zusammenhänge erkennt und vernetzt,
-- sich durch Rückmeldungen selbst verbessert (Self-Tuning).
-
-Das System soll langfristig als **digitales Gegenüber** funktionieren, das:
-
-- dich versteht,
-- deine Denkweise reflektiert,
-- deine Werte kennt,
-- Entscheidungen begründen kann,
-- Erinnerungen einordnet,
-- für Nachkommen eine Art digitaler Dialogpartner wird.
-
-mindnet ist **kein statisches Wissensarchiv**, sondern ein **lebendes, lernendes Gedächtnismodell**.
-
----
-
-## 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:
-
-- **Erklärbarkeit:** Jede Antwort muss begründbar sein (Edges, Scores, Wertebezüge).
-- **Wachstum:** Das System muss mit unvollständigen Daten arbeiten können.
-- **Flexibilität:** Spätere Strukturänderungen dürfen nie Massenarbeit erfordern.
-- **Autonomie:** mindnet ergänzt fehlende Links, Typen und Relationen selbst.
-- **Lernen:** Feedback führt zu Justierungen im Verhalten und den Wissensstrukturen.
-- **Persönlichkeit:** Entscheidungen werden wert- und erfahrungsbasiert begründet.
-
----
-
-## 3. Programmziele
-
-### 3.1 Kurzfristig (nächste Monate)
-
-- Automatische Sammlung von Wissen aus Markdown und Chat.
-- Aufbau eines soliden Graph-Speichers.
-- Semantischer und graphbasierter Retriever (WP-04).
-- Automatisierte Erkennung von Beziehungen.
-- Schrittweises Lernen über Feedback (Score-Tuning).
-- „Mitwachsendes“ Schema ohne Obsidian-Umstrukturierungen.
-- Technische Basis für den KI-Zwilling.
-
-### 3.2 Mittelfristig
-
-- Persönlichkeitsprofil wird stabil erkannt und genutzt.
-- KI-Assistenz für Entscheidungen (Why-Layer).
-- Interview-Assistent erstellt neue Notes automatisch.
-- mindnet erzeugt selbst Vorschläge für neue Notes & Edges.
-- Agenten können über MCP mit mindnet kommunizieren.
-
-### 3.3 Langfristig
-
-- KI-Zwilling, der langfristig deinen Stil, deine Werte und deine typische Denkweise repräsentiert.
-- Voll autonomes Self-Tuning der Wissensstruktur.
-- Lebenslanges Gedächtnis, das
-  - konsistent bleibt,
-  - wächst,
-  - sich weiterentwickelt,
-  - und deine Geschichte für deine Nachkommen erzählbar macht.
-
----
-
-## 4. Architekturprinzipien
-
-1. **Late Binding (späte Semantik)**  
-   Struktur und Interpretation werden möglichst spät (im Schema-/Config-Layer) festgelegt, nicht hart in Markdown-Dateien eingraviert.
-
-2. **Virtual Schema Layer**  
-   Typen, Regeln und semantische Felder liegen in Konfigurationsdateien (z. B. `types.yaml`, `knowledge_design.md`) und nicht zwingend in jeder einzelnen Note.
-
-3. **Self-Healing Graph**  
-   Der Graph wird regelmäßig analysiert und um fehlende Kanten ergänzt (ähnliche Inhalte, typisierte Beziehungen, Backlinks).
-
-4. **Deterministische IDs**  
-   Notes, Chunks und Edges nutzen stabile IDs (z. B. UUIDv5), damit der Graph wiederaufbaubar bleibt.
-
-5. **Full Explainability**  
-   Jeder Score, jede Beziehung, jeder Vorschlag muss über Edges, Pfade und Scoring-Komponenten nachvollziehbar sein.
-
-6. **Persistence First**  
-   Obsidian bleibt die bevorzugte Quelle der Wahrheit. mindnet ergänzt und schlägt Änderungen vor, überschreibt aber nicht unkontrolliert.
-
-7. **Minimalinvasives Schreiben**  
-   Ein späterer Rewriter darf Markdown-Dateien nur nach expliziter Zustimmung verändern.
-
-8. **Incremental Growth**  
-   Das System muss mit wenigen, unvollständigen Notizen starten und sich schrittweise verdichten können, ohne manuelle Massenmigrationen auszulösen.
-
----
-
-## 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 (WP) sind diesen Phasen zugeordnet.
-
----
-
-## 6. Workpackages – Übersicht
-
-### Legende Aufwand / Komplexität
-
-- Aufwand: Niedrig / Mittel / Hoch
-- Komplexität: Niedrig / Mittel / Hoch
-
----
-
-### 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.).
-- Standardfelder (Titel, Typ, Tags, Status, Zeitstempel, Referenzen).
-- Grundstruktur von Edges (belongs_to, references, depends_on, similar_to, etc.).
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Mittel  
-
-**Deliverables:**
-
-- `knowledge_design.md v0.1` (liegt vor).
-
-**DoD (Definition of Done):**
-
-- Note-Typen sind definiert und verständlich.
-- Edge-Arten sind beschrieben.
-- Dokument ist konsistent und anschlussfähig für Parser, Importer und Retriever.
-
----
-
-### WP-02 – Chunking Strategy (abgeschlossen)
-
-**Phase:** A  
-**Status:** 🟢 abgeschlossen  
-**Ziel:**  
-Regeln für Textsegmentierung, Overlaps und Fensterlogik definieren (`chunking_strategy.md`).
-
-**Inhalte:**
-
-- `text` (Chunk-Kern ohne Overlap).
-- `window` (Chunk + linker Kontext).
-- Overlap-Regeln (~30–40 Zeichen im Mittel).
-- Stabiler Bezug zwischen Chunks und ursprünglicher Note/Position.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Mittel  
-
-**Deliverables:**
-
-- `chunking_strategy.md v0.1`.
-
-**DoD:**
-
-- Strategy-Dokument vorhanden und konsistent.
-- Messwerte (Overlap, Textanteil) ermittelt.
-- Tests zur Überprüfung der Chunk-Integrität vorhanden.
-
----
-
-### WP-03 – Importer + Edge-Erzeugung (abgeschlossen)
-
-**Phase:** A  
-**Status:** 🟢 abgeschlossen  
-
-**Ziel:**  
-Robuster, idempotenter Importer, der Obsidian-Markdown-Dateien als:
-
-- Notes (mit Payload),
-- Chunks (mit Embeddings-Fenster),
-- Edges (verschiedene Typen)
-
-in Qdrant überführt.
-
-**Kernfunktionen:**
-
-- Parser mit Encoding-Fallback (UTF-8 → cp1252 → latin-1).
-- Erkennung von YAML-Frontmatter + Body.
-- Auslassung von speziellen Dateien (`CONFIG.md`, `index.md`, etc., je nach Regel).
-- Hash-basierte Idempotenz (verschiedene Modi).
-- Chunking gemäß `chunking_strategy.md`.
-- Edge-Ableitung aus:
-  - Wikilinks: `[[Note]]` → `references`.
-  - Inline-Relationen: `[[rel:depends_on XYZ]]`.
-  - Callout-Edges: z. B. `> [!edge] related_to: [[ABC]]`.
-  - Typbasierten Defaults aus `types.yaml`.
-  - Strukturkanten: `belongs_to`, `next`, `prev`.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Hoch  
-- Komplexität: Hoch  
-
-**Deliverables (Beispiele):**
-
-- `import_markdown.py`
-- `chunk_payload.py`
-- `derive_edges.py`
-- Testskripte (`verify_chunks_integrity.py`, `compare_vaults.py`, etc.).
-- Handbuch zum Import-Prozess.
-
-**DoD:**
-
-- Vollständiger Roundtrip-Test (Vault → Qdrant → Export → Vergleich) grün.
-- Edges werden deterministisch erzeugt.
-- Notes/Chunks/Edges folgen dem festgelegten Schema.
-- Alte Fehler (nur eine Note in Qdrant etc.) sind behoben.
-
----
-
-### WP-04 – Retriever & Scoring
-
-**Phase:** B  
-
-#### WP-04a – Hybrider Retriever (abgeschlossen)
-
-**Status:** 🟢 abgeschlossen  
-
-**Ziel:**  
-Hybrides Scoring-Modell, das:
-
-- Embedding-Ähnlichkeit,
-- Typwissen (`retriever_weight`),
-- Edge-Information (Nachbarschaft, Edge-Konfidenz),
-- ggf. Centrality-Metriken
-
-zu einem erklärbaren Gesamtscore kombiniert.
-
-**Deliverables:**
-
-- `retriever.yaml` (Konfiguration).
-- API-Endpunkt `/query` (FastAPI).
-- Scoring-Logik mit detaillierten Komponenten.
-
-**DoD:**
-
-- `/query` liefert Ergebnisse mit:
-  - Hauptscore,
-  - Zerlegung nach Komponenten (semantik / edges / centrality),
-  - Referenzpfaden und Metadaten.
-- Tests für typische Anfragen grün.
-
----
-
-#### WP-04b – Explanation Layer (offen)
-
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Antworten und Treffer so erklären, dass du nachvollziehen kannst:
-
-- Warum genau diese Chunks/Notes?
-- Welche Edges führten dorthin?
-- Welche Typen, Scores, Pfade waren entscheidend?
-
-**Umfang:**
-
-- „Top-K-Pfade“ vom Query-Embedding zu den relevanten Notes.
-- Darstellung: Edgeliste + Labels + Gewichte.
-- Menschlich lesbare „Why“-Erklärung pro Treffer.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Hoch  
-
-**DoD:**
-
-- Jede Antwort des Retrievers kann über eine API erklärt werden.
-- Erklärungen sind stabil, nachvollziehbar und nutzen Edges + Scores.
-- Tests mit Beispielqueries dokumentiert.
-
----
-
-#### WP-04c – Feedback Logging (offen)
-
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Grundlage für Self-Tuning schaffen, indem Queries, Antworten und Feedback gespeichert werden.
-
-**Umfang:**
-
-- Logging von:
-  - Query-Text,
-  - Retriever-Konfiguration (Snapshot),
-  - Resultlisten + Scores,
-  - optional Benutzer-Feedback (z. B. „gut“, „daneben“),
-  - Kontext (Session-ID, Zeitpunkt).
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Mittel/Hoch  
-
-**DoD:**
-
-- Strukturierte Logs (z. B. JSONL, DB-Collection).
-- Klar definierte Felder für Tuning späterer Retriever-Versionen.
-- Export-Funktion für Trainings-/Analysezwecke.
-
----
-
-### WP-05 – Virtual Schema Layer (neu)
-
-**Phase:** B  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Sicherstellen, dass du **nicht** hunderte von Markdown-Dateien neu anfassen musst, wenn neue Felder oder Typen eingeführt werden.
-
-**Idee:**
-
-- Notes können unvollständig oder inkonsistent sein.
-- Das „logische“ Schema liegt in:
-  - `types.yaml`,
-  - `knowledge_design.md`,
-  - weiteren Konfigurationsdateien.
-- Qdrant-Payload kann Felder ergänzen, die in der Datei nicht explizit stehen.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Mittel  
-
-**DoD:**
-
-- Alle Notes lassen sich ohne Fehler importieren, auch wenn Felder fehlen.
-- Neue Schemafelder können ausschließlich über Config eingeführt werden.
-- Qdrant-Payload spiegelt das „virtuelle Schema“, ohne die Markdown-Datei zu verändern.
-- Abfragen können auf virtuelle Felder zugreifen.
-
----
-
-### WP-06 – Self-Healing Graph (neu)
-
-**Phase:** B  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Der Graph wird regelmäßig analysiert und automatisch verbessert.
-
-**Funktionen (Beispiele):**
-
-- Erkennung von isolierten Notes/Chunks (ohne Edges).
-- Vorschlag oder automatische Anlage von:
-  - `similar_to`,
-  - `related_to`,
-  - `belongs_to` (z. B. zu Projekten, Leitbild, Rollen).
-- Verwendung von Typwissen, Embeddings und Strukturmustern.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Hoch  
-
-**DoD:**
-
-- Selbstdiagnose des Graphen (Report).
-- Optionale auto-fix-Funktionen (mit Sicherheitsregeln).
-- Self-Healing läuft inkrementell und zerstört keine bestehende Struktur.
-
----
-
-### WP-07 – Retroactive Edge Generation (neu)
-
-**Phase:** B  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Wenn dein Wissensstand wächst (z. B. Leitbild später ergänzt, neue Wertedefinitionen), sollen alte Notes automatisch mit neuen Kanten angereichert werden.
-
-**Umfang:**
-
-- Clustering und Ähnlichkeitsanalyse über existierende Notes.
-- Erzeugung von:
-  - `similar_to`,
-  - thematischen `related_to`,
-  - „Wertebezügen“ (z. B. Note ↔ Wert/Prinzip).
-
-**Aufwand / Komplexität:**  
-- Aufwand: Niedrig/Mittel  
-- Komplexität: Mittel  
-
-**DoD:**
-
-- Batch-Job(s) zur nachträglichen Edgenerierung.
-- Stabilität der entstehenden Kanten (keine Dubletten-Flut).
-- Kein Zwang, die ursprünglichen Markdown-Dateien zu editieren.
-
----
-
-### WP-08 – Self-Tuning (Retriever Lernen)
-
-**Phase:** B  
-**Status:** 🟡 geplant  
-
-#### v1 – Offline Tuning
-
-**Ziel:**  
-Anhand der geloggten Queries/Feedbacks das Scoring verbessern.
-
-**Umfang:**
-
-- Analyse von:
-  - Queries + Label („gut/schlecht“),
-  - Top-k-Treffern,
-  - genutzten Scores.
-- Anpassung von:
-  - `semantic_weight`,
-  - `edge_weight`,
-  - weights einzelner Edge-Typen,
-  - Typprioritäten.
-
-**DoD:**
-
-- Neue Retriever-Konfigurationen auf Basis von Logdaten.
-- Vergleichsmetriken, die zeigen, dass die Qualität steigt.
-
-#### v2 – Semi-automatischer Optimierer
-
-**Ziel:**  
-Ein Agent, der konkrete Konfigurationsvorschläge macht.
-
-**DoD:**
-
-- Vorschlagsmodus (nicht direkt produktiv).
-- Human-in-the-loop Freigabe.
-- Sicherungsmechanismen (Rollback, Versionierung der Configs).
-
----
-
-### WP-09 – Chat→Vault & Interview-Assistent
-
-**Phase:** B/C  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Ermöglichen, dass du Wissen direkt im Chat erfassen kannst, ohne selbst Markdown zu schreiben.
-
-**Umfang:**
-
-- API/Workflow:
-  - Chattext → Note (mit Typ, Tags, Metadaten).
-  - Chunking & Edges wie bei Obsidian-Notes.
-- Optional:
-  - Rückschreiben als `.md` in deinen Obsidian-Vault.
-- Später:
-  - Interview-Assistent, der strukturierte Fragen stellt und daraus Notes/Edges erzeugt.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Niedrig/Mittel  
-
-**DoD:**
-
-- Chat-basiertes Erzeugen von Notes voll integriert.
-- Optionaler Export nach Obsidian funktional.
-- Keine Brüche in der IDs/Edge-Logik.
-
----
-
-### WP-10 – Persönlichkeitsmodell (Identity Layer)
-
-**Phase:** C  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Deine Werte, Prinzipien, Zielbilder, biografischen Ankerpunkte und typischen Entscheidungsweisen werden in ein konsistentes Modell integriert.
-
-**Umfang:**
-
-- Extraktion aus:
-  - Leitbild-Notes,
-  - Werte- und Prinzipien-Assessments,
-  - Entscheidungen und deren Begründungen.
-- Repräsentation:
-  - Eigene Note/Typen (z. B. `identity_profile`, `value`, `principle`, `role`).
-  - Edges zwischen Identitätskern und konkreten Erfahrungen/Entscheidungen.
-- Nutzung im Retriever und in der Entscheidungsschicht.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Hoch  
-- Komplexität: Hoch  
-
-**DoD:**
-
-- Klar definierter Identity-Core im Graphen.
-- Abfragen können explizit „aus deiner Perspektive“ beantwortet werden.
-- Erste einfache Identity-Evaluationsszenarien (z. B. „passt diese Option zu meinen Werten X/Y?“).
-
----
-
-### WP-11 – Decision Engine
-
-**Phase:** C  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Begründete, konsistente Entscheidungen auf Basis deiner Daten, Werte und Präferenzen.
-
-**Umfang:**
-
-- Entscheidungs-Pipelines:
-  - Faktenlage zusammenstellen (Retriever).
-  - Werte/Prinzipien interpretieren.
-  - Alternativen generieren.
-  - Abwägungen begründen.
-- „Warum?“-Layer: jedes Urteil soll begründet sein.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Hoch  
-- Komplexität: Hoch  
-
-**DoD:**
-
-- Mindestens einige exemplarische Entscheidungsfälle (z. B. Trainingsplanung, Projektpriorisierung, Investitionsentscheidungen), die konsistent und erklärbar durchlaufen werden können.
-
----
-
-### WP-12 – Knowledge Rewriter (Soft Mode)
-
-**Phase:** C  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Optionaler Assistent, der vorhandene Notes „aufräumt“, zusammenfasst oder reorganisiert.
-
-**Einschränkung:**
-
-- Änderungen dürfen **nur** nach expliziter Freigabe erfolgen.
-- Kein „still und leise überschreiben“.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Niedrig/Mittel  
-- Komplexität: Mittel  
-
-**DoD:**
-
-- Vorschlagsmodus:
-  - Rewriter generiert Vorschlag (neue Version).
-  - Diff sichtbar.
-  - Manueller Merge / Freigabe.
-- Nach Freigabe:
-  - konsistente IDs/Edges bleiben erhalten oder werden aktualisiert.
-
----
-
-### WP-13 – MCP Integration & Agenten-Layer
-
-**Phase:** D  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-mindnet als MCP-Server bereitstellen, damit Agenten/LLMs über standardisierte Tools darauf zugreifen.
-
-**Umfang:**
-
-- MCP-Server mit Tools wie:
-  - `mindnet_query`,
-  - `mindnet_subgraph`,
-  - `mindnet_store_note`,
-  - `mindnet_explain`.
-- Integration in deine bestehende n8n-/LLM-Umgebung.
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Mittel  
-
-**DoD:**
-
-- Lokaler MCP-Server läuft.
-- Tools können aus einem LLM/Client heraus genutzt werden.
-- Sicherheits- und Loggingkonzept aufgesetzt.
-
----
-
-### WP-14 – Review / Refactoring / Dokumentation
-
-**Phase:** E  
-**Status:** 🟡 geplant  
-
-**Ziel:**  
-Aufräumen, dokumentieren, stabilisieren.
-
-**Deliverables (Beispiele):**
-
-- `tech_architecture.md`
-- `identity_model.md`
-- `api_spec.md`
-- `mcp_integration.md`
-- konsolidiertes Handbuch für mindnet v2.x
-
-**Aufwand / Komplexität:**  
-- Aufwand: Mittel  
-- Komplexität: Niedrig/Mittel  
-
-**DoD:**
-
-- Aktueller Stand ist sauber dokumentiert.
-- Wichtige Designentscheidungen sind festgehalten.
-- Onboarding eines Dritten wäre mit dieser Dokumentation möglich.
-
----
-
-## 7. Abhängigkeiten (vereinfacht)
-
-    WP01 → WP02 → WP03 → WP04a
-    WP04a → WP04b → WP04c → WP08
-    WP03 → WP05 → WP06 → WP07
-    WP03 → WP09
-    WP01/WP03 → WP10 → WP11 → WP12
-    WP03/WP04 → WP13
-    Alles → WP14
-
----
-
-## 8. Laufzeit- & Komplexitätsindikatoren
-
-| 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 |
-
----
-
-## 9. Programmfortschritt (Ampel)
-
-| WP    | Status |
-|-------|--------|
-| WP01  | 🟢     |
-| WP02  | 🟢     |
-| WP03  | 🟢     |
-| WP04a | 🟢     |
-| WP04b | 🟡     |
-| WP04c | 🟡     |
-| WP05  | 🟡     |
-| WP06  | 🟡     |
-| WP07  | 🟡     |
-| WP08  | 🟡     |
-| WP09  | 🟡     |
-| WP10  | 🟡     |
-| WP11  | 🟡     |
-| WP12  | 🟡     |
-| WP13  | 🟡     |
-| WP14  | 🟡     |
-
----
-
-## 10. Governance
-
-- Versionierung über Gitea (Branches, Tags, Releases).
-- Jede wesentliche Änderung an Architektur/Schema: eigener Commit + kurze Notiz.
-- Jeder WP bekommt ein eigenes Chatfenster mit dediziertem Prompt.
-- Programmleitung verantwortet:
-  - Konsistenz,
-  - Abhängigkeiten,
-  - Priorisierung,
-  - Dokumentation,
-  - Freigabe von Meilensteinen.
-
----
-
-## 11. Executive Summary
-
-mindnet v2.1 ist als Programm so aufgesetzt, dass:
-
-- du **schrittweise** Wissen erfassen kannst (Obsidian + Chat),
-- die Struktur **mitwächst**, ohne Retro-Massenarbeit,
-- ein **hybrider Retriever** qualitativ hochwertige, erklärbare Antworten liefert,
-- ein **Self-Healing- und Self-Tuning-Mechanismus** vorbereitet ist,
-- ein **Persönlichkeitsmodell** und eine **Decision Engine** aufgebaut werden,
-- langfristig ein **KI-Zwilling** entsteht, der deine Werte, Erfahrungen und Denkweise spiegelt.
-
-Dieser Plan ist bewusst **inkrementell** angelegt, sodass du jederzeit starten, pausieren, erweitern kannst – ohne deine bestehenden Obsidian-Daten zerstören oder massiv umbauen zu müssen.
-
----
diff --git a/Programmmanagement/Programmplan_V2.2.md b/Programmmanagement/Programmplan_V2.2.md
new file mode 100644
index 0000000..3069e20
--- /dev/null
+++ b/Programmmanagement/Programmplan_V2.2.md
@@ -0,0 +1,772 @@
+# 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.
+