mindnet/Programmmanagement/Dokumentationsrahmenplan.md

# mindnet v2.2 – Dokumentationsrahmenplan  
**Datei:** `docs/mindnet_docs_master_plan_v2.2.md`  
**Stand:** 2025-12-06  
**Bezug:** Programmplan mindnet v2.2 :contentReference[oaicite:0]{index=0}  

---

## 1. Zweck dieses Rahmenplans

Dieser Rahmenplan definiert:

- die **Zieldokumente** der mindnet v2.2 Dokumentation,
- deren **Dateinamen, Zielgruppen, Inhalte und Quellen**,
- die **Zuordnung** zu Workpackages (WP) und Release-Tags,
- die **Regeln zum Informations-Erhalt** (keine inhaltlichen Verluste),
- die **empfohlene Bearbeitungsreihenfolge**.

Alle hier beschriebenen Zieldokumente werden als **eigene Markdown-Dateien** gepflegt und sind Teil von WP-14 _Review / Refactoring / Dokumentation_ (Phase E). :contentReference[oaicite:1]{index=1}  

---

## 2. Prinzipien zur Sicherung der Informationen

Um zu verhindern, dass Inhalte oder Ergebnisse verloren gehen, gelten folgende Prinzipien:

1. **Programmplan v2.2 als Masterreferenz**  
   - Programmauftrag, Vision, Phasenmodell und WP-Status werden **nicht verändert**, sondern nur referenziert.  
   - `Programmplan_V2.2.md` bleibt das führende Dokument für Ziele, WPs, Ampelstatus. :contentReference[oaicite:2]{index=2}  

2. **Keine unkontrollierte Löschung von Inhalten**  
   - Bestehende Dokumente (`knowledge_design.md`, `chunking_strategy.md`, `mindnet_technical_architecture.md`, `Handbuch.md`, `TYPE_REGISTRY_MANUAL.md`, `docs_mindnet_retriever.md`, `wp04_retriever_scoring.md`) werden **nicht gelöscht**, sondern:
     - vollständig archiviert,
     - in die neuen Zieldokumente **überführt**,
     - oder **explizit** in den Anhängen (I) als „legacy / historisch“ verlinkt.   

3. **Explizite Quellenzuordnung („Building Blocks“)**  
   - Für jede Sektion eines Zieldokuments wird angegeben, aus **welchen bestehenden Dateien und Abschnitten** der Inhalt stammt.  
   - Neue Inhalte (z. B. User Guide H) werden klar als „neu, v2.2“ gekennzeichnet.

4. **Ist-Stand vs. Roadmap trennen**  
   - Implementierter Stand v2.2: WP01–WP04a (🟢) mit Importer, Chunking, Edge-Pipeline, Typ-Registry und hybrider Retriever.   
   - Geplante Features (Self-Healing, Virtual Schema Layer, Explanation Layer, Feedback-Logging, MCP-Agenten) werden als **Roadmap-Funktionen** kenntlich gemacht (Phase B–D, WPs 05–13).   

5. **Versionierbarkeit**  
   - Alle Zieldokumente tragen im Kopf eine **Version** und **Stand-Datum** sowie optional einen Verweis auf den letzten Gitea-Tag (z. B. `mindnet_v2.2_docs_initial`, `WP04a-Retriever_final`). :contentReference[oaicite:6]{index=6}  
   - Änderungen werden im Abschnitt „Changelog“ der jeweiligen Datei notiert.

6. **Keine funktionalen Annahmen ohne Verifikation**  
   - Wo das Verhalten nicht eindeutig aus Code-/Handbuch-/WP-Dokumenten hervorgeht, wird der Punkt zunächst als _offene Frage_ markiert und nicht als Tatsache dokumentiert.  
   - Verifizierte Funktionen (z. B. `import_markdown`, Edge-Schema, `types.yaml`, `/query`, Scoring-Formel) werden exakt gemäß der bestehenden Dokumente beschrieben.   

---

## 3. Zieldokumente der mindnet v2.2 Dokumentation

### 3.1 Übersichtstabelle

| ID | Zieldatei                                | Rolle/Zielgruppe                            | Hauptquellen (Building Blocks) |
|----|------------------------------------------|---------------------------------------------|--------------------------------|
| A  | `mindnet_overview_v2.2.md`               | Einstieg für alle Rollen                    | Programmplan v2.2, Knowledge Design  |
| B  | `mindnet_functional_architecture_v2.2.md`| Architekt:innen, Mindmaster                 | Knowledge Design, Functional Architecture, Programmplan  |
| C  | `mindnet_technical_architecture_v2.2.md` | Entwickler:innen, Tech-Architekt:innen      | mindnet_technical_architecture, chunking_strategy, Handbuch  |
| D  | `mindnet_knowledge_design_manual_v2.2.md`| Vault-Autor:innen, Mindmaster, Analyst:innen| knowledge_design, TYPE_REGISTRY_MANUAL, Functional Architecture  |
| E  | `mindnet_pipeline_playbook_v2.2.md`      | Dev/Ops, Tech-Lead                          | mindnet_v2_implementation_playbook, Handbuch, chunking_strategy, docs_mindnet_retriever, wp04_retriever_scoring  |
| F  | `mindnet_developer_guide_v2.2.md`        | Entwickler:innen (Code, API, Tests)         | Technical Architecture, Handbuch, docs_mindnet_retriever  |
| G  | `mindnet_admin_guide_v2.2.md`            | Admins, Betreiber                           | Handbuch, Implementation Playbook, Programmplan (Governance)  |
| H  | `mindnet_user_guide_v2.2.md`             | Endnutzer:innen, Agent-User                 | Knowledge Design, Programmplan (Use Cases), spätere MCP-WPs  |
| I  | `mindnet_appendices_v2.2.md`             | Alle Rollen (Referenzen, Tabellen)          | TYPE_REGISTRY_MANUAL, chunking_strategy, WP-Übersicht, Edge-Referenz  |

---

## 4. Detailpläne pro Zieldokument (Inhaltsverzeichnis & Building Blocks)

### A) `mindnet_overview_v2.2.md`

#### Zweck & Zielgruppe
- Einstieg in mindnet für alle Rollen (Owner, Mindmaster, Developer, Admin, Agenten-Entwickler).
- Auf 3–5 Seiten: _Was ist mindnet? Wie ist es gedacht? Wie lese ich die Dokumentation?_ :contentReference[oaicite:17]{index=17}  

#### Geplantes Inhaltsverzeichnis

1. **Einführung**
   1. Programmauftrag & Vision (v2.2)
   2. Was mindnet ist – und was nicht
2. **Drei Ebenen von mindnet**
   1. Content-Ebene (Vault, Notes, Chunks)
   2. Semantische Ebene (Edges, Typen, Retriever)
   3. Identitäts- / Persönlichkeits-Ebene (Werte, Entscheidungen, Profile – Roadmap)
3. **End-to-End-Überblick**
   1. Datenfluss: Vault → Import → Qdrant → Retriever → Antwort
   2. WP-Phasenmodell (A–E) und aktueller Stand (WP01–04a grün)
4. **Rollen & Perspektiven**
   1. Mindmaster / Owner
   2. Autor:in (Vault-Notes)
   3. Developer / Architect
   4. Administrator:in
   5. Agenten & LLMs (MCP-Perspektive)
5. **Leserführung durch die Dokumentation**
   1. Welche Datei für welche Rolle?
   2. Wie mit Ist-Stand vs. Roadmap umgehen?
6. **Glossar zentraler Begriffe**
   - mindnet, Vault, Note, Chunk, Edge, Type, Identity, Self-Healing, Self-Tuning, Explanation Layer, Virtual Schema Layer, etc.

#### Building Blocks (Quellen-Mapping)

- Programmauftrag & Vision → `Programmplan_V2.2.md`, Kapitel 1–2. :contentReference[oaicite:18]{index=18}  
- Phasenmodell & WPs → `Programmplan_V2.1.md`/v2.2, Kapitel 5–9 (angepasst auf v2.2-Stand).   
- High-Level-Architektur → `knowledge_design.md`, Kapitel 1–3 (Ziel, Zielarchitektur, Collections). :contentReference[oaicite:20]{index=20}  
- Rollenmodell → Ableitung aus Knowledge Design + Programmplan (Owner, Agenten, MCP-WPs).   

---

### B) `mindnet_functional_architecture_v2.2.md`

#### Zweck & Zielgruppe
- Fachliche Architektur von mindnet (Konzeptmodell).
- Für Architekt:innen, Mindmaster, Knowledge-Designer.

#### Geplantes Inhaltsverzeichnis

1. **Ziel & Einordnung**
   1. Bezug zu Programmauftrag & WPs (WP01–WP07, WP10–12)   
2. **Kernkonzepte**
   1. Notes & Note-Typen (concept, experience, project, decision, value, principle, person, event, …)   
   2. Chunks & Sections
   3. Edges (Struktur, explizit, inline, Default-Kanten)
   4. Typen-Registry & Virtual Schema Layer (fachliche Sicht, Roadmap)   
3. **Graph-Modell**
   1. Knotenarten (Notes, Chunks, Identity Nodes, People)
   2. Kantenarten (belongs_to, references, similar_to, depends_on, related_to, next/prev, …)
   3. Scope & Provenienz (chunk vs. note, rule_id, confidence)   
4. **End-to-End fachlicher Datenfluss**
   1. Erfassung von Wissen (Note erstellen)
   2. Import & Graphaufbau
   3. Retrieval & Begründungspfade
   4. Self-Healing & Retroactive Edges (WP06/07 – Roadmap)   
5. **Szenarien & Use Cases**
   1. Wissensspeicherung (z. B. Leitbild, Projekt, Erfahrung)
   2. Entscheidungen & Why-Layer (WP04b – Roadmap)
   3. Persönlichkeits-/Identitätsmodell (WP10–12 – Roadmap)
6. **Rollenmodell (fachliche Sicht)**
   1. Mindmaster
   2. Content-Autor:innen
   3. Analyst:innen (Graph-Leser)
7. **Designprinzipien (fachlich)**
   - Late Binding, Virtual Schema, Self-Healing, Minimalinvasives Schreiben etc.   

#### Building Blocks

- `knowledge_design.md` – Kapitel 1–4, 6–7 (Ziel, Architektur, Collections, Identitäten, Prinzipien). :contentReference[oaicite:28]{index=28}  
- `mindnet_functional_architecture.md` – alle Kapitel (Kernkonzepte, Edgetypen, Provenienz, Rollen). :contentReference[oaicite:29]{index=29}  
- `chunking_strategy.md` – Edges, Datenmodell, Graph-Sicht. :contentReference[oaicite:30]{index=30}  
- Programmplan – WPs 01–07, 10–12 für Roadmap-Features.   

---

### C) `mindnet_technical_architecture_v2.2.md`

#### Zweck & Zielgruppe
- Technische Architektur des Systems: Collections, Payload-Felder, Services, Schemata.
- Für Entwickler:innen und Tech-Architekt:innen.

#### Geplantes Inhaltsverzeichnis

1. **Ziel & Scope**
   1. Abgrenzung zur funktionalen Architektur
   2. Bezug zu WPs 02–04a, 05 (Schema, Importer, Retriever)   
2. **Systemübersicht**
   1. Komponentenübersicht (Importer, Qdrant, Retriever-API, Embedding-Service, n8n/MCP-Ausblick)
   2. Ports, Dienste, Hauptverzeichnisse
3. **Datenmodell in Qdrant**
   1. Notes (`mindnet_notes`)
   2. Chunks (`mindnet_chunks`)
   3. Edges (`mindnet_edges`)
   4. Optionale Collections (`mindnet_people`, zukünftige)   
4. **Typ-Registry & Konfiguration**
   1. `config/types.yaml` – Aufbau, Defaults, Typauflösung (Ist-Stand: Frontmatter-Overrides deaktiviert)   
   2. `config/retriever.yaml` – Scoringgewichte, Edge-Typ-Gewichte :contentReference[oaicite:35]{index=35}  
5. **Import-Pipeline (technische Sicht)**
   1. Discovery & Parsing (`import_markdown.py`)
   2. Hash-/Idempotenz-Mechanismus (ENV-Variablen, Baseline-Modi)
   3. Chunking (`chunker.py`, `chunk_payload.py`)
   4. Edge-Erzeugung (`derive_edges.py`)
   5. Roundtrip & Tests (Export & Vault-Vergleich)   
6. **Retriever-Architektur**
   1. API (FastAPI-Endpunkt `/query`)
   2. Semantik- und Hybridmodus
   3. Subgraph & Graph-API (expand)
   4. Scoring-Formel und Komponenten (semantik, edges, centrality) :contentReference[oaicite:37]{index=37}  
7. **Offene technische Punkte / Roadmap**
   1. Explanation Layer (WP04b)
   2. Feedback-Logging (WP04c)
   3. Virtual Schema Layer (WP05)
   4. Self-Healing & Self-Tuning (WP06–08)   

#### Building Blocks

- `mindnet_technical_architecture.md` – Kerntext. :contentReference[oaicite:39]{index=39}  
- `chunking_strategy.md` – Datenmodell & Chunk-Details. :contentReference[oaicite:40]{index=40}  
- `Handbuch.md` – ENV, Skripte, Runbooks. :contentReference[oaicite:41]{index=41}  
- `wp04_retriever_scoring.md` / `docs_mindnet_retriever.md` – Retriever-Details. :contentReference[oaicite:42]{index=42}  

---

### D) `mindnet_knowledge_design_manual_v2.2.md`

#### Zweck & Zielgruppe
- Konkrete Anleitung für das Schreiben und Strukturieren von Notes & Chunks im Vault.
- Für dich als Owner/Mindmaster und alle, die Notes erstellen.

#### Geplantes Inhaltsverzeichnis

1. **Zweck & Scope**
   1. Rolle des Vaults als „Source of Truth“
2. **Note-Struktur & Frontmatter**
   1. Pflicht- und optionale Felder (id, title, type, tags, status, created/updated, …)
   2. Empfehlungen für IDs, Pfade und Namenskonventionen   
3. **Note-Typen & Typ-Registry**
   1. Übersicht der Typen (concept, project, experience, decision, value, principle, person, event, …)
   2. Typ-spezifische Einsatzempfehlungen
   3. Zusammenspiel mit `types.yaml` (retriever_weight, chunk_profile, edge_defaults)   
4. **Edges & Referenzen in Notes**
   1. Wikilinks (`[[Note]]`) → `references`
   2. Inline-Relationen (`[[rel:depends_on XYZ]]`, `similar_to`, `related_to`)   
   3. Callout-Edges (`> [!edge] …`)  
   4. Strukturkanten (Ordner, belongs_to)
5. **Best Practices**
   1. Beispiele für gut modellierte Notes (Projekt, Entscheidung, Erfahrung)
   2. Typische Anti-Patterns und wie man sie vermeidet
6. **Langfristige Stabilität**
   1. Virtual Schema Layer – was bedeutet das für Note-Autoren? (Wenig Änderungen in bestehenden Notes, Logik in Configs) :contentReference[oaicite:46]{index=46}  

#### Building Blocks

- `knowledge_design.md` – Kerntext + Beispiele. :contentReference[oaicite:47]{index=47}  
- `TYPE_REGISTRY_MANUAL.md` – Typ-Registry & Verhalten. :contentReference[oaicite:48]{index=48}  
- `mindnet_functional_architecture.md` – ergänzende Konzepte & Edges. :contentReference[oaicite:49]{index=49}  
- `chunking_strategy.md` – Inline-Relationen, Edges, Datenmodell. :contentReference[oaicite:50]{index=50}  

---

### E) `mindnet_pipeline_playbook_v2.2.md`

#### Zweck & Zielgruppe
- End-to-End-Playbook für die gesamte Pipeline:
  - Importer,
  - Chunking,
  - Edge-Erzeugung,
  - Retriever & Scoring,
  - (perspektivisch) Explanation Layer, Self-Healing, Self-Tuning.
- Für Dev/Ops und technische Leads.

#### Geplantes Inhaltsverzeichnis

1. **Zweck & Einordnung**
   1. Bezug zu WPs 02–04a (Ist) und 04b–08 (Roadmap)   
2. **Import-Pipeline (Runbook-Sicht)**
   1. Inputs (Vault, Config-Files, ENV)
   2. Standardläufe (Initialimport, inkrementelle Updates, Sync-Deletes)
   3. Baseline-Builds & Hash-Modi
3. **Chunking & Payload-Aufbau**
   1. Chunk-Profile, Overlaps, Fenster
   2. Feldbesetzung (`text`, `window`, `section_title`, `neighbors`, …)   
4. **Edge-Erzeugung**
   1. Strukturkanten (belongs_to, next, prev)
   2. Explizite Edges (Wikilinks, Inline-Relationen, Callouts)
   3. Typ-Default-Kanten aus `types.yaml`   
5. **Retriever & Scoring**
   1. Konfiguration (`retriever.yaml`, ENV)
   2. Scoring-Formel und Parameter
   3. Semantik- vs. Hybridmodus
   4. Test- und Smoke-Suites   
6. **Quality Gates & Tests**
   1. Roundtrip-Tests (Vault → Qdrant → Export)
   2. Chunk-Integrität und Fenster-Checks
   3. Retriever-Regressionstests   
7. **Ausblick: Self-Healing, Retroactive Edges, Self-Tuning**
   1. Geplante Batch-Jobs und Feedback-Pipelines (WP06–08)   

#### Building Blocks

- `mindnet_v2_implementation_playbook.md` – Policies, Teststrategie, KPIs. :contentReference[oaicite:57]{index=57}  
- `Handbuch.md` – Skripte & Test-Runbooks. :contentReference[oaicite:58]{index=58}  
- `chunking_strategy.md` – Chunk- & Edge-Strategie. :contentReference[oaicite:59]{index=59}  
- `docs_mindnet_retriever.md` / `wp04_retriever_scoring.md` – Retriever-Praktiken & Tests. :contentReference[oaicite:60]{index=60}  

---

### F) `mindnet_developer_guide_v2.2.md`

#### Zweck & Zielgruppe
- Konzentrierte Sicht für Entwickler:innen:
  - wie das Projekt strukturiert ist,
  - wie man es lokal aufsetzt,
  - wie man neue Features implementiert/testet.

#### Geplantes Inhaltsverzeichnis

1. **Projektstruktur**
   1. Verzeichnisbaum (app/, scripts/, tests/, config/, …)
2. **Lokale Entwicklungsumgebung**
   1. Abhängigkeiten, venv, ENV
   2. Starten von Services (Qdrant, API, ggf. ollama)
3. **APIs & Module**
   1. Importer-Skripte
   2. Core-Module (Chunker, Edge-Engine, Retriever)
   3. FastAPI-Endpunkte (`/query`, evtl. Admin-Endpoints)   
4. **Tests & Debugging**
   1. pytest-Suites
   2. Logging & Diagnoseskripte
5. **Guidelines für Erweiterungen**
   1. Neue Typen & Edge-Regeln
   2. Änderungen am Datenmodell
   3. Umgang mit Schema-Änderungen (Virtual Schema Layer)   

#### Building Blocks

- `mindnet_technical_architecture.md` – Modul- & API-Beschreibungen. :contentReference[oaicite:63]{index=63}  
- `Handbuch.md` – Skripte & Beispiele. :contentReference[oaicite:64]{index=64}  
- `docs_mindnet_retriever.md` – API-Beispiele für den Retriever. :contentReference[oaicite:65]{index=65}  

---

### G) `mindnet_admin_guide_v2.2.md`

#### Zweck & Zielgruppe
- Betriebshandbuch für mindnet:
  - Installation,
  - Konfiguration,
  - Backup/Restore,
  - Monitoring,
  - Troubleshooting.

#### Geplantes Inhaltsverzeichnis

1. **Zielgruppe & Scope**
2. **Initial Setup**
   1. Voraussetzungen (Ubuntu, Docker/Qdrant, Python-Umgebung)
   2. ENV-Variablen & Config-Files (types.yaml, retriever.yaml)   
3. **Betrieb im Alltag**
   1. Regelmäßige Imports
   2. Umgang mit Fehlermeldungen im Importer
   3. Health-Checks für Qdrant & API
4. **Update-Prozess**
   1. Vorgehen bei Schema-/Code-Updates
   2. Umgang mit neuen Typen und Policies
5. **Backup & Restore**
   1. Qdrant-Snapshots
   2. Vault-Backup (Obsidian)
   3. Konsistenzprüfungen   
6. **Monitoring & Logging**
   1. typische Logquellen (Importer, API, n8n)
7. **Governance & Sicherheit**
   1. Bezug zur Programm-Governance (WP14, MCP-Sicherheit)   

#### Building Blocks

- `Handbuch.md` – Betriebsskripte & ENV. :contentReference[oaicite:69]{index=69}  
- `mindnet_v2_implementation_playbook.md` – Policies/Resilienz. :contentReference[oaicite:70]{index=70}  
- Programmplan – Governance / WP14. :contentReference[oaicite:71]{index=71}  

---

### H) `mindnet_user_guide_v2.2.md`

#### Zweck & Zielgruppe
- Anleitung für Nutzer:innen (inkl. späterer Chat-Agenten-User):
  - wie man mindnet im Alltag nutzt,
  - wie man Fragen stellt,
  - wie man neue Gedanken einbringt.

#### Geplantes Inhaltsverzeichnis

1. **Was mindnet für dich tut**
   1. Persönliches Gedächtnis
   2. KI-Zwilling als Gesprächspartner :contentReference[oaicite:72]{index=72}  
2. **Zugänge zu mindnet**
   1. Obsidian-Vault
   2. Chat-Agent (lokal, n8n-Workflows)
   3. (später) Interview-Assistent, MCP-Tools   
3. **Gute Fragen an mindnet**
   1. Beispiel-Queries (Wissensabruf, Entscheidungen, Reflexionen)
4. **Neue Inhalte eingeben**
   1. Notes in Obsidian erstellen
   2. Typen und Links bewusst setzen (vereinfachte Version aus D)
5. **Ergebnisse interpretieren**
   1. Was bedeutet ein Treffer-Set?
   2. Wie sind Scores zu lesen? (nur Ist-Stand, Explanation Layer als Ausblick)   
6. **Feedback & Lernen**
   1. Manuelles Feedback (gut/schlecht) – Roadmap WP04c/08   

#### Building Blocks

- Programmplan – Vision & Use-Cases. :contentReference[oaicite:76]{index=76}  
- Knowledge Design – Autorensicht (stark vereinfacht). :contentReference[oaicite:77]{index=77}  
- Retriever-Dokumente – Scoring & Interpretation. :contentReference[oaicite:78]{index=78}  

---

### I) `mindnet_appendices_v2.2.md`

#### Zweck & Zielgruppe
- Referenzen, Tabellen, technische Details, die Hauptdokumente nicht überfrachten sollen.

#### Geplantes Inhaltsverzeichnis

1. **Typenreferenz (Auszug aus `types.yaml`)**
   - Tabellenform: Typ, chunk_profile, edge_defaults, retriever_weight   
2. **Edge-Typen & Bedeutungen**
   - belongs_to, references, depends_on, similar_to, related_to, next, prev, …   
3. **Datenmodelle (JSON-Skizzen)**
   - Note, Chunk, Edge-Payload (aktuell implementierter Stand)   
4. **Relevante ENV-Variablen & Konfigurationen**
   - Hash-Settings, COLLECTION_PREFIX, MINDNET_TYPES_FILE, MINDNET_RETRIEVER_CONFIG etc.   
5. **WP-Übersicht & Status**
   - kompakte Tabelle aller WPs mit Status (🟢/🟡) und Verweisen auf relevante Dokumente.   
6. **Historische Dokumente**
   - Verweis auf alte Versionen (`mindnet_functional_architecture.md`, ältere Playbooks), falls diese nicht vollständig eingearbeitet werden.

#### Building Blocks

- `TYPE_REGISTRY_MANUAL.md` – Typen-Referenz. :contentReference[oaicite:84]{index=84}  
- `chunking_strategy.md` – JSON-Beispiele. :contentReference[oaicite:85]{index=85}  
- `mindnet_technical_architecture.md` – Felder & Prioritäten. :contentReference[oaicite:86]{index=86}  
- Programmplan – WP-Tabellen.   

---

## 5. Bearbeitungsreihenfolge (Empfehlung)

Aus Sicht der Informationssicherung und Konsistenz ist folgende Reihenfolge sinnvoll:

1. **C – `mindnet_technical_architecture_v2.2.md`**  
   - Begründung:
     - bildet den **aktuellen implementierten Stand** von WP02–WP04a am präzisesten ab,  
     - ist stark an konkrete Felder, Collections und Skripte gebunden (hier ist der Ist-Stand am eindeutigsten belegbar),  
     - ist die Grundlage für Developer Guide, Playbook und Admin Guide.   

2. **E – `mindnet_pipeline_playbook_v2.2.md`**  
   - Konsolidiert Handbuch + Implementation-Playbook + WP04-Dokumente.

3. **D – `mindnet_knowledge_design_manual_v2.2.md`**  
   - Stellt sicher, dass das Wissensdesign stabil dokumentiert ist, bevor Overview/User Guide entstehen.

4. **A – `mindnet_overview_v2.2.md`**  
   - Kann sich dann sauber auf die finalisierte fachliche/technische Sicht stützen.

5. **F, G, H, I**  
   - Developer/Admin/User Guides & Appendices, basierend auf den konsolidierten Kern-Dokumenten.

---

## 6. Nächster konkreter Schritt

Als nächstes finalisieren wir gemäß dieser Reihenfolge das Dokument:

> **C – `mindnet_technical_architecture_v2.2.md`**

Dabei gehen wir wie folgt vor:

1. Bestehendes `mindnet_technical_architecture.md` **vollständig** als Basis übernehmen. :contentReference[oaicite:89]{index=89}  
2. Fehlende Details aus `chunking_strategy.md`, `Handbuch.md`, `TYPE_REGISTRY_MANUAL.md` und `wp04_retriever_scoring.md` integrieren (ohne Informationsverlust).   
3. Ist-Stand vs. Roadmap klar kennzeichnen (WP04b–08, WP05–07).   

Dieses Vorgehen hält die technische Wahrheit konsistent und liefert eine stabile Basis für alle nachfolgenden Dokumente.