Red Queen 9b89ed77bb 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.

2026-08-25 05:49:25 +00:00

3.3 KiB

Raw Blame History

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.

3.3 KiB Raw Blame History