From 9bec16960a623c69116c818c0dbeea735c9d1649 Mon Sep 17 00:00:00 2001 From: ValueOn AG Date: Sun, 5 Apr 2026 23:45:51 +0200 Subject: [PATCH] fix: audit corrections - verify reference docs against code, fix misplacements and wrong paths Made-with: Cursor --- README.md | 6 +++--- .../market}/ai-skills-timeline-comparison.md | 0 b-reference/frontend-nyla/architecture.md | 15 ++++++------- b-reference/gateway/ai-agent.md | 2 +- b-reference/gateway/architecture.md | 21 ++++++++++--------- b-reference/gateway/automation-data-model.md | 2 +- b-reference/gateway/automation.md | 4 ++-- b-reference/gateway/billing.md | 2 +- b-reference/gateway/workflow.md | 14 ++++++++----- b-reference/platform/navigation.md | 17 +++++++-------- b-reference/platform/neutralization.md | 8 +++---- .../platform}/platform-diagrams.md | 0 b-reference/platform/rbac.md | 6 +++--- b-reference/product.md | 6 +++--- .../2026-03-codeeditor-phase1.md | 0 15 files changed, 54 insertions(+), 49 deletions(-) rename {e-compliance => a-strategy/market}/ai-skills-timeline-comparison.md (100%) rename {a-strategy => b-reference/platform}/platform-diagrams.md (100%) rename c-work/{1-plan => 4-done}/2026-03-codeeditor-phase1.md (100%) diff --git a/README.md b/README.md index 7bfcf88..944458a 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,18 @@ -# 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) | --- diff --git a/e-compliance/ai-skills-timeline-comparison.md b/a-strategy/market/ai-skills-timeline-comparison.md similarity index 100% rename from e-compliance/ai-skills-timeline-comparison.md rename to a-strategy/market/ai-skills-timeline-comparison.md diff --git a/b-reference/frontend-nyla/architecture.md b/b-reference/frontend-nyla/architecture.md index ed791ad..ed9fb93 100644 --- a/b-reference/frontend-nyla/architecture.md +++ b/b-reference/frontend-nyla/architecture.md @@ -1,6 +1,6 @@ - + # 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 `` (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) | diff --git a/b-reference/gateway/ai-agent.md b/b-reference/gateway/ai-agent.md index 9bcbb96..5d9e215 100644 --- a/b-reference/gateway/ai-agent.md +++ b/b-reference/gateway/ai-agent.md @@ -1,6 +1,6 @@ - + # AI Agent & Knowledge Store diff --git a/b-reference/gateway/architecture.md b/b-reference/gateway/architecture.md index dfb8b4b..8ce518a 100644 --- a/b-reference/gateway/architecture.md +++ b/b-reference/gateway/architecture.md @@ -1,6 +1,6 @@ - + # 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. diff --git a/b-reference/gateway/automation-data-model.md b/b-reference/gateway/automation-data-model.md index 5dd5c32..7599c1b 100644 --- a/b-reference/gateway/automation-data-model.md +++ b/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) --- diff --git a/b-reference/gateway/automation.md b/b-reference/gateway/automation.md index df03c12..fa559fe 100644 --- a/b-reference/gateway/automation.md +++ b/b-reference/gateway/automation.md @@ -1,6 +1,6 @@ - + # 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 | diff --git a/b-reference/gateway/billing.md b/b-reference/gateway/billing.md index e946f66..cceb717 100644 --- a/b-reference/gateway/billing.md +++ b/b-reference/gateway/billing.md @@ -1,6 +1,6 @@ - + # Billing & Subscriptions diff --git a/b-reference/gateway/workflow.md b/b-reference/gateway/workflow.md index 2680131..87a2be1 100644 --- a/b-reference/gateway/workflow.md +++ b/b-reference/gateway/workflow.md @@ -1,6 +1,6 @@ - + # 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 | --- diff --git a/b-reference/platform/navigation.md b/b-reference/platform/navigation.md index deef305..089fa63 100644 --- a/b-reference/platform/navigation.md +++ b/b-reference/platform/navigation.md @@ -1,6 +1,6 @@ - + # 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.admin.`, `page.feature..`, Feature-Gruppe `feature.`. - **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`. diff --git a/b-reference/platform/neutralization.md b/b-reference/platform/neutralization.md index 0af4c5d..732cdd3 100644 --- a/b-reference/platform/neutralization.md +++ b/b-reference/platform/neutralization.md @@ -1,6 +1,6 @@ - + # 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`. diff --git a/a-strategy/platform-diagrams.md b/b-reference/platform/platform-diagrams.md similarity index 100% rename from a-strategy/platform-diagrams.md rename to b-reference/platform/platform-diagrams.md diff --git a/b-reference/platform/rbac.md b/b-reference/platform/rbac.md index 30d7e22..7a50e0d 100644 --- a/b-reference/platform/rbac.md +++ b/b-reference/platform/rbac.md @@ -1,6 +1,6 @@ - + # 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 diff --git a/b-reference/product.md b/b-reference/product.md index e978913..2586e01 100644 --- a/b-reference/product.md +++ b/b-reference/product.md @@ -1,11 +1,11 @@ -# 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 diff --git a/c-work/1-plan/2026-03-codeeditor-phase1.md b/c-work/4-done/2026-03-codeeditor-phase1.md similarity index 100% rename from c-work/1-plan/2026-03-codeeditor-phase1.md rename to c-work/4-done/2026-03-codeeditor-phase1.md