- BACKUP_ARCHITECTURE, STORAGE_MAP, RECOVERY_RUNBOOK - TRANSFORMATION_BASELINE, DUPLICATE_RESOLUTION_PLAN - CANONICAL_KNOWLEDGE_PRINCIPLE, SEARCH_ARCHITECTURE_PROPOSAL - KNOWLEDGE_GRAPH_PRINCIPLE, FORGEJO_TOLARIA_SYNC_PRINCIPLE - HOST_CONTAINER_DISCOVERY Fresh Checker PASS (deleg_a19028bc). No productive vault mutation.
1.6 KiB
1.6 KiB
FORGEJO → TOLARIA SYNC PRINCIPLE — (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: DOKUMENTIERT — NICHT IMPLEMENTIERT
Verbindliches Prinzip für den zukünftigen Datenfluss. Noch nichts bauen.
Grundsatz
FORGEJO → MASTER (technische/versionierte Source of Truth)
TOLARIA → DERIVED KNOWLEDGE VIEW
Forgejo ist die autoritative, versionierte Quelle. Tolaria ist die abgeleitete, intelligente Sicht (Second Brain).
Datenfluss (bevorzugt, langfristig)
FORGEJO ↓ INGEST/SYNC ↓ TOLARIA ↓ HYBRID KNOWLEDGE LAYER ↓ SEARCH + RELATIONS ↓ KNOWLEDGE GRAPH
Regeln
- Kein bidirektionaler automatischer Sync ohne spätere ausdrückliche Architekturfreigabe.
- Forgejo darf durch Tolaria NICHT automatisch überschrieben werden.
- Kein automatischer Rück-Sync Tolaria → Forgejo.
- Vor dem Synchronisieren muss Red Queen pro Element bestimmen:
- NEW (neu → anlegen)
- UPDATE (geändert → aktualisieren)
- UNCHANGED (identisch → nichts tun)
- CONFLICT (widersprüchlich → Human-in-the-Loop, nicht blind überschreiben)
- SUPERSEDED (ersetzt → kennzeichnen/archivieren)
- CONFLICT → Human-in-the-Loop (kein automatisches Überschreiben).
Nicht jetzt
- Keine Sync-Implementierung Forgejo↔Tolaria.
- Kein automatischer Push Tolaria→Forgejo.
- Gilt erst in einer späteren Missionsphase mit eigener Freigabe.
Verhältnis
- Tolaria bleibt abgeleitet; Forgejo bleibt Master.
- Basis für den Sync sind die kanonischen Objekte (B3) + Revisions-Identität (git-HEAD).