mindnet/Programmmanagement/Programmplan_V2.2.md

mindnet v2.2 — Programmplan

Version: 2.2
Stand: 2025-12-06
Status: Aktiv (Fortschreibung von v2.1)

---

1. Programmauftrag

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

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

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

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

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

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

---

2. Vision

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

Kernprinzipien der Vision:

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

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

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

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

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

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

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

---

3. Programmziele

3.1 Kurzfristig (nächste Monate)

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

3.2 Mittelfristig

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

3.3 Langfristig

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

---

4. Architekturprinzipien

Die folgenden Prinzipien steuern alle Workpackages und Entscheidungen:

1. Late Binding (späte Semantik)

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

2. Virtual Schema Layer

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

3. Self-Healing Graph

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

4. Deterministische IDs

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

5. Full Explainability

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

6. Persistence First

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

7. Minimalinvasives Schreiben

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

8. Incremental Growth & Early Value

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

9. Observability & Testbarkeit

   • Jeder Importlauf, jede Retriever-Anfrage und jede Policy-Änderung soll prüfbar sein (Logs, Traces, Tests, Reports).

---

5. Programmstruktur (Phasenmodell)

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

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

---

6. Workpackages – detaillierte Übersicht

Legende Aufwand / Komplexität

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

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

---

WP-01 – Wissensdesign (abgeschlossen)

Phase: A
Status: 🟢 abgeschlossen

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

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Mittel

Erreichte Ergebnisse / Funktionsumfang:

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

DoD:

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

---

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

Phase: A
Status: 🟢 abgeschlossen

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

Umfang (fachlich & technisch):

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Mittel/Hoch

Erreichte Ergebnisse / Funktionsumfang:

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

DoD:

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

---

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

Phase: A/B
Status: 🟢 abgeschlossen

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Hoch
• Komplexität: Hoch

Erreichte Ergebnisse / Funktionsumfang:

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

DoD:

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

---

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

Phase: B
Status: 🟢 abgeschlossen

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Hoch
• Komplexität: Hoch

Erreichte Ergebnisse / Funktionsumfang:

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

DoD:

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

---

WP-04b – Explanation Layer (geplant)

Phase: B
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Hoch

DoD (Zielbild):

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

---

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

Phase: B
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Mittel/Hoch

DoD (Zielbild):

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

---

WP-05 – Persönlichkeitsmodell (geplant)

Phase: C
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Mittel

DoD (Zielbild):

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

---

WP-06 – Decision Engine (geplant)

Phase: C
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Hoch

DoD (Zielbild):

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

---

WP-07 – Interview-Assistent (geplant)

Phase: C
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Niedrig/Mittel
• Komplexität: Mittel

DoD (Zielbild):

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

---

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

Phase: B/C
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Hoch
• Komplexität: Hoch

DoD (Zielbild):

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

---

WP-09 – Vault-Onboarding & Migration (geplant)

Phase: B
Status: 🟡 geplant

Ziel:
Sicherstellen, dass bestehende und neue Obsidian-Vaults schrittweise in mindnet integriert werden können – ohne Massenumbau.

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Niedrig/Mittel

DoD (Zielbild):

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

---

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

Phase: D
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Hoch
• Komplexität: Hoch

DoD (Zielbild):

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

---

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

Phase: D
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Hoch
• Komplexität: Hoch

DoD (Zielbild):

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

---

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

Phase: C/D
Status: 🟡 geplant

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

Einschränkungen:

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

Aufwand / Komplexität:

• Aufwand: Niedrig/Mittel
• Komplexität: Mittel

DoD (Zielbild):

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

---

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

Phase: D
Status: 🟡 geplant

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

Umfang:

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Mittel

DoD (Zielbild):

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

---

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

Phase: E
Status: 🟡 geplant

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

Deliverables (Beispiele):

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

Aufwand / Komplexität:

• Aufwand: Mittel
• Komplexität: Niedrig/Mittel

DoD (Zielbild):

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

---

7. Abhängigkeiten (vereinfacht, aktualisiert)

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

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

---

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

WP	Aufwand	Komplexität
WP04b	Mittel	Hoch
WP04c	Mittel	Mittel/Hoch
WP05	Mittel	Mittel
WP06	Mittel	Hoch
WP07	Niedrig/Mittel	Mittel
WP08	Hoch	Hoch
WP09	Mittel	Niedrig/Mittel
WP10	Hoch	Hoch
WP11	Hoch	Hoch
WP12	Niedrig/Mittel	Mittel
WP13	Mittel	Mittel
WP14	Mittel	Niedrig/Mittel

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	🟡

---

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.