# Tolaria — Build Plan Proposal

**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** VORSCHLAG — NOCH NICHT UMZUSETZEN

> **Prämisse:** Dieser Plan ist die Grundlage für eine spätere Freigabe. **KEIN** Schritt wird in dieser Mission umgesetzt (READ-ONLY). Erst nach Christians Freigabe "TOLARIA SECOND BRAIN v1 — BUILD".

---

## 1. Abhängigkeits-Ordnung

Die Phasen sind strikt geordnet (Vorstufe vor Nachstufe), gemäß "Backup before Mutation".

## 2. Work-Packages

| WP | Name | Ziel | Abhängigkeit |
|----|------|------|--------------|
| **B1** | Backup Foundation | Backup-/Restore-Basis etablieren; Git-Tags + Snapshot; Restore-Drill; verifizieren, dass kein Verlust möglich ist | — |
| **B2** | Knowledge Inventory | 84 Dateien + 19 Duplikat-Paare + Struktur maschinell erfassen; Katalog + Hash-Basis für Dup-/Conflict-Erkennung | B1 |
| **B3** | Data Cleanup Engine | Duplikat-/Konflikt-/Aktualitäts-Erkennung (READ-ONLY-Verdacht); Vorschläge; kein Auto-Löschen | B2 |
| **B4** | Knowledge Schema | strukturierte Typen (Frontmatter) auf Module vereinheitlichen; `type`/`tags`/`relations`-Konsistenz | B2 |
| **B5** | Search | Keyword + **Hybrid**-Suche; Index; Regression-Tests für bestehende Suche | B4 |
| **B6** | Conflict Detection | divergente Versionen erkennen; Human-in-the-Loop-Freigabe | B2/B3 |
| **B7** | Forgejo Sync | Synchronisierung Forgejo→Tolaria (git pull/poll), Secret-Scan, Drift-Erkennung | B1 |
| **B8** | Graph Engine | derived knowledge graph aus Vault-Links + Struktur; rebuildbar | B4 |
| **B9** | Graph UI | Obsidian-artige Ansicht (Zoom/Pan/Cluster/Suche/Filter) | B8 |
| **B10** | Knowledge Steward | Red Queen als Steward: Konsolidierung, Pflege, Sync, Konflikt-Freigaben | B3–B9 |

> **INFERENCE:** Die Zerlegung folgt dem abgeleiteten IST-Zustand (Backup zuerst wegen 19 Duplikaten + Vault-Drift; Inventory vor Cleanup; Schema vor Search/Graph, da Search/Graph vom konsistenten Modell abhängen).

---

## 3. Reihenfolge-Rationale

- **B1 zuerst**, weil ohne verifiziertes Backup jede Cleanup-/Migraions-Aktion riskant ist (DATA LOSS HIGH).
- **B2 vor B3:** Duplikat-/Konflikt-Erkennung braucht zuerst einen vollständigen, maschinell erfassbaren Katalog.
- **B4 vor B5/B8:** Semantische Suche und Graph brauchen ein konsistentes Datenmodell (Type/Konsistenz).
- **B7 (Sync) parallel/bald:** Vault hinkt Forgejo hinterher; Sync ist Vorbedingung für frische Daten.
- **B8/B9 (Graph)** bewusst später, da Graph=derived view vom konsolidierten Bestand abhängt.

---

## 4. Abschlussbedingung

Jeder WP endet mit Checker-Verdict (PASS) gemäß bestehender A1–A5-Policy. Kein unbounded autonomer Umbau; Human-in-the-Loop bei Merge/Löschung/Konflikt.