Add AI workspace reviews

2026-05-18 04:37:23 +00:00
commit 7ac1371aff
106 changed files with 5378 additions and 0 deletions
@@ -0,0 +1,94 @@
+## Kritische Architekturprobleme
+
+### 1. Fataler Tenant-Isolation-Fehler
+
+Das Datenmodell nennt sowohl `organisation_id` als auch `tenant_id`, aber ohne klare Abgrenzung. Dies ist ein **kritischer Designfehler**:
+
+```
+# Problem in data-model-v0.1.md:
+"Von Anfang an vorbereiten:
+- organisation_id
+- tenant_id"
+```
+
+**Warum kritisch:** 
+- Unklare Hierarchie zwischen Organisation und Tenant
+- Potenzielle Tenant-Leaks durch falsche Filterung
+- Kein explizites Constraint-Modell definiert
+
+**Lösung erforderlich:** Eine klare Entscheidung - entweder Organisation ODER Tenant, nicht beides halbherzig.
+
+### 2. Secrets-Management ohne Implementierung
+
+Das Security-Dokument behauptet:
+```
+"Secrets werden nur über einen Secret-Service gelesen/geschrieben"
+```
+
+Aber:
+- Kein Secret-Service definiert
+- Registrar-Account hat "Zugangsdaten/API-Referenzen" direkt im Modell
+- Keine Encryption-at-Rest-Strategie
+
+**Risiko:** Passwörter landen im Klartext in der Datenbank.
+
+### 3. Audit-Log Hash-Chain ist Pseudo-Security
+
+ADR 0014 schlägt eine Hash-Chain vor, aber:
+- Kein Schutz gegen DB-Admin-Manipulation
+- Hash-Algorithm nicht spezifiziert
+- "V1 bereitet vor" = wird nicht implementiert
+
+**Problem:** Security-Theater ohne echten Schutz. Ein DB-Admin kann die gesamte Chain neu berechnen.
+
+### 4. Dead Letter Queue ohne Retention-Strategie
+
+ADR 0017 fordert Dead Letter Queues, aber:
+- Keine maximale Retention definiert
+- Potenzielle Speicher-Explosion
+- DSGVO-Konflikt bei personenbezogenen Daten in fehlgeschlagenen Jobs
+
+### 5. Fehlende Core-Domain-Boundaries
+
+Das Datenmodell mischt alles:
+- Billing (Rechnung, Zahlung)
+- Provisioning (Server, Hostingpaket)
+- CRM (Kunde, Ticket)
+- Registry (Domain, Registrar)
+
+**Problem:** Keine Bounded Contexts = massive Kopplung, unmöglich zu skalieren.
+
+### 6. Reconciliation ohne Event-Sourcing
+
+ADR 0017 fordert Reconciliation, aber das Datenmodell hat keine Event-Historie. Wie soll man reconcilen ohne zu wissen, was passiert ist?
+
+### 7. Security-Rollen ohne Scope-Definition
+
+"Staff/Support" hat Zugriff auf "operative Daten" - was heißt das konkret?
+- Kann Support Passwörter sehen?
+- Kann Support Rechnungen ändern?
+- Kann Support Server-Zugänge einsehen?
+
+### 8. Single Point of Failure: tenant_id
+
+Alles hängt an einem einzigen Feld. Ein fehlerhafter Query-Scope = Datenleck über alle Mandanten.
+
+**Fehlende Sicherheitsschicht:**
+- Kein Row-Level-Security auf DB-Ebene
+- Keine Tenant-Context-Validierung
+- Kein Fail-Safe-Mechanismus
+
+### 9. Dokument-Objekt ohne Storage-Strategy
+
+"Dokument" hat "Hashes" und "Archivinformationen", aber:
+- Wo werden Dateien gespeichert?
+- Wie wird Tenant-Isolation im Filesystem sichergestellt?
+- Was passiert bei Löschanfragen?
+
+### 10. Keine Migrationsstrategie für Multi-Tenancy
+
+"V1 arbeitet als Single-Tenant" aber "Struktur vorbereitet" - das ist ein Widerspruch. Entweder man designed multi-tenant von Anfang an oder man plant eine Migration. Beides fehlt.
+
+## Fazit
+
+Die Architektur versucht, zu viele Probleme gleichzeitig zu lösen, ohne eines davon richtig zu durchdenken. Kritischster Punkt: Die Tenant-Isolation ist nur oberflächlich geplant und wird mit hoher Wahrscheinlichkeit zu Datenleaks führen.