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