diff --git a/tolaria/BACKUP_ARCHITECTURE.md b/tolaria/BACKUP_ARCHITECTURE.md
new file mode 100644
index 0000000..19e9867
--- /dev/null
+++ b/tolaria/BACKUP_ARCHITECTURE.md
@@ -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).
diff --git a/tolaria/CANONICAL_KNOWLEDGE_PRINCIPLE.md b/tolaria/CANONICAL_KNOWLEDGE_PRINCIPLE.md
new file mode 100644
index 0000000..d20dfc4
--- /dev/null
+++ b/tolaria/CANONICAL_KNOWLEDGE_PRINCIPLE.md
@@ -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).
diff --git a/tolaria/DUPLICATE_RESOLUTION_PLAN.md b/tolaria/DUPLICATE_RESOLUTION_PLAN.md
new file mode 100644
index 0000000..460ddce
--- /dev/null
+++ b/tolaria/DUPLICATE_RESOLUTION_PLAN.md
@@ -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.
diff --git a/tolaria/FORGEJO_TOLARIA_SYNC_PRINCIPLE.md b/tolaria/FORGEJO_TOLARIA_SYNC_PRINCIPLE.md
new file mode 100644
index 0000000..100dcea
--- /dev/null
+++ b/tolaria/FORGEJO_TOLARIA_SYNC_PRINCIPLE.md
@@ -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).
diff --git a/tolaria/HOST_CONTAINER_DISCOVERY.md b/tolaria/HOST_CONTAINER_DISCOVERY.md
new file mode 100644
index 0000000..226c4a6
--- /dev/null
+++ b/tolaria/HOST_CONTAINER_DISCOVERY.md
@@ -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`).
diff --git a/tolaria/KNOWLEDGE_GRAPH_PRINCIPLE.md b/tolaria/KNOWLEDGE_GRAPH_PRINCIPLE.md
new file mode 100644
index 0000000..ea86852
--- /dev/null
+++ b/tolaria/KNOWLEDGE_GRAPH_PRINCIPLE.md
@@ -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).
diff --git a/tolaria/RECOVERY_RUNBOOK.md b/tolaria/RECOVERY_RUNBOOK.md
new file mode 100644
index 0000000..f66ff07
--- /dev/null
+++ b/tolaria/RECOVERY_RUNBOOK.md
@@ -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).
diff --git a/tolaria/SEARCH_ARCHITECTURE_PROPOSAL.md b/tolaria/SEARCH_ARCHITECTURE_PROPOSAL.md
new file mode 100644
index 0000000..3f527ab
--- /dev/null
+++ b/tolaria/SEARCH_ARCHITECTURE_PROPOSAL.md
@@ -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.
diff --git a/tolaria/STORAGE_MAP.md b/tolaria/STORAGE_MAP.md
new file mode 100644
index 0000000..be676e4
--- /dev/null
+++ b/tolaria/STORAGE_MAP.md
@@ -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.
diff --git a/tolaria/TRANSFORMATION_BASELINE.md b/tolaria/TRANSFORMATION_BASELINE.md
new file mode 100644
index 0000000..08801ad
--- /dev/null
+++ b/tolaria/TRANSFORMATION_BASELINE.md
@@ -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.