docs(tolaria): discovery & forensic audit — READ-ONLY IST-Zustand, 9 Analyse-Dokumente

tolaria/BUILD_PLAN_PROPOSAL.md

@@ -0,0 +1,44 @@
+# 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.

tolaria/CURRENT_STATE.md

@@ -0,0 +1,65 @@
+# Tolaria — Current State
+
+**Mission:** RED QUEEN — REAL MISSION 001 TOLARIA — DISCOVERY & FORENSIC AUDIT
+**Datum:** 2026-08-24/25
+**Autor:** Red Queen (Hermes)
+**Modus:** READ-ONLY / Autonome Analyse
+**Mutation:** VERBOTEN (keine Änderungen an Tolaria vorgenommen)
+
+---
+
+## 1. Runtime
+
+| Aspekt | Befund | Quelle |
+|--------|--------|--------|
+| Bereitstellung | Web-Version einer Tauri-Desktop-App, ausgeliefert über Vite-Dev-Server | HTTP-Probe Port 5173 |
+| Port (öffentlich) | `187.124.31.123:5173` | HTTP-Probe |
+| Version | **0.1.0** (`package.json`, `tauri.conf.json`) | `/app/tolaria/package.json` |
+| Quellcode | `/app/tolaria/` (Frontend), `/app/tolaria/src-tauri/` (Rust-Backend) | AGENTS.md / Quelltext |
+| Frontend | React + Vite + TypeScript + pnpm | `src/main.tsx` |
+| Backend | Rust (Tauri) | `src-tauri/` |
+| Wissens-Vault | `/app/vault/` (Git-basierter Markdown-Vault) | Vault-Liste |
+| API | `/api/vault/*` (HTTP-Bridge; einzige echte API) | Probe / vault-api.ts |
+| Reverse Proxy / Domain | nicht erkennbar; direkter Port 5173 | HTTP-Probe |
+
+> **EVIDENCE:** Version 0.1.0, Tauri+React+Rust, Git-Vault unter `/app/vault`, API `/api/vault/*`.
+> **INFERENCE:** Der Vite-Dev-Server läuft direkt im Container; keine separaten Reverse-Proxy-/Domain-Infos aus der Web-Schicht ablesbar.
+> **UNKNOWN:** Container-Name/Image-Konfiguration, Env-Variablen, Mounts, Volumes — **STOP-Punkt** (nur über Host-/Docker-Zugriff ermittelbar, der nicht verfügbar ist).
+
+---
+
+## 2. Wissensbestand (Kurzübersicht)
+
+- **84 Dateien** im Live-Vault `/app/vault`
+- **22 Top-Level-Modul-Dokus** (kein Frontmatter, Stand teils 20.–21.08.2026)
+- **30 Dateien** unter `notes/trading/system-docs/` (mit YAML-Frontmatter `type` + `_organized`)
+- **22 T212-Tageslogs** unter `notes/trading/second-brain/t212-logs/`
+- **~10 Hubs/Notizen** (start, trading, ai-agents, projekte, vps-infrastruktur, Phase-Dokus, journal)
+
+Detail siehe [KNOWLEDGE_AUDIT.md](KNOWLEDGE_AUDIT.md) und [DATA_MODEL.md](DATA_MODEL.md).
+
+---
+
+## 3. Zentrale Erkenntnisse
+
+1. **Tolaria = Rebranding/Evolution von Laputa Vault** (lucaong/laputa-vault). Git-first Markdown-Vault als Storage; kein klassisches DB-Schema.
+2. **Keine echte semantische Suche**: `exact`/`semantic`/`vector`-Modi liefern identische Volltext-Ergebnisse (siehe [SEARCH_AUDIT.md](SEARCH_AUDIT.md)).
+3. **Graph-Funktion vorhanden** (ADR `0123-full-vault-graph`), aber im aktuellen Wissensbestand kaum genutzt (Module unvernetzt).
+4. **19 Duplikat-Paare** zwischen Root-Modulen und `system-docs/`-Kopien (siehe [KNOWLEDGE_AUDIT.md](KNOWLEDGE_AUDIT.md)).
+5. **Forgejo-Repo `trading-system-docs` ist die versionierte Master-Quelle**; der Tolaria-Vault ist eine Teilmenge davon und hängt bei der neuesten Doku (z. B. `phase13_4_trust_gate.md`) hinterher → siehe [SOURCE_OF_TRUTH.md](SOURCE_OF_TRUTH.md).
+
+---
+
+## 4. Read-only-Nachweis / STOPP-Punkte
+
+Folgende Punkte konnten **nicht ohne Mutation/Host-Zugriff** ermittelt werden und werden daher als **STOPP-Punkte** dokumentiert:
+
+- Container-Image, Image-Tag, RestartPolicy
+- Mounts / Volumes / Bind-Mounts (exakte Pfade)
+- Compose-/Coolify-Zuordnung
+- Runtime-User (UID/GID)
+- Environment-Variablen-Werte (nur Existenz-Längen ohne Host-Zugriff möglich)
+- Docker-Netzwerke und Reverse-Proxy-Konfiguration
+- Backup-/Restore-Prozeduren (ausführbar nur via Host-Zugriff)
+
+Diese Punkte erfordern für die spätere Transformation einen Host-/Docker-Zugriff und sind kein Gegenstand dieser Read-only-Discovery.

tolaria/DATA_MODEL.md

@@ -0,0 +1,81 @@
+# Tolaria — Data Model
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+
+---
+
+## 1. Speicherarchitektur
+
+Tolaria verwendet **kein klassisches DB-Schema** (keine SQLite/Postgres-Tabellen für Wissen). Der Wissensbestand ist ein **Git-basierter Markdown-Vault** unter `/app/vault/`.
+
+| Schicht | Ort | Zweck |
+|---------|-----|-------|
+| **Vault (Wissen)** | `/app/vault/` | Git-versionierte `.md`-Dateien; Source of Knowledge |
+| **Cache** | `~/.laputa/cache/<vault-hash>.json` | Vault-Index außerhalb des Vaults (ADR-0024) |
+| **App-Config/Settings** | `~/.config/com.laputa.app/` | App-Einstellungen (ADR-0004, ADR-0177) |
+
+> **EVIDENCE:** ADRs 0004, 0024, 0177; Vault-Liste `/api/vault/list`.
+> **INFERENCE:** Der Vault ist das primäre Speichermedium; App-Settings und Cache sind sekundär und nicht Teil des Wissens.
+
+---
+
+## 2. Dateiformat
+
+- **Markdown** (`.md`)
+- **YAML-Frontmatter** (optional, bei organisierten/typisierten Notizen):
+  ```yaml
+  type: <Typ>
+  title: <Titel>
+  tags: [tag1, tag2]
+  created: YYYY-MM-DD
+  _organized: true
+  ```
+- **Wikilinks** `[[note-name]]` (Beziehungen, werden dynamisch erkannt)
+- System-Eigenschaften im Frontmatter mit `_`-Präfix (z. B. `_organized`, `_icon`)
+
+---
+
+## 3. Entity-/Typmodell (abgeleitet aus tatsächlichen Daten)
+
+Im aktuellen Bestand vorgefundene `type`-Werte:
+
+| `type` | Beispiel | Anmerkung |
+|--------|----------|-----------|
+| `Start` | `notes/start.md` | Vault-Home |
+| `Projekt` | `notes/projects/projekte.md` | Projekt-Hub |
+| `Bereich` | `notes/trading/trading.md` | Themenbereich |
+| `Agent` | `notes/ai-agents/ai-agents.md` | Agent-Übersicht |
+| `Referenz` | `notes/reference/vps-infrastruktur.md` | Referenz/Infra |
+| `Note` | `notes/trading/second-brain/Phase10c_Slippage_Deterministic.md` | Allgemeine Notiz |
+| `ADR` | `docs/adr/*.md` (App-intern) | Architecture Decision Record |
+| `Trading-Modul-System` | `system-docs/README.md` | Organisierte Systemdoku |
+
+> **INFERENCE:** Das Typmodell ist **dynamisch/frei** — `type` ist ein Freitext-Frontmatter-Feld, kein festes Enum. Die Hubs sind typisiert, die Root-Modul-Dokus sind **nicht** typisiert (kein Frontmatter).
+> **UNKNOWN:** Ob weitere Typen im ADR-/Schema-Code fix definiert sind (nur aus Vault-Daten ableitbar, nicht aus dem Produktcode ohne Source-Read).
+
+---
+
+## 4. Beziehungen
+
+- **`[[wikilinks]]`** werden dynamisch als Relationships erkannt (ADR-0010 "Dynamic Links").
+- **Frontmatter-Relationship-Felder** (`belongsTo`, `relatedTo`, `isA`) existieren im Entry-Endpunkt, sind aber im aktuellen Bestand **nicht belegt** (Module haben `relatedTo=[]`).
+- **Ist-Zustand:** Nur Hub-Notizen (`start`, `trading`, `ai-agents`) sind untereinander verlinkt. Die 19 Modul-Module sind untereinander **komplett unvernetzt** (keine Wikilinks).
+
+---
+
+## 5. Indizes / Constraints
+
+- Kein explizites DB-Schema, keine SQL-Constraints.
+- Git-Commit-Historie = impliziter Versions-/Änderungs-Index.
+- Vault-Cache-Index (ADR-0024) für schnelle Listen/Suche.
+- Frontmatter `_organized: true` markiert organisierte/typisierte Dateien.
+
+---
+
+## 6. Source / Timestamps
+
+- **Erstell-/Freigabe-Daten** stehen im Markdown-Body (z. B. `FREIGEGEBEN (20.08.2026)`) oder Frontmatter (`created:`).
+- **Root-Import-Zeitstempel:** Dateien im Vault-Root tragen eine einheitliche Batch-Mtime (`2026-08-22 18:21`) → Import-Zeitpunkt, nicht echter Inhalt.
+- **Git-Historie** des Repos `trading-system-docs` liefert versionierte Wahrheit.
+
+> **INFERENCE:** `created` ist Frontmatter-datiert; `modified` ist über die einheitliche Root-Mtime nicht je Datei verlässlich. Aktualität ist am ehesten aus Body-Datumsangaben und Git-Historie ablesbar.

tolaria/GRAPH_READINESS.md

@@ -0,0 +1,67 @@
+# Tolaria — Graph Readiness
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+
+---
+
+## 1. Vorhandene Graph-Funktionalität (EVIDENCE)
+
+- Tolaria besitzt eine **Graph-Funktion**: ADR `0123-full-vault-graph` existiert in `/app/tolaria/docs/adr/`.
+- **Dynamic Links** (ADR-0010) erkennen `[[wikilinks]]` als Relationships.
+- Frontmatter-Relationship-Felder (`belongsTo`, `relatedTo`, `isA`) sind im Entry-Endpunkt vorhanden.
+
+---
+
+## 2. Ist-Zustand der Verknüpfung (EVIDENCE)
+
+| Datei | Wikilinks |
+|-------|-----------|
+| `modul-15-monitoring-control.md` | `[]` (keine) |
+| `modul-09-execution-service.md` | `[]` (keine) |
+| `notes/trading/trading.md` | `['vps-infrastruktur']` |
+| `notes/ai-agents/ai-agents.md` | `['alice-betrieb', 'vps-infrastruktur']` |
+| `notes/start.md` | `['ai-agents', 'inbox', 'projekte', 'reference', 'trading']` |
+
+**Befund:** Die **Modul-Systemdokumente sind untereinander komplett unvernetzt** (keine Wikilinks). Nur die Hub-Notizen (`start`, `trading`, `ai-agents`) sind untereinander und auf Hubs verlinkt.
+
+> **INFERENCE:** Die Graph-Funktion existiert im Produkt, aber der aktuelle Wissensbestand nutzt sie kaum. Für einen Knowledge Graph müssten die Module erst verknüpft (oder Links aus strukturierten Feldern) abgeleitet werden.
+
+---
+
+## 3. Graph-Readiness (abgeleitete Nodes/Edges)
+
+Aus den **tatsächlichen** Tolaria-Daten ableitbare Node-Typen:
+
+| Node-Typ | Quelle (tatsächlich) | Beispiel |
+|----------|----------------------|----------|
+| `PROJECT` | `type: Projekt` | `projekte.md` |
+| `AREA` | `type: Bereich` | `trading.md` |
+| `AGENT` | `type: Agent` | `ai-agents.md`, `modul-17-hermes-agent` |
+| `REFERENCE` | `type: Referenz` | `vps-infrastruktur.md` |
+| `MODULE` | Root-Modul-Dokus | `modul-03-market-data` … |
+| `LOG` | T212-Logs | `2026-08-19_log.md` |
+| `PHASE_DOC` | Phase-Dokus | `phase10b_semantic_correction.md` |
+| `CONCEPT` | Phase-Dokus / Notizen | `Stop_Loss_Fix_2026-08-18` |
+| `ADR` | App-interne ADRs | `0123-full-vault-graph` |
+
+Abgeleitete Edge-Typen (aus vorhandenen oder plausibel ableitbaren Beziehungen):
+
+| Edge | Quelle | Status |
+|------|--------|--------|
+| `LINKED_TO` / `REFERENCES` | `[[wikilinks]]` | vorhanden (Hubs) |
+| `PART_OF` | Bereich → Module | ableitbar (Struktur) |
+| `DEPENDS_ON` | Module untereinander | fehlt (nicht dokumentiert) |
+| `SUPERSEDES` | Root neu vs docs alt | ableitbar (Duplikate) |
+| `CONFLICTS_WITH` | divergent README/Modul-09 | ableitbar |
+
+> **INFERENCE:** Graph-Readiness ist **teilweise gegeben**: Node-Typen sind ableitbar, aber **Edge-Dichte ist sehr niedrig** (Module unvernetzt). Ein voller Knowledge Graph erfordert zuerst Link-/Relation-Extraktion.
+
+---
+
+## 4. Empfehlung (RECOMMENDATION, nicht umgesetzt)
+
+- Graph muss eine **DERIVED VIEW** sein, rebuildbar aus dem Markdown-Vault (nicht primärer Store).
+- Erst die Module verknüpfen (Wikilinks oder Frontmatter-Relationships) bzw. Beziehungen aus Struktur ableiten.
+- Der Graph ist NICHT die Source of Truth.
+
+> **STOP:** KEINE Graph-Implementierung in dieser Mission. Nur Readiness-Bewertung.

tolaria/KNOWLEDGE_AUDIT.md

@@ -0,0 +1,97 @@
+# Tolaria — Knowledge Audit
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+**Befunde:** EVIDENCE (gemessen), INFERENCE (abgeleitet), UNKNOWN (nicht ermittelbar)
+
+---
+
+## 1. Wissensinventur
+
+| Kategorie | Anzahl | Details |
+|-----------|--------|---------|
+| **Top-Level-Modul-Dokus** (Root, kein Frontmatter) | 22 | `modul-01…modul-19`, Handbuch, README, Ports, Spec, vps |
+| **system-docs** (organisiert, Frontmatter) | 30 | Module + Phase-/Historical-Dokus + README |
+| **T212-Tageslogs** | 22 | `2026-07-21` … `2026-08-19` |
+| **Hubs/Notizen** | ~10 | start, trading, ai-agents, projekte, vps-infrastruktur, Journal, Phase-Dokus |
+| **Gesamt (Live-Vault)** | **84** | `/app/vault` |
+| **Forgejo-Repo** | **120** | inkl. A2–A5-Code, Red-Queen-Architektur, `phase13_4_trust_gate.md` |
+
+---
+
+## 2. Qualitätsklassifikation (Phase 5)
+
+| Kandidat | Klasse | Begründung |
+|----------|--------|------------|
+| `vps.md` (Root, 43 B) | **DELETE/STUB** | leerer Stub, nur Frontmatter-Rest |
+| 17 Duplikat-Paare (Root↔system-docs) | **DUPLICATE** | nahezu identisch, nur Frontmatter-/Newline-Diff |
+| README (Root vs system-docs) | **UPDATE/MERGE CANDIDATE** | divergent (17 vs 19/20 Module) |
+| `modul-09-execution-service` (Root vs docs) | **UPDATE CANDIDATE** | divergent (33.5 % Diff; Root enthält IG-Demo vom 21.08) |
+| `infrastructure-handbook` (Root vs docs) | **VERSIONED** | zwei Entwicklungsstände, keine direkte Kopie |
+| `modul-15-m09-anbindung-*` (Root vs docs) | **IDENTISCH** | inhaltlich gleich (nur Newline) |
+| Phase-Dokus (nur in system-docs) | **KEEP** | historische Phasen-Doku, eindeutig |
+
+> **EVIDENCE:** Größen-/Hash-/Diff-Vergleiche via `/api/vault/content`.
+> **INFERENCE:** Kein Kandidat ist offensichtlicher "Müll"; die Duplikate sind echte Doppel-Ablagen desselben Inhalts in zwei Verzeichnissen.
+
+---
+
+## 3. Duplikat-Analyse (Phase 6)
+
+**19 Duplikat-Paare** zwischen `Root/*.md` und `notes/trading/system-docs/*.md`.
+
+| Vergleich | Befund |
+|-----------|--------|
+| Größen nahezu identisch | ja, bei 17 von 19 Paaren (Diff ≤ ~60 B = Frontmatter/Newline) |
+| Inhaltlich (nach Newline-Normalisierung) | bei den meisten Paaren **identisch** |
+| Signifikant divergent | **README** (11.7 %), **modul-09** (33.5 %) |
+| Inhaltlich identisch (nur Newline) | `modul-15-m09-anbindung-design` + `-implementierung` |
+
+**Klassifikation:**
+
+| Paar | Klasse | Detail |
+|------|--------|--------|
+| modul-03…07,10,11,12,13,14,15,18,19 (16 Paare) | **EXACT/NEAR-EXACT DUPLICATE** | gleicher Body, nur Frontmatter/Newline |
+| README | **VERSIONED INFORMATION** | zwei Entwicklungsstände (17 vs 19/20 Module) |
+| modul-09 | **VERSIONED INFORMATION** | Root neuer (IG-Demo 21.08), docs älter |
+| infrastructure-handbook | **VERSIONED INFORMATION** | abweichende Stände |
+
+> **INFERENCE:** Die `system-docs/`-Kopien sind ein **älterer organisierter Snapshot** (20.08, 17 Module), die Root-Dateien ein **neuerer Roh-Import** (22.08, 19 Module). Duplikate sind eine Ablage-Doppelung, nicht semantische Duplikate.
+> **UNKNOWN:** Ob das beabsichtigt ist (organisierte Kopie vs Roh) oder ein Fehler — Christian entscheidet später.
+
+---
+
+## 4. Konflikt-Analyse (Phase 7)
+
+| Konflikt | Klasse | Evidenz |
+|----------|--------|---------|
+| README: **"17 Module"** (system-docs, 20.08) vs **"19 Module"** (Root, 21.08) | **POSSIBLE CONFLICT / HISTORICAL VERSION** | zwei Entwicklungsstände, keine gegenseitige Übernahme |
+| Modul-09: IG-Demo-Adapter (21.08) nur in Root, nicht in docs | **HISTORICAL VERSION** | Root aktueller, docs älter |
+| Struktur: Root-Module ohne Frontmatter vs system-docs mit `type` | **UNKNOWN** | zwei organistische Layouts, kein direkter Widerspruch |
+
+> **INFERENCE:** Es sind **Entwicklungsstände**, keine echten inhaltlichen Widersprüche. Der "neue" Stand ist durchgehend der Root (22.08-Import), der "alte" der system-docs (20.08).
+> **RECOMMENDATION:** Vor Zusammenführung Root als autoritativ prüfen, da dieser die neueren Module (18, 19) und neuesten Freigabedaten enthält.
+
+---
+
+## 5. Aktualität (Phase 8)
+
+| Element | Stand | Quelle |
+|---------|-------|--------|
+| Modul-03…15 Freigabe | **20.08.2026** | Body `FREIGEGEBEN` |
+| Modul-18, 19 Freigabe | **21.08.2026** | Body `FREIGEGEBEN` |
+| Root-Import (Vault) | **22.08.2026** | einheitliche Mtime |
+| T212-Tageslogs | bis **19.08.2026** | Dateinamen |
+| Phase9, 10a, historical-v2 | **22.08.2026** | Body |
+| Phase10b, 10d | **23.08.2026** | Body |
+| Phase 13.4 Trust Gate (nur Forgejo-Repo) | **24.08.2026** | Body |
+
+> **EVIDENCE:** Der Live-Vault enthält **NICHT** `phase13_4_trust_gate.md` (24.08), das nur im Forgejo-Repo liegt → **der Vault hinkt bei der neuesten Doku hinterher**.
+> **INFERENCE:** Vault zuletzt am 22.08 importiert; seitdem neuer Stand nur in Forgejo.
+
+---
+
+## 6. Fazit
+
+- **Gut:** Klare Modul-Doku, konsistente Freigabedaten, saubere Log-Struktur, gut versioniert (Git).
+- **Schwach:** 19 Duplikat-Paare, keine semantische Suche, Root-Module untypisiert/unvernetzt, `vps.md` leerer Stub, Vault hinter Forgejo zurück.
+- **Keine Löschung, kein Merge, keine Migration** in dieser Mission (READ-ONLY).

tolaria/README.md

@@ -0,0 +1,35 @@
+# Tolaria Discovery & Forensic Audit
+
+**Mission:** RED QUEEN — REAL MISSION 001 TOLARIA — DISCOVERY & FORENSIC AUDIT
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen (Hermes) · **Modus:** READ-ONLY · **Mutation:** VERBOTEN
+
+Dieses Verzeichnis dokumentiert den vollständigen, read-only verifizierten IST-Zustand der Tolaria-Installation auf Christians VPS (`187.124.31.123:5173`) als Grundlage für das spätere Ziel **TOLARIA SECOND BRAIN v1**.
+
+## Dokumente
+
+| Datei | Inhalt |
+|-------|--------|
+| [CURRENT_STATE.md](CURRENT_STATE.md) | Runtime, Version, Deployment, Read-only-STOPP-Punkte |
+| [DATA_MODEL.md](DATA_MODEL.md) | Datenmodell (Git-Vault, Frontmatter, Typen, Beziehungen) |
+| [KNOWLEDGE_AUDIT.md](KNOWLEDGE_AUDIT.md) | Wissensinventur, Qualität, Duplikate, Konflikte, Aktualität |
+| [SEARCH_AUDIT.md](SEARCH_AUDIT.md) | Suchbefund (keine echte semantische Suche) |
+| [GRAPH_READINESS.md](GRAPH_READINESS.md) | Graph-Funktion, Node-/Edge-Ableitung, Readiness |
+| [SOURCE_OF_TRUTH.md](SOURCE_OF_TRUTH.md) | Forgejo vs Tolaria vs Red Queen (Master vs derived) |
+| [RISK_ASSESSMENT.md](RISK_ASSESSMENT.md) | Transformationsrisiken (LOW–CRITICAL) |
+| [TARGET_ARCHITECTURE_PROPOSAL.md](TARGET_ARCHITECTURE_PROPOSAL.md) | Zielarchitektur v1 (Vorschlag) |
+| [BUILD_PLAN_PROPOSAL.md](BUILD_PLAN_PROPOSAL.md) | Work-Package-Build-Plan B1–B10 (Vorschlag) |
+
+## Kernbefunde (Kurzfassung)
+
+1. **Runtime:** Tauri-Desktop-App (React+Vite+TS+Rust), Web-Version, Version **0.1.0**, Vault `/app/vault`, API `/api/vault/*`.
+2. **Storage:** Git-basierter Markdown-Vault, kein DB-Schema.
+3. **Wissen:** 84 Dateien; 22 Root-Module, 30 system-docs, 22 T212-Logs, Hubs.
+4. **Duplikate:** 19 Paare Root↔system-docs (meist identisch; README + Modul-09 divergent).
+5. **Suche:** keine echte semantische Suche (`exact`/`semantic`/`vector` identisch).
+6. **Source of Truth:** Forgejo-Repo `trading-system-docs` ist Master; Vault ist Teilmenge und hinkt hinterher.
+7. **Graph:** Funktion existiert (ADR 0123), aber Module unvernetzt → Graph-Readiness mittel.
+
+## Status
+
+- **Keine Mutation:** Keine Datei/Löschung/Migration/Graph/Sync in dieser Mission.
+- **Nächster Schritt:** warten auf Freigabe **"TOLARIA SECOND BRAIN v1 — BUILD"**.

tolaria/RISK_ASSESSMENT.md

@@ -0,0 +1,40 @@
+# Tolaria — Risk Assessment
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+
+**Skala:** LOW / MEDIUM / HIGH / CRITICAL
+
+---
+
+## 1. Risiko-Tabelle (für spätere Transformation)
+
+| Risiko | Bewertung | Begründung / Mitigation |
+|--------|-----------|-------------------------|
+| **DATA LOSS** | **HIGH** | Vault ist Git-versioniert (gute Grundlage), aber kein Backup-/Restore-Verfahren verifiziert. Erst Backup-Basis (B1) vor jedem Umbau. |
+| **BROKEN REFERENCES** | **MEDIUM** | Wikilinks dynamisch; bei Datei-Umbenennung/-Merge können Links brechen. Wiederverlinkung testen. |
+| **BROKEN RELATIONS** | **MEDIUM** | Frontmatter-Relationships kaum genutzt; bei Restrukturierung müssten Relationen neu abgeleitet werden. |
+| **DUPLICATE MERGE ERROR** | **HIGH** | 19 Duplikat-Paare; Zusammenführung ohne saubere Versionsbestimmung (Root vs docs) kann Info verlieren. Merge nur mit Diff + Freigabe. |
+| **FALSE CONFLICT** | **MEDIUM** | README 17-vs-19/20-Module ist Entwicklungsstand, kein Widerspruch; Auto-Erkennung könnte False Positives melden. Human-in-the-Loop nötig. |
+| **OUTDATED KNOWLEDGE** | **MEDIUM** | Vault hinkt Forgejo hinterher (22.08 vs 24.08); ohne Sync werden Inhalte veraltet. |
+| **GRAPH DRIFT** | **LOW** | Graph als derived view ist rebuildbar; Drift-Risiko gering, solange Quelle der Graph-Ableitung definiert ist. |
+| **SEARCH REGRESSION** | **MEDIUM** | Einführung von Semantik/Embeddings kann bestehende Keyword-Suche verändern; Regression-Tests vorhalten. |
+| **SCHEMA MIGRATION** | **MEDIUM** | Kein DB-Schema, aber Frontmatter-Felder; Umstieg auf strukturierte Typen ist Migration über viele Dateien. |
+| **AUTH/IDENTITY** | **LOW** | Read-only-Zugriff über offenen Port 5173; aktuell keine Schreib-API/ Auth sichtbar. Später schreibende API braucht Auth. |
+| **SECRET EXPOSURE** | **HIGH** | Vault/Repo muss frei von Tokens bleiben (0 Treffer aktuell); Sync/Scans vor jedem Push. Keine Secrets in Doku. |
+| **FORGEJO DRIFT** | **HIGH** | Zwei Systeme (Forgejo + Vault) können divergieren; klare Einbahn Forgejo→Tolaria + Synchronisierung nötig, sonst verliert die "aufbereitete Sicht" die Wahrheit. |
+| **ROLLBACK FAILURE** | **HIGH** | Restore-Mechanik unverifiziert; Backups müssen vor Transformation getestet werden (Restore-Drill). |
+
+---
+
+## 2. Größte kritische Risiken
+
+1. **FORGEJO DRIFT + OUTDATED KNOWLEDGE** (MEDIUM–HIGH): Ohne definierten Sync-Pfad Forgejo→Tolaria veralten die aufbereiteten Inhalte.
+2. **DUPLICATE MERGE ERROR** (HIGH): 19 Duplikate; vorschnelles Zusammenführen (ohne autoritative Stand-Bestimmung) kann Infos verschütten.
+3. **SECRET EXPOSURE** (HIGH): Muss bei jeder zukünftigen automatisierten Integration (Git-Pull, Sync) kontrolliert werden.
+
+---
+
+## 2. STOPP-Punkte
+
+- Keine Mitigation wird in dieser Mission umgesetzt (READ-ONLY).
+- Die Bewertung dient als Grundlage für den [BUILD_PLAN_PROPOSAL.md](BUILD_PLAN_PROPOSAL.md), insbesondere B1 (Backup) und B2 (Inventory) als Vorbedingung.

tolaria/SEARCH_AUDIT.md

@@ -0,0 +1,69 @@
+# Tolaria — Search Audit
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+
+---
+
+## 1. Befund (EVIDENCE)
+
+Die Vault-Such-API (`/api/vault/search`) wurde mit verschiedenen `mode`-Parametern getestet:
+
+| Mode | Ergebnis (Scores/Reihenfolge) | echte semantische Suche? |
+|------|------------------------------|--------------------------|
+| `exact` | identische Treffer wie unten | nein |
+| `fuzzy` | gleiche Ranking-Logik | nein |
+| `semantic` | **identisch** zu `exact`/`vector` | **nein** |
+| `vector` | **identisch** zu `exact`/`semantic` | **nein** |
+| `tags` / `filename` | Filter-/Namensvariante | — |
+
+**Kernbefund:** `exact`, `semantic` und `vector` liefern **identische Ergebnisse** (gleiche Scores/Reihenfolge). Es gibt **kein Embedding, keinen Vector-Store, keine echte semantische Suche**.
+
+- Die Suche ist eine **Rust-Substring-/Keyword-Suche** (`src-tauri/src/search.rs`): Titel-Wort +10, Titel-Substring +5, Content-Treffer ×0.5, Cap 20.
+- Der `mode`-Parameter wird in `search_vault_with_options` **ignoriert**; alle Modi fallen auf dieselbe Implementierung zurück.
+
+> **EVIDENCE:** Direkte API-Proben + Quelltext-Read (`search.rs`).
+> **INFERENCE:** Die Suche ist eine schnelle Volltext-/Substring-Suche ohne Embeddings.
+
+---
+
+## 2. Suchgeschwindigkeit
+
+| Query | elapsed_ms | Treffer |
+|-------|-----------|---------|
+| `Modul-15` | 1 | 15 |
+| `Stop-Loss` | 1 | 2 |
+| `backtesting` | 1 | 16 |
+| `rabbitmq` | 1 | 20 |
+
+**Befund:** Sehr schnell (1 ms) für 84 Dateien — reine In-Memory-Substring-Suche, kein Netzwerk-/Vector-Aufwand.
+
+---
+
+## 3. Was funktioniert / was fehlt
+
+**Funktioniert:**
+- Exakte/substring Keyword-Suche ✓
+- Ranking nach Titel-Wort/Substring ✓ (heuristisch)
+- Filter über `tags`/`filename` ✓
+- Sehr niedrige Latenz ✓
+
+**Fehlt (für Second-Brain-Ziel):**
+- **Semantische Suche** (Begriffe ≠ exakte Wörter) ✗
+- **Embeddings / Vector-Store** ✗
+- **Hybrid-Suche** (Keyword + semantisch) ✗
+- **Konzept-/Synonym-Auflösung** ✗
+- Dafür kein ADR im Bestand (`docs/adr/`) ✓ (bestätigt)
+
+---
+
+## 4. Skalierung
+
+- Bei 84 Dateien ist 1 ms unkritisch.
+- Bei tausenden Dateien skaliert eine In-Memory-Substring-Suche linear; ohne Index/Embeddings wird sie bei großem Vault langsam und unpräzise.
+- **Einschätzung (INFERENCE):** Für den aktuellen Umfang ausreichend; für ein langfristiges Second Brain (tausende Notes) nicht skalierbar ohne Index/Embeddings.
+
+---
+
+## 5. Fazit
+
+Die Suche ist **technisch korrekt implementiert** (schnell, deterministisch), aber **semantisch eingeschränkt**. Die drei "semantisch" klingenden Modi sind funktional identisch und liefern keine Synonym-/Konzept-Treffer. Das ist die größte Suchlücke für das Second-Brain-Ziel.

tolaria/SOURCE_OF_TRUTH.md

@@ -0,0 +1,53 @@
+# Tolaria — Source of Truth
+
+**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
+
+---
+
+## 1. Empirischer Befund (EVIDENCE)
+
+| System | Dateien | Stand | Rolle |
+|--------|---------|-------|-------|
+| **Forgejo-Repo** `trading-system-docs` | **120** | aktueller (enthält `phase13_4_trust_gate.md`, 24.08) | versionierte Master-Quelle |
+| **Tolaria-Vault** `/app/vault` | **84** (Teilmenge) | hinkt (letzter Import 22.08) | Arbeitskopie / Konsum-Sicht |
+
+- Der Live-Vault `/app/vault` ist **inhaltlich identisch** mit den korrespondierenden Dateien im Forgejo-Repo (nach Newline-Normalisierung verifiziert).
+- Der Vault enthält **alle** 84 seiner Dateien auch im Repo; das Repo enthält **zusätzlich** A2–A5-Code, Red-Queen-Architektur und `phase13_4_trust_gate.md`.
+- **`phase13_4_trust_gate.md` (24.08.2026) existiert NUR im Forgejo-Repo, NICHT im Live-Vault** → der Vault hängt bei der neuesten Doku hinterher.
+
+> **INFERENCE:** Der Forgejo-Repo ist der **versionierte Git-Remote / Master**, der Tolaria-Vault die **lokale Arbeitskopie** eines Teilbereichs. Neue Dokumentation (z. B. Phase 13.4) landet zuerst in Forgejo und erreicht den Vault erst beim nächsten Import/Pull.
+
+---
+
+## 2. Bewertung der vorgeschlagenen Trennung
+
+Die Mission-Hypothese lautete:
+
+- **FORGEJO** = technische/versionierte Projektwahrheit
+- **TOLARIA** = aufbereitetes, verknüpftes Wissenssystem
+- **RED QUEEN** = Knowledge Steward
+
+**Befund (INFERENCE):** Diese Trennung ist **grundsätzlich sinnvoll und teilweise bereits real**, allerdings mit umgekehrter Einbahn:
+- Aktuell ist Forgejo die **Wahrheitsquelle** (Master), Tolaria ein **Spiegel/Teilmenge**.
+- Die "aufbereitete, verknüpfte" Tolaria-Sicht ist erst **schwach ausgeprägt** (Module unvernetzt, kein semantisches Modell).
+- Red Queen ist durch das Forgejo-Repo bereits de-facto Steward (schreibt Dokumentation, hält versionierte Wahrheit).
+
+---
+
+## 3. Empfohlene Ziel-Rollen (RECOMMENDATION)
+
+| System | Soll-Rolle | Verantwortlich |
+|--------|-----------|----------------|
+| **Forgejo** | **Master / Source of Truth** (versioniert, versionierte technische Wahrheit) | Red Queen (schreibt/versioniert) |
+| **Tolaria** | **Derived, aufbereitete Wissens-Sicht** (verknüpft, semantisch) | Red Queen (pflegt als Steward) |
+| **Red Queen** | **Knowledge Steward** (konsolidiert, konflikt-erkennt, pflegt) | Red Queen |
+
+> **RECOMMENDATION:** Forgejo bleibt die autoritative Quelle (Git-Historie = Wahrheit). Tolaria wird zur verknüpften, aufbereiteten Sicht, die **ableitbar** aus dem Forgejo-Wissensstand ist. Red Queen synchronisiert gezielt Forgejo → Tolaria (nicht umgekehrt), um Drift zu vermeiden.
+
+---
+
+## 4. STOPP-Punkte
+
+- Diese Mission implementiert **keine** Synchronisierung.
+- **Keine** Änderung von Vault oder Repo-Inhalten.
+- Es wird nur der IST-Zustand und die Ziellogik dokumentiert.

tolaria/TARGET_ARCHITECTURE_PROPOSAL.md

@@ -0,0 +1,42 @@
+# 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
+
+1. **Forgejo = Source of Truth** (versioniert), Tolaria = derived, aufbereitete Sicht.
+2. **Graph = derived view**, rebuildbar aus dem Markdown-Vault (nie primärer Store).
+3. **Human-in-the-Loop** bei echten Wissenskonflikten (Christian entscheidet).
+4. **Backup vor jeder Mutation**; Restore-Drill vor Transformation.
+5. **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).