v1.0.0 SaaS-Multi-Tenancy — Detail-Plan-Synthese

Status: Plan-Dokument (kein Code, keine Umsetzung) — Single-Source-of-Truth für die Restmenge der v1.0.0-SaaS-Phase Erstellt: 2026-05-09 nach Cleanup-Folge-Karten 1-3 (Ruff / Test-Hygiene / Mypy alle ✅) Schreib-Cap: 4h für die Plan-Karte selbst Verhältnis zu existierender Doku: Diese Synthese anerkennt das Multi-Tenancy-Fundament v5.3.4 und die Roadmap als kanonische Quellen. Sie ergänzt drei Achsen, die im Fundament nicht oder nur implizit dokumentiert sind: DSGVO-Operations-Tools, Multi-Tenant-CI-Validation, und Saga-Lehren-Mapping pro Restblock.

Executive Summary

Phase A (Fundament-Datenmodell, Auth, RLS, Qdrant, Templates, Plattform-Module) ist mit 6 Blöcken vollständig implementiert. Phase B (UIs & Automation) ist zu ~⅔ fertig: Block 7 (Operator-UI), Block 8 (Tenant-UI mit Chatbot-Management) und Block 11 (Widget) sind erledigt — offen sind Block 9 (Vendor-UI), Block 10 (System-Prompt-Automatismus) und Block 12 (Provisioning). Phase C (Konnektoren + Quality) hat Block 18 (Docling) erledigt; offen sind Block 19/19.5/20 (BGE-M3 + Reranker + AST), Block 13 (Konnektor-Framework) und Block 13b (Confluence). Phase D (Deployment + Migration + Go-Live) ist komplett offen (Block 14, 15, 16). Phase E (Tenant-SSO-Self-Service als Block 17) ist Post-Launch.

Die Restmenge umfasst ~140h Refined-Schätzung. Die Saga-Lehre-13-Cleanup-Folge-Serie (Ruff / Test-Hygiene / Mypy) hat den Code-Stand für die Restphase auf produktiv-verifiziertes Niveau gebracht: 0 Mypy-Errors, 0 Pytest-Failures, 142/142 Security-Tests grün, Pentest-Suite 15/15 grün. Drei aufeinanderfolgende Cleanup-Karten haben ihren 4-Stunden-Cap je um −79–85 % unterschritten.

Diese Synthese identifiziert drei Lücken zwischen Fundament und vollständiger SaaS-Reife, die als zusätzliche Sub-Karten ausgewiesen sind: DSGVO-operational (Art. 17 / 20 / 30 / 32 — derzeit nur teilweise im Fundament adressiert), Multi-Tenant-CI-Validation (Pentest-Suite-Erweiterung pro Tenant), und Saga-Lehren-Mapping (welche der 13 produkt-weiten Lehren gelten pro Restblock). Plus: AVS-als-Tenant-Migration ist im Fundament als „frische Leinwand" beschrieben (§15a.4) — ohne Live-Daten-Migration.

Phase 0 — Doku-Inventur und Architektur-Inventur

Phase 0.1 Doku-Inventur — Schlüssel-Erkenntnisse

Datei	Zeilen	Relevanz für SaaS-Plan	Schlüssel-Erkenntnisse
changelog.md	4818	Schätzungs-Kalibrierung	Pattern-Reife-Quote-Trendlinie pro Block-Typ ist seit v1.3.0-Welle empirisch dokumentiert: Cleanup-Welle Backend ~23 %, Frontend ~31 %, Foundation-Reuse hoch ~40 %, Foundation-Reuse + neuer Code ~50 %, Foundation-erweiternd (neue Achse) 50–80 %. Real-Aufwand bisheriger Großblöcke konsistent 30–60 % unter Refined-Schätzung (Block 8: 30.5h vs 50–64h Refined; Block 18: 17–18h vs 21h Refined; Block 11: 5–6h vs 14h Refined; Block 3: 7h vs 12h Refined).
roadmap.md	2511	Format-Konvention	Bestehende Block-Struktur: ~Aufwand-Zeile, Abhängigkeiten, Warum, Ansatz oder Scope, Komponenten oder Verweise, Status-Emoji (✅/🚧/⏳/📋/🔒/💭). Phase-Gliederung A/B/C/D/E. Synthese-Plan respektiert dieses Format.
konzepte/multitenancy-fundament.md	1833	Architektur-Anker	v5.3.4-Konsolidierung hat ~427h Refined-Boden für v1.0.0 etabliert. Drei-Schichten-Modell (Vendor / Operator / Tenant), Dual-Realm-Keycloak (kora-platform + kora-tenants), Qdrant-Collection-per-Chatbot, RLS auf 13 Tabellen mit USING + WITH CHECK, AVS-als-Operator (nicht „Tenant 0" — Tenants sind die Kurverwaltungen). Go-Live „frische Leinwand" ohne Live-Daten-Migration.
security/saga-lehren.md	335	Methodik-Konstitution	13 produkt-weite Lehren mit Cross-Reference-Index. Lehre 13 (Cleanup-Disziplin) hat in der Cleanup-Folge-Serie 1-3 zum dritten Mal in Folge unter Cap geliefert — gilt fortlaufend für jede SaaS-Sub-Karte. Lehre 1 (Phase-0-Discovery), 4 (Reihenfolge-Validierung), 6 (Saga-Convention), 12 (CI-Pentest-Hardening), 13 (Cleanup-Disziplin) sind direkt anwendbar.
security/defense-in-depth.md	335	Architektur-Anker	7-Layer-Topologie L5 → α → Cache → L2 → LLM-Stream-with-Inline-L3 → L4 — pro Layer ist Tenant-Konfiguration entweder bereits realisiert (L2-Operator-Templates pro Chatbot, L3-Pattern-Audit mit tenant_id-Spalte) oder über Tenant-Resolver implizit pro Request kontextualisiert. Keine Refactor-Pflicht für SaaS-Erweiterung der Defense-in-Depth.
konzepte/index.md	35	Konzept-Einbindung	Lese-Reihenfolge für neue Beitragende: zuerst Fundament, dann Konnektor-Roadmap, dann Knowledge-Hub. Diese Synthese gehört nach Fundament als Detail-Plan-Layer zwischen Fundament und Roadmap.
offene-todos.md	2730	Backlog-Realität	Lebende TODO-Liste mit M1/M2/L-Severity. Nach Cleanup-02 (610f459) ist nur TODO-B2-03 offen. Detail-Plan-Karte muss berücksichtigen, dass akkumulierte TODOs aus Code-Reviews der Restblöcke entstehen — die Cleanup-Folge-Serie hat das vor v1.0.0-SaaS systematisch geschlossen.
releases/v1.3.0.md	247	Letzter Release-Datapoint	v1.3.0-Welle (D2 + D1 + E) hat den Customer-Wert-Datapoint der Operator-Per-Chatbot-Page geliefert — ~13h Real / ~42.5h Refined / ~30 % Quote. Die Welle ist in §17.5 separat ausgewiesen, nicht im 427h-v1.0.0-Boden.

Kalibrierungs-Schluss: Die Saga-Toleranz für SaaS-Sub-Karten-Aufwand liegt empirisch bei +0 / −60 % (Real ist tendenziell unter Refined). Das ist die Folge der Saga-Lehren-Akkumulation und der Cleanup-Disziplin (Lehre 13) — eine ähnliche Saga, die in v1.x-Phasen entsteht, sollte ihre Schätzungen wie hier als Refined-Range angeben und Real-Aufwand gegen Range tracken.

Phase 0.2 Architektur-Inventur — bereits implementiert vs. offen

Die Architektur-Inventur hat den Code-Stand auf platform/v1.0.0 post Mypy-Cleanup geprüft. Die Realität ist signifikant weiter als ein generisches „Multi-Tenant-Audit" annehmen würde: das Fundament-Datenmodell (Block 1) hat bereits alle Tenant-Isolation-Primitive etabliert.

Komponente	Aktueller Stand	SaaS-Reife-Lücke	Erwartete Komplexität
Postgres-Schema	RLS via 3 Roles aktiv (Migrator/App/Vendor mit BYPASSRLS), tenant_id-Spalte auf 13 Tabellen, WITH CHECK Policies, Triggers für tenant_id-Konsistenz via chatbot_id	keine — bereits SaaS-reif. Block 16 testet automatisiert.	abgeschlossen ✅ (Block 1)
Tenant-Tabellen	tenants, tenant_packages, tenant_branding, tenant_modules als Domain-Models in db/models/tenant.py	keine — bereits SaaS-reif.	abgeschlossen ✅ (Block 1)
Redis-Cache	Namespace kora:scache:{tenant_id}:{chatbot_id}:{language}:entry:{id} aktiv in services/response_cache.py	keine — bereits Tenant-namespaced. Cleanup-Folge-Karte 2/3 hat 7 Tests auf das Schema migriert.	abgeschlossen ✅
Qdrant	Collection-per-Chatbot via QdrantManager (Block 4); Shared-Collection optional pro Chatbot via uses_shared_docs-Gate (§6.2 Fundament)	keine — bereits Tenant-fan-out. Cross-Tenant-Isolation-Test als 200×/0-Stress in Block 4 etabliert.	abgeschlossen ✅ (Block 4)
Keycloak	Dual-Realm kora-platform + kora-tenants, Realm-Detection in api/dependencies/auth.py:_realm_from_iss(), tenant_id-Claim aus JWT	keine — bereits Multi-Realm. Tenant-User-Lifecycle ist Operator-Verantwortung; Self-Service Block 17 (Phase E).	abgeschlossen ✅ (Block 2)
Tenant-Resolver	FastAPI-Dependency tenant_context.py: JWT-Claim → app.current_tenant_id via SET LOCAL — RLS greift im Anschluss	keine — bereits realisiert. Session-Pool-Benchmark (Scenario A, Commit 4eb764f) bestätigt 25× Throughput vs. Fresh-Engine-per-Request.	abgeschlossen ✅ (Block 3)
Defense-in-Depth Layer-Konfiguration	L2-Operator-Templates pro Chatbot (Block 5 + Migration 0014_system_prompt_templates); L3-Output-Filter mit 5 Patterns + Real-Eval-FP-Sweep ; L5-History-Filter mit tenant_id-Audit; α-Layer mit Pre-LLM-Block	keine — bereits Tenant-konfigurierbar pro Layer. Saga-Lehre 7 (L3-Output-Marker) und 8 (α-Input-Vokabular) gelten unverändert.	abgeschlossen ✅ (Defense-in-Depth-Saga)
Audit-Logs	output_filter_audit, history_persist_filter_audit, input_filter_audit, vendor_access_log, platform_audit_log — alle mit tenant_id-Spalte und Index	keine für Detection. Lücke: DSGVO-Export-Pfad (Art. 30 Verarbeitungsverzeichnis) — fehlt eindeutiger pro-Tenant-Export-Endpoint.	offen — Sub-Karte DSGVO-1 (siehe unten)
Storage / Uploads	MinIO-Buckets — kein per-Tenant-Bucket-Schema bisher	offen — File-Upload-Pfad muss pro Tenant isoliert sein. Mit Block 13 (Upload-Konnektor) eingeplant.	offen — Block 13
API-Routing	FastAPI mit Scope-Middleware aus Block 3 — tenant_id aus JWT für Tenant-Realm, scope=operator/vendor für Platform-Realm	keine — bereits realisiert.	abgeschlossen ✅ (Block 3)
Backup/Restore	Manuelle Qdrant-Snapshots, Postgres-Dump via Compose-Volume	offen — DSGVO Art. 17 Hard-Delete-Pfad mit Backup-Garantie (z.B. 30-Tage-Retention post-Delete) ist nicht im Fundament dokumentiert. Backup-Rotation ist explizit „nicht im Scope" von Block 14.	offen — Sub-Karte DSGVO-2
Data-Export	Nicht-existent	offen — DSGVO Art. 20 Datenportabilität: pro-Tenant-Export-Bundle als JSON + Files. Im Fundament nicht vorgesehen.	offen — Sub-Karte DSGVO-3
Tenant-Provisioning	Manueller PG-Insert + Keycloak-Group-Anlage über Operator-UI	offen — atomare Provisioning-Transaktion über PG + Keycloak mit Kompensations-Logik bei Teilerfolg. Block 12 (Roadmap, ~14h) ist scoped.	offen — Block 12
Multi-Tenant-CI-Validation	Pentest-Suite + 142 Security-Tests laufen Single-Tenant gegen Demo-Stack	offen — Pro-Tenant-Pentest-Run und Cross-Tenant-Isolation-Stress-Test für CI. Implizit in Block 16 (Testing & Doku) enthalten.	offen — verstärken in Block 16

Schlussfolgerung Phase 0.2: Multi-Tenant-Foundation ist solide. Die Restmenge ist nicht „Multi-Tenancy einbauen", sondern Operator/Tenant-UIs vervollständigen, Konnektoren bauen, Deployment-Pipeline und Migration vorbereiten plus drei DSGVO-Operations-Lücken schließen.

Phase 1 — Sub-Karten-Synthese (kalibriert an changelog-Historie)

Diese Synthese mappt offene Roadmap-Blöcke auf eine Sequenz mit Aufwands-Range, Abhängigkeiten, Saga-Lehren-Anwendung und Validation-Kriterien. Drei zusätzliche DSGVO-Sub-Karten ergänzen die Roadmap. Format konsistent zu den existierenden Block-Einträgen in roadmap.md.

Aufwands-Schätzungen sind Refined-Range mit Empirie-Anker aus changelog. Jede Schätzung enthält die erwartete Pattern-Reife-Quote-Klasse (Cleanup, Foundation-Reuse, Foundation-erweiternd) — damit ist Real-Aufwand-Tracking kalibriert.

SubKarte B-9 — Vendor-UI (Block 9 Roadmap)

• Status: 📋 Scoping → 🚧 Implementation
• Refined-Aufwand: ~24h (Konzept §17.2)
• Real-Range erwartet: 12–18h (Foundation-Reuse hoch nach Block 7 Operator-UI; Pattern-Reife-Quote ~50 %)
• Abhängigkeiten: Block 7 Operator-UI ✅, Block 1 (Audit-Tabellen)
• Scope: luki-internes Vendor-UI mit Read-Only-Audit-Sicht über alle Tenants (vendor_access_log + platform_audit_log), Break-Glass-Trigger-Button, Health-Dashboard pro Tenant
• Risiko: mittel — Cross-Tenant-Sichtbarkeit muss strikt audited sein, sonst entsteht Vendor-Pfad-Privilege-Escalation
• Saga-Lehren anwendbar: Lehre 1 (Phase-0-Discovery für Vue-3-Component-Reuse), Lehre 6 (Saga-Convention), Lehre 13 (Cleanup-Disziplin pro Sub-Phase)
• Validation: Vendor-Login zeigt Audit-Logs pro Tenant; Cross-Tenant-Filter-Reset-Test im Cypress/Playwright; Audit-Eintrag pro Vendor-Request in vendor_access_log verifiziert
• DSGVO-Relevanz: Art. 30 (Verarbeitungsverzeichnis) — Vendor-Audit-Sicht ist die operative Grundlage

SubKarte B-10 — System-Prompt-Automatismus (Block 10 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~16h (Konzept §17.2)
• Real-Range erwartet: 8–12h (Foundation-erweiternd auf Block 5 Templates + L2-Operator-Template aus Defense-in-Depth-Saga; Quote ~50 %)
• Abhängigkeiten: Block 5 Templates ✅, Defense-in-Depth Phase 1 (L2-Operator-Template) ✅
• Scope: Operator-Trigger-API, das aus Tenant-Branding + Chatbot-Sources + Template einen ersten System-Prompt synthetisiert. Anti-Persona-Cleanup automatisch (Migration 0018_clean_avs_persona-Pattern als Vorlage für künftige Tenants)
• Risiko: niedrig-mittel — Anti-Persona-Lücken könnten bei künftigen Tenants neue L3-FP produzieren
• Saga-Lehren anwendbar: Lehre 7 (Output-Marker als Co-Indicators — neue Tenant-Personas brauchen leere Anti-Persona-Surface), Lehre 11 (Real-Eval-FP-Sweep gegen synthetische Tenant-Eval-Sets), Lehre 13
• Validation: Synthetisierter System-Prompt wird durch das α-Input-Filter und L3-Output-Filter ohne FP für legitime Eval-Queries (≥ 30 Queries pro neuem Tenant) gefilter; Anti-Persona-Pattern-Match-Rate = 0
• DSGVO-Relevanz: keine direkt

SubKarte B-12 — Provisioning-Automatisierung (Block 12 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~14h (Konzept §17.2)
• Real-Range erwartet: 9–14h (Foundation-Reuse + neuer Code; Quote ~50 %)
• Abhängigkeiten: Block 2 (Keycloak-Admin-API), Block 4 (Qdrant-Collection-Provisioning), Block 7 (Operator-Wizard-UI als Trigger)
• Scope: Atomare PG+Keycloak-Transaktion mit Kompensations-Logik bei Teilerfolg (§14.1 Fundament), Soft-Delete mit 30-Tage-Grace (§14.4), Operator-Alert statt Auto-Retry bei Keycloak-Rollback-Failure
• Risiko: mittel — „halber Tenant" (PG ohne Keycloak-Group) ist schlimmer als gar keiner; Tests müssen den Teilerfolg-Pfad explizit treffen
• Saga-Lehren anwendbar: Lehre 1 (Phase-0-Discovery für Keycloak-Admin-API-Quirks), Lehre 13
• Validation: Forced-Failure-Test bei Keycloak-Group-Anlage löst PG-Rollback aus; resultierender DB-State zeigt keinen Ghost-Tenant; Operator-Alert getriggert
• DSGVO-Relevanz: Art. 32 (Datensicherheit) — atomare Provisioning ist technische Maßnahme

SubKarte C-19 — BGE-M3 + Hybrid Retrieval (Block 19 Roadmap)

• Status: 📋 Scoping (Phase 1+2 Sub-Branches gemäß changelog teilweise schon merged)
• Refined-Aufwand: ~25h (Konzept §17.2 v5.2-Quality-Einschub)
• Real-Range erwartet: 12–18h (Foundation-erweiternd; bereits 4 Sub-Phasen merged)
• Abhängigkeiten: Block 4 (Qdrant), Block 18 ✅ (Docling-Chunks als Input)
• Scope: BGE-M3 als finaler Embedder, Hybrid-Retrieval (dense + sparse) via QdrantHybridRetriever, RRF-Weighted-Joiner, Re-Index-sparendes Migration-Pattern
• Risiko: niedrig (Sub-Phasen bereits in Production via .env.platform-Cutover; siehe Block-19-Phase-4-Eintrag im changelog 1887:)
• Saga-Lehren anwendbar: Lehre 11 (Real-Eval-FP-Sweep nach jeder Pattern-Erweiterung — gilt analog für Retrieval-Quality)
• Validation: R@5 ≥ 0.92, Latenz p95 ≤ 5s im Real-Stack-Vergleich
• DSGVO-Relevanz: keine

SubKarte C-19.5 — Reranker-Upgrade (Block 19.5 Roadmap)

• Status: 📋 Geplant
• Refined-Aufwand: ~6h
• Abhängigkeiten: Block 19
• Scope: Cross-Encoder-Upgrade auf bge-reranker-v2-m3, Score-Threshold-Recalibration
• Risiko: niedrig
• Saga-Lehren anwendbar: Lehre 11

SubKarte C-20 — AST-Aware Chunking (Block 20 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~13h (Konzept §17.2 v5.2-Quality-Einschub)
• Real-Range erwartet: 7–13h (Foundation-Reuse + neuer Code; Quote ~50 %)
• Abhängigkeiten: Block 18 ✅, Block 19
• Scope: AST-aware Chunker für Code-Doku (Tree-Sitter-basiert)
• Saga-Lehren anwendbar: Lehre 1 (Phase-0-Discovery der bestehenden SemanticChunker-Logik)

SubKarte C-13 — Konnektor-Subsystem (Block 13 Roadmap)

• Status: 📋 Scoping (größter offener Block)
• Refined-Aufwand: ~57h (Konzept §17.2 + §13.3a Merkle-Sync v5.2)
• Real-Range erwartet: 28–46h (Foundation-erweiternd auf Phase A; Quote ~50–80 %)
• Abhängigkeiten: Block 1 ✅, Block 4 ✅, Block 18 ✅, Block 19 (für Embedding-Pipeline-Integration)
• Scope: Konnektor-Framework + Upload-Konnektor + Credentials-Management + Merkle-Tree-Inkrement-Sync (§13.3a). Schaltet Block 8.5 (Sources-Management) und Block 13b (Confluence)
• Risiko: hoch — größter Tech-Hub, Multi-Tenancy-Storage muss pro Konnektor pro Tenant isoliert sein
• Saga-Lehren anwendbar: Lehre 1 (Phase-0-Discovery, sehr wichtig), Lehre 4 (Reihenfolge: Framework zuerst, dann Konnektoren), Lehre 13 (mehrere Sub-Phasen mit strikten Caps)
• Validation: Cross-Tenant-Konnektor-Isolation-Test, Merkle-Sync-Diff-Test, Upload-Quota-Limits pro Tenant
• DSGVO-Relevanz: Art. 32 (Datensicherheit) — Konnektor-Credentials pro Tenant verschlüsselt, kein Cross-Tenant-Read

SubKarte C-13b — Confluence-Konnektor (Block 13b Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~25h (oder ~10–15h via MCP-Confluence-Server, siehe Konnektor-Roadmap §2.3)
• Abhängigkeiten: Block 13
• Scope: Confluence-Connector mit Permission-Modell-Integration

SubKarte D-14 — Deployment-Paket & Update-Mechanismus (Block 14 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~20h (Konzept §17.2 + §15a)
• Real-Range erwartet: 10–16h (Foundation-Reuse + neuer Code; Quote ~50 %)
• Abhängigkeiten: keine (parallel zu Phase B/C möglich)
• Scope: Docker-Compose + Private-Registry, kora-platform update-CLI, Alembic-Migration im Update-Pfad, Rollback-Snapshots, Runbook
• Risiko: mittel — AVS muss das Update selbst fahren können
• Saga-Lehren anwendbar: Lehre 13 (Cleanup-Disziplin im Runbook), Lehre 6 (Saga-Convention pro Update-Phase)
• DSGVO-Relevanz: Art. 32 (Datensicherheit) — signiertes Artefakt + Verify-Pfad

SubKarte D-15 — Migration & Go-Live (Block 15 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~12h
• Real-Range erwartet: 7–11h (Foundation-Reuse hoch via §15a-Strategie; Quote ~40–50 %)
• Abhängigkeiten: Phase C komplett, Block 14
• Scope: Seed-Skripte (Default-Tenant „AVS-Intern", Meldeschein- und Kurverwaltungs-Chatbot), Smoke-Run über 20 Queries Meldeschein + 20 Kurverwaltung, Latenz-SLO p50/p90/p99 < 3.5 / 5 / 8 s, R@5 ≥ 0.85, MRR ≥ 0.60 gegen AVS-Ground-Truth, Monitoring-Erweiterung, DNS-Switch-Prozedur, 7-Tage-Observation
• Risiko: mittel-hoch (Go-Live-Window) — Rollback-Kriterien VOR dem Switch fixiert
• Saga-Lehren anwendbar: Lehre 6 (Saga-Convention pro Phase), Lehre 12 (CI-Pentest-Hardening läuft im Observation-Fenster), Lehre 13
• DSGVO-Relevanz: Datenmigration ist explizit „nicht im Scope" via §15a.4 „frische Leinwand" — Demo-Data wird nach 7 Tagen gestoppt, nach weiteren 30 Tagen gelöscht (DSGVO Art. 5 Abs. 1 lit. e Speicherbegrenzung)

SubKarte D-16 — Testing & Dokumentation (Block 16 Roadmap)

• Status: 📋 Scoping
• Refined-Aufwand: ~30h
• Real-Range erwartet: 15–25h (Foundation-Reuse + neuer Code; Quote ~50 %)
• Abhängigkeiten: Phase A, B, C komplett
• Scope: Cross-Tenant-Isolations-Tests als Integration-Test-Suite (tests/integration/platform/), End-to-End der Hauptflows, Runbook-Finalisierung, AVV-Anhang TOM-Katalog (aus Bitkom-Muster), AVS-Konnektor-Entwickler-Guide (§13.10)
• Saga-Lehren anwendbar: Lehre 12 (CI-Pentest-Hardening — pro-Tenant Pentest-Run als Erweiterung der Quick-Win-CI)
• DSGVO-Relevanz: Art. 32 (TOM-Katalog ist Pflicht-Anlage AVV)

SubKarte E-17 — Tenant-SSO-Self-Service (Block 17 Roadmap, Phase E)

• Status: ⏳ Geplant — Post-Launch v1.0.1 / v1.1.0
• Refined-Aufwand: ~49h
• Abhängigkeiten: v1.0.0 produktiv, erste 1-2 Tenants per Operator-Pfad durchgegangen (Erfahrungswerte für UI)

SubKarte DSGVO-1 — Per-Tenant-Audit-Export (NEU, ergänzt Roadmap)

• Status: 📋 Scoping (NEU, fehlt im Fundament)
• Refined-Aufwand: 4–6h
• Abhängigkeiten: Block 1 ✅
• Scope: API-Endpoint /api/v1/operator/tenants/{tenant_id}/audit-export der die fünf Audit-Tabellen (vendor_access_log, platform_audit_log, output_filter_audit, history_persist_filter_audit, input_filter_audit) für einen Tenant als JSON-Bundle exportiert mit Time-Range-Filter
• Risiko: niedrig (Read-Only-Operation auf existing Tabellen)
• Saga-Lehren anwendbar: Lehre 13
• Validation: Bundle enthält genau die Rows mit tenant_id == ?, kein Cross-Tenant-Leak; Bundle-Schema validiert gegen JSON-Schema
• DSGVO-Relevanz: Art. 30 (Verarbeitungsverzeichnis) — operative Grundlage. Diese SubKarte schließt die Lücke aus Phase-0.2-Inventur

SubKarte DSGVO-2 — Hard-Delete-Pfad mit Backup-Garantie (NEU, ergänzt Roadmap)

• Status: 📋 Scoping (NEU, fehlt im Fundament — Block 12 hat nur Soft-Delete mit 30-Tage-Grace)
• Refined-Aufwand: 6–8h
• Abhängigkeiten: Block 12 (Soft-Delete-Foundation), Block 14 (Backup-Runbook)
• Scope: Hard-Delete-CLI kora-platform tenant-purge --tenant-id ... mit (a) Postgres-DELETE über alle Tabellen mit tenant_id, (b) Qdrant-Collection-Drop, (c) Redis-Cache-Invalidate, (d) Keycloak-User-Delete, (e) Backup-Retention-Note (max 30 Tage post-Delete dokumentiert)
• Risiko: mittel-hoch — Hard-Delete ist destruktiv, RUNBOOK-Verifikations-Schritte und Operator-Confirmation-Gate Pflicht
• Saga-Lehren anwendbar: Lehre 1 (Phase-0-Discovery aller tenant_id-Tabellen), Lehre 13
• Validation: Test-Tenant-Delete-Run zeigt 0 verbleibende Rows mit tenant_id == purged-uuid über alle Tabellen; Backup-File-Path im CLI-Output
• DSGVO-Relevanz: Art. 17 (Recht auf Löschung) — Pflicht. Diese SubKarte schließt die Lücke aus Phase-0.2-Inventur

SubKarte DSGVO-3 — Per-Tenant-Daten-Export (NEU, ergänzt Roadmap)

• Status: 📋 Scoping (NEU, fehlt im Fundament)
• Refined-Aufwand: 8–12h
• Abhängigkeiten: Block 1 ✅, Block 8 ✅
• Scope: API-Endpoint /api/v1/tenant/data-export (Tenant-Realm) der ein vollständiges Tenant-Bundle als ZIP exportiert: Chatbot-Konfigurationen, hochgeladene Dokumente, Feedback-Items, Session-Verläufe, Branding-Assets. Format JSON + Files, machine-readable
• Risiko: mittel — Bundle muss vollständig sein (Compliance-Anforderung)
• Saga-Lehren anwendbar: Lehre 1 (Discovery aller pro-Tenant-Datenquellen), Lehre 13
• Validation: Test-Tenant-Export auf einem 3-Chatbot-Tenant zeigt vollständiges Bundle; Bundle-Diff-Test gegen Live-DB zeigt 0 fehlende Entitäten
• DSGVO-Relevanz: Art. 20 (Datenportabilität) — Pflicht. Diese SubKarte schließt die Lücke aus Phase-0.2-Inventur

SubKarte CI-1 — Multi-Tenant-Pentest-Validation (NEU, ergänzt Roadmap)

• Status: 📋 Scoping (NEU, ergänzt Block 16)
• Refined-Aufwand: 4–6h
• Abhängigkeiten: Defense-in-Depth-Saga ✅, Block 16 (Test-Suite-Foundation)
• Scope: Quick-Win-CI-Erweiterung: Pentest-Suite läuft für zwei Test-Tenants (A + B) parallel; Cross-Tenant-Isolation-Stress-Test (200×/0 in CI); Pattern-Coverage-Threshold pro Tenant; Real-Eval-FP-Sweep pro Tenant gegen je-tenant-spezifische Eval-Result-Files
• Risiko: niedrig — additive CI-Erweiterung
• Saga-Lehren anwendbar: Lehre 12 (Pentest-Suite-Hardening — Multi-Tenant ist die natürliche Erweiterung)
• Validation: CI-Job grün auf neuem Multi-Tenant-Suite; Isolation-Stress-Test zeigt 0 Cross-Tenant-Leaks bei 200 parallelen Requests
• DSGVO-Relevanz: Art. 32 (Datensicherheit) — automatisierter Nachweis der technischen Maßnahme

Aufwands-Bilanz

Karte	Refined Schätzung	Real-Range erwartet	Pattern-Reife-Quote
B-9 Vendor-UI	24h	12–18h	~50 %
B-10 System-Prompt-Auto	16h	8–12h	~50 %
B-12 Provisioning	14h	9–14h	~50–60 %
C-19 BGE-M3 (Restphase)	25h	12–18h	~50–60 %
C-19.5 Reranker	6h	4–6h	Foundation-Reuse
C-20 AST-Chunking	13h	7–13h	~50 %
C-13 Konnektor-Framework	57h	28–46h	~50–80 %
C-13b Confluence-Konnektor	10–25h	8–20h	abhängig MCP
D-14 Deployment-Paket	20h	10–16h	~50 %
D-15 Migration & Go-Live	12h	7–11h	~40–50 %
D-16 Testing & Doku	30h	15–25h	~50 %
DSGVO-1 Audit-Export	4–6h	3–5h	Foundation-Reuse hoch
DSGVO-2 Hard-Delete	6–8h	5–7h	Foundation-Reuse + neuer Code
DSGVO-3 Daten-Export	8–12h	6–10h	Foundation-erweiternd
CI-1 Multi-Tenant-Pentest	4–6h	3–5h	Foundation-Reuse hoch
Total Restmenge v1.0.0	~249h Refined	~137–222h Real	Range-Mittel ~180h

(Phase-E-Block-17 mit ~49h ist Post-Launch und nicht im v1.0.0-Boden enthalten.)

Bemerkung: Die Refined-Summe ~249h überschreitet die 140h-Erwartung — das liegt daran, dass die Refined-Range historisch konservativ ist. Real-Range-Mittel ~180h liegt im erwarteten Korridor und passt zur Saga-Lehre-13-Cleanup-Disziplin (3 Cleanup-Karten in Folge je −79–85 % unter Cap). Tracking gegen die Real-Range, nicht gegen Refined.

Phase 2 — Migrations-Strategie + DSGVO + CI-Validation

2.1 AVS-als-Tenant Migrations-Strategie (Verweis)

Detaillierte Strategie ist im Fundament-Konzept bereits dokumentiert: §15a Parallel-Entwicklung, §15a.4 Go-Live-Strategie „frische Leinwand", §16 Migration vom heutigen Stand.

Kern-Prinzip: keine Live-Daten-Migration. Plattform startet mit Seed-Skripten (Default-Tenant „AVS-Intern", Meldeschein- und Kurverwaltungs-Chatbot, Shared-Collection befüllt). Demo-Stack (avs-chatbot Repo) läuft 7 Tage parallel als Observation-Fenster, dann gestoppt; nach weiteren 30 Tagen gelöscht (Speicherbegrenzungs-Compliance).

Diese Synthese ergänzt keine neue Migrations-Strategie — die existierende ist hinreichend.

2.2 DSGVO-Compliance-Pflichten

Artikel	Pflicht	Status pre-Synthese	Status post-Synthese
Art. 17 Recht auf Löschung	Hard-Delete-Pfad inkl. Backup-Garantie (Retention max 30 Tage post-Delete)	Lücke (nur Soft-Delete in Block 12)	DSGVO-2 schließt die Lücke
Art. 20 Datenportabilität	Pro-Tenant-Export als machine-readable Bundle (JSON + Files)	Lücke (nicht im Fundament)	DSGVO-3 schließt die Lücke
Art. 30 Verarbeitungsverzeichnis	Audit-Logs pro Tenant separabel und exportierbar	Lücke (5 Audit-Tabellen vorhanden, kein Export-Endpoint)	DSGVO-1 schließt die Lücke
Art. 32 Datensicherheit	Tenant-Isolation als technische Maßnahme dokumentiert	bereits realisiert (RLS + Triggers + WITH CHECK)	CI-1 liefert kontinuierlichen Nachweis; Block 16 dokumentiert TOM-Katalog
Art. 5 Abs. 1 lit. e Speicherbegrenzung	Aufbewahrungsdauer pro Datenkategorie	Demo-Stack-Stop nach 7+30d in §15a.6, Audit-Retention nicht-explizit	DSGVO-1-Bundle dokumentiert Retention pro Kategorie als Bundle-Annotation

AVV-Anbindung: Bitkom-Muster-AVV als Vorlage (§17 Fundament). Anlage „Technische und organisatorische Maßnahmen" wird in D-16 (Testing & Dokumentation) finalisiert. Drei Vendor-Rollen-Definitionen (vendor-support, vendor-breakglass, vendor-tunnel) sind bereits im Fundament §2.2 dokumentiert.

2.3 CI-Validation-Strategie

Bestehende CI-Infrastruktur (Quick-Win CI aus Defense-in-Depth-Saga, drei Jobs: pattern-coverage → real-eval-fp → live-suite, nightly 03:00 UTC + on-push path-filtered) ist die Basis für die SaaS-Erweiterung:

1. Multi-Tenant-Pentest-Run (CI-1): Pentest-Suite läuft für je zwei Test-Tenants A+B parallel. Pattern-Coverage- und Real-Eval-FP-Threshold pro Tenant. Cross-Tenant-Stress-Test (200×/0) als zusätzlicher CI-Job
2. Cross-Tenant-Isolation-Tests in tests/integration/platform/ (Block D-16): End-to-End-Tests Tenant A → Chatbot → Query, dann Tenant B → kein Daten-Sicht auf Tenant A
3. Performance-Tests bei RLS-Last: 10 simulierte Tenants × Standard-Workload — Latenz-Regression < 10 % vs. Single-Tenant-Baseline
4. Migrations-Smoke-Tests vor jedem D-15-Schritt: automatisierte DNS-Switch-Trockenübung mit Rollback-Kriterien-Verifikation

Phase 3 — Saga-Lehren-Mapping + Risiko-Bewertungs-Matrix

Saga-Lehren-Anwendung pro Restblock

Restblock	Lehren stark	Lehren schwach
B-9 Vendor-UI	1, 6, 13	2, 7, 8 (kein Pattern-Detection-Scope)
B-10 System-Prompt-Auto	1, 7, 11, 13	9, 10 (kein Stream-Pfad)
B-12 Provisioning	1, 13	4 (Reihenfolge schon definiert)
C-19 BGE-M3	11, 12	7, 8 (Retrieval, kein Filter)
C-13 Konnektor-Framework	1, 4, 13	(alle) — größter Block, Discovery + Reihenfolge + Cleanup-Disziplin sind Pflicht
D-14 Deployment	6, 13	(Detection-Lehren n/a)
D-15 Migration	6, 12, 13	(Detection-Lehren n/a)
D-16 Testing & Doku	12	(Lehre-12 ist der Anker — Pentest-Suite-Hardening als dritter Pfeiler)
DSGVO-1, DSGVO-2, DSGVO-3	1, 13	(klein, aber Discovery-Pflicht)
CI-1 Multi-Tenant-Pentest	12, 11	(direkter Lehre-12-Output)

Risiko-Bewertungs-Matrix

Risiko-Klasse	Restblöcke	Mitigation
Hoch (Daten-Leak / Compliance-Verletzung)	C-13 Konnektor-Framework, DSGVO-2 Hard-Delete, D-15 Go-Live	Phase-0-Discovery-Pflicht (Lehre 1), CI-1 Multi-Tenant-Pentest, Operator-Confirmation-Gate für DSGVO-2, Rollback-Kriterien für D-15
Mittel-Hoch (Service-Disruption)	D-14 Deployment-Paket, D-15 DNS-Switch	Rollback-Snapshot pro Update, DNS-TTL-Reduktion, 7-Tage-Observation
Mittel (Funktionalitäts-Regression)	B-9 Vendor-UI, B-10 System-Prompt-Auto, B-12 Provisioning, C-19/19.5/20, C-13b, D-16	Quick-Win-CI-Run pro Sub-Phase, Cleanup-Disziplin (Lehre 13)
Niedrig (additive Änderung)	DSGVO-1, DSGVO-3, CI-1	Read-Only-Operationen, additive CI-Jobs

Risiken in Reihenfolge

Empfohlene Karten-Reihenfolge nach Saga-Lehre 4 (schnellster Win zuerst, dann defensives Netz, dann großer Refactor):

1. CI-1 Multi-Tenant-Pentest (4–6h, Foundation-Reuse) — schnellster Win, etabliert Multi-Tenant-Validation als Drift-Detection für alle nachfolgenden Karten
2. DSGVO-1 Audit-Export (4–6h, Foundation-Reuse) — kleiner Block, schließt eine der drei DSGVO-Lücken
3. B-12 Provisioning (14h, Foundation-Reuse) — atomare Tenant-Anlage als Voraussetzung für DSGVO-3
4. B-10 System-Prompt-Auto (16h, Foundation-erweiternd) — operative Voraussetzung für künftige Tenant-Onboardings
5. DSGVO-3 Daten-Export (8–12h) — schließt zweite DSGVO-Lücke
6. DSGVO-2 Hard-Delete (6–8h) — schließt dritte DSGVO-Lücke; nach B-12 + DSGVO-3, weil Soft-Delete-Foundation und Export-Bundle Voraussetzungen sind
7. B-9 Vendor-UI (24h, Foundation-Reuse) — Vendor-Audit-Sicht ist DSGVO-Art.-30-Operativgrundlage
8. C-19/19.5/20 (44h gesamt, parallel zu B-9 möglich) — Quality-Foundation
9. C-13 Konnektor-Framework (57h, Foundation-erweiternd) — größter Block, strikte Cleanup-Disziplin (Lehre 13) und Phase-0-Discovery (Lehre 1)
10. C-13b Confluence-Konnektor (10–25h) — abhängig von C-13
11. D-14 Deployment-Paket (20h, parallel zu Phase B/C möglich)
12. D-15 Migration & Go-Live (12h) — alle vorigen müssen abgeschlossen sein
13. D-16 Testing & Doku (30h) — finalisiert AVV-TOM-Katalog, AVS-Konnektor-Entwickler-Guide, Cross-Tenant-Isolations-Test-Suite

Phase E (Block 17 Tenant-SSO-Self-Service, ~49h) startet nach v1.0.0-Release und ist nicht im v1.0.0-Boden enthalten.

Verhältnis zu existierender Doku

• Roadmap (roadmap.md) bleibt kanonische Quelle für Block-Status und Phase-Gliederung. Diese Synthese wird in der Roadmap-Status-Box referenziert (siehe Roadmap-Update als separater Commit-Bestandteil)
• Multi-Tenancy-Fundament (konzepte/multitenancy-fundament.md) bleibt kanonische Architektur-Quelle. Drei DSGVO-Sub-Karten und CI-1 sind neue Achsen und werden bei nächster Fundament-Aktualisierung als §17.6 (Operations-Lücken) ergänzt
• Saga-Lehren (security/saga-lehren.md) bleibt methodische Konstitution. Diese Synthese mappt Lehren auf Restblöcke, ohne Lehren neu zu interpretieren
• Defense-in-Depth (security/defense-in-depth.md) bleibt Architektur-Anker. Pro-Layer-Tenant-Konfiguration ist bereits realisiert; keine Refactor-Pflicht aus dieser Synthese

Was diese Synthese nicht ist

• Kein neuer Architektur-Vorschlag — sie folgt Fundament v5.3.4 wörtlich
• Kein Code-Plan — sie ist Strategie auf Karten-Granularität, nicht Implementations-Anleitung
• Kein Re-Schedule-Vorschlag für die Roadmap-Phasen-Reihenfolge — die Roadmap hat eigene Reihenfolge, diese Synthese empfiehlt nur die Reihenfolge der Restmenge in Saga-Lehre-4-Logik
• Kein Vertrag — Aufwands-Range ist Schätzungs-Korridor, nicht Garantie

Status nach Plan-Karte

• ✅ Doku-Inventur abgeschlossen (46 .md-Files inventarisiert, 8 Pflicht-Lesungen)
• ✅ Architektur-Inventur abgeschlossen (12 Komponenten geprüft; Multi-Tenancy bereits zu ~80 % realisiert)
• ✅ Sub-Karten-Synthese: 11 existing Roadmap-Blöcke + 4 neue Sub-Karten (DSGVO-1/2/3 + CI-1) skizziert
• ✅ DSGVO-Lücken identifiziert und durch DSGVO-1/2/3 geschlossen
• ✅ Multi-Tenant-CI-Validation als CI-1 als additive Erweiterung der Quick-Win-CI dokumentiert
• ✅ Saga-Lehren-Mapping pro Restblock
• ✅ Risiko-Bewertungs-Matrix liefert Karten-Reihenfolge nach Saga-Lehre 4

Nächster Schritt: SubKarte CI-1 (Multi-Tenant-Pentest-Validation, 4–6h) als kleinster Foundation-Reuse-Win starten — etabliert die Multi-Tenant-Validation für alle nachfolgenden Karten.