mindnet/Programmmanagement/Programmplan_V2.1

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

---