mindnet/docs/99_Archive/99_legacy_workpackages.md

doc_type	audience	status	context
archive	historian, architect	archived	Archivierte Details zu abgeschlossenen Workpackages (WP01-WP19). Referenz für historische Design-Entscheidungen.

Legacy Workpackages (Archiv)

Quellen: Programmplan_V2.2.md, Active Roadmap

Status: Abgeschlossen / Implementiert. Dieses Dokument dient als Referenz für die Entstehungsgeschichte von Mindnet v2.6.

Phase A: Fundament (WP01-03)

WP-01 – Wissensdesign

• Ziel: Definition der Datenstruktur.
• Ergebnis: Entscheidung gegen komplexe Ontologien (RDF/OWL), für pragmatische Typen (project, concept). Definition der YAML-Frontmatter-Pflichtfelder.
• Artefakt: 01_knowledge_design.md.

WP-02 – Chunking & Hash-Strategie

• Ziel: Texte suchbar machen und Änderungen erkennen.
• Ergebnis: Implementierung des SlidingWindowChunker. Einführung von UUIDv5 für deterministische IDs.
• Learning: Starre Chunking-Grenzen zerschneiden oft den Kontext. Daher Einführung von Overlap (50 Tokens).

WP-03 – Import-Pipeline & Edge-System

• Ziel: Markdown in Vektoren wandeln.
• Ergebnis: Der "Importer" (import_markdown.py). Entscheidung, Kanten (_edges) als eigene Collection zu führen statt als Payload in Chunks (für bessere Graphen-Algorithmen wie Centrality).

---

Phase B: Semantik (WP04)

WP-04a – Retriever & Graph-Scoring

• Ziel: Bessere Suchergebnisse als reines Vektor-Matching.
• Ergebnis: Die Formel Score = Semantik + GraphBonus + TypGewicht.
• Learning: Reine Vektorsuche reichte nicht, um den Kontext ("Warum ist das wichtig?") zu erfassen. Der "Graph Bonus" war der Durchbruch für assoziatives Finden.

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

• Ziel: Transparenz.
• Ergebnis: explain=True Parameter. Die API liefert menschenlesbare Gründe ("Gefunden, weil Projekt Alpha davon abhängt").

WP-04c – Feedback Logging

• Ziel: Datenbasis für zukünftiges Lernen schaffen.
• Ergebnis: Das "Data Flywheel". Jede Suche und Bewertung wird in JSONL-Dateien geloggt (search_history.jsonl, feedback.jsonl).

---

Phase C: Persönlichkeit (WP05-07)

WP-05 – RAG-Chat

• Ziel: Natürliche Sprache statt Suchergebnisse.
• Ergebnis: Integration von Ollama (phi3).
• Tech: Prompt-Engineering (prompts.yaml) statt Fine-Tuning, um flexibel zu bleiben.

WP-06 – Decision Engine

• Ziel: Strategische Beratung statt nur Fakten.
• Ergebnis: Der Hybrid Router.
• Konzept: Unterscheidung von Fragen (RAG) und Handlungen (Interview). Strategisches Laden von Werten (type: value), um Entscheidungen moralisch zu begründen.

WP-07 – Interview-Assistent

• Ziel: Bekämpfung des "Writer's Block".
• Ergebnis: One-Shot Extraction. Der Chatbot generiert aus einem losen Satz ("Neues Projekt Alpha") einen strukturierten Markdown-Draft.

---

Phase D: Interaktion (WP10-15)

WP-10/10a – Web UI & Draft Editor

• Ziel: Usability für Nicht-Techniker.
• Ergebnis: Streamlit App. Ablösung des Terminals.
• Feature: "Healing Parser", der defektes JSON vom LLM repariert.

WP-11 – Backend Intelligence

• Ziel: Automatisierung der Vernetzung.
• Ergebnis: AsyncIO Umstellung für Performance. Einführung von nomic-embed-text (768d) für präzise Semantik. Matrix-Logik für automatische Kanten-Typisierung.

WP-15 – Smart Edge Allocation (Meilenstein)

• Problem: "Broadcasting". Ein Chunk erbte alle Links der Note, auch irrelevante. Das verwässerte die Suchergebnisse.
• Lösung: LLM prüft jeden Chunk auf Link-Relevanz.
• Tech: Einführung von Traffic Control (Semaphore), um Import und Chat zu parallelisieren, ohne die Hardware zu überlasten.

---

Phase E: Visualisierung & Maintenance (WP19)

WP-19 – Graph Visualisierung & Modularisierung

• Ziel: Transparenz über die Datenstruktur schaffen und technische Schulden (Monolith) abbauen.
• Ergebnis:
  • Modularisierung: Aufsplittung der ui.py in Router, Services und Views (ui_*.py).
  • Graph Explorer: Einführung von st-cytoscape für stabile, nicht-überlappende Layouts (COSE) als Ergänzung zur Legacy-Engine (Agraph).
  • Single Source of Truth: Der Editor lädt Inhalte nun direkt vom Dateisystem statt aus (potenziell veralteten) Vektor-Payloads.
  • UX: Einführung von URL-Persistenz für Layout-Settings und CSS-basiertes Highlighting zur Vermeidung von Re-Renders.

Phase E+: Architektur-Konsolidierung (WP-14)

WP-14 – Modularisierung & Paket-Struktur

• Ziel: Auflösung technischer Schulden und Beseitigung von Zirkelbezügen (Circular Imports).
• Ergebnis:
  • Domänen-Pakete: Aufteilung der monolithischen app/core/ Struktur in spezialisierte Pakete: database/, ingestion/, retrieval/ und graph/.
  • Proxy-Pattern: Einsatz von Fassaden-Modulen (z. B. graph_adapter.py) zur Aufrechterhaltung der Abwärtskompatibilität für bestehende API-Endpunkte.
  • Registry-Zentralisierung: Auslagerung neutraler Hilfsfunktionen (wie clean_llm_text) in eine unabhängige registry.py, um Abhängigkeitsschleifen zwischen Diensten zu brechen.
• Tech: Einführung von __init__.py Exporten zur Definition sauberer Paket-Schnittstellen.

WP-15b – Two-Pass Ingestion & Candidate Validation

• Problem: Die ursprüngliche Smart Edge Extraktion (WP-15) war teuer und neigte zu Halluzinationen, da sie ohne globalen Kontext operierte.
• Lösung: Implementierung eines Two-Pass Workflows.
  • Pass 1 (Pre-Scan): Schnelles Einlesen aller Notizen zur Erstellung eines LocalBatchCache (Metadaten & Summaries).
  • Pass 2 (Processing): Gezielte semantische Verarbeitung nur für geänderte Dateien.
• Feature: Binary Validation Gate. Statt Kanten frei zu erfinden, validiert das LLM nun Kanten-Kandidaten aus einem Pool gegen den Kontext des LocalBatchCache. Dies garantiert 100% Konformität mit der Edge Registry.
• Ergebnis: Höhere Geschwindigkeit durch Reduktion komplexer LLM-Prompts auf binäre Entscheidungen (VALID/INVALID).