nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/tolaria/BUILD_PLAN_PROPOSAL.md

2.7 KiB
Raw Blame History

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.