Plan anpassen: 4.5/4.6 entfernt, neue generelle 4.5 Modul-Konfiguration pro Workspace

docs/RECOVERY_SCOPE.md

@@ -3,25 +3,33 @@
 **Erstellt:** 2026-08-03
 **Git-Tag:** `pre-recovery-current` (3cbf921)
 **Branch:** `recovery/minimal-finish`
-**Alembic-Head:** 0092
+**Alembic-Head:** 0096
 
-> Diese Datei ist die einzige verbindliche Quelle für den Reparatur- und Abschlussplan.
-> Alle früheren Umbau- und Abschlussdokumente sind überholt.
+> Diese Datei ist die einzige verbindliche Quelle fuer den Reparatur- und Abschlussplan.
+> Alle frueheren Umbau- und Abschlussdokumente sind ueberholt.
 
 ---
 
 ## Verbindliche Regeln
 
 1. Keine neue Zielarchitektur entwerfen.
-2. Keine Microservices einführen.
+2. Keine Microservices einfuehren.
 3. Keine neuen generischen Security-, Entity-, Storage- oder Agentenplattformen bauen.
-4. Bestehende Services nicht vollständig auf Commands umbauen.
+4. Bestehende Services nicht vollstaendig auf Commands umbauen.
 5. Keine Beispiele als Produktanforderungen behandeln.
-6. Keine Migration bis einschließlich `0092` erneut verändern.
-7. Schemafehler ausschließlich über neue Forward-Migrationen korrigieren.
-8. Keine produktiven Daten automatisch zusammenführen oder löschen.
-9. Keine manuellen Änderungen in laufenden Coolify-Containern.
-10. Jeder Arbeitsschritt benötigt: konkreten Fehler, begrenzte Codeänderung, reproduzierbaren Test, eigenen Git-Commit.
+6. Keine Migration bis einschliesslich 0092 erneut veraendern.
+7. Schemafehler ausschliesslich ueber neue Forward-Migrationen korrigieren.
+8. Keine produktiven Daten automatisch zusammenfuehren oder loeschen.
+9. Keine manuellen Aenderungen in laufenden Coolify-Containern.
+10. Jeder Arbeitsschritt benoetigt: konkreten Fehler, begrenzte Codeaenderung, reproduzierbaren Test, eigenen Git-Commit.
+11. Der bisherige UMBAU_PLAN.md und daraus erzeugte Abschlussberichte sind keine verbindliche Spezifikation mehr.
+12. Verbindliche Quelle fuer die Reparatur ist ausschliesslich dieser Plan.
+
+---
+
+## Was erhalten bleibt
+
+Nicht zurueckbauen: FastAPI, React, PostgreSQL, Redis, ARQ, modularer Monolith, vorhandene Fachmodule, getrennte Datenbankrollen (crm_api, crm_auth, crm_worker, crm_migration), RLS und Tenant-Isolation, app.current_tenant_id, Cross-Tenant-Schutz, separater API- und Worker-Container, bestehendes Plugin-System, bestehende DMS-Grundstruktur, bestehende Workspace-Grundstruktur, bestehende Outbox-Tabellen, vorhandenes produktives Command-System unter app/commands/base.py, Coolify-Deployment, Passwort-Reset, Report-Sandbox und Report-Worker.
 
 ---
 
@@ -30,10 +38,10 @@
 | Phase | Status | Hinweis |
 |-------|--------|---------|
 | 0 — Stand sichern | ✅ Abgeschlossen | Tag + Branch + RECOVERY_SCOPE.md |
-| 1 — Migrationen & Zielschema | ⏳ Nicht begonnen | Migrationsaudit + Forward-Migrationen ab 0093 |
-| 2 — Security & Permissions | 🔶 Teilweise erledigt | Workspace-Permissions registriert, Frontend-Fallback entfernt. RLS-Tests offen. |
-| 3 — Doppelte Command-Struktur | ⏳ Nicht begonnen | app/core/commands.py + app/commands/create_contact.py entfernen |
-| 4 — Workspaces | 🔶 Teilweise erledigt | Widget-Fixes, Permissions, Context is_visible, AVAILABLE_MODULES entfernt. Kalenderauswahl, Modulunterpunkte offen. |
+| 1 — Migrationen & Zielschema | ✅ Abgeschlossen | Audit + Forward-Migrationen 0093-0096 |
+| 2 — Security & Permissions | ✅ Abgeschlossen | Permissions registriert, Fallback entfernt, RLS in Produktion verifiziert |
+| 3 — Doppelte Command-Struktur | ✅ Abgeschlossen | core/commands.py + create_contact.py entfernt |
+| 4 — Workspaces | 🔶 Teilweise erledigt | Siehe unten |
 | 5 — AI & MCP | ⏳ Nicht begonnen | Delegationstoken, Bearer-Auth, Pfadbegrenzung |
 | 6 — DMS & Attachments | ⏳ Nicht begonnen | Streaming, Deduplikation, Alt-Migration |
 | 7 — Plugins, Worker, Outbox | ⏳ Nicht begonnen | Plugin-Gate, Event-Envelope, Handler-Tracking |
@@ -42,10 +50,79 @@
 
 ---
 
+## Phase 4 — Workspaces
+
+### Verbindlicher Funktionsumfang
+
+1. Workspaces sind ausschliesslich UI- und Arbeitskontext.
+2. Workspaces veraendern keine Rechte.
+3. Module koennen je Workspace sichtbar oder ausgeblendet werden.
+4. Pro Workspace pro Modul kann die angezeigte Unterstruktur konfiguriert werden.
+5. Die Konfiguration erfolgt ueber workspace_modules.config (JSONB) — jedes Modul definiert selbst was in seiner config steht.
+6. Beispiel: Kontakte-Modul → config enthaelt sichtbare Ordner-IDs.
+7. Beispiel: DMS-Modul → config enthaelt sichtbare Ordner-IDs.
+8. Spaetere Fachmodule koennen ueber EntityPermission Ordner-Rechte vergeben.
+9. Kein Schema-Aenderung noetig — JSONB ist flexibel genug.
+10. Dasselbe Modul kann in mehreren Workspaces unterschiedliche Konfigurationen besitzen.
+11. Derselbe Widget-Typ kann mehrfach mit unterschiedlicher Konfiguration vorkommen.
+
+Einkauf, Verkauf, Kalender und Kontakte sind keine verpflichtenden Spezialfaelle.
+
+### 4.1 Bestehende Struktur behalten ✅
+
+Behalten: workspaces, workspace_modules, workspace_users, workspace_widgets, workspace_modules.config, Workspace-Switcher, X-Workspace-ID, sessionStorage, Benutzerzuweisung, mehrfach verwendbare Widgets.
+
+Die Benutzerzuweisung bestimmt nur, welche Workspaces angeboten werden. Sie vergibt keine Datenrechte.
+
+### 4.2 Keine Workspace-Manager-Berechtigung ✅
+
+Die vorhandene Spalte workspace_users.role wird nicht als Autorisierung verwendet. Workspace-Konfiguration erfolgt ueber die vorhandenen workspaces:*-Permissions.
+
+### 4.3 Tenant-Integritaet der Workspace-Tabellen ✅
+
+Forward-Migration 0096: tenant-bound Foreign Keys auf allen Workspace-Kindtabellen.
+
+### 4.4 Modulverwaltung ✅
+
+Hartcodierte Modulliste im Frontend entfernt. Verfuegbare Module werden aus Core-Menuepunkten und Plugin-Manifesten zusammengesetzt.
+
+### 4.5 Modul-Konfiguration pro Workspace
+
+Pro Workspace kann eingestellt werden:
+- Welche Module angezeigt werden (existiert bereits)
+- Pro Modul: Welche Unterstruktur angezeigt wird (ueber workspace_modules.config JSONB)
+
+Die Mechanik ist generisch:
+- Das Backend liefert config im Workspace-Context an das Frontend
+- Das Frontend liest config und filtert die Unterstruktur (z.B. Ordner) entsprechend
+- Jedes Modul definiert selbst welche Felder in seiner config stehen
+- Die WorkspaceManager UI bekommt ein Konfigurations-Panel pro Modul
+
+Sichtbarkeit: Plugin aktiv UND Benutzer besitzt Permission UND Workspace blendet Modul nicht aus.
+
+### 4.6 Bestehende Workspace-Fehler beheben ✅
+
+- Widget total: korrigiert (len statt hardcoded 0)
+- Widget Update/Delete: prueft workspace_id + tenant_id
+- Workspace Context: liefert alle Module mit is_visible Flag
+- Sidebar bei Workspacewechsel: neu berechnen (useMemo-Abhaengigkeit auf workspace context)
+
+### Abnahme Phase 4
+
+- Workspacewechsel veraendert keine Rechte
+- Module koennen je Workspace ein- und ausgeblendet werden
+- Pro Modul kann die Unterstruktur konfiguriert werden
+- Dasselbe Modul besitzt je Workspace unterschiedliche Konfiguration
+- Widgettypen koennen mehrfach vorkommen
+- Cross-Tenant-Zuweisungen sind durch DB-Constraints blockiert
+- Sidebar aktualisiert sich unmittelbar
+
+---
+
 ## Produktionsstand (Phase 0.1)
 
-- **Git-Commit:** 3cbf921 (main)
-- **Alembic-Version:** 0092
+- **Git-Commit:** 3eb11b1 (main)
+- **Alembic-Version:** 0096
 - **Produktions-URL:** https://crm.media-on.de — healthy
 - **API:** healthy, Worker: healthy
 - **RLS-Tabellen:** 109
@@ -56,10 +133,10 @@
 
 ---
 
-## Überholte Dokumente
+## Ueberholte Dokumente
 
 Folgende Dokumente sind nicht mehr als Umsetzungsanweisung zu verwenden:
 
-- `docs/ABSCHLUSSBERICHT_PHASE0_PHASE1.md` — ÜBERHOLT
-- `SANIERUNGS_FORTSCHRITT.md` — ÜBERHOLT
-- `docs/phase0_phase1_acceptance_report.md` — ÜBERHOLT
+- docs/ABSCHLUSSBERICHT_PHASE0_PHASE1.md — UEBERHOLT
+- SANIERUNGS_FORTSCHRITT.md — UEBERHOLT
+- docs/phase0_phase1_acceptance_report.md — UEBERHOLT