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.
88 lines
3.3 KiB
Markdown
88 lines
3.3 KiB
Markdown
# 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.
|