2.2 KiB
2.2 KiB
Tolaria — Target Architecture Proposal (v1)
Datum: 2026-08-24/25 · Autor: Red Queen · Modus: VORSCHLAG — NOCH NICHT UMZUSETZEN
1. Zielbild
TOLARIA SECOND BRAIN v1: Tolaria als aufbereitetes, verknüpftes, semantisch auffindbares Wissenssystem, gespeist aus der versionierten Wahrheit im Forgejo-Repo, gepflegt von Red Queen als Knowledge Steward.
2. Grundprinzipien
- Forgejo = Source of Truth (versioniert), Tolaria = derived, aufbereitete Sicht.
- Graph = derived view, rebuildbar aus dem Markdown-Vault (nie primärer Store).
- Human-in-the-Loop bei echten Wissenskonflikten (Christian entscheidet).
- Backup vor jeder Mutation; Restore-Drill vor Transformation.
- Read-only Discovery → Plan → Freigabe → Build (kein unkontrollierter Umbau).
3. Ziel-Komponenten
| Komponente | Zweck |
|---|---|
| Source of Truth | Forgejo-Repo trading-system-docs bleibt Master |
| Knowledge Model | strukturierte Typen (Frontmatter type/tags/relations), Konsistenz bei Modulen |
| Search | Keyword (bestehend) + Hybrid (Keyword + semantisch) |
| Indexing / Semantic Search | Embeddings + Vector-Store für Synonym-/Konzept-Treffer |
| Conflict Detection | automatische Erkennung divergenter Versionen (READ-ONLY-Verdacht, Human entscheidet) |
| Duplicate Detection | Erkennung EXACT/NEAR/VERSIONED Duplikate |
| Freshness | Sync Forgejo→Tolaria; Erkennung veralteter Einträge |
| Forgejo Integration | git-basierte Synchronisierung (Polling/Pull), kein Webhook-Pflicht |
| Knowledge Graph | derived view aus Vault-Links + Struktur |
| Graph UI | Obsidian-artige Ansicht (Zoom/Pan/Cluster/Suche/Filter) |
| Red Queen Steward | konsolidiert, pflegt, konflikt-erkennt, hält Sync |
| Human-in-the-Loop | Freigabegates bei Merge/Konflikt/Löschung |
| Backup/Rollback | Git-Tags + Snapshot; getesteter Restore |
| Security | Secret-Scan, Auth bei Schreib-API, kein Leak |
| Benchmarking | Such-/Sync-/Graph-Regression-Suite |
4. Abgrenzung
- Der Graph ist nicht die Source of Truth.
- Es wird kein unbounded autonomer Umbau angestrebt; jeder Build-Schritt läuft über die bestehende Safety-/Retry-/Checker-Architektur (A1–A5).