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:
parent
1dc44d3b4f
commit
819fd8a6ff
10 changed files with 622 additions and 0 deletions
72
tolaria/BACKUP_ARCHITECTURE.md
Normal file
72
tolaria/BACKUP_ARCHITECTURE.md
Normal 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).
|
||||||
42
tolaria/CANONICAL_KNOWLEDGE_PRINCIPLE.md
Normal file
42
tolaria/CANONICAL_KNOWLEDGE_PRINCIPLE.md
Normal 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).
|
||||||
76
tolaria/DUPLICATE_RESOLUTION_PLAN.md
Normal file
76
tolaria/DUPLICATE_RESOLUTION_PLAN.md
Normal 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.
|
||||||
45
tolaria/FORGEJO_TOLARIA_SYNC_PRINCIPLE.md
Normal file
45
tolaria/FORGEJO_TOLARIA_SYNC_PRINCIPLE.md
Normal 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).
|
||||||
95
tolaria/HOST_CONTAINER_DISCOVERY.md
Normal file
95
tolaria/HOST_CONTAINER_DISCOVERY.md
Normal 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`).
|
||||||
43
tolaria/KNOWLEDGE_GRAPH_PRINCIPLE.md
Normal file
43
tolaria/KNOWLEDGE_GRAPH_PRINCIPLE.md
Normal 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).
|
||||||
85
tolaria/RECOVERY_RUNBOOK.md
Normal file
85
tolaria/RECOVERY_RUNBOOK.md
Normal 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).
|
||||||
49
tolaria/SEARCH_ARCHITECTURE_PROPOSAL.md
Normal file
49
tolaria/SEARCH_ARCHITECTURE_PROPOSAL.md
Normal 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
69
tolaria/STORAGE_MAP.md
Normal 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.
|
||||||
46
tolaria/TRANSFORMATION_BASELINE.md
Normal file
46
tolaria/TRANSFORMATION_BASELINE.md
Normal 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.
|
||||||
Loading…
Reference in a new issue