Lars
ba0cdea9d0
All checks were successful
Deploy mindnet to llm-node / deploy (push) Successful in 3s
707 lines
19 KiB
Markdown
707 lines
19 KiB
Markdown
# 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.
|
||
|
||
---
|