Agent Zero
143 lines
6.4 KiB
Markdown
143 lines
6.4 KiB
Markdown
# 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
|
|
|
|
1. Keine neue Zielarchitektur entwerfen.
|
|
2. Keine Microservices einfuehren.
|
|
3. Keine neuen generischen Security-, Entity-, Storage- oder Agentenplattformen bauen.
|
|
4. Bestehende Services nicht vollstaendig auf Commands umbauen.
|
|
5. Keine Beispiele als Produktanforderungen behandeln.
|
|
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.
|
|
|
|
---
|
|
|
|
## 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
|
|
|
|
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:** 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
|