mindnet/docs/99_Archive/alte_Versionen/Programmplan_V2.2.md
Lars 620858a575
All checks were successful
Deploy mindnet to llm-node / deploy (push) Successful in 4s
neue Dokumentationstruktur - (QS geprüft)
2025-12-13 18:38:37 +01:00

27 KiB
Raw Blame History

mindnet v2.4 — Programmplan

Version: 2.7.0 (Post-WP15: Roadmap Erweiterung für Graph-Health & Visualisierung) Stand: 2025-12-12 Status: Aktiv



1. Programmauftrag

mindnet v2.4 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 (Decision Engine & RAG-Chat aktiv),
    • Interview-Assistent (One-Shot Extraction aktiv),
    • Draft Editor (Active Intelligence aktiv),
  • 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 (Why-Layer),
  • 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. Das System kann Entscheidungen auf zugrundeliegende [DECISION]-Notizen zurückführen.

  • 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, prompts.yaml, decision_engine.yaml) festgelegt. Die Persönlichkeit entsteht durch das Config-Design, nicht durch Hardcoding.

  • 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; das System agiert als KI-Zwilling durch Nutzung lokaler LLMs (z.B. Phi-3/Mistral) und eines Intent-Routers.

  • 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 (Abgeschlossen / Laufend)

  • Automatische Sammlung von Wissen aus Markdown-Vault.
  • Aufbau eines stabilen Graph-Speichers in Qdrant (*_notes, *_chunks, *_edges).
  • Semantischer und graphbasierter Retriever (WP-04a abgeschlossen).
  • Erklärbarkeit: Why-Layer liefert Begründungen zu Treffern (WP-04b abgeschlossen).
  • Feedback-Loop: Systematisches Logging von Suche und Bewertung (WP-04c abgeschlossen).
  • RAG-Chat: KI antwortet in natürlicher Sprache auf Basis von Wissen und Persönlichkeit (WP-05 abgeschlossen).
  • Decision Engine: System erkennt Intent (Fakt vs. Entscheidung) und wägt Werte ab (WP-06 abgeschlossen).
  • Multi-Persona: System wechselt den Tonfall (Empathisch vs. Analytisch) situativ (WP-06 abgeschlossen).
  • Chat Interface: Web-basiertes Frontend (Streamlit) für einfache Interaktion und Feedback-Gabe (WP-10 abgeschlossen).
  • Interview-Assistent (WP-07): One-Shot Extraction von Notizen ("Neues Projekt anlegen") ist live.
  • Active Intelligence (WP-11): Automatische Link-Vorschläge (Matrix-Logik) während des Schreibens.
  • Technische Basis: FastAPI (Async), Qdrant (768 Dim), Ollama (Phi-3/Nomic), Streamlit.
  • Automatisierte Erkennung von Beziehungen:
    • Wikilinks, Inline-Relationen, Callout-Edges, Typ-Defaults.
  • „Mitwachsendes“ Schema ohne Obsidian-Umstrukturierungen:
    • Neues Wissen kann sofort erfasst werden,
    • bestehende Notizen bleiben gültig (Virtual Schema Layer).

3.2 Mittelfristig (Nächste Schritte)

  • Self-Tuning (WP-08): Optimierung der Gewichte in retriever.yaml basierend auf dem gesammelten Feedback.
  • Agenten können über MCP-Tools (mindnet_query, mindnet_chat) auf mindnet zugreifen (WP-13).

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, prompts.yaml, decision_engine.yaml) definiert, nicht direkt in den Vault-Dateien.
    • Die "Persönlichkeit" des Chats ist ein Prompt-Template, kein Code.
  2. Virtual Schema Layer

    • Typen, Regeln, Policies, Edge-Defaults werden im Schema-Layer beschrieben.
    • 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.
  4. Deterministische IDs

    • Notes, Chunks und Edges erhalten stabile IDs (z. B. UUIDv5).
    • Der Graph ist jederzeit wiederaufbaubar (Import-Pipeline idempotent).
  5. Full Explainability & Context Enrichment

    • Jeder Score, jede Beziehung muss nachvollziehbar sein.
    • Dem LLM werden Metadaten ([DECISION], [PROJECT]) injiziert, um Halluzinationen zu vermeiden und logische Schlüsse zu ermöglichen.
  6. Persistence First

    • Obsidian bleibt die primäre Quelle der Wahrheit.
    • mindnet ergänzt, schlägt Änderungen vor, schreibt aber nur kontrolliert.
  7. Minimalinvasives Schreiben

    • Automatische Veränderungen an Markdown-Dateien erfolgen ausschließlich nach expliziter Zustimmung.
  8. Incremental Growth & Early Value

    • Das System muss bereits mit wenigen Notizen und einem kleinen Vault sinnvolle Antworten liefern.
    • Feedback-Mechanismen werden früh eingeführt.
  9. Observability & Testbarkeit

    • Jeder Importlauf, jede Retriever-Anfrage und jede Policy-Änderung soll prüfbar sein.
  10. Local First & Privacy

    • Nutzung lokaler LLMs (Ollama) für Inference. Keine Daten verlassen den Server.

5. Programmstruktur (Phasenmodell)

Phase A  Fundament & Import (Fertig)
Phase B  Semantik, Graph & Lernen (Fertig)
Phase C  Persönlichkeitsmodell & KI-Zwilling (Fertig)
Phase D  Agenten, MCP & Interaktion (Aktiv)
Phase E  Maintenance, Visualisierung & Scaling (Neu)

Alle Workpackages sind einer Phase zugeordnet. WP-01 bis WP-07 und WP-10/10a/11 sind erfolgreich abgeschlossen.


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.


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).
  • Standard-Properties und Grundstruktur von Edges.
  • Abbildung zentraler Lebens-Bereiche.

Erreichte Ergebnisse:

  • knowledge_design.md und types.yaml definieren die Zielarchitektur.

WP-02 Chunking & Hash-Strategie (abgeschlossen)

Phase: A Status: 🟢 abgeschlossen

Ziel: Festlegen und implementieren einer robusten Chunking-Strategie und einer Hash-Logik zur Änderungserkennung.

Erreichte Ergebnisse:

  • Implementierte Chunker-Logik mit Overlap.
  • Stabile Hash-Strategie zur sicheren Änderungserkennung.

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.

Erreichte Ergebnisse:

  • Vollständige E2E-Import-Pipeline.
  • Vollständiges Edge-Modell (Strukturkanten, Wikilinks, Inline-Relationen).

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

Phase: B Status: 🟢 abgeschlossen

Ziel: Aufbau eines hybriden Retrievers, der Semantik, Typwissen und Graph-Informationen kombiniert.

Erreichte Ergebnisse:

  • Hybrides Scoring-Modell (Semantic + Edge + Centrality).
  • Konfiguration über retriever.yaml.
  • /query Endpoint aktiv.

WP-04b Explanation Layer ("Why-Layer") (abgeschlossen)

Phase: B Status: 🟢 abgeschlossen

Ziel: Treffererklärungen liefern, die verständlich machen, warum ein Ergebnis gewählt wurde.

Erreichte Ergebnisse:

  • DTO-Erweiterung: QueryHit enthält explanation, breakdown und reason.
  • Logic: Graph-Adapter unterstützt incoming_edges (Reverse Lookup) für Authority-Erklärungen.
  • Output: /query Endpoint liefert auf Wunsch (explain: true) menschenlesbare Begründungen ("Verweist auf...").

WP-04c Feedback Logging & Bewertungsdaten (abgeschlossen)

Phase: B Status: 🟢 abgeschlossen

Ziel: Grundlage für Self-Tuning schaffen durch systematisches Logging.

Erreichte Ergebnisse:

  • Data Flywheel: Logging von Queries und User-Feedback in lokalen JSONL-Dateien.
  • Search Log: Speichert Query + Score-Snapshot in data/logs/search_history.jsonl.
  • Feedback Log: Speichert User-Ratings in data/logs/feedback.jsonl.
  • Traceability: Durchgängige query_id von Request bis Feedback.

WP-05 Persönlichkeitsmodell & RAG-Chat (abgeschlossen)

Phase: C Status: 🟢 abgeschlossen

Ziel: Aufbau eines RAG-Systems, das in natürlicher Sprache antwortet und Kontext versteht.

Erreichte Ergebnisse:

  • Infrastruktur: Integration von Ollama (Phi-3 Mini) in den Service-Layer.
  • Router: /chat Endpoint mit "Hybrid Retrieval Enforcement".
  • Context Enrichment: Injection von Metadaten ([TYPE], [SCORE]) in den Prompt, damit kleine Modelle (SLMs) komplexe Zusammenhänge ("Warum?") verstehen.
  • Config: prompts.yaml steuert System-Prompt und RAG-Template.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Mittel

WP-05b Advanced Chat (Optional)

Phase: C Status: optional

Ziel: Erweiterung des Chats um Gedächtnis (History) und einfache Tools.

Umfang:

  • Implementierung von ChatHistory (vergangene Nachrichten in den Kontext).
  • Einfache Tool-Nutzung (z.B. "Suche in Web").

WP-06 Decision Engine & Hybrid Router (abgeschlossen)

Phase: C Status: 🟢 abgeschlossen

Ziel: Transformation vom reinen Wissens-Abrufer zum strategischen Entscheidungspartner durch Intent-Erkennung.

Erreichte Ergebnisse:

  • Hybrid Intent Router: Kombination aus schnellem Keyword-Matching und intelligentem LLM-Fallback zur Erkennung der Absicht (DECISION, EMPATHY, FACT, CODING).
  • Strategic Retrieval: Gezieltes Nachladen von Werten (value), Zielen (goal) oder Erfahrungen (experience) basierend auf dem Intent.
  • Multi-Persona: Dynamische Anpassung des Tonfalls (Berater vs. Spiegel vs. Techniker) durch prompts.yaml.
  • Late Binding: Vollständige Konfiguration via decision_engine.yaml.
  • Robustheit: Konfigurierbare Timeouts für CPU-Inference.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Hoch

WP-07 Interview-Assistent (abgeschlossen)

Phase: C/D Status: 🟢 abgeschlossen

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

Erreichte Ergebnisse:

  • One-Shot Extractor: Extrahiert Notiz-Inhalte aus einem Prompt.
  • Schema Injection: Typspezifische Pflichtfelder (Late Binding).
  • Draft Generator: Liefert validen Markdown-Codeblock mit status: draft.

Aufwand / Komplexität:

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

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

Phase: B/C Status: 🟡 geplant (Nächster Fokus)

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

Umfang:

  • Auswertung der JSONL-Feedback-Daten.
  • Regel-basierte Anpassungs-Vorschläge für retriever.yaml und Typ-Prioritäten.

Aufwand / Komplexität:

  • Aufwand: Hoch
  • Komplexität: Hoch

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 zur Analyse des Vault-Status.
  • Empfehlungen für minimale Anpassungen.

Aufwand / Komplexität:

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

WP-10 Chat-Interface & Writeback (abgeschlossen)

Phase: D Status: 🟢 abgeschlossen

Ziel: Ablösung der Terminal-Interaktion durch ein grafisches Interface.

Erreichte Ergebnisse:

  • Tech-Stack: Streamlit Frontend (app/frontend/ui.py).
  • Funktionen: Chat-Verlauf, Visualisierung von Intents und Quellen (Expander).
  • Feedback: Globales Rating (Sterne) und granulare Quellen-Bewertung (Faces).
  • Writeback: Mockup-Interface für neue Einträge (Vorbereitung WP-07).
  • Deployment: Systemd-Services für Prod (8501) und Dev (8502).

Aufwand / Komplexität:

  • Aufwand: Hoch
  • Komplexität: Hoch

WP-10a GUI Evolution: Draft Editor (abgeschlossen)

Phase: D Status: 🟢 abgeschlossen

Ziel: Anpassung der GUI an komplexe Interaktionsmuster, die durch den Interview-Assistenten und Knowledge-Builder entstehen.

Erreichte Ergebnisse:

  • Draft Editor: Interaktive st.text_area für generierte Entwürfe.
  • Sanitizer: normalize_meta_and_body zur Korrektur von LLM-Fehlern.
  • Download/Copy: Export-Funktionen für Markdown.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Mittel

WP-11 Backend Intelligence & Persistence (abgeschlossen)

Phase: D Status: 🟢 abgeschlossen

Ziel: Ermöglichung von "Active Intelligence" durch asynchrone Verarbeitung und semantische Analyse im Hintergrund.

Erreichte Ergebnisse:

  • Async Core: Umstellung der Pipeline auf asyncio und httpx (Vermeidung von Blockaden).
  • Nomic Embeddings: Integration von nomic-embed-text (768 Dim) für State-of-the-Art Semantik.
  • Matrix Logic: Regelwerk für kontextsensitive Kanten (experience + value -> based_on).
  • Sliding Window: Analyse langer Texte für Link-Vorschläge.
  • Persistence API: Neuer Endpunkt /ingest/save für atomares Speichern & Indizieren.

Aufwand / Komplexität:

  • Aufwand: Hoch
  • Komplexität: Hoch

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.

Aufwand / Komplexität:

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

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.

Umfang:

  • MCP-Server mit Tools (mindnet_query, mindnet_explain, etc.).

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Mittel

WP-14 Review / Refactoring / Dokumentation (geplant)

Phase: E Status: 🟡 geplant

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

Aufwand / Komplexität:

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

WP-15 Smart Edge Allocation & Chunking Strategies (abgeschlossen)

Phase: D Status: 🟢 abgeschlossen

Ziel: Einführung einer intelligenten Verteilung von Wissenskanten an spezifische Text-Chunks, um die Präzision des Retrievals zu erhöhen, ohne die Stabilität des Systems durch lange LLM-Verarbeitungszeiten zu gefährden.

Erreichte Ergebnisse:

  • 5-Stufen-Workflow: Implementierung von "Smart Edge Allocation" (Global Scan -> Deterministic Split -> LLM Filter -> Injection -> Fallback).
  • Neue Chunking-Strategien: Einführung von by_heading (für strukturierte Daten) und verbessertem sliding_window als deterministische Basis.
  • Robustheit: Trennung von Zerlegung (Code) und Analyse (LLM). Bei LLM-Fehlern oder Timeouts greift ein Fallback-Mechanismus (Datenverlust ausgeschlossen).
  • Architektur: Trennung der Orchestrierung (chunker.py) von der KI-Logik (semantic_analyzer.py).
  • Konfiguration: Steuerung über types.yaml (enable_smart_edge_allocation) ermöglicht granulare Anpassung pro Notiztyp.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Hoch

WP-16 Auto-Discovery & Enrichment (geplant)

Phase: D Status: 🟡 geplant

Ziel: Automatisches Erkennen und Vorschlagen von fehlenden Kanten in "dummem" Text (ohne explizite Wikilinks) vor der Speicherung. Umwandlung von Text in "smarten Text" durch Nutzung des DiscoveryService.

Umfang:

  • Integration eines "Enrichers" in die Ingestion-Pipeline (Schritt 0).
  • Unterscheidung zwischen "Hard Candidates" (explizite Links) und "Soft Candidates" (Vektor-basierte Vorschläge).
  • LLM-basierte Verifikation der Vorschläge zur Vermeidung von Halluzinationen.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Hoch

WP-17 Conversational Memory (Dialog-Gedächtnis) (geplant)

Phase: D Status: 🟡 geplant

Ziel: Erweiterung des Chat-Backends von einem statischen Request-Response-Modell zu einem zustandsbehafteten Dialogsystem ("Multi-Turn Conversation"). Das System soll sich an vorherige Aussagen im aktuellen Gesprächsverlauf erinnern, um Rückfragen ("Was meinst du damit?") korrekt zu interpretieren.

Umfang:

  • API-Erweiterung: ChatRequest DTO erhält ein history-Feld (Liste von Nachrichten).
  • Context Management: Implementierung einer Token-Budget-Logik, die dynamisch zwischen RAG-Kontext (Dokumente) und Dialog-Verlauf (History) balanciert, um das Kontextfenster (8k) optimal zu nutzen.
  • Prompt Engineering: Integration eines {chat_history} Platzhalters in den System-Prompt.
  • Frontend-Update: Die ui.py muss die letzten N Nachrichtenpaare (User/AI) bei jedem Request mitsenden.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Mittel

WP-18 Graph Health & Maintenance (NEU, geplant)

Phase: E Status: 🟡 geplant (Prio 2)

Ziel: Sicherstellung der Konsistenz des Wissensgraphen bei Löschungen oder Umbenennungen von Notizen ("Dangling Edges").

Architektur-Idee:

  • Health-Check Script: Ein Cronjob (scripts/check_graph_integrity.py), der alle Kanten prüft, ob ihre target_id noch in mindnet_notes existiert.
  • Report: Ausgabe von "Broken Links" als Liste für den User.
  • Auto-Heal (Optional): Markieren von defekten Kanten als broken statt hartem Löschen.

Aufwand / Komplexität:

  • Aufwand: Niedrig
  • Komplexität: Mittel

WP-19 Graph Visualisierung & Explorer (NEU, geplant)

Phase: E Status: 🟡 geplant (Prio 1)

Ziel: Schaffung von Vertrauen und Transparenz durch Visualisierung der vom "Smart Chunker" erzeugten Verbindungen.

Architektur-Idee:

  • Frontend-Erweiterung: Neuer Tab "🕸️ Graph" in Streamlit.
  • Tech-Stack: Integration von streamlit-agraph oder pyvis.
  • Feature: Visualisierung der Nachbarschaft einer Notiz (Ego-Graph) oder eines Suchergebnisses.
  • Nutzen: Schnelle Validierung, ob Smart Edges korrekt gesetzt wurden.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Mittel

WP-20 Cloud Hybrid Mode (Gemini) (NEU, geplant)

Phase: E Status: optional

Ziel: Optionale Beschleunigung ("Turbo-Modus") für Massen-Imports oder komplexe Analysen durch Nutzung externer High-Performance LLMs (Google Gemini 1.5 Flash), unter Beachtung des Datenschutzes.

Architektur-Idee:

  • Provider-Switch: Erweiterung des LLMService um einen Provider-Parameter (ollama vs. gemini).
  • Konfiguration: types.yaml oder .env erlaubt Umschalten pro Umgebung (z.B. Dev=Cloud, Prod=Local).
  • Privacy: Warnhinweis im UI, wenn Daten die lokale Umgebung verlassen.

Aufwand / Komplexität:

  • Aufwand: Mittel
  • Komplexität: Niedrig

7. Abhängigkeiten (vereinfacht, aktualisiert)

WP01-03 → WP04-06 (Core)
WP11 → WP15 (Smart Edges)
WP15 → WP19 (Visualisierung - zur Kontrolle)
WP15 → WP16 (Auto-Discovery)
WP03 → WP18 (Maintenance)
WP10 → WP17 (Memory)
WP20 (Cloud) ist unabhängig/optional.

8. Laufzeit- & Komplexitätsindikatoren (aktualisiert)

WP Aufwand Komplexität
WP15 Mittel Hoch
WP16 Mittel Hoch
WP17 Mittel Mittel
WP18 Niedrig Mittel
WP19 Mittel Mittel
WP20 Mittel Niedrig

9. Programmfortschritt (Ampel, aktualisiert)

WP Status Titel
WP01-14 🟢 (Basis-System)
WP15 🟢 Smart Edge Allocation
WP16 🟡 Auto-Discovery
WP17 🟡 Conversational Memory
WP18 🟡 Graph Health (Neu)
WP19 🟡 Visualization (Neu)
WP20 Cloud Mode (Neu)

10. Governance & Versionierung

  • Versionierung über Gitea (Branches, Tags, Releases).
  • Feature-Branch Workflow mit "Sync First" Strategie.
  • Jede wesentliche Änderung an Architektur/Schema erhält einen eigenen Commit.
  • Jedes Workpackage erhält ein eigenes Chat-Fenster mit dediziertem Prompt (WP-Hand-Over).
  • Programmleitung verantwortet Konsistenz und Priorisierung.
  • Modell-Governance: Das verwendete LLM (z.B. phi3:mini) wird in der .env und config.py festgeschrieben. Updates erfordern Tests gegen die "Why-Layer" Referenzfragen.

11. Executive Summary

mindnet v2.4 ist so aufgesetzt, dass:

  • du schrittweise Wissen erfassen kannst (Obsidian + Chat + Interview-Drafts),
  • 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 (durch WP-04c Feedback-Daten),
  • ein Persönlichkeitsmodell (Decision Engine, Empathie) existiert und den Tonfall situativ anpasst,
  • eine grafische Oberfläche (WP-10/10a) existiert, die komplexe Zusammenhänge visualisiert und Co-Creation ermöglicht,
  • Active Intelligence (WP-11) dich beim Schreiben unterstützt, indem es automatisch Verknüpfungen vorschlägt,
  • langfristig ein KI-Zwilling aufgebaut wird, der deine Werte, Erfahrungen und Denkweise spiegelt,
  • die technische Architektur (AsyncIO, Qdrant 768d, YAML-Policies) lokal, nachvollziehbar und performant bleibt.

Dieser Programmplan bildet die konsolidierte Grundlage (v2.4.0) für alle weiteren Arbeiten.