# 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.