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.
2.9 KiB
2.9 KiB
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.