fix: audit corrections - verify reference docs against code, fix misplacements and wrong paths

Made-with: Cursor

README.md

@@ -1,18 +1,18 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
 
-# PowerOn Portal -- Dokumentation
+# PowerOn PORTA -- Dokumentation
 
 ## Produkt
 
-PowerOn Portal ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung.
+PowerOn PORTA ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung.
 
 | Komponente | Repository | Technologie | Beschreibung |
 |-----------|-----------|-------------|-------------|
 | Frontend Nyla | `frontend_nyla` | React/TypeScript, Vite | Zentrales UI für alle Features |
 | Gateway | `gateway` | FastAPI, Python, PostgreSQL | Backend REST-API, Services, AI-Core |
 | Private LLM | `private-llm` | Python | Internes LLM für Neutralisierung + sensitive Daten |
-| Teams Bot | `service-teams-browser-bot` | Node.js/.NET | Bot für Teams-Meeting-Teilnahme |
+| Teams Bot | `service-teams-browser-bot` | TypeScript/Node.js | Bot für Teams-Meeting-Teilnahme |
 | Wiki | `wiki` | Markdown | Dokumentation (dieses Repo) |
 
 ---

b-reference/frontend-nyla/architecture.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: frontend_nyla (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: frontend_nyla (codebase audit 2026-04-05) -->
 
 # Frontend Nyla -- Architektur
 
@@ -14,9 +14,9 @@ Technologie-Stack (Stand UI-Doku): React 19.x, Vite 5.x, TypeScript 5.8.x, React
 
 | Ordner | Inhalt |
 |--------|--------|
-| `pages/` | Seiten: `admin/`, `basedata/`, `billing/`, `settings/`, `views/` (workspace, commcoach, chatbot, trustee, automation) |
+| `pages/` | Seiten: `admin/`, `basedata/`, `billing/`, `settings/`, `views/` (workspace, commcoach, chatbot, trustee, automation, automation2, realestate, neutralization, teamsbot) |
 | `components/` | Wiederverwendbar: FormGenerator, FolderTree, Navigation, UnifiedDataBar, Automation2FlowEditor, OnboardingAssistant |
-| `hooks/` | useApi, useFiles, useNavigation, useConfirm, usePrompt, useResizablePanels, etc. |
+| `hooks/` | useApiRequest (useApi.ts), useFiles, useNavigation, useConfirm, usePrompt, useResizablePanels, etc. |
 | `contexts/` | FileContext, PekContext, ToastContext, WorkflowSelectionContext |
 | `api/` | API-Client (`api.ts`) und Feature-spezifische API-Module |
 | `core/` | PageManager |
@@ -42,8 +42,8 @@ Ergänzend typische Root-Dateien und Bereiche im Repo: `main.tsx`, `App.tsx`, `a
 
 - **Einstieg:** `main.tsx` rendert `App.tsx` mit Providern (z. B. Sprache, Auth) und **React Router** (`Routes` / `Route`).
 - **Geschützte Bereiche:** Route-Guards (z. B. `ProtectedRoute`) prüfen Authentifizierung; Redirect bei fehlender Session.
-- **Haupt-App:** Nach Login typischerweise ein Home-/Shell-Layout mit **Sidebar** und **PageManager**.
-- **Seiten-Mapping:** `PageManager` + Konfiguration (z. B. `pageConfigs`) — lazy geladene Page-Komponenten, Sidebar-Metadaten, optional `preserveState` für Navigation ohne State-Verlust.
+- **Haupt-App:** Nach Login **`MainLayout.tsx`** mit **`MandateNavigation`** (Sidebar) und `<Outlet />` (React Router).
+- **Seiten-Mapping:** `pageRegistry.tsx` definiert `PAGE_REGISTRY` und `FEATURE_REGISTRY`; Seiten werden lazy geladen. `core/PageManager/` enthält ergänzende Infrastruktur (State Preservation, Lifecycle-Hooks).
 - **i18n / Theme:** global über Context; API-Requests mit Auth-Header (Interceptor in zentralem API-Client).
 
 ## UI-Regeln
@@ -59,8 +59,9 @@ Ergänzend typische Root-Dateien und Bereiche im Repo: `main.tsx`, `App.tsx`, `a
 | `main.tsx` | Application Entry Point |
 | `App.tsx` | Root-Komponente, Router-Setup, Provider |
 | `api.ts` (Root) | Axios-Instanz, Base URL, Token-Interceptor, 401-Handling |
-| `core/` / `components/PageManager/` | Dynamisches Laden, Animationen, Lifecycle, Caching |
-| `pageConfigs` (o. ä.) | Lazy Imports, Sidebar-Einträge, Page-Metadaten |
+| `layouts/MainLayout.tsx` | Haupt-Shell mit MandateNavigation + Outlet |
+| `config/pageRegistry.tsx` | PAGE_REGISTRY, FEATURE_REGISTRY, Lazy Imports |
+| `core/PageManager/` | State Preservation, Lifecycle, Caching |
 | `auth/authConfig`, `authProvider`, `ProtectedRoute` | MSAL, geschützte Routen |
 | `contexts/*` | FileContext, PekContext, Toast, Workflow-Auswahl, etc. |
 | `locales/*` | Übersetzungen (z. B. de / en / fr) |

b-reference/gateway/ai-agent.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # AI Agent & Knowledge Store
 

b-reference/gateway/architecture.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Gateway -- Architektur
 
@@ -15,27 +15,27 @@ Unter `gateway/modules/` (Kontext-Audit):
 | Modul | Zweck |
 |-------|-------|
 | `aicore/` | Model-Registry, Model-Selector, Provider-Plugins (Anthropic, OpenAI, Mistral, Perplexity, Tavily, PrivateLLM) |
-| `auth/` | Authentifizierung |
-| `connectors/` | DB-Connector (PostgreSQL), externe Konnektoren |
+| `auth/` | Authentifizierung, CSRF, Token-Refresh-Middleware, JWT |
+| `connectors/` | DB-Connector (PostgreSQL), Provider-Subpakete (Microsoft, Google, ClickUp, FTP), Ticket/Messaging/Geo-Konnektoren |
 | `datamodels/` | Pydantic-Datenmodelle (u. a. Ai, Billing, Chat, Content, Files, Knowledge, Rbac, Subscription, Workflow) |
 | `features/` | Feature-Module (autonome Domänen): workspace, automation, automation2, chatbot, commcoach, neutralization, realEstate, trustee, teamsbot |
 | `interfaces/` | DB-Interfaces (App, Billing, Chat, Knowledge, Management, Subscription), AI-Objects, RBAC, Features, Messaging |
 | `migration/` | Daten-Migrationen |
 | `routes/` | REST-API-Routen (u. a. Admin, Billing, DataFiles, DataSources, Security, Store, System) |
-| `security/` | Sicherheits-Middleware |
+| `security/` | RBAC (`rbac.py`, `rbacCatalog.py`), Root-Access |
 | `serviceCenter/` | Zentrale Service-Orchestrierung (Registry, Resolver, Kontext, Haupt-Services) |
 | `serviceHub/` | Service-Registry und Dependency Injection (u. a. `PublicService`-Wrapper) |
 | `shared/` | Gemeinsame Utilities (attributeUtils, Konfiguration, Logging, …) |
-| `system/` | System-Konfiguration |
+| `system/` | System-Konfiguration, Feature-Discovery (`registry.py`: `loadFeatureMainModules`, `loadFeatureRouters`) |
 | `workflows/` | Workflow-Engine mit Methoden und Aktionen |
 
 ## ServiceCenter (Kern-Orchestrierung)
 
 Das ServiceCenter ist die zentrale Schicht, die Kern- und importierbare Services verbindet. Pro Request/Session wird ein **`ServiceCenterContext`** (`serviceCenter/context.py`) mitgeführt und propagiert u. a.:
 
-- `userId`, `mandateId`, `featureInstanceId`
+- `user: User` (gesamtes User-Objekt), `mandateId`, `featureInstanceId`
+- `workflow_id`, `workflow`, `feature_code`
 - `requireNeutralization` (optional) — Neutralisierungsflag auf Chat-Ebene
-- Provider-Restrictions, Billing-Context
 
 Die öffentliche API umfasst u. a. `getService(key, context)` zur Auflösung einer Service-Instanz; registrierte Services sind in `registry.py` als **CORE_SERVICES** und **IMPORTABLE_SERVICES** hinterlegt, mit feature-spezifischer Auflösung und optionaler Vorabladung (`preWarm`).
 
@@ -91,9 +91,10 @@ Weitere Interface-Dateien im Ordner (z. B. Voice, Tickets, Messaging, Bootstrap)
 | `gateway/modules/routes/*.py` | HTTP-Endpunkte, Aufruf in Richtung Service Center / Features |
 | `gateway/modules/interfaces/*.py` | Stabile Verträge und DB-Zugriffe (keine direkte Vendor-Logik in Services) |
 | `gateway/modules/connectors/*.py` | Vendor-spezifische Adapter (Auth, Transport, Mapping) |
-| `gateway/modules/security/*` | CSRF, Token-Refresh-Middleware, JWT/Auth-Utilities |
+| `gateway/modules/security/*` | RBAC-Auswertung, RBAC-Katalog, Root-Access |
+| `gateway/modules/auth/*` | CSRF, Token-Refresh-Middleware, JWT, OAuth |
 | `gateway/modules/shared/*` | Querschnitt: Konfiguration, Audit-Logging, Events, Utilities |
-| `gateway/modules/features/init.py` | Initiale Trigger beim App-Start |
+| `gateway/modules/system/registry.py` | Feature-Discovery, Router-Laden, Katalog-Registrierung beim App-Start |
 | `gateway/modules/workflows/workflowManager.py` | Zentrale Workflow-Steuerung |
 
 ## Regeln / Invarianten
@@ -102,5 +103,5 @@ Weitere Interface-Dateien im Ordner (z. B. Voice, Tickets, Messaging, Bootstrap)
 - **Datenbank:** Persistenz und die genannten Domänen-Reads/Writes laufen über die **Interface**-Schicht, nicht ad hoc aus Routen heraus.
 - **Service Center:** Aufrufe laufen über die zentrale Auflösung (`getService` + Kontext); Workflows und Routen konsumieren dieselbe Landschaft.
 - **Sicherheit & Governance:** RBAC und Geheimnisse werden zentral geführt; Service-Aufrufe und Workflow-Schritte sollen nachvollziehbar sein (Audit); Kontingente und Limits pro Mandant/Service sind vorgesehen.
-- **HTTP-Einstieg:** Globale Middleware u. a. CSRF und Token-Refresh; zusätzliche AuthN/AuthZ-Utilities unter `modules/security/`.
+- **HTTP-Einstieg:** Globale Middleware (CSRF, Token-Refresh unter `modules/auth/`); RBAC-Auswertung und Katalog unter `modules/security/`.
 - **Code-Konventionen (Projekt):** Interne Hilfsfunktionen mit Präfix **`_`**; Bezeichner in **camelCase** für Variablen und Funktionen.

b-reference/gateway/automation-data-model.md

@@ -2,7 +2,7 @@
 
 **Version:** 2.0  
 **Datum:** 2026-04-05  
-**Referenz:** [Automation Business Spec.md](./Automation%20Business%20Spec.md)
+**Referenz:** [Automation Business Spec](./automation-business-spec.md)
 
 ---
 

b-reference/gateway/automation.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Automation
 
@@ -66,7 +66,7 @@ PowerOn hat **mehrere Automatisierungs-Spuren**, die sich die **gleiche Unified
 |--------|----------------|------------------|
 | Modell | Template/Cron/Placeholders | Graph + Node-Typen (`nodeDefinitions/`) |
 | DB / Schema | `poweron_automation` | `poweron_automation2` |
-| Scheduler | Inkrementell, Callback `automation.changed`, `eventId` auf Workflow | u.a. Full re-register, Callback `automation2.workflow.changed` |
+| Scheduler | Inkrementell, Callback `automation.changed`, `eventId` auf `AutomationDefinition` | Full re-register, Callback `automation2.workflow.changed` |
 | Engine | `WorkflowManager` + `WorkflowProcessor` + `modeAutomation` | `executionEngine.executeGraph` |
 | Stärken | Bewährtes Scheduling, Execution-Logs | Branching, Loops, Pause/Resume, visuelles Editing |
 

b-reference/gateway/billing.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Billing & Subscriptions
 

b-reference/gateway/workflow.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Workflow-Engine
 
@@ -34,7 +34,11 @@ Zentrale Steuerung in `gateway/modules/workflows/workflowManager.py` (grosse Dat
 
 **Workflow-Zustände (konzeptionell):** `running`, `stopped`, `completed`, `failed`.
 
-**Modi (Dokumentation):** Klassische Beschreibung nennt u.a. **React** (iterativ, begrenzte Schritte) und **Actionplan** (Plan upfront, ein Pfad). Die erweiterte Planungsarchitektur (`ai_plan_architecture.md`) beschreibt zusätzlich **dynamischen Modus** mit zweistufiger Aktionsplanung (Stage 1: Aktionswahl + Ressourcen; optional Stage 2: Parametergenerierung).
+**Modi (Code-Stand):** `WorkflowProcessor` unterstützt zwei Modi:
+- **`WORKFLOW_DYNAMIC`** (`modeDynamic.py`) — zweistufige Aktionsplanung (Stage 1: Aktionswahl + Ressourcen; Stage 2: Parametergenerierung)
+- **`WORKFLOW_AUTOMATION`** (`modeAutomation.py`) — sequenzielle Abarbeitung für Automation v1
+
+Zusätzlich definiert `WorkflowModeEnum` den Modus **`WORKFLOW_CHATBOT`** (Chatbot-Feature).
 
 ---
 
@@ -73,13 +77,13 @@ Methoden sind Python-Klassen unter `gateway/modules/workflows/methods/`; der **M
 | Pfad (unter `gateway/modules/`) | Rolle |
 |--------------------------------|--------|
 | `workflows/workflowManager.py` | Workflow-Orchestrierung, Einstieg |
-| `workflows/processing/` | Processor, Modi (`modeReact`, `modeActionplan`, `modeDynamic`, …), `ActionExecutor` |
+| `workflows/processing/` | Processor, Modi (`modeDynamic`, `modeAutomation`), `ActionExecutor` |
 | `workflows/methods/methodBase.py` | Basis für Methoden, Aktions-Validierung |
 | `workflows/methods/method*/` | Konkrete Methoden und Aktionen |
 | `datamodels/datamodelChat.py` | `ChatWorkflow`, `TaskContext`, Task-/Plan-Modelle |
 | `datamodels/datamodelWorkflowActions.py` | Aktionsdefinitionen |
-| `services/serviceWorkflow/` | Fortschritt, Logs, Nachrichten/Dokumente am Workflow |
-| `services/serviceAi/` | Planning- und Content-KI (kein direkter Workflow-Import aus Methods zurück) |
+| `serviceCenter/services/serviceChat/` | Fortschritt, Logs, Nachrichten/Dokumente am Workflow |
+| `serviceCenter/services/serviceAi/` | Planning- und Content-KI (kein direkter Workflow-Import aus Methods zurück) |
 | `interfaces/interfaceDbChat*` | Persistenz Workflow/Nachrichten/Dokumente |
 
 ---

b-reference/platform/navigation.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Navigation API
 
@@ -8,8 +8,7 @@
 
 Die Navigation-API ist die **Single Source of Truth** für die Navigationsstruktur: Das **Gateway** entscheidet, welche Einträge ein Benutzer sieht; das **UI** rendert nur die gelieferte Struktur — **keine** parallele Berechtigungslogik im Frontend für die Navigation. Die API liefert **keine** Darstellungsassets (Icons, CSS); stattdessen **UI-Komponenten-Codes** (`uiComponent`), die im Client (z. B. `PAGE_REGISTRY`) auf Komponenten gemappt werden. Einträge ohne Berechtigung erscheinen **nicht** im Baum (kein `hasAccess: false`). Unbekannte `uiComponent`-Codes sollen im UI **sichtbar als Fehler** gemeldet werden, damit Gateway/UI-Drift auffällt.
 
-**Ziel-Endpoint (Konzept):** `GET /api/navigation` mit Antwort u. a. `language`, `blocks[]`.  
-**Ist-Stand (Audit):** Statische Navigation u. a. über `GET /api/system/navigation` mit `sections` — Migration auf kombinierten Endpoint und `blocks`-Schema ist im Konzept dokumentiert.
+**Endpoint:** `GET /api/navigation` mit Antwort u. a. `language`, `blocks[]` (implementiert in `routeSystem.py`, gemountet als `navigationRouter`).
 
 **Personalisierung:** Sortierung über numerisches `order`; User-Overrides in Settings (`navOrder`), Merge im Gateway: `EffektiveOrder = User-Override ?? Default ?? 50`. Update-Konzept: `PUT /api/user/settings/navOrder`.
 
@@ -43,11 +42,11 @@ Die Antwort besteht aus einer geordneten Liste von **Blocks**:
 Typische **static** Blöcke im Konzept:
 
 - **`system`:** mandatsübergreifende Systemseiten (z. B. Home, Einstellungen) — `page.system.*`, ObjectKeys `ui.system.*`.
-- **`workflows`:** Workflow-bezogene Systemseiten (z. B. Playground, Chat-Liste) — ebenfalls `page.system.*` / `ui.system.*` im Beispiel.
-- **`basedata`:** Stammdaten (z. B. Prompts, Dateien) — weiterhin `page.system.*` mit Pfaden unter `/basedata/...`.
+- **`billing`:** Billing-Seiten — `page.system.*`, ObjectKeys `ui.system.*`.
+- **`basedata`:** Stammdaten (z. B. Prompts, Dateien) — `page.system.*` mit Pfaden unter `/basedata/...`.
 - **`admin`:** Administration — `page.admin.*`, ObjectKeys `ui.admin.*` (Benutzer, Mandanten, …).
 
-Die exakte Liste und Default-`order` stammen aus der Gateway-Konfiguration (`NAVIGATION_SECTIONS` in `mainSystem.py` laut Analyse — Felder teilweise noch `label`/`path`/`icon`; Zielmapping: `uiLabel`/`uiPath`, ohne `icon` in der API).
+Die exakte Liste und Default-`order` stammen aus der Gateway-Konfiguration (`NAVIGATION_SECTIONS` in `mainSystem.py`); Response-Felder sind `uiLabel`/`uiPath` (kein `icon` in der API). Static Blocks können **Subgruppen** (verschachtelte `items[]`) enthalten, nicht nur flache Listen.
 
 ## Dynamic Block (Features)
 
@@ -68,11 +67,11 @@ Die exakte Liste und Default-`order` stammen aus der Gateway-Konfiguration (`NAV
 | Schicht | Pfad / Artefakt |
 |---------|------------------|
 | Statische Sektionen (Gateway) | `mainSystem.py` — `NAVIGATION_SECTIONS` |
-| Navigation-Route | `routeSystem.py` — Endpoint-Evolution `/api/system/navigation` → `/api/navigation` |
+| Navigation-Route | `routeSystem.py` — `GET /api/navigation` (`navigationRouter`) |
 | Feature-Views / Template-Rollen | z. B. `mainTrustee.py`, `mainRealEstate.py` — `UI_OBJECTS`, `TEMPLATE_ROLES` |
 | Admin-Feature-Permission (Ist teils feature-spezifisch) | `routeAdminFeatures.py` — z. B. `_deriveViewPermissions` |
 | Frontend: Navigation | `MandateNavigation.tsx`, `useNavigation` |
-| Frontend: Registry (Ziel) | `frontend_nyla/src/config/pageRegistry.ts` — `PAGE_REGISTRY`, `FEATURE_REGISTRY` |
+| Frontend: Registry | `frontend_nyla/src/config/pageRegistry.tsx` — `PAGE_REGISTRY`, `FEATURE_REGISTRY` |
 | Legacy-Duplikate (Audit) | `mandate.ts` — `FEATURE_REGISTRY` / View-Definitionen parallel zum Backend |
 
 ## Regeln / Invarianten
@@ -82,4 +81,4 @@ Die exakte Liste und Default-`order` stammen aus der Gateway-Konfiguration (`NAV
 - **Sortierung:** ausschließlich vom Gateway; das UI sortiert empfangene Listen nicht erneut.
 - **`uiComponent`-Konventionen:** `page.system.<page>`, `page.admin.<page>`, `page.feature.<feature>.<view>`, Feature-Gruppe `feature.<code>`.
 - **Drift sichtbar machen:** Unbekannte Codes im UI als Fehler anzeigen, nicht still ignorieren.
-- Vollständiges API-Konzept und Migrationsphasen: `wiki/concepts/Navigation-API-Konzept.md`.
+- Vollständiges API-Konzept und Migrationsphasen: `wiki/z-archive/concepts/Navigation-API-Konzept.md`.

b-reference/platform/neutralization.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # Neutralisierungs-System
 
@@ -22,9 +22,9 @@ Orthogonal dazu (kein Ersatz des Gates, sondern Data-at-rest bzw. Workflow):
 
 **Am AI-Gate (`_shouldNeutralize`)** (Auswertung in der dokumentierten Reihenfolge):
 
-1. **Pro Request:** `AiCallRequest.requireNeutralization` — expliziter Override auf dem Call.
+1. **Feature-Konfiguration:** `NeutralizationConfig.enabled` (DataNeutraliser / Feature-Instanz).
 2. **Chat-/Session-Level:** `ServiceCenterContext.requireNeutralization` (z. B. Workspace, Automation).
-3. **Mandanten-/Feature-Konfiguration:** `NeutralizationConfig.enabled` (DataNeutraliser / Feature-Instanz).
+3. **Pro Request:** `AiCallRequest.requireNeutralization` — expliziter Override auf dem Call.
 
 **Quellen gesamt (OR-Logik):** Ist irgendwo Neutralisierung erforderlich (Feature-Instanz, Workflow/Session, konkretes Objekt mit `FileItem.neutralize` / `DataSource.neutralize` / `FeatureDataSource.neutralize`), wird entsprechend verarbeitet. Dokumentierte Produktregel: **Kein `False` von einer Quelle hebt ein `True` einer anderen auf.**
 
@@ -78,4 +78,4 @@ Im zentralen AI-Gate (`_neutralizeRequest`):
 - **Hard-Mode:** `requireNeutralization=True` und Neutralisierung scheitert → Call blockieren bzw. Inhalt nicht im Klartext an das Modell geben.
 - **Kein stilles Weiterreichen** sensibler Inhalte bei Pflicht zur Neutralisierung.
 - **Platzhalter:** Mapping `[typ.uuid]` in der DB; `resolveText` für kontrollierte Rückübersetzung.
-- Detaillierte Compliance- und Prozessbeschreibung: `wiki/compliance/Neutralisierung.md`.
+- Detaillierte Compliance- und Prozessbeschreibung: `wiki/e-compliance/neutralisierung-detail.md`.

b-reference/platform/rbac.md

@@ -1,6 +1,6 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
-<!-- verifiedAgainst: gateway (codebase audit 2026-03-29) -->
+<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
 
 # RBAC-System
 
@@ -49,7 +49,7 @@ Felder `id` und Namen mit führendem `_` sind für Anwendungs-CUD geschützt; Co
 
 ### Frontend-Optionen für Rollen
 
-`frontend_options` an Feldern kann statische Listen oder String-Referenzen (z. B. `"user.role"`) nutzen; dynamische Optionen über `/api/options/{optionsName}`. Typ-Hilfen: `gateway/modules/shared/frontendOptionsTypes.py`.
+`frontend_options` an Feldern kann statische Listen oder String-Referenzen (z. B. `"user.role"`) nutzen; dynamische Optionen über `/api/options/{optionsName}`. Typ-Hilfen: `gateway/modules/shared/frontendTypes.py`.
 
 ## Schlüssel-Dateien
 
@@ -58,7 +58,7 @@ Felder `id` und Namen mit führendem `_` sind für Anwendungs-CUD geschützt; Co
 | RBAC-Auswertung / DB-Schicht | `gateway/modules/interfaces/interfaceRbac.py` |
 | AccessRule- und Permission-Modelle | `gateway/modules/datamodels/` (u. a. RBAC-bezogene Modelle) |
 | Nutzer / Rollenlabels | User-Modell mit `roleLabels` (Multiselect, Union) |
-| Konzept & Feldsemantik | `wiki/appdoc/doc_security_role_based_access.md` |
+| Konzept & Feldsemantik | `wiki/z-archive/appdoc/doc_security_role_based_access.md` |
 
 ## Regeln / Invarianten
 

b-reference/product.md

@@ -1,11 +1,11 @@
 <!-- status: canonical -->
 <!-- lastReviewed: 2026-04-05 -->
 
-# PowerOn Portal -- Komponentenübersicht
+# PowerOn PORTA -- Komponentenübersicht
 
 ## Produkt
 
-PowerOn Portal ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung.
+PowerOn PORTA ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung.
 
 ## Komponenten
 
@@ -14,7 +14,7 @@ PowerOn Portal ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI
 | Frontend Nyla | frontend_nyla | React/TypeScript, Vite | Zentrales UI für alle Features |
 | Gateway | gateway | FastAPI, Python, PostgreSQL | Backend REST-API, Services, AI-Core |
 | Private LLM | private-llm | Python | Internes LLM für Neutralisierung + sensitive Daten |
-| Teams Bot | service-teams-browser-bot | Node.js/.NET | Bot für Teams-Meeting-Teilnahme |
+| Teams Bot | service-teams-browser-bot | TypeScript/Node.js | Bot für Teams-Meeting-Teilnahme |
 | Wiki | wiki | Markdown | Dokumentation (dieses Repo) |
 
 ## Technologie-Stack