# RBAC Zugriffskonzept (Katalog + Seiten + Endpoints)

## Kontext aus dem Codebestand (aktueller Stand)

- RBAC-Regeln und Rollen existieren bereits mit immutable Kontextfeldern und AccessRule-Unterstuetzung fuer DATA/UI/RESOURCE. Siehe `AccessRuleContext`, `Role`, `AccessRule` in:
```
21:116:gateway/modules/datamodels/datamodelRbac.py
class AccessRuleContext(str, Enum):
    DATA = "DATA"
    UI = "UI"
    RESOURCE = "RESOURCE"
...
class AccessRule(BaseModel):
    roleId: str
    context: AccessRuleContext
    item: Optional[str]
    view: bool
    read: Optional[AccessLevel]
    create: Optional[AccessLevel]
    update: Optional[AccessLevel]
    delete: Optional[AccessLevel]
```
- RBAC-Endpunkte fuer Permissions und Access Rules existieren bereits (Access Rules sind SysAdmin-only):
```
35:214:gateway/modules/routes/routeRbac.py
@router.get("/permissions")
@router.get("/permissions/all")
@router.get("/rules")
```
- Mandantenzuordnung von Benutzern/Rollen laeuft ueber `/api/mandates/{mandateId}/users` und die Junction-Tabellen `UserMandateRole` (Mandanten-Kontext) und `FeatureAccessRole` (Feature-Instanz-Kontext):
```
15:149:gateway/modules/datamodels/datamodelMembership.py
class UserMandateRole(BaseModel):
    userMandateId: str
    roleId: str
...
class FeatureAccessRole(BaseModel):
    featureAccessId: str
    roleId: str
```
- Im Frontend existieren Admin-Seiten fuer Benutzer-Mandant-Mitgliedschaften und Mandanten-Rollen:
```
1:120:frontend_nyla/src/pages/admin/AdminUserMandatesPage.tsx
1:185:frontend_nyla/src/pages/admin/AdminMandateRolesPage.tsx
```

Damit ist klar:
- Zugriffregeln existieren bereits (view + CRUD mit none/my/group/all).
- Fehlend ist ein **Katalog + Editor-UI** fuer Objektregeln (DATA/UI/RESOURCE).

## Entscheidungen / Antworten zu Inputs

1) **Shared Katalog-Location (Gateway):**
   - Es gibt aktuell keinen gemeinsamen RBAC-Objektkatalog in datamodels. Datamodels definieren nur Schema.
   - Ziel-Location: `gateway/modules/security/rbacCatalog/` (Service-Layer), nicht `datamodels`.
   - DATA-Objekte koennen on-the-fly aus Modellen/Attributen abgeleitet werden, ohne Persistenz.
   - UI- und RESOURCE-Objekte brauchen explizite Registry-Eintraege, persistent in einer Katalog-Tabelle, dann ueber Gateway-Endpunkte abrufbar.
   - Feature-Initialisierung im Gateway registriert die UI/RESOURCE-Keys. Die Admin-UI zeigt alle persistierten Katalogobjekte (keine Filterung nach Registrierungsstatus).
   - Persistenz ist Pflicht, um Regeln nicht zu verlieren, wenn Features entfernt oder deaktiviert werden.

2) **Admin-Seite fuer Mandantenverwaltung: gleich wie Rollen-Zuordnung?**
   - Mandanten-CRUD getrennt von Rollen-Zuordnung.
   - Heute: Mandanten-CRUD ist SysAdmin-only (`/api/mandates`), Rollen-Zuordnung ist Mandanten-Admin (`/api/mandates/{mandateId}/users`).
   - Ziel: separate **AdminMandatesPage** (SysAdmin), **AdminUserMandatesPage** fuer Rollen-Zuordnung.
   - Zusaetzlich: **AdminRbacRulesPage** (Feature-Instanz-Admin) fuer Objektregeln.

3) **Registry-Eigentum und Quellen:**
   - Feature-Initialisierung im Gateway definiert alle UI/RESOURCE-Objekte der Features.
   - Frontend registriert keine Feature-UI-Objekte.
   - System-UI-Objekte werden direkt im Backend definiert (keine UI-Abhaengigkeit).

4) **UI-Permissions:**
   - UI-Kontext nutzt nur `view`.
   - Kein create/update/delete fuer UI-Kontext.

5) **Katalog-Scope:**
   - Der Katalog enthaelt alle Objekte (global + mandate + feature instance).

6) **Bootstrap-Scope (interfaceBootstrap.py):**
   - Bootstrap laeuft nur, wenn die Datenbank leer ist.
   - Bootstrap erzeugt nur System-RBAC (Root-Mandant, Admin/Event-User, globale Rollen, Basisregeln).
   - Bootstrap definiert keine Feature-Rollen oder Feature-Zugriffsregeln.
   - System-UI-Objekte sind im Backend definiert und koennen im Bootstrap registriert werden.

## Zielarchitektur

### A) RBAC Objektkatalog (shared im Gateway)

**Ziel:** Ein einziger Objektbaum fuer DATA / UI / RESOURCE, mit Mandant + Feature-Instanz-Kontext.

**Quelle je Objekttyp:**
- **DATA**: abgeleitet aus Model-Metadaten (Tabellen + Felder).
- **UI**: Registry aus Feature-Initialisierung plus backend-definierte System-UI-Objekte.
- **RESOURCE**: Registry aus Feature-Initialisierung.

**Persistenz:**
- Kleine Katalog-Tabelle `RbacObject` (oder aehnlich) fuer UI/RESOURCE.
- DATA-Objekte nicht speichern; on-demand generieren.
- Nicht registrierte Objekte bleiben im Katalog und bleiben selektierbar; keine Filterung nach Registrierung.

**Model (gateway/modules/datamodels/datamodelRbacCatalog.py):**
- `id`
- `objectKey` (unique, z.B. `ui.feature.trustee.contracts.tab.documents`)
- `context` (DATA | UI | RESOURCE)
- `featureCode` (z.B. `trustee`)
- `featureInstanceId` (nullable)
- `mandateId` (nullable)
- `label` (multilingual, optional)
- `meta` (JSON, optional, z.B. Endpoint-Info oder UI-Hints)

**Registry-Logik (gateway/modules/security/rbacCatalog/catalogService.py):**
- `getDataCatalog(mandateId, featureInstanceId)` -> aus Modellen ableiten:
  - `data.table.<table>`
  - `data.table.<table>.<field>`
- `getUiCatalog(mandateId, featureInstanceId, featureCode)` -> aus `RbacObject` (UI-Kontext)
- `getResourceCatalog(mandateId, featureInstanceId, featureCode)` -> aus `RbacObject` (RESOURCE-Kontext)
- `getCatalog(...)` -> zusammenfuehren; alle Objekte (global + mandate + feature instance)

**ObjectKey-Konvention:**
- DATA:
  - `data.table.<table>`
  - `data.table.<table>.<field>`
- UI:
  - `ui.feature.<featureCode>.<area>.<element>`
  - Beispiel: `ui.feature.trustee.contracts.tab.documents`
- RESOURCE:
  - `resource.feature.<featureCode>.<endpoint>`
  - Beispiel: `resource.feature.trustee.contracts.create`

### B) RBAC Rules Editor (neue Admin-Seite)

**Seitenname:** `AdminRbacRulesPage`  
**Zielgruppe:** Feature-Instanz-Admin  
**Route:** `/admin/feature-instances/:featureInstanceId/rbac`  
**Navigation:** Feature-Instanz-Seiten “Rollen” + “Zugriffe” ersetzen durch:
- “Feature-Benutzer” (bestehende User/Rollen-Zuordnung)
- “Zugriffe (RBAC)” (neue Seite fuer Objektregeln)

**Layout:**
- Links: Objektbaum (DATA / UI / RESOURCE)
- Oben: Rollen-Auswahl (Feature-Instanz-Rollen)
- Rechts: Regel-Grid (view/read/create/update/delete mit Scope)
  - UI: nur `view`
  - RESOURCE: view + CRUD mit none/my/group/all
  - DATA: CRUD mit none/my/group/all

**Verhalten:**
- Auswahl eines Objekts zeigt Regeln je Rolle.
- Aenderungen ueber create/update/delete von AccessRule.
- Nur Rollen der Feature-Instanz sind auswaehlbar.

### C) Backend-Endpunkte (Vorschlag)

#### Katalog-Endpunkte
```
GET /api/rbac/catalog?featureInstanceId=...&featureCode=...&include=data,ui,resource
```
Response:
```
{
  "data": [{ "objectKey": "data.table.TrusteeContract", "label": "...", "children": [...] }],
  "ui": [{ "objectKey": "ui.feature.trustee.contracts", "label": "...", "children": [...] }],
  "resource": [{ "objectKey": "resource.feature.trustee.contracts.create", "label": "..." }]
}
```

```
POST /api/rbac/catalog/ui
POST /api/rbac/catalog/resource
```
Payload:
```
{
  "featureCode": "trustee",
  "featureInstanceId": "optional",
  "mandateId": "optional",
  "objects": [
    { "objectKey": "ui.feature.trustee.contracts", "label": { "en": "...", "de": "..." }, "meta": {} }
  ]
}
```
Notes:
- Endpunkte registrieren/aktualisieren UI/RESOURCE-Katalogeintraege.
- DATA-Objekte werden nie gepostet.
- Admin-UI darf alle persistenten Objekte selektieren.

#### AccessRule-Endpunkte (bestehend, aber erweitert)
```
GET  /api/rbac/rules?roleId=...&context=UI&item=ui.feature.trustee.contracts
POST /api/rbac/rules
PUT  /api/rbac/rules/{ruleId}
DELETE /api/rbac/rules/{ruleId}
```
Policy:
- Nur SysAdmin darf Regeln verwalten.

#### Optionale Options-Endpunkte fuer Admin-UI
```
GET /api/options/mandate.roles?mandateId=...
GET /api/options/featureInstance.roles?featureInstanceId=...
GET /api/options/featureInstances?mandateId=...
```

### D) Enforcement
- **DATA:** ueber RBAC in der Daten-Schicht.
- **UI:** Frontend nutzt `getAllPermissions` und blendet aus via `view`.
- **RESOURCE:** Gateway prueft am Endpoint-Entry.

## Implementierungsschritte (high level)

1) Katalog-Model + Service im Gateway.
2) Katalog-Endpunkte in `routeRbacCatalog.py`.
3) Registry-Producer:
   - Feature-Initialisierung registriert UI/RESOURCE.
   - System-UI-Objekte werden im Backend registriert.
4) Neue Admin-Seite `AdminRbacRulesPage`.
5) Feature-Instanz-Navigation anpassen.

## Bootstrap-Abgleich (aktuell vs Ziel)

**Aktuell (interfaceBootstrap.py):**
- Root-Mandant, Admin-User, Event-User.
- Globale Template-Rollen: `admin`, `user`, `viewer`.
- AccessRules (nur wenn keine existieren):
  - Default DATA rules (item=None).
  - Table-spezifische DATA rules (Mandate, UserInDB, Standard-Tabellen, AuthEvent).
  - UI rules (context=UI, item=None, view=True).
  - RESOURCE rules (context=RESOURCE, item=None, view=True).
- Feature-Initialisierung und Feature-Template-Rollen.
- AccessRules fuer Feature-Template-Rollen.

**Ziel:**
- Bootstrap nur System-RBAC, nur bei leerer DB.
- Feature-Definitionen/Template-Rollen/Feature-Regeln entfernen.
- Feature-Initialisierung verwaltet Katalog + Feature-Regeln.

### Konkrete Aenderungen in `interfaceBootstrap.py`

**Aus `initBootstrap()` entfernen:**
- `initFeatures(db)`
- `_initFeatureTemplateRoleAccessRules(db)`

**Feature-Template-Rollen entfernen:**
- `_initFeatureTemplateRoles(db)` und alle Aufrufe

**Feature-Regeln entfernen:**
- `_initFeatureTemplateRoleAccessRules(db)` und alle Aufrufe

**System-RBAC behalten:**
- `initRoles()` fuer globale Rollen `admin`, `user`, `viewer`
- `initRbacRules()` fuer:
  - Default DATA rules
  - Table-spezifische DATA rules
  - UI rules (view)
  - RESOURCE rules (view)

**Bootstrap-Guard:**
- Nur bei leerer DB.
- System-UI-Objekte im Backend registrieren (Bootstrap oder Startup).

## Offene Punkte

- Alle Regeln bleiben persistent, bis sie manuell geloescht werden.

## Feature-Containerisierung

### Ziel
Jedes Feature in einem eigenen Ordner, damit Features durch Ordner-Praesenz aktiv sind. Jeder Container enthaelt:
- `datamodelFeatureXxx.py`
- `interfaceFeatureXxx.py`
- `routeFeatureXxx.py`
- main module fuer RBAC-Objekte
- optionale Helpers

### Aktuelle Feature-Dateien

**Routes (gateway/modules/routes):**
- `routeFeatureTrustee.py`
- `routeFeatureChatbot.py`
- `routeFeatureChatDynamic.py` (chatworkflow)
- `routeFeatureNeutralization.py`
- `routeFeatureRealEstate.py`
- `routeFeatureWorkflow.py` (automation events)
- `routeFeatures.py` (Feature/Instance-Management, kein Feature)

**Interfaces (gateway/modules/interfaces):**
- `interfaceDbTrustee.py`
- `interfaceDbChatbot.py` (shared mit workflow)
- `interfaceDbRealEstate.py`
- `interfaceFeatures.py` (Feature/Instance-Management, kein Feature)

**Datamodels (gateway/modules/datamodels):**
- `datamodelTrustee.py`
- `datamodelChat.py`
- `datamodelWorkflow.py`
- `datamodelRealEstate.py`
- `datamodelNeutralizer.py`
- `datamodelFeatures.py` (Feature/Instance-Management, kein Feature)

**Feature-Logik (gateway/modules/features):**
- `chatbot/` (mainChatbot.py, eventManager.py, chatbotConstants.py)
- `realEstate/` (mainRealEstate.py)
- `neutralizePlayground/` (mainNeutralizePlayground.py)

**Nicht-Feature Module (aus features heraus):**
- `gateway/modules/features/featuresLifecycle.py` -> `gateway/modules/workflows/automation/` (Event Scheduler Handling)
- `gateway/modules/features/workflow/` -> `gateway/modules/workflows/automation/` (zentrale Workflow Execution Engine)
- `gateway/modules/features/dynamicOptions/` -> entfernen, dynamische Optionen ueber API-Routen

### Zielstruktur pro Feature

**trustee** (neu):
- Move:
  - `modules/routes/routeFeatureTrustee.py`
  - `modules/interfaces/interfaceDbTrustee.py`
  - `modules/datamodels/datamodelTrustee.py`
- Add:
  - `modules/features/trustee/mainTrustee.py` (RBAC UI/RESOURCE-Katalog)
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

**chatbot**:
- Move:
  - `modules/routes/routeFeatureChatbot.py`
  - `modules/interfaces/interfaceDbChatbot.py`
  - modules/datamodels/datamodelChatbot.py
- Keep:
  - `modules/features/chatbot/mainChatbot.py`, Helpers
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

**aichat** (chatworkflow):
- Move:
  - `modules/routes/routeFeatureChatDynamic.py`
  - `modules/interfaces/interfaceDbChat.py`
  - modules/datamodels/datamodelChat.py
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

**neutralizer** (Rename von neutralizePlayground):
- Move:
  - `modules/routes/routeFeatureNeutralization.py`
  - `modules/datamodels/datamodelNeutralizer.py`
- Keep:
  - `modules/features/neutralizePlayground/mainNeutralizePlayground.py` (Rename Ordner zu `neutralizer`)
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

**realestate**:
- Move:
  - `modules/routes/routeFeatureRealEstate.py`
  - `modules/interfaces/interfaceDbRealEstate.py`
  - `modules/datamodels/datamodelRealEstate.py`
- Keep:
  - `modules/features/realEstate/mainRealEstate.py`
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

**automation** (neu):
- Move:
  - `modules/routes/routeDataAutomation.py`
  - `modules/interfaces/interfaceDbAutomation.py` <<- new, to put all automation related interfaces here>>
  - `modules/datamodels/datamodelAutomation.py` <<- new, to put class AutomationDefinition here>>
- Add main module fuer RBAC-Katalog (falls noch nicht vorhanden)

- Neue datamodel/interface/route/main Module

### App-Routing als Plug-and-Play
`gateway/app.py` importiert `routeFeature*.py` aus Feature-Containern.
Pattern:
- `from modules.features.<featureCode>.routeFeature<FeatureCode> import router as <featureRouter>`
- Nur existierende Ordner werden eingebunden.
- Feature-Ordner loeschen = Feature deaktivieren.

### Notwendige Referenz-Updates
- Imports in `app.py` auf neue Pfade.
- Alle direkten Imports der alten `modules/routes/routeFeature*.py`.
- `featuresLifecycle.py` und `workflow` nach `gateway/modules/workflows/automation/` verschieben.
- `dynamicOptions` entfernen und UI/API auf Options-Routen umstellen.
- Referenzen auf `modules/interfaces/interfaceDb*.py` und `modules/datamodels/datamodel*.py` anpassen.

### Machbarkeit und Bedenken
- Shared Interfaces/Models (chatbot/workflow) brauchen klare Ownership oder Shared-Modul.
- Feature-Lifecycle sollte Feature-Registry dynamisch laden.
- Feature-Registry (`routeFeatures.py`, `interfaceFeatures.py`, `datamodelFeatures.py`) bleibt global.

### Fragen / Klaerungen
- Bleiben `routeFeatures.py` und `interfaceFeatures.py` global? -> JA
- Shared chatbot/chat: Shared-Modul oder Duplikation? --> Bereits dupliziert, somit separiert
- Feature-Discovery dynamisch (scan) oder explizite Imports in `app.py`? -> dynamisch

### Propositionen
- `routeFeatures.py`, `interfaceFeatures.py`, `datamodelFeatures.py` global behalten (System-Feature-Registry).
- Explizite Imports in `app.py`, aber zentral ueber Feature-Index. --> Die einzelnen Features benötigen keine zentrale komponente mehr. Echt plug & play
- Event Scheduler + Workflow Engine in `gateway/modules/workflows/automation/` (kein Feature).
- `dynamicOptions` entfernen, dynamische Daten per spezialisierte API-Routen (RBAC-Admin Stil).

### Bedenken
- Feature-Removal muss Cron/Jobs/Hook-Registrierungen entfernen. --> bereits implementiert. die werden dann nicht mehr gefunden
- Migration erzeugt viele Import-Aenderungen und Test-Anpassungen. --> korrekt. daher schritt für schritt plan machen
- `dynamicOptions`-Ablösung erfordert UI/API-Umstellung auf neue Options-Routen.

## Services in Feature-Container integrieren

### Ziel
Services, die eindeutig zu Features gehoeren, sollen in den jeweiligen Feature-Container verschoben werden und plug&play geladen werden (analog zu Routes).

### Zuordnung
- **aichat**:
  - `gateway/modules/aicore`
  - `gateway/modules/services/serviceAi`
  - `gateway/modules/services/serviceExtraction`
  - `gateway/modules/services/serviceGeneration`
  - `gateway/modules/services/serviceWeb`
- **neutralizer**:
  - `gateway/modules/services/serviceNeutralization`
- **Generisch (bleibt shared):**
  - alle anderen Services bleiben in `gateway/modules/services`

### Plug&Play fuer Services (analog Routes)
- Feature-Container exportiert Service-Registrierung (z.B. `registerServices()`).
- Zentrale Service-Registry laedt nur vorhandene Feature-Container.
- Entfernt man den Feature-Ordner, werden auch Services nicht mehr geladen.

### Umsetzungsschritte (Ergaenzung)

**Schritt S1: aichat-Services verschieben**
- Move:
  - `gateway/modules/aicore/` -> `gateway/modules/features/aichat/aicore/`
- Move:
  - `gateway/modules/services/serviceAi/` -> `gateway/modules/features/aichat/services/serviceAi/`
  - `gateway/modules/services/serviceExtraction/` -> `gateway/modules/features/aichat/services/serviceExtraction/`
  - `gateway/modules/services/serviceGeneration/` -> `gateway/modules/features/aichat/services/serviceGeneration/`
  - `gateway/modules/services/serviceWeb/` -> `gateway/modules/features/aichat/services/serviceWeb/`
- Referenzen anpassen:
  - alle Imports dieser Services auf die neuen Pfade.
  - Service-Registry in aichat registriert diese Module.

**Schritt S2: neutralizer-Services verschieben**
- Move:
  - `gateway/modules/services/serviceNeutralization/` -> `gateway/modules/features/neutralizer/services/serviceNeutralization/`
- Referenzen anpassen:
  - alle Imports auf neuen Pfad.
  - Service-Registry in neutralizer registriert dieses Modul.

**Schritt S3: Service-Discovery**
- Zentraler Loader (shared) laedt Services pro Feature-Container dynamisch.
- Shared Services bleiben unveraendert in `gateway/modules/services`.

## Umsetzungskonzept (schrittweise)

### Schritt 0: Bestandsaufnahme und Freeze
- **Ziel:** saubere Basis, keine parallelen Feature-Refactors.
- **Aktion:** Branch erstellen, keine Feature-Folder loeschen vor Abschluss.

### Schritt 1: Bootstrap auf System-RBAC reduzieren
- **Datei:** `gateway/modules/interfaces/interfaceBootstrap.py`
- **Aenderung:**
  - In `initBootstrap()` entfernen:
    - `initFeatures(db)`
    - `_initFeatureTemplateRoleAccessRules(db)`
  - Entfernen:
    - `_initFeatureTemplateRoles(db)` (Funktion + Call-Sites)
    - `_initFeatureTemplateRoleAccessRules(db)` (Funktion + Call-Sites)
- **Referenzen:** alle Verweise auf Feature-Template-Rollen und Feature-AccessRules loeschen.
- **Ergebnis:** Bootstrap erstellt nur System-RBAC bei leerer DB.

### Schritt 2: Feature-Container vorbereiten (Ordnerstruktur)
- **Ziel:** pro Feature ein Container mit klarer Struktur.
- **Neuer Ordner pro Feature:**
  - `gateway/modules/features/<featureCode>/`
  - Pflicht-Module:
    - `datamodelFeatureXxx.py`
    - `interfaceFeatureXxx.py`
    - `routeFeatureXxx.py`
    - `main<Feature>.py` (registriert UI/RESOURCE Katalog)
- **Ergebnis:** leere Container fuer `trustee`, `chatbot`, `aichat`, `neutralizer`, `realestate`, `automation`.

### Schritt 3: Trustee in Container verschieben
- **Move:**
  - `gateway/modules/routes/routeFeatureTrustee.py` -> `gateway/modules/features/trustee/routeFeatureTrustee.py`
  - `gateway/modules/interfaces/interfaceDbTrustee.py` -> `gateway/modules/features/trustee/interfaceFeatureTrustee.py`
  - `gateway/modules/datamodels/datamodelTrustee.py` -> `gateway/modules/features/trustee/datamodelFeatureTrustee.py`
- **Neu:**
  - `gateway/modules/features/trustee/mainTrustee.py` (RBAC UI/RESOURCE Katalogregistrierung)
- **Referenzen anpassen:**
  - Alle Imports von `routeFeatureTrustee.py`, `interfaceDbTrustee.py`, `datamodelTrustee.py`
  - `app.py` Router-Import und Registrierung
  - Tests, falls vorhanden

### Schritt 4: Chatbot in Container verschieben
- **Move:**
  - `gateway/modules/routes/routeFeatureChatbot.py` -> `gateway/modules/features/chatbot/routeFeatureChatbot.py`
  - `gateway/modules/interfaces/interfaceDbChatbot.py` -> `gateway/modules/features/chatbot/interfaceFeatureChatbot.py`
  - `gateway/modules/datamodels/datamodelChatbot.py` -> `gateway/modules/features/chatbot/datamodelFeatureChatbot.py`
- **Keep:**
  - `gateway/modules/features/chatbot/mainChatbot.py` + Helpers
- **Neu:**
  - `gateway/modules/features/chatbot/mainChatbotCatalog.py` (oder in `mainChatbot.py`)
- **Referenzen anpassen:**
  - Alle Imports von `routeFeatureChatbot.py`, `interfaceDbChatbot.py`, `datamodelChatbot.py`
  - `app.py` Router-Import und Registrierung

### Schritt 5: AIChat (chatworkflow) in Container verschieben
- **Move:**
  - `gateway/modules/routes/routeFeatureChatDynamic.py` -> `gateway/modules/features/aichat/routeFeatureAiChat.py`
  - `gateway/modules/interfaces/interfaceDbChat.py` -> `gateway/modules/features/aichat/interfaceFeatureAiChat.py`
  - `gateway/modules/datamodels/datamodelChat.py` -> `gateway/modules/features/aichat/datamodelFeatureAiChat.py`
- **Keep:**
  - `gateway/modules/features/workflow/mainWorkflow.py` (falls nur Workflow-Logik)
- **Neu:**
  - `gateway/modules/features/aichat/mainAiChat.py` (RBAC UI/RESOURCE Katalog)
- **Referenzen anpassen:**
  - Alle Imports von `routeFeatureChatDynamic.py`, `interfaceDbChat.py`, `datamodelChat.py`
  - `app.py` Router-Import und Registrierung

### Schritt 6: Neutralizer in Container verschieben und Ordner umbenennen
- **Rename:**
  - `gateway/modules/features/neutralizePlayground/` -> `gateway/modules/features/neutralizer/`
- **Move:**
  - `gateway/modules/routes/routeFeatureNeutralization.py` -> `gateway/modules/features/neutralizer/routeFeatureNeutralizer.py`
  - `gateway/modules/datamodels/datamodelNeutralizer.py` -> `gateway/modules/features/neutralizer/datamodelFeatureNeutralizer.py`
- **Neu:**
  - `gateway/modules/features/neutralizer/mainNeutralizer.py` (RBAC UI/RESOURCE Katalog)
- **Referenzen anpassen:**
  - Alle Imports auf `neutralizePlayground`
  - `app.py` Router-Import und Registrierung

### Schritt 7: RealEstate in Container verschieben
- **Move:**
  - `gateway/modules/routes/routeFeatureRealEstate.py` -> `gateway/modules/features/realestate/routeFeatureRealEstate.py`
  - `gateway/modules/interfaces/interfaceDbRealEstate.py` -> `gateway/modules/features/realestate/interfaceFeatureRealEstate.py`
  - `gateway/modules/datamodels/datamodelRealEstate.py` -> `gateway/modules/features/realestate/datamodelFeatureRealEstate.py`
- **Keep:**
  - `gateway/modules/features/realEstate/mainRealEstate.py`
- **Neu:**
  - `gateway/modules/features/realestate/mainRealEstateCatalog.py` (oder in mainRealEstate)
- **Referenzen anpassen:**
  - Alle Imports der alten Pfade
  - `app.py` Router-Import und Registrierung

### Schritt 8: Automation als Feature-Container
- **Move:**
  - `gateway/modules/routes/routeDataAutomation.py` -> `gateway/modules/features/automation/routeFeatureAutomation.py`
- **Neu:**
  - `gateway/modules/features/automation/interfaceFeatureAutomation.py`
  - `gateway/modules/features/automation/datamodelFeatureAutomation.py` (enthaelt `AutomationDefinition`)
  - `gateway/modules/features/automation/mainAutomation.py` (RBAC UI/RESOURCE Katalog)
- **Referenzen anpassen:**
  - Alle Imports von `routeDataAutomation.py`
  - `app.py` Router-Import und Registrierung

### Schritt 9: App-Routing dynamisch
- **Datei:** `gateway/app.py`
- **Aenderung:**
  - Entferne direkte Imports aus `modules/routes/`.
  - Importiere Router aus Feature-Containern dynamisch (Feature-Discovery).
- **Referenzen:** alle Router-Registrierungen auf neue Pfade/Discovery umstellen.

### Schritt 10: featuresLifecycle anpassen
- **Datei:** `gateway/modules/features/featuresLifecycle.py`
- **Aenderung:**
  - Feature-Registry dynamisch laden (Folder-Discovery).
  - Keine direkten Imports aus alten Pfaden.
- **Referenzen:** Aufrufe in `app.py` bleiben, aber Lifecycle nutzt Feature-Liste.

### Schritt 11: Referenzen global bereinigen
- **Ziel:** Import-Pfade konsistent.
- **Aenderungen:**
  - Alle Imports von `modules/routes/routeFeature*.py` entfernen.
  - Alle Imports von `modules/interfaces/interfaceDb*.py` auf `interfaceFeature*.py` umstellen.
  - Alle Imports von `modules/datamodels/datamodel*.py` auf `datamodelFeature*.py` umstellen.

### Schritt 12: RBAC Katalog Registrierungen pro Feature
- **Ziel:** jede Feature-Instanz registriert UI/RESOURCE Keys.
- **Dateien:** `main<Feature>.py` je Feature-Container
- **Aenderung:** einheitliche Registrierungs-API verwenden (im Katalog-Service).

### Schritt 13: Tests und Verifikation
- **Smoke Tests:**
  - Start Gateway, pruefen dass alle Feature-Routes registriert sind.
  - Entferne Feature-Ordner testweise -> Route nicht mehr vorhanden.
  - RBAC Katalog liefert Objekte fuer alle Features.
  - Bootstrap erzeugt nur System-RBAC bei leerer DB.