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

2.9 KiB

Raw Blame History

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:

Daten geschrieben wurden (Write = nur Schritt 1).
Red Queen sie wieder aus Notion lesen konnte.
Quelle und Backup verglichen wurden (Inhalt).
Hash / Version / Manifest geprüft (SOURCE_HASH == read-back hash).
Anzahl erwarteter und gesicherter Objekte stimmt überein.
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.

2.9 KiB Raw Blame History