Agent Zero
6.4 KiB
LeoCRM Recovery Scope
Erstellt: 2026-08-03
Git-Tag: pre-recovery-current (3cbf921)
Branch: recovery/minimal-finish
Alembic-Head: 0096
Diese Datei ist die einzige verbindliche Quelle fuer den Reparatur- und Abschlussplan. Alle frueheren Umbau- und Abschlussdokumente sind ueberholt.
Verbindliche Regeln
- Keine neue Zielarchitektur entwerfen.
- Keine Microservices einfuehren.
- Keine neuen generischen Security-, Entity-, Storage- oder Agentenplattformen bauen.
- Bestehende Services nicht vollstaendig auf Commands umbauen.
- Keine Beispiele als Produktanforderungen behandeln.
- Keine Migration bis einschliesslich 0092 erneut veraendern.
- Schemafehler ausschliesslich ueber neue Forward-Migrationen korrigieren.
- Keine produktiven Daten automatisch zusammenfuehren oder loeschen.
- Keine manuellen Aenderungen in laufenden Coolify-Containern.
- Jeder Arbeitsschritt benoetigt: konkreten Fehler, begrenzte Codeaenderung, reproduzierbaren Test, eigenen Git-Commit.
- Der bisherige UMBAU_PLAN.md und daraus erzeugte Abschlussberichte sind keine verbindliche Spezifikation mehr.
- 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.
Phasen-Status
| Phase | Status | Hinweis |
|---|---|---|
| 0 — Stand sichern | ✅ Abgeschlossen | Tag + Branch + RECOVERY_SCOPE.md |
| 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 |
| 8 — CI, Restore, Coolify | ⏳ Nicht begonnen | Merge-CI, Migrations-Gate, Restore-Test |
| 9 — Abschluss | ⏳ Nicht begonnen | RECOVERY_ACCEPTANCE_REPORT.md |
Phase 4 — Workspaces
Verbindlicher Funktionsumfang
- Workspaces sind ausschliesslich UI- und Arbeitskontext.
- Workspaces veraendern keine Rechte.
- Module koennen je Workspace sichtbar oder ausgeblendet werden.
- Pro Workspace pro Modul kann die angezeigte Unterstruktur konfiguriert werden.
- Die Konfiguration erfolgt ueber workspace_modules.config (JSONB) — jedes Modul definiert selbst was in seiner config steht.
- Beispiel: Kontakte-Modul → config enthaelt sichtbare Ordner-IDs.
- Beispiel: DMS-Modul → config enthaelt sichtbare Ordner-IDs.
- Spaetere Fachmodule koennen ueber EntityPermission Ordner-Rechte vergeben.
- Kein Schema-Aenderung noetig — JSONB ist flexibel genug.
- Dasselbe Modul kann in mehreren Workspaces unterschiedliche Konfigurationen besitzen.
- 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:
3eb11b1(main) - Alembic-Version: 0096
- Produktions-URL: https://crm.media-on.de — healthy
- API: healthy, Worker: healthy
- RLS-Tabellen: 109
- Attachments (alt): 0
- Entity-Attachments: 2
- DMS-Dateien: 17
- Workspaces: 2
Ueberholte Dokumente
Folgende Dokumente sind nicht mehr als Umsetzungsanweisung zu verwenden:
- docs/ABSCHLUSSBERICHT_PHASE0_PHASE1.md — UEBERHOLT
- SANIERUNGS_FORTSCHRITT.md — UEBERHOLT
- docs/phase0_phase1_acceptance_report.md — UEBERHOLT