diff --git a/docs/RECOVERY_SCOPE.md b/docs/RECOVERY_SCOPE.md index 84e0858..d2f7004 100644 --- a/docs/RECOVERY_SCOPE.md +++ b/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