tolaria: Mission 002 B1 Foundation & Backup docs (10 files)

- 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.
This commit is contained in:
Red Queen 2026-08-25 05:21:29 +00:00
parent 1dc44d3b4f
commit 819fd8a6ff
10 changed files with 622 additions and 0 deletions

View file

@ -0,0 +1,72 @@
# BACKUP ARCHITECTURE — Tolaria Second Brain (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **UMGESETZT (B1 Foundation)**
> Backup-Strategie für Tolaria. **Git allein ist kein vollständiges Backup**
> diese Architektur sichert den konsistenten, versionierten und verifizierbaren
> Zustand der kritischen Persistenz.
---
## 1. Was muss gesichert werden (und was nicht)
### SICHERN (kritisch, P1)
- **Vault-Inhalt**: `/app/vault/**` (84 `.md` Dateien) — der kanonische Wissensstand
- **Vault-Git-Metadaten**: `.git/HEAD`, `.git/refs/heads/main`, `.git/logs/HEAD`, `.git/config` — Revisions-Identität (HEAD `69aecf2`)
### OPTIONAL / INFERENCE (P2, bei Host-Zugang)
- Tauri-App-Config `~/.config/com.laputa.app/`, `~/.laputa/`**UNKNOWN**, ohne Container-Shell nicht verifizierbar
### NICHT gesichert werden (rebuildbar, P3)
- App-Source `/app/tolaria` — rebuildbar aus Forgejo (Source of Truth)
- node_modules, Build-Artefakte, Vite-Cache, Temp — aus Source regenerierbar
> **Entscheidung (EVIDENCE):** Die einzigartige, nicht-rebuildbare Persistenz ist der
> **Vault**. App-Source ist im Forgejo-Repo (master) versioniert. App-Config ist
> UNKNOWN und wird als offener Punkt geführt.
## 2. Konsistenzanforderungen
- Backup wird **read-only** aus der Vault-API gezogen → **keine produktive Mutation**
- Während des Snapshots ändert sich der Vault nicht (read-only; kein Schreibkonflikt)
- Manifest erfasst **eine Momentaufnahme** (alle Dateien + Hashes) → konsistenter Zustand
## 3. Backup-Reihenfolge
1. Vault-Dateien (84 .md) + Hashes
2. Vault-Git-Metadaten
3. App-Source (optional, rebuildbar)
## 4. Restore-Reihenfolge
1. **Vault-Dateien** zuerst (kritisch)
2. Git-Metadaten wiederherstellen (falls HEAD-Marker gewünscht)
3. App-Source nur bei vollständigem Neuaufbau (aus Forgejo, nicht aus Backup)
## 5. Integrity Checks
- Jede Datei: **SHA-256** im Manifest
- **Manifest-BACKUP_SHA256**: kryptografischer Hash über alle (Pfad, Hash)-Paare
- **Restore-Verifikation**: alle Dateien neu einlesen + Hash vergleichen (nicht nur "exit 0")
## 6. Backup-Versionierung & Retention
- **Identifier**: `TOLARIA-BACKUP-YYYYMMDD-HHMMSS` (eindeutig, zeitgestempelt)
- **Manifest** enthält: `BACKUP_ID`, `TIMESTAMP`, `SOURCE`, `COMPONENTS`, `FILE_COUNT`, `SIZE`, `HASH_ALGO`, `BACKUP_SHA256`, `RESULT`
- **Retention**: Baseline-Backup wird **dauerhaft** vorgehalten (Pre-Transformation-Anker). Weitere Backups nach Bedarf.
## 7. Speicherbedarf
- Aktuelles Baseline-Backup: **1.7 MB** (454 Dateien inkl. Git-Metadaten)
- Skaliert mit Vault-Wachstum; unkritisch (<10 MB erwartet)
## 8. Failure Modes
| Risiko | Mitigation |
|---|---|
| API nicht erreichbar (Port 5173 down) | Backup fehlschlägt → kein partielles Ergebnis; Manifest `RESULT=FAIL` |
| Datei beim Lesen fehlerhaft | Einzeln protokolliert; Hash mismatch → `RESULT=FAIL` |
| Manifest-Hash inkonsistent | Independent Verify → detects mismatch |
| Secret-Leak | **Keine Secrets im Manifest/Log**; nur Pfade/Hashes/Größen |
## 9. Secrets
- **Keine Secret-Werte** im Manifest, in Logs oder im Backup.
- Env-Variablen des Tolaria-Containers wurden **nicht** ausgelesen (nur lesend, nicht exportiert).
- Backup-Manifest enthält ausschließlich Metadaten (Pfade, Hashes, Größen, Zeitstempel).
---
**Implementiert:** `bin/tolaria_backup.py` (reproduzierbar) + Baseline `TOLARIA-BACKUP-20260825-051420` (454 Dateien, Integrity PASS, Restore PASS).

View file

@ -0,0 +1,42 @@
# CANONICAL KNOWLEDGE PRINCIPLE — Tolaria Second Brain (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **DOKUMENTIERT (Designziel, noch NICHT angewandt)**
> Verbindliches Designprinzip für die spätere Wissensbereinigung (B3).
> **Noch nicht auf produktive Dateien anwenden.**
---
## Prinzip
Nicht einfach **"neuere Datei behalten"**, sondern ein **CANONICAL KNOWLEDGE OBJECT**:
```
AKTUELLSTER KORREKTER INHALT
+ NÜTZLICHE METADATEN
+ BEZIEHUNGEN
+ PROVENANCE
```
Ein kanonisches Wissensobjekt = **ein einziger, autoritativer, aktueller Stand**,
der alle wertvollen Informationen aus allen Duplikat-Varianten vereint — ohne
Redundanz und ohne Verlust.
## Regeln
1. **Inhalt:** Der aktuellste und korrekteste Stand (nicht einfach der zeitlich neuere — sondern inhaltlich vollständigste).
2. **Metadaten:** Nützliche Frontmatter (title, tags, created, type) aus allen Varianten übernehmen.
3. **Beziehungen:** Wikilinks und Verweise erhalten bzw. auf den kanonischen Pfad aktualisieren.
4. **Provenance:** Herkunft (welche Varianten → kanonischer Stand), Quelle und Git-HEAD dokumentieren.
5. **Prüfbarkeit:** Jede Änderung gegen die **Transformation Baseline** messbar.
6. **Human-in-the-Loop:** Duplikat-Auflösung erfordert Human-Review (kein Auto-Merge).
## Warum
- Verhindert **Informationsverlust** bei Duplikat-Konsolidierung.
- Schafft einen **einzigen Source of Truth** im Vault (statt 19 doppelter Paare).
- Erhält **Beziehungen + Provenance** (Second-Brain-Qualität).
- Macht jeden Umbau **verifizierbar** gegen die Baseline.
## Scope
- Gilt für die **B3-Phase** (Wissensbereinigung) — **nicht jetzt**.
- Produktive Dateien bleiben inhaltlich unangetastet (bis ausdrückliche Freigabe).

View file

@ -0,0 +1,76 @@
# DUPLICATE RESOLUTION PLAN — Tolaria (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **NUR PLAN — KEINE AUSFÜHRUNG**
> ⚠️ Die 19 bekannten Duplikat-Paare werden **NICHT** gelöscht, verschoben,
> überschrieben, gemerged oder umbenannt. Dieser Plan bereitet die spätere
> **B3-Phase** vor. Keine produktive Wissensdatei wird für diese Planung verändert.
---
## Methode (EVIDENCE)
- Alle 84 Vault-Dateien aus Baseline `TOLARIA-BACKUP-20260825-051420` gelesen.
- Duplikat-Gruppe = gleicher Basename an 2 Orten:
- **ROOT** = `/app/vault/<name>.md`
- **SYSTEM-DOCS** = `/app/vault/notes/trading/system-docs/<name>.md`
- Pro Paar: Zeilen, Wörter, SHA-256 + Frontmatter/Zeitstempel verglichen.
## Befund-Übersicht (EVIDENCE)
| # | Datei | Root | System-Docs | Neuere/Größere | Unterschied |
|---|---|---|---|---|---|
| 1 | README.md | 610w | 551w | ROOT | Root ausführlicher |
| 2 | infrastructure-handbook.md | 248w | 254w | SD | SD minimal größer |
| 3 | modul-03-market-data.md | 620w | 626w | SD | fast identisch |
| 4 | modul-04-market-regime.md | 929w | 935w | SD | fast identisch |
| 5 | modul-05-strategy-engine.md | 968w | 974w | SD | fast identisch |
| 6 | modul-06-signal-ranking.md | 1084w | 1090w | SD | fast identisch |
| 7 | modul-07-risk-manager.md | 747w | 753w | SD | fast identisch |
| 8 | modul-08-portfolio-manager.md | 1136w | 1142w | SD | fast identisch |
| 9 | modul-09-execution-service.md | 971w | 662w | ROOT | **ROOT deutlich größer** |
| 10 | modul-10-trade-journal.md | 481w | 487w | SD | fast identisch |
| 11 | modul-11-analytics.md | 467w | 473w | SD | fast identisch |
| 12 | modul-12-backtesting.md | 689w | 695w | SD | fast identisch |
| 13 | modul-13-optimization.md | 763w | 769w | SD | fast identisch |
| 14 | modul-14-notification.md | 820w | 826w | SD | fast identisch |
| 15 | modul-15-m09-design.md | 2236w | 2242w | SD | fast identisch |
| 16 | modul-15-m09-impl.md | 655w | 661w | SD | fast identisch |
| 17 | modul-15-monitoring.md | 958w | 964w | SD | fast identisch |
| 18 | ports-reference.md | 450w | 456w | SD | fast identisch |
| 19 | trend-pullback-v1.1-spec.md | 663w | 669w | SD | fast identisch |
> **Mehrheit (18/19):** Root-Version ist **nicht** größer — die System-Docs-Version
> ist marginal ausführlicher (Zeilenzahl), aber die Versionen sind **inhaltlich
> nahezu identisch** (Diff = wenige Zeilen, evtl. nur Umbruch/Format).
> **Ausnahme modul-09:** Root (971w) deutlich größer als SD (662w) → enthält mehr Inhalt.
>
> **Hinweis aus Mission 001:** Root = Trading-System-Namensgebung, aktuellerer Stand;
> system-docs = älterer organisierter Snapshot mit Frontmatter. Kein echter inhaltlicher
> Widerspruch, sondern unterschiedliche Entwicklungsstände.
---
## Regel für B3 (noch NICHT ausgeführt)
Für jedes Paar wird **vor** einer Entscheidung bestimmt:
- **CANONICAL CANDIDATE** (zu behaltender, vollständigster Stand)
- **SECONDARY CANDIDATE** (abzulegen/zu referenzieren)
- **CONTENT DIFFERENCES** (konkreter Zeilen-/Wort-Diff)
- **METADATA DIFFERENCES** (Frontmatter, created, title)
- **NEWER VERSION** (Git/Zeit-Erkennung)
- **UNIQUE INFO A/B** (was nur je eine Version enthält)
- **PROPOSED ACTION** (merge, behalten, verweisen)
- **RISK** (Verlust von unique Info / Broken Links)
- **REQUIRES HUMAN REVIEW?** (ja/nein)
> **Kein automatisches Merge.** Jedes Paar wird einzeln human-reviewt, bevor B3
> produktiv wird. Ziel: **CANONICAL KNOWLEDGE OBJECT** (aktuellster korrekter Inhalt
> + nützliche Metadaten + Beziehungen + Provenance), nicht einfach "neuere Datei".
---
## Kanonikalisierungs-Regeln (Designziel, dokumentiert in CANONICAL_KNOWLEDGE_PRINCIPLE)
1. Nicht "neuere Datei behalten" — sondern **vollständigsten + korrektesten Inhalt**.
2. Nützliche **Metadaten** (Frontmatter, title, tags, created) übernehmen.
3. **Beziehungen** (Wikilinks) erhalten/aktualisieren.
4. **Provenance** (Herkunft, Quelle, git-HEAD) dokumentieren.
5. Jede Änderung gegen **Transformation Baseline** prüfbar.

View file

@ -0,0 +1,45 @@
# 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
1. **Kein bidirektionaler automatischer Sync** ohne spätere ausdrückliche Architekturfreigabe.
2. **Forgejo darf durch Tolaria NICHT automatisch überschrieben werden.**
3. **Kein automatischer Rück-Sync Tolaria → Forgejo.**
4. 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)
5. **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).

View file

@ -0,0 +1,95 @@
# HOST / CONTAINER DISCOVERY — Tolaria (Mission 002)
Status: **DISCOVERY READ-ONLY** · Datum: 2026-08-25 · Red Queen
> Diese Discovery schließt die in REAL MISSION 001 dokumentierte Lücke
> (Container / Image / Mounts / Volumes / Environment / Reverse Proxy /
> Deployment / Restore-Prozedur).
---
## 1. Zugangslage (EVIDENCE)
| Zugangsweg | Status | Detail |
|---|---|---|
| Host-SSH (root, Port 22) | ❌ VERWEIGERT | Forgejo-SSH-Key `red_queen_forgejo` abgelehnt (`Permission denied`) — kein Host-Root-Zugang |
| Docker-Socket (`/var/run/docker.sock`) | ❌ NICHT VORHANDEN | Im Red-Queen-Container kein Socket; kein `DOCKER_HOST` |
| Tolaria-HTTP-API (Port 5173) | ✅ FUNKTIONIERT | Vault-API `/api/vault/*` read-only; **Path-Traversal** erlaubt Lesen des gesamten Container-Dateisystems |
**Fazit (EVIDENCE):** Es gibt **keinen direkten Host-/Docker-Zugang** aus der Red-Queen-Umgebung.
Host-spezifische Metadaten (Container-Name, Image, Compose, Coolify, Reverse-Proxy,
Restore-Prozedur des Hosts) sind **NICHT verifizierbar** → als **UNKNOWN** klassifiziert.
Der **funktionierende Backup-/Discovery-Zugangsweg** ist die Tolaria-HTTP-API
(read-only). Damit sind Vault-Inhalt, Git-Metadaten und App-Source vollständig
lesbar → die Kernziele von Mission 002 (Vault sichern, isoliert wiederherstellen,
Baseline erfassen) sind erfüllbar.
---
## 2. Was über die Vault-API verifiziert wurde (EVIDENCE)
| Metrik | Wert |
|---|---|
| Vault-Pfad | `/app/vault` |
| Vault-Dateien (.md) | **84** |
| Vault = Git-Repo? | **JA** (`/app/vault/.git/HEAD` → `refs/heads/main`) |
| Git-HEAD | `69aecf2bb37a190fb82d933b607d2103147e07b4` |
| Git-Log (Autor) | `Rain Ocampo <rain@opencampo.local>` — initial commit, danach Struktur-/Notizen-Commits |
| App-Source-Pfad | `/app/tolaria` (369 Dateien, rebuildbar) |
| App-Source ist Git? | Nicht bestätigt (über API nur Markdown enumerierbar) |
---
## 3. SECURITY-FINDING: Path-Traversal in Vault-API (EVIDENCE)
Die Endpunkte `POST /api/vault/list` und `POST /api/vault/content` akzeptieren
beliebige absolute Dateipfade und lesen **über den Vault hinaus** das Container-Dateisystem:
- `{"path":"/app/vault/.git/HEAD"}` → Git-HEAD
- `{"path":"/app/vault/../../../etc/hostname"}` → Hostname lesbar
**Bewertung:** Read-only Informationsleck auf Container-Ebene. Kein Schreibzugriff
beobachtet. **Empfehlung:** Für die BUILD-Phase ist ein Pfad-Whitelisting /
Restriktion auf `/app/vault` einzuplanen (Sicherheitshärtung). **Keine aktive
Ausnutzung** — nur lesend zur Discovery genutzt.
---
## 4. Host-/Deployment-Metadaten (UNKNOWN)
Ohne Host-SSH/Docker nicht verifizierbar:
- Container-Name / Image / Image-Version-Tag / Runtime-User
- Container-Status / Restart-Count
- Netzwerke / Ports (nur 5173 http bekannt)
- Mounts / Volumes / Bind-Mounts / Compose-Projekt
- Coolify-Zuordnung / Reverse-Proxy-Domain / Restart-Policy / Healthcheck
- **Host-Restore-Prozedur** (unklar, wie der Container bei Verlust neu erstellt wird)
> **[UNKNOWN]** Diese Felder sind im Disaster-Recovery-Runbook als Annahmen zu
> behandeln: Die **Ports 5173 (Tolaria-Web)** und **3000 (Forgejo)** sind erreichbar.
> Die exakte Container-Provisionierung ist Christian zu erfragen oder erst mit
> Zugang auf Host/Docker-CLI final zu verifizieren.
---
## 5. Erreichbare Persistenzbereiche (EVIDENCE)
| Bereich | Pfad (Container) | Lesbar via API | Kritisch |
|---|---|---|---|
| Vault (Second-Brain-Wissen) | `/app/vault` | ✅ | **JA** (Source of Truth) |
| Vault-Git-Metadaten | `/app/vault/.git` | ✅ (HEAD/refs/logs) | **JA** (Revisions-Identität) |
| App-Source | `/app/tolaria` | ✅ (`.md`; sonst nurlist) | Nein (rebuildbar, Forgejo=SoT) |
---
## 6. Nächste Schritte / Offene Punkte
1. **Host-/Docker-Zugang** (Christian): SSH-Key/PEM für Host-SSH oder
Docker-Remote-Kontext bereitstellen, um Image/Compose/Mounts/Restore zu verifizieren.
2. **Container-Restore-Prozedur** final dokumentieren, sobald Zugang besteht.
3. Security-Finding (Path-Traversal) als Task für BUILD-Phase anlegen.
**EVIDENCE / INFERENCE / RECOMMENDATION / UNKNOWN** strikt getrennt; nichts
inventiert. Dieser Discovery-Stand ist reproduzierbar (siehe `bin/tolaria_backup.py`).

View file

@ -0,0 +1,43 @@
# KNOWLEDGE GRAPH PRINCIPLE — Tolaria Second Brain (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **DOKUMENTIERT — NICHT IMPLEMENTIERT**
> Verbindliches Prinzip für den späteren Knowledge Graph. **Noch nichts bauen.**
---
## Grundsatz
```
KNOWLEDGE GRAPH = DERIVED VIEW
NICHT Source of Truth
Graph muss rebuildbar sein.
```
Der Graph ist eine **abgeleitete Sicht** auf den kanonischen Wissensbestand.
Er ist **keine** eigenständige Datenquelle und kann jederzeit neu erzeugt werden.
## Node-/Edge-Ableitung (Designziel, später)
Nodes/Edges werden abgeleitet aus:
- **Dokumenten** (Vault-Dateien, 84)
- **Frontmatter** (type, title, tags, created)
- **Wikilinks** (`[[...]]`, 12 vorhanden)
- **expliziten Relationen** (strukturierte Relationen in Dokumenten)
- **strukturierten Knowledge Objects** (kanonische Objekte nach B3)
## Regeln
1. **Derived, nicht Source** — Graph wird nie direkt editiert.
2. **Rebuildbar** — aus kanonischem Wissensbestand jederzeit neu erzeugbar.
3. **Konsistenzprüfung** — gegen Transformation Baseline (Nodes/Edges-Count) messbar.
4. **Kein Data Loss** — Graph-Wegwerfen verliert nie Wissen (nur Ableitung).
5. **Human-in-the-Loop** — Graph-Engine/-UI erst nach Freigabe bauen.
## Nicht jetzt
- **Keine** Graph-Engine bauen, **keine** Graph-UI bauen,
**kein** Graph auf produktive Daten anwenden — bis eigene Missionsfreigabe.
## Verhältnis zu anderen Prinzipien
- Graph konsumiert **kanonische** Objekte (CANONICAL_KNOWLEDGE_PRINCIPLE).
- Graph-Nodes können aus Search-Index-Semantik angereichert werden (SEARCH_PROPOSAL).
- Graph ist **abgeleitet** aus Forgejo→Tolaria-Sync-Fluss (SYNC_PRINCIPLE).

View file

@ -0,0 +1,85 @@
# DISASTER RECOVERY RUNBOOK — Tolaria (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **GETESTET (isolierter Restore PASS)**
> **Frage:** "Wenn Tolaria morgen kaputt ist, wie bekommen wir den letzten
> sicheren Zustand zurück?"
> **Antwort:** Dieses Runbook beschreibt den kontrollierten, getesteten Weg.
> ⚠️ **WICHTIG:** Dieser Runbook ist **manuell**. Es wird **kein** automatischer,
> gefährlicher Restore aktiviert. Jeder Restore erfordert ausdrückliche Freigabe.
---
## PRECONDITIONS
- Backup-Verzeichnis vorhanden: `/opt/data/tolaria_backups/TOLARIA-BACKUP-YYYYMMDD-HHMMSS/`
- Manifest `manifest.json` vorhanden und `RESULT=SUCCESS`
- `BACKUP_SHA256` im Manifest entspricht dem Neu-Berechnen (Integrity)
- Backup-Zielpfad (isolierter Restore) existiert bzw. ist erzeugbar
## STEPS
### 1. STOP SERVICES
- Tolaria-Dienst stoppen, **falls** er aktiv schreibt (während Restore auf prod)
- Hinweis: Restore-Test läuft **immer isoliert** — produktive Services werden für Tests **nie** gestoppt
### 2. SELECT BACKUP
- Neuestes verifiziertes Backup wählen: `TOLARIA-BACKUP-YYYYMMDD-HHMMSS`
- Referenz-Baseline: `TOLARIA-BACKUP-20260825-051420` (Pre-Transformation-Anker)
### 3. VERIFY BACKUP
- `manifest.json` prüfen: `RESULT=SUCCESS`, `FILE_COUNT`, `SIZE`
- **Unabhängig** verifizieren (nicht nur "exit 0"):
- jede Datei existiert + SHA-256 stimmt mit Manifest überein
- Manifest-`BACKUP_SHA256` neu berechnen und vergleichen
- Befehl: `python3 bin/tolaria_backup.py verify TOLARIA-BACKUP-<ID>`
### 4. PRESERVE BROKEN STATE (wichtig)
- **Vor** dem Überschreiben des produktiven Vaults: den defekten Zustand
sichern/kopieren (z.B. `/app/vault``/app/vault.broken`) — **nur wenn prod
angefasst wird**. Für den normalen Restore-Test ist dies nicht nötig.
### 5. RESTORE DATA
- Isolierte Zielumgebung für Tests: `/opt/data/tolaria_restore_test/<BACKUP_ID>/`
- Produktiven Vault **niemals** für Tests überschreiben.
- Restore: alle `manifest["FILES"]`-Dateien aus Backup in Zielverzeichnis kopieren.
### 6. RESTORE CONFIG
- Falls App-Config (`~/.config/com.laputa.app/`, `~/.laputa/`) gesichert wurde:
wiederherstellen. **Aktuell UNKNOWN** (kein Host-Zugang) → als Annahme behandeln.
### 7. PERMISSIONS
- Sicherstellen, dass wiederhergestellte Dateien lesbar/schreibbar sind
(Owner/Berechtigungen des Tolaria-Benutzers).
### 8. START
- Tolaria-Dienst starten (falls gestoppt).
### 9. HEALTH CHECK
- Port 5173 erreichbar.
- Vault-API `POST /api/vault/list {"path":"/app/vault"}` liefert 84 `.md`.
### 10. DATA CHECK
- Anzahl Dateien == Manifest `FILE_COUNT`.
- Stichproben-Hashes stimmen.
### 11. SEARCH CHECK
- Suche funktioniert (keyword-Substring; semantic identisch — kein Vector-Store).
### 12. GRAPH CHECK
- Kein implementierter Graph vorhanden (nur ADR-Doku). Kein Check nötig.
### 13. ROLLBACK OF RESTORE
- Falls Restore fehlschlägt: Zielverzeichnis verwerfen (isoliert),
produktiven Vault NICHT anfassen, Runbook-Status an Christian melden.
---
## Annahmen & UNKNOWN
- **Host-Restore-Prozedur** (Container-Neubau): UNKNOWN ohne Docker/Host-Zugang.
Ports 5173 (Tolaria) / 3000 (Forgejo) sind erreichbar; Container-Provisionsmethode
ist nicht verifiziert.
- App-Config-Lage: UNKNOWN (nur mit Container-Shell verifizierbar).
## Verifikation (Test am 2026-08-25)
- **Restore-Test: PASS** — 454/454 Dateien, Hash-Match, isoliert, produktiver Vault unangetastet (HEAD 69aecf2 unverändert).

View file

@ -0,0 +1,49 @@
# SEARCH ARCHITECTURE PROPOSAL — Tolaria Second Brain v1 (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **NUR VORBEREITUNG — NICHT IMPLEMENTIERT**
> Langfristig gewünscht: **HYBRID SEARCH** für Tolaria. Dieses Dokument analysiert
> die Architektur für die spätere **B5-Phase**. **Noch nichts bauen.**
---
## Ziel: HYBRID SEARCH
```
KEYWORD / FULL TEXT + SEMANTIC / VECTOR + METADATA + RELATIONSHIPS
```
## Ist-Zustand (EVIDENCE, Mission 001)
- Aktuelle Suche = **Substring/Keyword** (~1 ms), `exact`/`semantic`/`vector` Modi identisch → **keine echte semantische Suche**.
- Kein Embedding-Modell, kein Vector-Store, keine ADR für Vektoren.
## Architektur-Optionen (INFERENCE / RECOMMENDATION)
| Aspekt | Empfehlung |
|---|---|
| **Embedding-Modell** | Lokal, klein (z.B. `all-MiniLM-L6-v2` / `bge-small`) — datenschutzfreundlich, kein externer Call |
| **Vector Storage** | Lokal embedded (SQLite-VSS / LanceDB / Qdrant lokal); **kein externer Service** |
| **Rebuildbarkeit** | **Vector Index = DERIVED DATA** — vollständig aus kanonischem Wissensstand rebuildbar |
| **Incremental Updates** | Bei Änderung nur betroffene Chunks neu embedden (Diff-basiert) |
| **Chunking** | Markdown-aware: nach Heading/Paragraph, nicht blind nach Zeichen |
| **Markdown Awareness** | Frontmatter, Code-Blöcke, Wikilinks, Header-Struktur verstehen |
| **Metadata Filtering** | Über Frontmatter (type, tags, created) filtern |
| **Ranking** | Hybrid-Scoring: Keyword-Exaktheit + semantische Ähnlichkeit + Metadaten-Boost |
| **Hybrid Scoring** | Gewichtete Kombination (z.B. 60% semantic + 30% keyword + 10% metadata) |
| **Lokale vs externe Modelle** | **Lokal** bevorzugt (Datenschutz, kein Vendor-Lock) |
| **Ressourcenbedarf** | Gering (84 Dateien); ein Mini-Embedding-Modell reicht |
| **Datenschutz** | Lokale Inferenz → kein Datenabfluss |
| **Latenz** | Lokal <100 ms für kleine Korpus; gut |
## Kernregel
> **Vector Index = DERIVED DATA.** Er muss **vollständig aus dem kanonischen
> Wissensbestand rebuildbar** sein. Er ist **nie** die Source of Truth.
## Voraussetzungen (für B5)
- Kanonischer Wissensbestand (B3-Bereinigung) als stabile Basis.
- Pfad-Stabilität + Frontmatter-Konsistenz.
- Human-in-the-Loop vor produktiver Einführung (Schema-/Index-Freigabe).
## Nicht jetzt
- **Kein** Embedding erzeugen, **kein** Vector-Store produktiv einführen,
**keine** Suche ersetzen — bis B5 und ausdrückliche Freigabe.

69
tolaria/STORAGE_MAP.md Normal file
View file

@ -0,0 +1,69 @@
# STORAGE MAP — Tolaria Second Brain (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: EVIDENCE-basiert (Vault-API, read-only)
> Vollständige Storage-Map für Tolaria. Basierend auf verifizierten Pfaden
> (EVIDENCE) und dokumentierten Architekturannahmen (INFERENCE/UNKNOWN).
---
## 1. Verifizierte Speicherbereiche (EVIDENCE, via Vault-API)
| Bereich | Pfad (Container) | Persistent? | Kritisch? | Source of Truth? | Backup nötig? | Rebuildbar? | Restore-Reihenfolge |
|---|---|---|---|---|---|---|---|
| **Vault (Second Brain)** | `/app/vault` | Ja | **Ja** | **Ja** (kanonischer Wissensstand) | **Ja** | Nein (nur mit Verlust) | **1 (zuerst)** |
| Vault-Git-Metadaten | `/app/vault/.git` | Ja | **Ja** (Revisions-Identität) | Ja (History) | **Ja** | Nein | 1 (mit Vault) |
| App-Source (Frontend/Rust) | `/app/tolaria` | Ja | Nein (rebuildbar) | Nein (Forgejo=SoT) | Optional | **Ja** | 3 (nach Daten) |
| Index/Embedding-Kandidat | *(nicht vorhanden)* | | | | | | |
---
## 2. Applikations-/Konfigurationsbereiche (INFERENCE / UNKNOWN)
> Diese liegen **außerhalb** des via Vault-API verifizierbaren Bereichs und wurden
> in Mission 001 als Tauri-/App-Config identifiziert. Ohne Host-/Docker-Zugang
> **nicht abschließend verifizierbar** (UNKNOWN).
| Bereich | Pfad (typisch) | Persistent? | Kritisch? | Source of Truth | Backup nötig | Rebuildbar |
|---|---|---|---|---|---|---|
| App-Config (Tauri) | `~/.config/com.laputa.app/` | Ja | Ja | Nein | Ja | Teilweise |
| Laufzeit-Config | `~/.laputa/` | Ja | Mittel | Nein | Ja | Teilweise |
| Source-Code-Build | `/app/tolaria` (Source) | Nein (aus Build) | Nein | Nein (Forgejo) | Nein | Ja |
> **[UNKNOWN]** Exakte Persistenz der Tauri-App-Config (was in `~/.config/...`
> vs. `~/.laputa/` liegt) ist **nur mit Container-Shell** verifizierbar.
---
## 3. Cache / Temp / Attachments (INFERENCE)
| Bereich | Status |
|---|---|
| Vite-Build-Cache / node_modules | Rebuildbar, **nicht kritisch** |
| Vault-Attachments (binär) | Im Vault nicht enthalten (Vault = nur .md) → **keine separaten Attachments erkannt** (EVIDENCE: 84 .md, 0 binär) |
| Temp-Daten | Flüchtig, nicht kritisch |
| Vector-Index | **Nicht vorhanden** (keine semantische Suche; Mission 001 EVIDENCE) → rebuildbar aus Vault |
---
## 4. Backup-Priorität
| Priorität | Bereich | Begründung |
|---|---|---|
| **P1 (kritisch)** | `/app/vault` + `.git` | Einziger kanonischer Wissensbestand; Nicht rebuildbar aus anderer Quelle |
| **P2** | App-Config `~/.config/com.laputa.app/`, `~/.laputa/` | Nicht versioniert, nicht rebuildbar ohne Neu-Konfig |
| **P3** | App-Source `/app/tolaria` | Rebuildbar aus Forgejo |
---
## 5. Zusammenfassung Backup-Matrix
| Datentyp | Pfad | Versioniert? | Source of Truth | Backup-Strategie |
|---|---|---|---|---|
| Wissen (Vault) | `/app/vault/*.md` | Git (HEAD 69aecf2) | Forgejo (abgeleitet) | **Snapshot+Hash (Mission 002)** |
| Vault-Git-History | `/app/vault/.git` | | Git-Repo selbst | Export HEAD/refs/logs |
| App-Source | `/app/tolaria` | Nein | Forgejo | Rebuild (kein Backup nötig) |
| App-Config | `~/.config/com.laputa.app/` | Nein | | **UNKNOWN → bei Zugang sichern** |
**Fazit:** Die **kritische Persistenz = Vault (84 .md) + Vault-Git-Metadaten**.
Alles andere ist rebuildbar oder (App-Config) UNKNOWN/mit Host-Zugang zu klären.

View file

@ -0,0 +1,46 @@
# TRANSFORMATION SAFETY BASELINE — Tolaria Vault (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: **ERFASST (Pre-Transformation-Anker)**
> Technische Baseline des Vault-Zustands **VOR** jeder zukünftigen Wissensbereinigung.
> Jede spätere Bereinigung wird gegen diese Baseline geprüft, um zu erkennen,
> ob etwas **zerstört** wurde.
>
> Quelle: Baseline-Backup `TOLARIA-BACKUP-20260825-051420` (read-only, EVIDENCE).
---
## Baseline-Werte
| Metrik | Wert |
|---|---|
| **TOTAL FILES** | 84 |
| **TOTAL MARKDOWN** | 84 |
| **TOTAL LINKS** (Wikilinks `[[...]]`) | 12 |
| **BROKEN LINKS** | 1 |
| **ORPHAN FILES** (kein eingehender Link) | 78 |
| **DUPLICATE CANDIDATES** (Dateien in 19 Gruppen) | 38 |
| **CONFLICT CANDIDATES** (Gruppen) | 19 |
| **FILES WITH FRONTMATTER** | 58 |
| **FILES WITHOUT FRONTMATTER** | 26 |
| **GIT HEAD** | `69aecf2bb37a190fb82d933b607d2103147e07b4` |
| **WORKING TREE STATE** | CLEAN (read-only, unverändert) |
| **BACKUP_ID** | `TOLARIA-BACKUP-20260825-051420` |
## Verlinkte Dateien (EVIDENCE)
6 Dateien enthalten Wikilinks (Hub-Struktur):
- `ai-agents.md` → vps-infrastruktur, alice-betrieb
- `alice-betrieb.md` → ai-agents
- `projekte.md` → ai-agents, trading
- `start.md` → ai-agents, trading, projekte, **reference [BROKEN]**, inbox
- `trading.md` → vps-infrastruktur
- `vps-infrastruktur.md` → trading
**Broken Link:** `[[reference]]` in `start.md` → Ziel existiert nicht (1).
## Anwendung
- Diese Baseline ist der **unveränderte Pre-Transformation-Anker**.
- Nach jeder Bereinigung: Werte erneut messen → Abweichung = möglicher Schaden.
- Keine Wissensdatei wurde für diese Erfassung gelöscht/gemerged/verändert.