notion-safety-brain: Mission 003 Discovery & Architecture docs (11 files)

Red Queen - REAL MISSION 003 NOTION SAFETY BRAIN DISCOVERY & ARCHITECTURE.
One-Way Safety-Brain-Design (Forgejo/Tolaria -> Notion, keine Source of Truth),
Provenance-Modell, Backup-Manifest, Verify (WRITE != SUCCESS), Restore Human Gate,
Secret-Policy, Scaling/Versions/Delete-Safety, RQ-Access (Minimum Privilege).
Fresh Checker PASS. READ-ONLY, keine Notion-Implementierung.

notion-safety-brain/ACCESS_ARCHITECTURE.md

@@ -0,0 +1,54 @@
+# NOTION SAFETY BRAIN — Access & Architecture (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DISCOVERY + ARCHITECTURE (READ-ONLY)**
+
+> Notion als **externer Safety Brain / Disaster-Recovery-Wissensspeicher** für
+> **zwei getrennte Systeme**: Forgejo (technische Source of Truth) und Tolaria
+> (operatives Second Brain). **Notion ist KEINE neue Source of Truth.**
+
+---
+
+## 1. Architekturprinzip
+
+```
+FORGEJO  ────────────►  NOTION SAFETY BRAIN
+TOLARIA  ────────────►  NOTION SAFETY BRAIN
+
+NICHT (kein Rückfluss):
+NOTION ────────────► FORGEJO / TOLARIA
+```
+
+- **ONE-WAY** Datenfluss: Quelle → Notion.
+- Ein Fehler / falsche Bearbeitung / Löschung in Notion darf **niemals** Forgejo oder Tolaria verändern.
+- **Kein** bidirektionaler Sync. **Kein** automatischer Rück-Sync.
+
+## 2. Rollen
+
+| System | Rolle |
+|---|---|
+| **FORGEJO** | technische/versionierte Source of Truth |
+| **TOLARIA** | operatives Second Brain / Knowledge System |
+| **NOTION** | externer Safety Brain / Knowledge Backup / Disaster-Recovery View |
+
+> Notion ist ausdrücklich **KEINE Source of Truth** — sondern ein abgeleiteter,
+> externer Sicherungsspeicher.
+
+## 3. Ausgangslage (EVIDENCE)
+- Christians Notion wurde **bewusst geleert** (vorher unbrauchbare Inhalte) → saubere Struktur von Grund auf planbar.
+- Rain und Alice besitzen bereits funktionierenden Notion-Zugriff.
+- **Red Queen hat aktuell KEINEN eigenen Notion-Zugriff** (kein `NOTION_API_KEY`, kein `ntn`, keine Config) — verifiziert via read-only Discovery.
+
+## 4. Zugangskonzept — Red Queen (MINIMUM NECESSARY PRIVILEGE)
+- Red Queen erhält einen **eigenen, sauber getrennten, minimal privilegierten** Notion-Zugriff.
+- **Kein Credential-Transfer** von Rain/Alice. **Keine** fremden Tokens kopieren.
+- **Keine Owner-/Admin-Rechte** — nur der Scope, den der Safety-Brain-Write benötigt.
+- Empfohlener Weg (Implementierung erst nach Freigabe):
+  - Eigene Notion-Integration anlegen (Read+Insert) mit dediziertem Token.
+  - Token in `${HERMES_HOME}/.env` als `NOTION_API_KEY` (nie ausgeben).
+  - Nur die nötigen Safety-Brain-Seiten/DBs mit der Integration teilen (Seiten-`...` → Connect to).
+  - **Keine Secrets in den Artefakten**; Token nur ephemer nutzen.
+
+## 5. Kein-Cloud-Write in dieser Mission
+- Diese Mission ist **READ-ONLY** (Discovery + Architecture).
+- Kein Anlegen von Notion-Seiten, keine Datenbank, kein Schreiben, kein Sync, kein Cron.
+- Produktive Daten / Credentials / Berechtigungen bleiben unverändert.

notion-safety-brain/BACKUP_MANIFEST.md

@@ -0,0 +1,34 @@
+# NOTION SAFETY BRAIN — BACKUP MANIFEST (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (nicht implementiert)**
+
+> Ein Backup-Run erzeugt ein Manifest, das Lauf-Ergebnis und Verifikation abbildet.
+> **Ein Backup ist NICHT allein deshalb erfolgreich, weil ein API-Write HTTP 200 lieferte.**
+
+## Manifest-Felder
+```
+BACKUP_RUN_ID
+TIMESTAMP
+FORGEJO_HEAD
+TOLARIA_HEAD
+FORGEJO_OBJECTS_EXPECTED
+FORGEJO_OBJECTS_BACKED_UP
+TOLARIA_OBJECTS_EXPECTED
+TOLARIA_OBJECTS_BACKED_UP
+SKIPPED_OBJECTS
+FAILED_OBJECTS
+SECRET_BLOCKED_OBJECTS
+HASH_STATUS
+VERIFY_STATUS
+RESULT
+```
+
+- `HASH_STATUS` = `all_match` | `mismatch` (alle Source-Hashes vs. Notion-read-back).
+- `VERIFY_STATUS` = `verified` | `unverified`.
+- `RESULT` = `BACKUP VERIFIED` nur wenn Write + Read-back + Compare + Hash + Count + Logs ok.
+
+## Registry-Zuordnung
+Manifest-Zeile wird in Notion-DB **05 Backup Registry** je RUN_ID abgelegt (siehe RESTORE_MODEL.md).
+
+## Verify-Prinzip (WRITE ≠ SUCCESS)
+1. Write → 2. Read-back → 3. Compare → 4. Hash/Version-Check → 5. Count-Match → 6. Error/Skip-Log → **BACKUP VERIFIED**.

notion-safety-brain/BUILD_PLAN.md

@@ -0,0 +1,45 @@
+# NOTION SAFETY BRAIN — BUILD PLAN (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **PLAN (nicht implementiert)**
+
+> Konkretes, gestuftes Umsetzungsmodell. Jede Phase erst nach **ausdrücklicher Freigabe** durch Christian.
+
+---
+
+## Phase 0 — Access (Red Queen)
+- [ ] Eigene Notion-Integration anlegen (Read + Insert), minimal privilegiert.
+- [ ] `NOTION_API_KEY` in `${HERMES_HOME}/.env` (nie ausgeben, nur EXISTS/LENGTH).
+- [ ] Nur Safety-Brain-Seiten/DBs mit der Integration teilen.
+- [ ] Kein Credential-Transfer von Rain/Alice.
+
+## Phase 1 — Struktur in Notion anlegen
+- [ ] Root-Seite **KI-SYSTEM — SAFETY BRAIN**.
+- [ ] Bereiche 00–10 (siehe NOTION_STRUCTURE.md).
+- [ ] Datenbank `05 Backup Registry` + `07 Knowledge Index`.
+
+## Phase 2 — Backup-Engine (lokal)
+- [ ] Secret-Scan (SECRET_POLICY.md) fest einbauen.
+- [ ] Provenance-Frontmatter (PROVENANCE_MODEL.md) je Objekt.
+- [ ] Incremental / Hash-Change-Detection (SCALING_MODEL.md).
+- [ ] Manifest-Erzeugung (BACKUP_MANIFEST.md).
+
+## Phase 3 — Verify & Registry
+- [ ] READ-BACK + COMPARE + Hash-Verify (WRITE ≠ SUCCESS).
+- [ ] Registry-Zeilen pflegen.
+
+## Phase 4 — Restore-Modul
+- [ ] Staging → Validate → Human Review → Approval → Restore (RESTORE_MODEL.md).
+
+## Phase 5 — Red Queen als Knowledge Backup Steward
+- Änderungen erkennen · klassifizieren · Secrets blocken · Delta · Backup schreiben ·
+  zurücklesen · verifizieren · Manifest · Status · Fehler melden.
+
+> **NOCH NICHT AUTOMATISIEREN.** Kein Cron / Daemon / Heartbeat in dieser Mission.
+> **A5 bleibt AUS.**
+
+---
+
+## Wichtig
+- Diese Mission = **Discovery + Architecture + Checker + Forgejo-Doku**, dann **STOPP**.
+- Kein Bau von Notion-Seiten, keine Datenbank, kein Upload, kein Sync, kein Cron.
+- Warte auf Christians ausdrückliche Freigabe vor Phase 1.

notion-safety-brain/CURRENT_STATE.md

@@ -0,0 +1,24 @@
+# NOTION SAFETY BRAIN — CURRENT STATE (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **READ-ONLY Discovery-Stand**
+
+## Notion
+- **WORKSPACE:** nicht verifizierbar ohne Zugriff (Red Queen hat noch kein Token) — UNKNOWN bis Phase 0.
+- **AUTH METHOD:** geplant = eigene Notion-Integration (OAuth-token-basiert), min. privilegiert.
+- **PERMISSIONS (Red Queen):** keine — Zugriff noch NICHT eingerichtet.
+- **CURRENT NOTION STATE:** bewusst geleert (Christian) → saubere Struktur planbar. Kein Inhalt von RQ verifizierbar (kein Zugang).
+
+## Red Queen Zugriff
+- **TOKEN_EXISTS=NO** · `ntn` CLI: nicht installiert · keine Notion-Config/Credential-Datei unter RQ-Volume.
+
+## Rain / Alice
+- Haben funktionierenden Notion-Zugriff (Missionsangabe). **Nicht herangezogen** für Credentials.
+- Diese Mission: **RAIN REFERENCE USED = NO**, **ALICE REFERENCE USED = NO** (kein Credential-Transfer nötig; Architekturweg dokumentiert).
+
+## Quellen-Stand (EVIDENCE)
+- **Forgejo** `main` = `819fd8a` (Repo-Struktur lokal verifiziert).
+- **Tolaria** Vault = HEAD `69aecf2…`, 84 .md (API-Read verifiziert).
+
+## Grundsatz (verbindlich)
+- Notion = externer Safety Brain, **KEINE Source of Truth**.
+- **One-Way** von Forgejo/Tolaria → Notion. Kein Rückfluss.

notion-safety-brain/DATA_CLASSIFICATION.md

@@ -0,0 +1,55 @@
+# NOTION SAFETY BRAIN — DATA CLASSIFICATION (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **EVIDENCE-basiert (read-only)**
+
+> Klassifikation, welche Inhalte aus Forgejo und Tolaria in den Notion Safety Brain
+> gesichert werden sollen. Kategorien:
+> **BACKUP_REQUIRED** · **BACKUP_RECOMMENDED** · **OPTIONAL** · **DO_NOT_BACKUP** · **SECRET/FORBIDDEN**
+
+---
+
+## 1. FORGEJO (technische Source of Truth)
+
+EVIDENCE (lokaler Klon `/opt/data/forgejo/trading-system-docs`, main=`819fd8a`):
+
+| Inhalt | Kategorie | Begründung |
+|---|---|---|
+| `red-queen-architecture/` (10 Contracts) | **BACKUP_REQUIRED** | Architektur-Entscheidungen, Safety/External-Review-Contracts, MISSION_STATE_MACHINE |
+| `tolaria/` (Discovery-Report, B1-Docs) | **BACKUP_REQUIRED** | Tolaria-Dokumentation, Baseline, Recovery-Runbook |
+| `a2/`..`a5/` (Design/README/Code) | **BACKUP_RECOMMENDED** | Red-Queen-Automatisierung, relevant für Recovery |
+| Modul-Doku (`modul-*.md`, `ports-reference`, `infrastructure-handbook`, `trend-pullback-spec`) | **BACKUP_RECOMMENDED** | System-/Modul-Dokumentation |
+| `backup_patches/` | **BACKUP_RECOMMENDED** | Wichtige Patches |
+| `notes/` (Hubs/Wikilinks) | **BACKUP_RECOMMENDED** | Verknüpfungs-Struktur |
+| `README.md` | OPTIONAL | Überblick (bereits in modul-Doku enthalten) |
+| `__pycache__/`, `.git/`, Binär-/Build-Artefakte | **DO_NOT_BACKUP** | Rebuildbar, keine Knowledge-Inhalte |
+| `.env`, `*.pem`, `*.key`, `*.token`, config mit Secrets | **SECRET/FORBIDDEN** | Nie nach Notion |
+
+**Doppel-Zählung beachten:** Modul-Dateien existieren teils auch im Vault (Root + system-docs) → Deduplizierung nötig (siehe Provenance).
+
+## 2. TOLARIA (operatives Second Brain, 84 .md via API)
+
+EVIDENCE (Vault-API, `/app/vault`, HEAD `69aecf2…`):
+
+| Bereich | Kategorie | Begründung |
+|---|---|---|
+| `notes/trading/second-brain/` (journal, t212-logs, Phase-Docs) | **BACKUP_REQUIRED** | Operative Knowledge-Logs, Verlauf |
+| `notes/trading/system-docs/*` (30) | **BACKUP_RECOMMENDED** | Modul-/System-Doku (teils identisch mit Forgejo → dedupe) |
+| `/app/vault/*.md` Root (README, infrastructure-handbook, modul-*) | **BACKUP_RECOMMENDED** | Duplikat-Struktur (19 Paare) |
+| `notes/` Hubs (ai-agents, alice-betrieb, projekte, start, inbox, trading, reference) | **BACKUP_RECOMMENDED** | Wikilink-/Hub-Struktur, Beziehungen |
+| **Frontmatter / Wikilinks / Provenance** | **BACKUP_REQUIRED** (als Metadaten) | Für Beziehungs-/Graph-Rebuild |
+| `.git/` (Objects) | **DO_NOT_BACKUP** via API | Binär, nicht via JSON-API vollständig ziehbar; separat technisch sichern |
+| secrets in Frontmatter/Inhalt (falls vorhanden) | **SECRET/FORBIDDEN** | Secret-Scan vor Upload |
+
+## 3. Kategorientabelle (Provenance-Vorbereitung)
+
+Jede Notion-Seite erhält im Frontmatter/Property die Quelle:
+`SOURCE_SYSTEM` (forgejo|tolaria), `SOURCE_PATH`, `SOURCE_HASH`, `SOURCE_VERSION` (git-HEAD / Vault-HEAD).
+
+## 4. Zwei-Quellen-Prinzip
+- Forgejo und Tolaria enthalten **nicht zwingend** dieselben Informationen.
+- Notion sichert **beide getrennt und nachvollziehbar** (je `SOURCE_SYSTEM`).
+- **Kein blindes Mergen** der beiden Quellen in Notion.
+
+## 5. DO_NOT_BACKUP + SECRET — Grundregeln
+- Secrets/Tokens/Passwörter/private Keys/.env/Credentials → **SECRET_BLOCKED**, nie hochladen.
+- Binär-/Build-Artefakte, `.git/objects`, große Dateien → **DO_NOT_BACKUP** (technical backup übernimmt das).

notion-safety-brain/NOTION_STRUCTURE.md

@@ -0,0 +1,23 @@
+# NOTION SAFETY BRAIN — NOTION STRUCTURE (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (Vorschlag, nicht angelegt)**
+
+Arbeitstitel: **KI-SYSTEM — SAFETY BRAIN**
+
+| Bereich | Inhalt | Typ |
+|---|---|---|
+| 00 — Dashboard | Registry-Übersicht, Status | Seite |
+| 01 — Forgejo Safety Backup | Gesicherte Forgejo-Dokumente | Seite(n) |
+| 02 — Tolaria Safety Backup | Gesicherte Tolaria-Notes | Seite(n) |
+| 03 — Architecture & ADR | Architektur-Entscheidungen | Seite |
+| 04 — System Recovery | Recovery-Runbooks, Restore-Fluss | Seite |
+| 05 — Backup Registry | Lauf-Manifeste | **Datenbank** |
+| 06 — Integrity Reports | Verify-Ergebnisse | Seite |
+| 07 — Knowledge Index | Index der Objekte | **Datenbank** |
+| 08 — Historical Snapshots | Historische Stande | Seite |
+| 09 — Incidents / Recovery Events | Vorfälle, Restore | Seite |
+| 10 — Safety Brain Documentation | Diese Docs, Build-Plan | Seite |
+
+**Empfehlung:** Seiten für statische Bereiche + **Datenbanken** für Registry (05) und Index (07),
+da dort je Zeile Provenance/Status/Hash/Head als Properties abbildbar und filterbar sind.
+Notion API: Markdown für Seiten (agent-freundlich), Properties für DB-Zeilen (Relation/Select/Date).

notion-safety-brain/PROVENANCE_MODEL.md

@@ -0,0 +1,80 @@
+# NOTION SAFETY BRAIN — PROVENANCE MODEL & BACKUP MANIFEST (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (noch keine Implementierung)**
+
+---
+
+## 1. PROVENANCE-METADATEN-MODELL
+
+Jedes zukünftige Notion-Backupobjekt trägt Herkunft erkennbar im Frontmatter/Properties:
+
+| Feld | Typ | Beschreibung |
+|---|---|---|
+| `SOURCE_SYSTEM` | select | `forgejo` \| `tolaria` |
+| `SOURCE_PATH` | text | Pfad im Quellsystem (Repo-Pfad / Vault-Pfad) |
+| `SOURCE_OBJECT_ID` | text | Objekt-Identifikator (Dateiname / Git-Blob / Vault-Pfad) |
+| `SOURCE_VERSION` | text | Git-HEAD / Vault-HEAD zum Sicherungszeitpunkt |
+| `SOURCE_HASH` | text | SHA-256 des Quellinhalts |
+| `SOURCE_UPDATED_AT` | date | Letzte Änderung der Quelle |
+| `BACKUP_CREATED_AT` | date | Erstanlage im Notion-Safety-Brain |
+| `BACKUP_UPDATED_AT` | date | Letztes Update des Backups |
+| `BACKUP_RUN_ID` | text | ID des Backup-Laufs (z.B. NSB-YYYYMMDD-HHMMSS) |
+| `CONTENT_TYPE` | select | `markdown` \| `note` \| `decision` \| `log` \| `adr` |
+| `BACKUP_STATUS` | select | `current` \| `changed` \| `superseded` \| `source_missing` |
+| `INTEGRITY_STATUS` | select | `verified` \| `unverified` \| `hash_mismatch` |
+
+**Optional:** `FORGEJO_COMMIT`, `TOLARIA_VAULT_HEAD`, `RELATION_COUNT`, `LINK_COUNT`, `CLASSIFICATION`, `SENSITIVITY`.
+
+## 2. BACKUP-MANIFEST (pro Lauf)
+
+Ein Backup-Run erzeugt ein Manifest (Notion-Datenbank oder Seite):
+
+| Feld | Beispiel |
+|---|---|
+| `BACKUP_RUN_ID` | `NSB-20260825-000001` |
+| `TIMESTAMP` | ISO-8601 |
+| `FORGEJO_HEAD` | `819fd8a` |
+| `TOLARIA_HEAD` | `69aecf2` |
+| `FORGEJO_OBJECTS_EXPECTED` | 30 |
+| `FORGEJO_OBJECTS_BACKED_UP` | 30 |
+| `TOLARIA_OBJECTS_EXPECTED` | 60 |
+| `TOLARIA_OBJECTS_BACKED_UP` | 58 |
+| `SKIPPED_OBJECTS` | 2 (unchanged) |
+| `FAILED_OBJECTS` | 0 |
+| `SECRET_BLOCKED_OBJECTS` | 0 |
+| `HASH_STATUS` | `all_match` |
+| `VERIFY_STATUS` | `verified` |
+| `RESULT` | `BACKUP VERIFIED` |
+
+> **Ein Backup ist NICHT allein deshalb erfolgreich, weil ein API-Write HTTP 200 lieferte.**
+
+---
+
+## 3. VERIFIKATIONSPRINZIP — WRITE ≠ BACKUP SUCCESS
+
+Ein Backup-Lauf ist erst **erfolgreich**, wenn **alle** Punkte erfüllt sind:
+
+1. **Daten geschrieben** wurden (Write = nur Schritt 1).
+2. Red Queen sie **wieder aus Notion lesen** konnte.
+3. **Quelle und Backup verglichen** wurden (Inhalt).
+4. **Hash / Version / Manifest geprüft** (SOURCE_HASH == read-back hash).
+5. **Anzahl erwarteter und gesicherter Objekte stimmt** überein.
+6. **Fehler / Skipped Objects** dokumentiert.
+
+Erst dann: **`BACKUP VERIFIED`**.
+
+```
+BACKUP RUN
+  ├─ WRITE (Notion)
+  ├─ READ BACK (Notion → RQ)
+  ├─ COMPARE (SOURCE vs BACKUP)
+  ├─ HASH / VERSION CHECK
+  ├─ COUNT MATCH
+  └─ ERROR / SKIP LOG
+  →  BACKUP VERIFIED  (nur wenn alles grün)
+```
+
+## 4. DELETE-SAFETY (Provenance ergänzt)
+- Objekt in Quelle verschwunden → **NICHT** aus Notion löschen.
+- Status setzen: `SOURCE_MISSING` oder `SUPERSEDED`.
+- Notion behält historische Information für den Disaster-Fall.

notion-safety-brain/README.md

@@ -0,0 +1,32 @@
+# NOTION SAFETY BRAIN — DISCOVERY & ARCHITECTURE (Mission 003)
+
+Red Queen · 2026-08-25 · **READ-ONLY DISCOVERY / ARCHITECTURE / SECURITY REVIEW**
+
+Notion als **externer Safety Brain / Disaster-Recovery-Wissensspeicher** für
+**Forgejo** (technische Source of Truth) und **Tolaria** (operatives Second Brain).
+
+## Kernprinzipien
+- **One-Way**: Forgejo/Tolaria → Notion. **Notion ist KEINE Source of Truth.**
+- **Minimum Necessary Privilege**: eigener, getrennter RQ-Notion-Zugang (kein Credential-Transfer von Rain/Alice).
+- **READ-ONLY in dieser Mission**: keine Seiten/DBs/Uploads/Sync/Cron; **A5 bleibt AUS**.
+- **WRITE ≠ BACKUP SUCCESS**: Backup nur nach Read-back + Hash/Count-Verify **VERIFIED**.
+
+## Dokumente
+| Datei | Inhalt |
+|---|---|
+| ACCESS_ARCHITECTURE.md | Architekturprinzip, One-Way, Rollen, RQ-Zugang |
+| CURRENT_STATE.md | Discovery-Stand, Zugriff, Quellen-Stand |
+| DATA_CLASSIFICATION.md | Forgejo/Tolaria-Klassifikation (EVIDENCE) |
+| NOTION_STRUCTURE.md | Vorgeschlagene 00–10-Struktur |
+| PROVENANCE_MODEL.md | Metadatenmodell + Manifest + Verify |
+| BACKUP_MANIFEST.md | Manifest-Felder |
+| SECRET_POLICY.md | Secret-Scan, Blocked-Status |
+| RESTORE_MODEL.md | Restore-Fluss + Human Gate + Registry |
+| SCALING_MODEL.md | Skalierung, Versionierung, Delete-Safety |
+| BUILD_PLAN.md | Gestuftes Umsetzungsmodell |
+
+## Vorgeschlagene Notion-Struktur (nicht angelegt)
+`KI-SYSTEM — SAFETY BRAIN` mit 00 Dashboard … 10 Safety Brain Documentation; Datenbanken für Backup-Registry (05) + Knowledge-Index (07).
+
+## Status
+**DISCOVERY + ARCHITECTURE — READ-ONLY. Keine Produktiv-Änderung.**

notion-safety-brain/RESTORE_MODEL.md

@@ -0,0 +1,86 @@
+# NOTION SAFETY BRAIN — RESTORE MODEL (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (keine Implementierung)**
+
+---
+
+## 1. Grundprinzip
+- **KEIN automatischer Restore** von Notion nach Forgejo/Tolaria.
+- Restore immer mit **Human Gate** und expliziter Freigabe.
+
+## 2. Recovery-Fluss
+
+```
+NOTION
+  │  Export / API Read
+  ▼
+RECOVERY STAGING AREA   (lokal, z.B. /opt/data/notion_restore_staging/)
+  │
+  ▼
+MANIFEST VALIDATION     (BACKUP_RUN_ID, counts, provenance)
+  │
+  ▼
+HASH VALIDATION         (SOURCE_HASH vs staging content)
+  │
+  ▼
+HUMAN REVIEW            (Christian prüft Restore-Kandidaten)
+  │
+  ▼
+EXPLICIT APPROVAL       (Christian gibt frei)
+  │
+  ▼
+RESTORE                 (in Forgejo / Tolaria — nur nach Approval)
+```
+
+## 3. Restore-Regeln
+- Staging ist **isolierte Area** (nie produktiver Vault/Repo).
+- Jede Wiederherstellung validiert **Provenance + Hash + Manifest**.
+- Menschliche Prüfung VOR Schreiben in produktives Ziel.
+- Ein Restore ohne explizite Freigabe ist **verboten**.
+- Rollback des Restores: siehe Recovery-Runbook (Mission 002 / tolaria-Runbook analog).
+
+---
+
+# NOTION-STRUKTUR (Safety Brain — Vorschlag)
+
+Arbeitstitel: **KI-SYSTEM — SAFETY BRAIN**
+
+| Bereich | Inhalt |
+|---|---|
+| **00 — Dashboard** | Backup-Registry-Übersicht (s. unten) |
+| **01 — Forgejo Safety Backup** | Gesicherte Forgejo-Dokumente |
+| **02 — Tolaria Safety Backup** | Gesicherte Tolaria-Notes |
+| **03 — Architecture & ADR** | Architektur-Entscheidungen, ADRs |
+| **04 — System Recovery** | Recovery-Runbooks, Restore-Fluss |
+| **05 — Backup Registry** | Lauf-Manifeste, Status |
+| **06 — Integrity Reports** | Verify-Ergebnisse, Hash-Status |
+| **07 — Knowledge Index** | Index der Wissensobjekte |
+| **08 — Historical Snapshots** | Historische Stande |
+| **09 — Incidents / Recovery Events** | Vorfälle, Restore-Ereignisse |
+| **10 — Safety Brain Documentation** | Diese Docs, Build-Plan |
+
+**Empfehlung:** Kombination aus **Seiten** (01–04, 06–10 statisch) + **Datenbanken** (05 Backup-Registry als DB; 07 Index als DB). Datenbanken eignen sich für die Registry, da dort je Zeile Status/Hash/Provenance abgebildet wird und gefiltert werden kann.
+
+> Notion API: Seiten via Markdown (agent-freundlich), Datenbanken via Properties (Relation/Select/Date) — gut für Provenance-Metadaten.
+
+---
+
+## BACKUP REGISTRY (Design)
+
+Zentrale Notion-Datenbank `05 Backup Registry`, Felder:
+
+| Property | Typ |
+|---|---|
+| RUN_ID | text |
+| FORGEJO_HEAD | text |
+| TOLARIA_HEAD | text |
+| FORGEJO_OBJECTS | number |
+| TOLARIA_OBJECTS | number |
+| FAILED_OBJECTS | number |
+| INTEGRITY_STATUS | select (verified/failed) |
+| LAST_VERIFIED | date |
+| LAST_RESTORE_TEST | date |
+| NEXT_CHECK | date |
+
+Christians Frage **ohne SSH**: **"IST MEIN SAFETY BACKUP AKTUELL UND VERIFIZIERT?"** → Ja, wenn
+`INTEGRITY_STATUS=verified` UND `LAST_VERIFIED` aktuell UND `FORGEJO_HEAD`/`TOLARIA_HEAD` == aktuelle Quelle.

notion-safety-brain/SCALING_MODEL.md

@@ -0,0 +1,35 @@
+# NOTION SAFETY BRAIN — SCALING MODEL (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (nicht implementiert)**
+
+## Skalierung
+
+| Größe | Strategie |
+|---|---|
+| 100 Docs | Initial-Backup, dann inkrementell |
+| 1.000 Docs | **Batching/Pagination**, Hash-Change-Detection |
+| 10.000 Docs | **Incremental + Delta**, nur geänderte Objekte neu schreiben |
+
+Mechanismen: **Pagination** (API), **Batching** (Gruppen-Writes), **Incremental**,
+**Hash-basierte Change-Detection**, **Dedup** (Forgejo/Vault-Duplikate).
+
+## Change-Detection (bevorzugt später)
+```
+SOURCE HASH
+  ├─ UNCHANGED → SKIP
+  ├─ CHANGED   → UPDATE BACKUP
+  ├─ NEW       → CREATE
+  └─ MISSING   → FLAG, NICHT SOFORT LÖSCHEN
+```
+
+## Versionierung
+- CURRENT COPY + HISTORICAL SNAPSHOT.
+- **Snapshot nur bei Änderung** + **wichtige Milestones dauerhaft**. Kein unendliches Duplizieren.
+- Optional Rolling History (letzte N Versionen).
+
+## Delete-Safety
+- Quelle-Objekt verschwindet → **NICHT automatisch löschen**, Status `SOURCE_MISSING` / `SUPERSEDED`.
+
+## Notion API Limite (Referenz)
+- ~3 requests/s avg (Rate Limit). Batch/Paginate berücksichtigen.
+- `Notion-Version: 2025-09-03`; DB = data source im API.

notion-safety-brain/SECRET_POLICY.md

@@ -0,0 +1,88 @@
+# NOTION SAFETY BRAIN — SECRET POLICY (Mission 003)
+
+Datum: 2026-08-25 · Red Queen · Status: **DESIGN (verbindliche Policy)**
+
+---
+
+## 1. Pflicht — Secret Scan VOR jedem Notion-Write
+Jeder zukünftige Backup-Lauf führt VOR dem Upload einen Secret-Scan durch.
+
+## 2. Mindestens zu erkennen
+API Keys · Tokens · Authorization Header · Passwords · Private Keys · SSH Keys ·
+.env-Inhalte · Database Credentials · Webhook Secrets · Session Tokens · Cookie Secrets.
+
+## 3. Bei Verdacht
+- **NICHT HOCHLADEN.**
+- Objekt-Status: `SECRET_BLOCKED`.
+- Nur dokumentieren (nie den Wert):
+  ```
+  SOURCE_LOCATION = <Pfad>
+  TYPE            = <Art>
+  VALUE           = REDACTED
+  ```
+
+## 4. Erkennungs-Regeln (Konzeption)
+- Muster-basiert (Token-Präfixe: `ntn_`, `secret_`, `ghp_`, `Bearer `, PEM-Header, `FORGEJO_*`-Env).
+- Heuristik: 40-hex/Base64-Langwerte → verdächtig (verifizieren, NICHT sofort als Secret werten; z.B. SHA-256-Hashes sind legitime Metadaten).
+- `.env`- und Credential-Dateien → **DO_NOT_BACKUP / SECRET_FORBIDDEN**.
+- Immer: Wert niemals in Manifest/Logs/Notion ausgeben.
+
+## 5. Keine fremden Credentials
+- Red Queen übernimmt **keine** Tokens von Rain/Alice.
+- Zugriff erfolgt ausschließlich über eine eigene, minimal privilegierte Integration.
+- `NOTION_API_KEY` wird nie ausgegeben, nur `EXISTS`/`LENGTH`.
+
+---
+
+# SCALING / VERSIONING / DELETE-SAFETY (Design)
+
+## 1. Datenmenge & Skalierung
+
+Notion API Rate Limits: ~3 requests/s (avg). Für 100/1.000/10.000 Objekte:
+
+| Größe | Strategie |
+|---|---|
+| 100 Docs | Einmaliger Initial-Backup, dann inkrementell |
+| 1.000 Docs | **Batching/Pagination** (API paginiert), Hash-Change-Detection |
+| 10.000 Docs | **Incremental + Delta**; nur geänderte Objekte neu schreiben |
+
+Prinzipien: **Pagination** (Seitenweises Lesen), **Batching** (Gruppenweise Writes), **Incremental** (nicht alles neu), **Hash-basierte Change-Detection**, **Dedup** (Forgejo/Vault-Duplikate).
+
+**Change-Detection-Fluss (bevorzugt später):**
+```
+SOURCE HASH
+  ├─ UNCHANGED → SKIP
+  ├─ CHANGED   → UPDATE BACKUP
+  ├─ NEW       → CREATE
+  └─ MISSING   → FLAG, NICHT SOFORT LÖSCHEN
+```
+
+## 2. Versionierung
+- **CURRENT COPY** = aktueller Backup-Stand je Objekt.
+- **HISTORICAL SNAPSHOT** = Snapshot bei Änderung / bei Milestone.
+- Empfehlung: **Snapshot nur bei Änderung** + **wichtige Milestones dauerhaft**. Kein unendliches Duplizieren jeder Kleinigkeit.
+- Optional: **Rolling History** (z.B. letzte N Versionen behalten).
+
+## 3. Delete-Safety
+- Objekt in Quelle verschwindet → **NICHT automatisch aus Notion löschen**.
+- Status: `SOURCE_MISSING` oder `SUPERSEDED`.
+- Notion behält historische Information für den Disaster-Fall.
+
+---
+
+# TECHNICAL BACKUP vs SAFETY BRAIN
+
+**NOTION SAFETY BRAIN ersetzt NICHT** (technische Disaster-Recovery-Backups bleiben Pflicht):
+
+- Git-Repository-Backup
+- `.git/objects` Backup
+- Datenbank-Dump
+- Container-/Volume-Backup
+- Host-Backup
+- Konfigurationsbackup
+
+**Beides ist langfristig nötig:**
+- **A) TECHNICAL DISASTER RECOVERY BACKUP** — vollständige binärer/Wiederherstellbarkeit (Host, DB, Container, Git, Volume).
+- **B) NOTION KNOWLEDGE SAFETY BRAIN** — menschen-/agent-lesbares Wissens-Backup für Kenntnis- und Entscheidungs-Recovery.
+
+Notion Safety Brain deckt **Knowledge** ab, NICHT die technische Infrastruktur-Wiederherstellung.