Programmmanagement/Programmplan_V2.2.md aktualisiert
All checks were successful
Deploy mindnet to llm-node / deploy (push) Successful in 4s
All checks were successful
Deploy mindnet to llm-node / deploy (push) Successful in 4s
This commit is contained in:
parent
ba0cdea9d0
commit
70ab118612
|
|
@ -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.
|
|
||||||
|
|
||||||
---
|
|
||||||
772
Programmmanagement/Programmplan_V2.2.md
Normal file
772
Programmmanagement/Programmplan_V2.2.md
Normal file
|
|
@ -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 Änderungserkennung.
|
||||||
|
|
||||||
|
**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 Änderungserkennung (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 Änderungserkennung 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.
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user