Red Queen
9b89ed77bb
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.
86 lines
2.9 KiB
Markdown
86 lines
2.9 KiB
Markdown
# 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.
|