44 lines
2.7 KiB
Markdown
44 lines
2.7 KiB
Markdown
# 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.
|