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.
This commit is contained in:
Red Queen 2026-08-25 05:49:25 +00:00
parent 819fd8a6ff
commit 9b89ed77bb
11 changed files with 556 additions and 0 deletions

View file

@ -0,0 +1,54 @@
# NOTION SAFETY BRAIN — Access & Architecture (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **DISCOVERY + ARCHITECTURE (READ-ONLY)**
> Notion als **externer Safety Brain / Disaster-Recovery-Wissensspeicher** für
> **zwei getrennte Systeme**: Forgejo (technische Source of Truth) und Tolaria
> (operatives Second Brain). **Notion ist KEINE neue Source of Truth.**
---
## 1. Architekturprinzip
```
FORGEJO ────────────► NOTION SAFETY BRAIN
TOLARIA ────────────► NOTION SAFETY BRAIN
NICHT (kein Rückfluss):
NOTION ────────────► FORGEJO / TOLARIA
```
- **ONE-WAY** Datenfluss: Quelle → Notion.
- Ein Fehler / falsche Bearbeitung / Löschung in Notion darf **niemals** Forgejo oder Tolaria verändern.
- **Kein** bidirektionaler Sync. **Kein** automatischer Rück-Sync.
## 2. Rollen
| System | Rolle |
|---|---|
| **FORGEJO** | technische/versionierte Source of Truth |
| **TOLARIA** | operatives Second Brain / Knowledge System |
| **NOTION** | externer Safety Brain / Knowledge Backup / Disaster-Recovery View |
> Notion ist ausdrücklich **KEINE Source of Truth** — sondern ein abgeleiteter,
> externer Sicherungsspeicher.
## 3. Ausgangslage (EVIDENCE)
- Christians Notion wurde **bewusst geleert** (vorher unbrauchbare Inhalte) → saubere Struktur von Grund auf planbar.
- Rain und Alice besitzen bereits funktionierenden Notion-Zugriff.
- **Red Queen hat aktuell KEINEN eigenen Notion-Zugriff** (kein `NOTION_API_KEY`, kein `ntn`, keine Config) — verifiziert via read-only Discovery.
## 4. Zugangskonzept — Red Queen (MINIMUM NECESSARY PRIVILEGE)
- Red Queen erhält einen **eigenen, sauber getrennten, minimal privilegierten** Notion-Zugriff.
- **Kein Credential-Transfer** von Rain/Alice. **Keine** fremden Tokens kopieren.
- **Keine Owner-/Admin-Rechte** — nur der Scope, den der Safety-Brain-Write benötigt.
- Empfohlener Weg (Implementierung erst nach Freigabe):
- Eigene Notion-Integration anlegen (Read+Insert) mit dediziertem Token.
- Token in `${HERMES_HOME}/.env` als `NOTION_API_KEY` (nie ausgeben).
- Nur die nötigen Safety-Brain-Seiten/DBs mit der Integration teilen (Seiten-`...` → Connect to).
- **Keine Secrets in den Artefakten**; Token nur ephemer nutzen.
## 5. Kein-Cloud-Write in dieser Mission
- Diese Mission ist **READ-ONLY** (Discovery + Architecture).
- Kein Anlegen von Notion-Seiten, keine Datenbank, kein Schreiben, kein Sync, kein Cron.
- Produktive Daten / Credentials / Berechtigungen bleiben unverändert.

View file

@ -0,0 +1,34 @@
# NOTION SAFETY BRAIN — BACKUP MANIFEST (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **DESIGN (nicht implementiert)**
> Ein Backup-Run erzeugt ein Manifest, das Lauf-Ergebnis und Verifikation abbildet.
> **Ein Backup ist NICHT allein deshalb erfolgreich, weil ein API-Write HTTP 200 lieferte.**
## Manifest-Felder
```
BACKUP_RUN_ID
TIMESTAMP
FORGEJO_HEAD
TOLARIA_HEAD
FORGEJO_OBJECTS_EXPECTED
FORGEJO_OBJECTS_BACKED_UP
TOLARIA_OBJECTS_EXPECTED
TOLARIA_OBJECTS_BACKED_UP
SKIPPED_OBJECTS
FAILED_OBJECTS
SECRET_BLOCKED_OBJECTS
HASH_STATUS
VERIFY_STATUS
RESULT
```
- `HASH_STATUS` = `all_match` | `mismatch` (alle Source-Hashes vs. Notion-read-back).
- `VERIFY_STATUS` = `verified` | `unverified`.
- `RESULT` = `BACKUP VERIFIED` nur wenn Write + Read-back + Compare + Hash + Count + Logs ok.
## Registry-Zuordnung
Manifest-Zeile wird in Notion-DB **05 Backup Registry** je RUN_ID abgelegt (siehe RESTORE_MODEL.md).
## Verify-Prinzip (WRITE ≠ SUCCESS)
1. Write → 2. Read-back → 3. Compare → 4. Hash/Version-Check → 5. Count-Match → 6. Error/Skip-Log → **BACKUP VERIFIED**.

View file

@ -0,0 +1,45 @@
# NOTION SAFETY BRAIN — BUILD PLAN (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **PLAN (nicht implementiert)**
> Konkretes, gestuftes Umsetzungsmodell. Jede Phase erst nach **ausdrücklicher Freigabe** durch Christian.
---
## Phase 0 — Access (Red Queen)
- [ ] Eigene Notion-Integration anlegen (Read + Insert), minimal privilegiert.
- [ ] `NOTION_API_KEY` in `${HERMES_HOME}/.env` (nie ausgeben, nur EXISTS/LENGTH).
- [ ] Nur Safety-Brain-Seiten/DBs mit der Integration teilen.
- [ ] Kein Credential-Transfer von Rain/Alice.
## Phase 1 — Struktur in Notion anlegen
- [ ] Root-Seite **KI-SYSTEM — SAFETY BRAIN**.
- [ ] Bereiche 0010 (siehe NOTION_STRUCTURE.md).
- [ ] Datenbank `05 Backup Registry` + `07 Knowledge Index`.
## Phase 2 — Backup-Engine (lokal)
- [ ] Secret-Scan (SECRET_POLICY.md) fest einbauen.
- [ ] Provenance-Frontmatter (PROVENANCE_MODEL.md) je Objekt.
- [ ] Incremental / Hash-Change-Detection (SCALING_MODEL.md).
- [ ] Manifest-Erzeugung (BACKUP_MANIFEST.md).
## Phase 3 — Verify & Registry
- [ ] READ-BACK + COMPARE + Hash-Verify (WRITE ≠ SUCCESS).
- [ ] Registry-Zeilen pflegen.
## Phase 4 — Restore-Modul
- [ ] Staging → Validate → Human Review → Approval → Restore (RESTORE_MODEL.md).
## Phase 5 — Red Queen als Knowledge Backup Steward
- Änderungen erkennen · klassifizieren · Secrets blocken · Delta · Backup schreiben ·
zurücklesen · verifizieren · Manifest · Status · Fehler melden.
> **NOCH NICHT AUTOMATISIEREN.** Kein Cron / Daemon / Heartbeat in dieser Mission.
> **A5 bleibt AUS.**
---
## Wichtig
- Diese Mission = **Discovery + Architecture + Checker + Forgejo-Doku**, dann **STOPP**.
- Kein Bau von Notion-Seiten, keine Datenbank, kein Upload, kein Sync, kein Cron.
- Warte auf Christians ausdrückliche Freigabe vor Phase 1.

View file

@ -0,0 +1,24 @@
# NOTION SAFETY BRAIN — CURRENT STATE (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **READ-ONLY Discovery-Stand**
## Notion
- **WORKSPACE:** nicht verifizierbar ohne Zugriff (Red Queen hat noch kein Token) — UNKNOWN bis Phase 0.
- **AUTH METHOD:** geplant = eigene Notion-Integration (OAuth-token-basiert), min. privilegiert.
- **PERMISSIONS (Red Queen):** keine — Zugriff noch NICHT eingerichtet.
- **CURRENT NOTION STATE:** bewusst geleert (Christian) → saubere Struktur planbar. Kein Inhalt von RQ verifizierbar (kein Zugang).
## Red Queen Zugriff
- **TOKEN_EXISTS=NO** · `ntn` CLI: nicht installiert · keine Notion-Config/Credential-Datei unter RQ-Volume.
## Rain / Alice
- Haben funktionierenden Notion-Zugriff (Missionsangabe). **Nicht herangezogen** für Credentials.
- Diese Mission: **RAIN REFERENCE USED = NO**, **ALICE REFERENCE USED = NO** (kein Credential-Transfer nötig; Architekturweg dokumentiert).
## Quellen-Stand (EVIDENCE)
- **Forgejo** `main` = `819fd8a` (Repo-Struktur lokal verifiziert).
- **Tolaria** Vault = HEAD `69aecf2…`, 84 .md (API-Read verifiziert).
## Grundsatz (verbindlich)
- Notion = externer Safety Brain, **KEINE Source of Truth**.
- **One-Way** von Forgejo/Tolaria → Notion. Kein Rückfluss.

View file

@ -0,0 +1,55 @@
# NOTION SAFETY BRAIN — DATA CLASSIFICATION (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **EVIDENCE-basiert (read-only)**
> Klassifikation, welche Inhalte aus Forgejo und Tolaria in den Notion Safety Brain
> gesichert werden sollen. Kategorien:
> **BACKUP_REQUIRED** · **BACKUP_RECOMMENDED** · **OPTIONAL** · **DO_NOT_BACKUP** · **SECRET/FORBIDDEN**
---
## 1. FORGEJO (technische Source of Truth)
EVIDENCE (lokaler Klon `/opt/data/forgejo/trading-system-docs`, main=`819fd8a`):
| Inhalt | Kategorie | Begründung |
|---|---|---|
| `red-queen-architecture/` (10 Contracts) | **BACKUP_REQUIRED** | Architektur-Entscheidungen, Safety/External-Review-Contracts, MISSION_STATE_MACHINE |
| `tolaria/` (Discovery-Report, B1-Docs) | **BACKUP_REQUIRED** | Tolaria-Dokumentation, Baseline, Recovery-Runbook |
| `a2/`..`a5/` (Design/README/Code) | **BACKUP_RECOMMENDED** | Red-Queen-Automatisierung, relevant für Recovery |
| Modul-Doku (`modul-*.md`, `ports-reference`, `infrastructure-handbook`, `trend-pullback-spec`) | **BACKUP_RECOMMENDED** | System-/Modul-Dokumentation |
| `backup_patches/` | **BACKUP_RECOMMENDED** | Wichtige Patches |
| `notes/` (Hubs/Wikilinks) | **BACKUP_RECOMMENDED** | Verknüpfungs-Struktur |
| `README.md` | OPTIONAL | Überblick (bereits in modul-Doku enthalten) |
| `__pycache__/`, `.git/`, Binär-/Build-Artefakte | **DO_NOT_BACKUP** | Rebuildbar, keine Knowledge-Inhalte |
| `.env`, `*.pem`, `*.key`, `*.token`, config mit Secrets | **SECRET/FORBIDDEN** | Nie nach Notion |
**Doppel-Zählung beachten:** Modul-Dateien existieren teils auch im Vault (Root + system-docs) → Deduplizierung nötig (siehe Provenance).
## 2. TOLARIA (operatives Second Brain, 84 .md via API)
EVIDENCE (Vault-API, `/app/vault`, HEAD `69aecf2…`):
| Bereich | Kategorie | Begründung |
|---|---|---|
| `notes/trading/second-brain/` (journal, t212-logs, Phase-Docs) | **BACKUP_REQUIRED** | Operative Knowledge-Logs, Verlauf |
| `notes/trading/system-docs/*` (30) | **BACKUP_RECOMMENDED** | Modul-/System-Doku (teils identisch mit Forgejo → dedupe) |
| `/app/vault/*.md` Root (README, infrastructure-handbook, modul-*) | **BACKUP_RECOMMENDED** | Duplikat-Struktur (19 Paare) |
| `notes/` Hubs (ai-agents, alice-betrieb, projekte, start, inbox, trading, reference) | **BACKUP_RECOMMENDED** | Wikilink-/Hub-Struktur, Beziehungen |
| **Frontmatter / Wikilinks / Provenance** | **BACKUP_REQUIRED** (als Metadaten) | Für Beziehungs-/Graph-Rebuild |
| `.git/` (Objects) | **DO_NOT_BACKUP** via API | Binär, nicht via JSON-API vollständig ziehbar; separat technisch sichern |
| secrets in Frontmatter/Inhalt (falls vorhanden) | **SECRET/FORBIDDEN** | Secret-Scan vor Upload |
## 3. Kategorientabelle (Provenance-Vorbereitung)
Jede Notion-Seite erhält im Frontmatter/Property die Quelle:
`SOURCE_SYSTEM` (forgejo|tolaria), `SOURCE_PATH`, `SOURCE_HASH`, `SOURCE_VERSION` (git-HEAD / Vault-HEAD).
## 4. Zwei-Quellen-Prinzip
- Forgejo und Tolaria enthalten **nicht zwingend** dieselben Informationen.
- Notion sichert **beide getrennt und nachvollziehbar** (je `SOURCE_SYSTEM`).
- **Kein blindes Mergen** der beiden Quellen in Notion.
## 5. DO_NOT_BACKUP + SECRET — Grundregeln
- Secrets/Tokens/Passwörter/private Keys/.env/Credentials → **SECRET_BLOCKED**, nie hochladen.
- Binär-/Build-Artefakte, `.git/objects`, große Dateien → **DO_NOT_BACKUP** (technical backup übernimmt das).

View file

@ -0,0 +1,23 @@
# NOTION SAFETY BRAIN — NOTION STRUCTURE (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **DESIGN (Vorschlag, nicht angelegt)**
Arbeitstitel: **KI-SYSTEM — SAFETY BRAIN**
| Bereich | Inhalt | Typ |
|---|---|---|
| 00 — Dashboard | Registry-Übersicht, Status | Seite |
| 01 — Forgejo Safety Backup | Gesicherte Forgejo-Dokumente | Seite(n) |
| 02 — Tolaria Safety Backup | Gesicherte Tolaria-Notes | Seite(n) |
| 03 — Architecture & ADR | Architektur-Entscheidungen | Seite |
| 04 — System Recovery | Recovery-Runbooks, Restore-Fluss | Seite |
| 05 — Backup Registry | Lauf-Manifeste | **Datenbank** |
| 06 — Integrity Reports | Verify-Ergebnisse | Seite |
| 07 — Knowledge Index | Index der Objekte | **Datenbank** |
| 08 — Historical Snapshots | Historische Stande | Seite |
| 09 — Incidents / Recovery Events | Vorfälle, Restore | Seite |
| 10 — Safety Brain Documentation | Diese Docs, Build-Plan | Seite |
**Empfehlung:** Seiten für statische Bereiche + **Datenbanken** für Registry (05) und Index (07),
da dort je Zeile Provenance/Status/Hash/Head als Properties abbildbar und filterbar sind.
Notion API: Markdown für Seiten (agent-freundlich), Properties für DB-Zeilen (Relation/Select/Date).

View file

@ -0,0 +1,80 @@
# NOTION SAFETY BRAIN — PROVENANCE MODEL & BACKUP MANIFEST (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **DESIGN (noch keine Implementierung)**
---
## 1. PROVENANCE-METADATEN-MODELL
Jedes zukünftige Notion-Backupobjekt trägt Herkunft erkennbar im Frontmatter/Properties:
| Feld | Typ | Beschreibung |
|---|---|---|
| `SOURCE_SYSTEM` | select | `forgejo` \| `tolaria` |
| `SOURCE_PATH` | text | Pfad im Quellsystem (Repo-Pfad / Vault-Pfad) |
| `SOURCE_OBJECT_ID` | text | Objekt-Identifikator (Dateiname / Git-Blob / Vault-Pfad) |
| `SOURCE_VERSION` | text | Git-HEAD / Vault-HEAD zum Sicherungszeitpunkt |
| `SOURCE_HASH` | text | SHA-256 des Quellinhalts |
| `SOURCE_UPDATED_AT` | date | Letzte Änderung der Quelle |
| `BACKUP_CREATED_AT` | date | Erstanlage im Notion-Safety-Brain |
| `BACKUP_UPDATED_AT` | date | Letztes Update des Backups |
| `BACKUP_RUN_ID` | text | ID des Backup-Laufs (z.B. NSB-YYYYMMDD-HHMMSS) |
| `CONTENT_TYPE` | select | `markdown` \| `note` \| `decision` \| `log` \| `adr` |
| `BACKUP_STATUS` | select | `current` \| `changed` \| `superseded` \| `source_missing` |
| `INTEGRITY_STATUS` | select | `verified` \| `unverified` \| `hash_mismatch` |
**Optional:** `FORGEJO_COMMIT`, `TOLARIA_VAULT_HEAD`, `RELATION_COUNT`, `LINK_COUNT`, `CLASSIFICATION`, `SENSITIVITY`.
## 2. BACKUP-MANIFEST (pro Lauf)
Ein Backup-Run erzeugt ein Manifest (Notion-Datenbank oder Seite):
| Feld | Beispiel |
|---|---|
| `BACKUP_RUN_ID` | `NSB-20260825-000001` |
| `TIMESTAMP` | ISO-8601 |
| `FORGEJO_HEAD` | `819fd8a` |
| `TOLARIA_HEAD` | `69aecf2` |
| `FORGEJO_OBJECTS_EXPECTED` | 30 |
| `FORGEJO_OBJECTS_BACKED_UP` | 30 |
| `TOLARIA_OBJECTS_EXPECTED` | 60 |
| `TOLARIA_OBJECTS_BACKED_UP` | 58 |
| `SKIPPED_OBJECTS` | 2 (unchanged) |
| `FAILED_OBJECTS` | 0 |
| `SECRET_BLOCKED_OBJECTS` | 0 |
| `HASH_STATUS` | `all_match` |
| `VERIFY_STATUS` | `verified` |
| `RESULT` | `BACKUP VERIFIED` |
> **Ein Backup ist NICHT allein deshalb erfolgreich, weil ein API-Write HTTP 200 lieferte.**
---
## 3. VERIFIKATIONSPRINZIP — WRITE ≠ BACKUP SUCCESS
Ein Backup-Lauf ist erst **erfolgreich**, wenn **alle** Punkte erfüllt sind:
1. **Daten geschrieben** wurden (Write = nur Schritt 1).
2. Red Queen sie **wieder aus Notion lesen** konnte.
3. **Quelle und Backup verglichen** wurden (Inhalt).
4. **Hash / Version / Manifest geprüft** (SOURCE_HASH == read-back hash).
5. **Anzahl erwarteter und gesicherter Objekte stimmt** überein.
6. **Fehler / Skipped Objects** dokumentiert.
Erst dann: **`BACKUP VERIFIED`**.
```
BACKUP RUN
├─ WRITE (Notion)
├─ READ BACK (Notion → RQ)
├─ COMPARE (SOURCE vs BACKUP)
├─ HASH / VERSION CHECK
├─ COUNT MATCH
└─ ERROR / SKIP LOG
→ BACKUP VERIFIED (nur wenn alles grün)
```
## 4. DELETE-SAFETY (Provenance ergänzt)
- Objekt in Quelle verschwunden → **NICHT** aus Notion löschen.
- Status setzen: `SOURCE_MISSING` oder `SUPERSEDED`.
- Notion behält historische Information für den Disaster-Fall.

View file

@ -0,0 +1,32 @@
# NOTION SAFETY BRAIN — DISCOVERY & ARCHITECTURE (Mission 003)
Red Queen · 2026-08-25 · **READ-ONLY DISCOVERY / ARCHITECTURE / SECURITY REVIEW**
Notion als **externer Safety Brain / Disaster-Recovery-Wissensspeicher** für
**Forgejo** (technische Source of Truth) und **Tolaria** (operatives Second Brain).
## Kernprinzipien
- **One-Way**: Forgejo/Tolaria → Notion. **Notion ist KEINE Source of Truth.**
- **Minimum Necessary Privilege**: eigener, getrennter RQ-Notion-Zugang (kein Credential-Transfer von Rain/Alice).
- **READ-ONLY in dieser Mission**: keine Seiten/DBs/Uploads/Sync/Cron; **A5 bleibt AUS**.
- **WRITE ≠ BACKUP SUCCESS**: Backup nur nach Read-back + Hash/Count-Verify **VERIFIED**.
## Dokumente
| Datei | Inhalt |
|---|---|
| ACCESS_ARCHITECTURE.md | Architekturprinzip, One-Way, Rollen, RQ-Zugang |
| CURRENT_STATE.md | Discovery-Stand, Zugriff, Quellen-Stand |
| DATA_CLASSIFICATION.md | Forgejo/Tolaria-Klassifikation (EVIDENCE) |
| NOTION_STRUCTURE.md | Vorgeschlagene 0010-Struktur |
| PROVENANCE_MODEL.md | Metadatenmodell + Manifest + Verify |
| BACKUP_MANIFEST.md | Manifest-Felder |
| SECRET_POLICY.md | Secret-Scan, Blocked-Status |
| RESTORE_MODEL.md | Restore-Fluss + Human Gate + Registry |
| SCALING_MODEL.md | Skalierung, Versionierung, Delete-Safety |
| BUILD_PLAN.md | Gestuftes Umsetzungsmodell |
## Vorgeschlagene Notion-Struktur (nicht angelegt)
`KI-SYSTEM — SAFETY BRAIN` mit 00 Dashboard … 10 Safety Brain Documentation; Datenbanken für Backup-Registry (05) + Knowledge-Index (07).
## Status
**DISCOVERY + ARCHITECTURE — READ-ONLY. Keine Produktiv-Änderung.**

View file

@ -0,0 +1,86 @@
# 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** (0104, 0610 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.

View file

@ -0,0 +1,35 @@
# NOTION SAFETY BRAIN — SCALING MODEL (Mission 003)
Datum: 2026-08-25 · Red Queen · Status: **DESIGN (nicht implementiert)**
## Skalierung
| Größe | Strategie |
|---|---|
| 100 Docs | Initial-Backup, dann inkrementell |
| 1.000 Docs | **Batching/Pagination**, Hash-Change-Detection |
| 10.000 Docs | **Incremental + Delta**, nur geänderte Objekte neu schreiben |
Mechanismen: **Pagination** (API), **Batching** (Gruppen-Writes), **Incremental**,
**Hash-basierte Change-Detection**, **Dedup** (Forgejo/Vault-Duplikate).
## Change-Detection (bevorzugt später)
```
SOURCE HASH
├─ UNCHANGED → SKIP
├─ CHANGED → UPDATE BACKUP
├─ NEW → CREATE
└─ MISSING → FLAG, NICHT SOFORT LÖSCHEN
```
## Versionierung
- CURRENT COPY + HISTORICAL SNAPSHOT.
- **Snapshot nur bei Änderung** + **wichtige Milestones dauerhaft**. Kein unendliches Duplizieren.
- Optional Rolling History (letzte N Versionen).
## Delete-Safety
- Quelle-Objekt verschwindet → **NICHT automatisch löschen**, Status `SOURCE_MISSING` / `SUPERSEDED`.
## Notion API Limite (Referenz)
- ~3 requests/s avg (Rate Limit). Batch/Paginate berücksichtigen.
- `Notion-Version: 2025-09-03`; DB = data source im API.

View file

@ -0,0 +1,88 @@
# 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.