refactory subscriptions and rag and udb integration

concepts/Kontext-20260328.md

@@ -61,14 +61,14 @@ Es gibt ZWEI vollständig getrennte Rollensysteme. Siehe auch: `@poweron/.cursor
 
 | Datei | Zweck |
 |-------|-------|
-| `@poweron/gateway/modules/interfaces/interfaceDbApp.py` | Kern-DB-Interface: createUserMandate, createFeatureAccess, _provisionMandateForUser (44x `_`-Prefix-Filter für System-Felder) |
+| `@poweron/gateway/modules/interfaces/interfaceDbApp.py` | Kern-DB-Interface: createUserMandate, createFeatureAccess, _provisionMandateForUser; Domain-Models nutzen `PowerOnModel` / `sys*`-Metadaten |
 | `@poweron/gateway/modules/interfaces/interfaceFeatures.py` | Feature-Instanz-Verwaltung: _copyTemplateRoles, syncRolesFromTemplate |
 | `@poweron/gateway/modules/routes/routeStore.py` | Store-API: activate, mandates-list |
 | `@poweron/gateway/modules/routes/routeAdminFeatures.py` | Admin-API: add_user_to_feature_instance (Rollen-Validierung: nur Instanz-Rollen!), rename instance |
 | `@poweron/gateway/modules/routes/routeSystem.py` | `/api/navigation` — liefert isAdmin pro FeatureInstance |
 | `@poweron/gateway/modules/routes/routeSecurityLocal.py` | Login, Register, _provisionMandateForUser |
 | `@poweron/gateway/modules/shared/attributeUtils.py` | Generiert Attribute aus Pydantic-Models für FormGenerator |
-| `@poweron/gateway/modules/connectors/connectorDbPostgre.py` | DB-Connector: _saveRecord setzt automatisch _createdAt, _createdBy, _modifiedAt, _modifiedBy |
+| `@poweron/gateway/modules/connectors/connectorDbPostgre.py` | DB-Connector: `sysCreatedAt` / `sysCreatedBy` / `sysModifiedAt` / `sysModifiedBy`; Migration alter `_createdAt`-Spalten via `migrateLegacyUnderscoreSysColumns` (Bootstrap) |
 | `@poweron/gateway/modules/migration/migrateRootUsers.py` | Root→Personal-Mandate-Migration |
 
 ---
@@ -90,31 +90,24 @@ Es gibt ZWEI vollständig getrennte Rollensysteme. Siehe auch: `@poweron/.cursor
 | `@poweron/frontend_nyla/src/components/FormGenerator/` | Dynamische Formulare aus Backend-Attribut-Definitionen |
 | `@poweron/frontend_nyla/src/hooks/useNavigation.ts` | Navigation-Hook mit FeatureInstance.isAdmin |
 | `@poweron/frontend_nyla/src/pages/views/workspace/WorkspacePage.tsx` | Workspace-Feature-Seite |
+| `@poweron/frontend_nyla/src/pages/views/commcoach/CommcoachDossierView.tsx` | CommCoach mit UDB (`hideTabs: chats`), gleicher `instanceId`/`mandateId`-Kontext wie Workspace |
+| `@poweron/gateway/modules/datamodels/datamodelBase.py` | `PowerOnModel`: `sysCreatedAt`, `sysCreatedBy`, `sysModifiedAt`, `sysModifiedBy` (camelCase, UI-readonly vorbereitet) |
 
 ---
 
-## System-Felder (DB-Metadaten) — OFFENER PUNKT
+## System-Felder (DB-Metadaten)
 
-Die DB-Schicht (`connectorDbPostgre.py`) pflegt automatisch 4 System-Felder für jede Tabelle:
-- `_createdAt` (float, UTC timestamp)
-- `_createdBy` (str, userId)
-- `_modifiedAt` (float, UTC timestamp)
-- `_modifiedBy` (str, userId)
-
-Diese werden aktuell in `interfaceDbApp.py` an 44 Stellen via `{k: v for k, v in record.items() if not k.startswith("_")}` herausgefiltert, bevor Records an die API/Frontend gehen. Es gibt KEINE gemeinsame Base-Klasse — alle 30+ Pydantic-Models erben direkt von `BaseModel`.
-
-**Offene Architektur-Entscheidung:** Diese 4 System-Felder sollen im UI als read-only sichtbar sein (z.B. in Tabellen/Formularen). Optionen:
-- (a) `PowerOnModel(BaseModel)` als Base-Klasse mit den 4 Feldern (mit `alias="_createdAt"` etc.) einführen, `_`-Filter entfernen
-- (b) Einige Models (`FeatureDataSource`, `DataSource`, `FileFolder`, `Invitation`, `Messaging`) haben bereits eigene `createdAt`/`createdBy` als Business-Felder — Namenskonflikte zu klären!
-- Der `FormGenerator` unterstützt bereits `readonly`-Attribute korrekt
+- **Spalten / Modelle:** `sysCreatedAt`, `sysCreatedBy`, `sysModifiedAt`, `sysModifiedBy` — gepflegt durch den Connector (`connectorDbPostgre.py`); viele Domain-Models erben von `PowerOnModel` in `datamodelBase.py`.
+- **Legacy:** Frühere `_createdAt`-ähnliche Spalten werden bei Bootstrap durch `migrateLegacyUnderscoreSysColumns` / `migrateLegacyUnderscoreSysColumnsAllPoweronDatabases` in die `sys*`-Felder übernommen.
+- **UI:** FormGenerator unterstützt `readonly`-Attribute; wo Metadaten in Listen/Forms explizit gezeigt werden sollen, Felder als readonly markieren (schrittweise je Screen).
 
 ---
 
-## Weitere offene Themen aus dem vorherigen Chat
+## Produkt-Themen (Stand laut Umsetzung)
 
-1. **CommCoach UDB-Integration:** UDB in CommCoach einbinden (ohne Chats-Tab), gleicher AI-Service wie Workspace, CommCoach behält eigene SSE-Chat-Komponente
-2. **Zentrale AI-Neutralisierung:** RAG mandate-weit verfügbar, Neutralisierungs-Pipeline weiter konsolidieren
-3. **Settings-Seite:** 5 Tabs vorhanden (profile, appearance, voice, neutralization, privacy) — Vollständigkeit prüfen
+1. **CommCoach UDB:** `CommcoachDossierView` nutzt `UnifiedDataBar` mit `hideTabs={['chats']}` (Dateien + Quellen). Coaching bleibt bei der bestehenden SSE-Pipeline. **KI:** `CommcoachService._callAi` nutzt `getService("ai", ServiceCenterContext)` — dieselbe ServiceCenter-AI-Schicht wie der Workspace inkl. Neutralisierung in `mainServiceAi.callAi`. Nach `documentCreated` im Stream feuert die View `fileUploaded`, die UDB-`FilesTab` lädt die Liste neu.
+2. **Zentrale Neutralisierung & RAG:** Prompt-Neutralisierung und Rehydration laufen in `mainServiceAi` (stream + non-stream). Tool `neutralizeData` im Agent und die Indizierung in `mainServiceKnowledge` nutzen denselben Neutralization-Service. **Mandanten-RAG in CommCoach:** Bei Retrieval-Intent „Thema erinnern“ (`RECALL_TOPIC`) werden nach Keyword-Suche zusätzlich Embedding + `searchSessionsByTopicRag` (Knowledge-Interface, mandate-scoped) eingespeist; die Prompt-Zeile „Relevante Sessions und Mandantenwissen …“ fasst Sessions und RAG-Snippets zusammen.
+3. **Settings (5 Tabs):** Profil (Modal + Konto + About), Darstellung (Theme + UI-Sprache), Stimme (STT/TTS API), Datenneutralisierung (Erklärung + Platzhalter-Mappings-Liste), Datenschutz (Kurztext Mandant/Features + Link GDPR). Für tiefergehende Neutralizer-Konfiguration (Feature-Instanz) bleiben die Feature-spezifischen Admin-UIs zuständig.
 
 ---