integration view
This commit is contained in:
parent
1cb99f8639
commit
5de8aa0558
6 changed files with 792 additions and 142 deletions
|
|
@ -248,7 +248,7 @@ Features registrieren sich **nicht** in einer zentralen DB-Liste. Stattdessen:
|
|||
|
||||
### Admin-Sicht
|
||||
|
||||
`routeSecurityAdmin.py` bietet eine API, die alle `poweron_%`-Datenbanken aus PostgreSQL auflistet -- fuer Systemadministration und Diagnostik.
|
||||
Die Admin-DB-Listing-API (`routeSecurityAdmin.py`) wurde am 2026-04-12 entfernt. Datenbank-Diagnostik erfolgt direkt ueber PostgreSQL-Tools oder das System-Dashboard.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -267,5 +267,4 @@ Features registrieren sich **nicht** in einer zentralen DB-Liste. Stattdessen:
|
|||
| Feature-Interface (Template) | `gateway/modules/interfaces/interfaceFeatures.py` |
|
||||
| Bootstrap / DB-Seed | `gateway/modules/interfaces/interfaceBootstrap.py` |
|
||||
| DB-Migration Script | `gateway/scripts/script_db_export_migration.py` |
|
||||
| Admin DB-Listing | `gateway/modules/routes/routeSecurityAdmin.py` |
|
||||
| Datenmodelle (Pydantic) | `gateway/modules/datamodels/` |
|
||||
|
|
|
|||
83
c-work/1-plan/2026-04-automation-central-admin.md
Normal file
83
c-work/1-plan/2026-04-automation-central-admin.md
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
<!-- status: build -->
|
||||
<!-- started: 2026-04-12 -->
|
||||
<!-- component: gateway | frontend-nyla -->
|
||||
|
||||
# Automatisierung — Zentrale Administration aller Workflows
|
||||
|
||||
## Beschreibung und Kontext
|
||||
|
||||
Die Seite "Automatisierung" in "Meine Sicht" zeigt aktuell nur ein Dashboard mit Workflow-Run-Metriken und einer Runs-Tabelle. Was fehlt, ist eine zentrale Verwaltung ALLER Workflows, auf die der User gemäss RBAC Zugriff hat — über alle Mandanten und Feature-Instanzen hinweg.
|
||||
|
||||
**Business-Treiber:** Admins und Power-User brauchen eine Übersicht über alle Workflows ohne in jede einzelne graphicalEditor-Instanz navigieren zu müssen. Berechtigungen (View/Edit/Delete/Execute) sollen pro Workflow-Zeile sichtbar sein.
|
||||
|
||||
**Abhängigkeiten:**
|
||||
- `routeWorkflowDashboard.py` — bestehender System-Dashboard-Endpunkt (nur Runs)
|
||||
- `GraphicalEditorWorkflowsPage.tsx` — Referenz-Implementierung für Instanz-Workflows
|
||||
- `FormGeneratorTable` — Backend-driven Table mit Paginierung
|
||||
- `Tabs`-Komponente — existiert bereits
|
||||
|
||||
**Risiko bei Nicht-Umsetzung:** Admins müssen manuell durch jede Instanz navigieren, um Workflows zu finden/verwalten. Keine zentrale Kontrolle.
|
||||
|
||||
## Fokus und kritische Details
|
||||
|
||||
- RBAC-Scoping muss konsistent mit bestehender `_scopedRunFilter`-Logik sein
|
||||
- Dashboard-Tabelle nutzt aktuell KEINE Backend-Paginierung (nur Client-seitig) — muss korrigiert werden
|
||||
- AutoWorkflow hat `mandateId` + `featureInstanceId` — Enrichment mit Labels nötig
|
||||
- Per-Workflow RBAC-Permissions (`canEdit`, `canDelete`, `canExecute`) müssen vom Backend geliefert werden
|
||||
- `t()` konsequent für alle Sprachtexte
|
||||
|
||||
## Ziel und Nicht-Ziele
|
||||
|
||||
- Ziel: 2 Tabs auf der Automatisierung-Seite (Dashboard + Workflows), zentraler Workflow-Manager mit RBAC
|
||||
- Ziel: Dashboard-Tabelle auf saubere Backend-Paginierung via `hookData`
|
||||
- Explizit NICHT: Workflow-Editor in der zentralen Ansicht (Edit navigiert zur Instanz)
|
||||
- Explizit NICHT: Neue Workflows erstellen aus der zentralen Ansicht
|
||||
|
||||
## Betroffene Module
|
||||
|
||||
- Gateway: `routeWorkflowDashboard.py` — neuer Endpunkt `GET /api/system/workflows`
|
||||
- Frontend: `AutomationsDashboardPage.tsx` — Tabs, Backend-Paginierung, WorkflowsTab
|
||||
- DB-Migration: nein
|
||||
- Andere Komponenten: keine
|
||||
|
||||
## Entscheidungen
|
||||
|
||||
| Datum | Entscheidung | Begründung |
|
||||
|-------|-------------|------------|
|
||||
| 2026-04-12 | Neuer Endpunkt unter bestehendem Router `/api/system/workflow-runs` als `/api/system/workflow-runs/workflows` | Konsistenz mit bestehendem Prefix, kein neuer Router nötig |
|
||||
| 2026-04-12 | RBAC-Permissions pro Workflow-Row vom Backend | Frontend muss nicht selbst RBAC-Logik duplizieren |
|
||||
| 2026-04-12 | Bestehende `Tabs`-Komponente verwenden | Bereits vorhanden und getestet |
|
||||
|
||||
## Umsetzungs-Checkliste
|
||||
|
||||
- [x] API-Endpunkt: `GET /api/system/workflow-runs/workflows`
|
||||
- [ ] DB-Schema / Migration: nicht nötig
|
||||
- [x] Frontend: Tabs-Struktur in AutomationsDashboardPage
|
||||
- [x] Frontend: Dashboard-Tab mit Backend-Paginierung
|
||||
- [x] Frontend: WorkflowsTab mit zentraler Workflow-Verwaltung
|
||||
- [x] RBAC / Permissions: Scoping + per-row Permissions
|
||||
- [ ] Neutralisierung betroffen? Nein
|
||||
- [ ] Navigation / Routing: keine Änderung (bestehende Route `/automations`)
|
||||
- [ ] Billing-Impact? Nein
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium (Given-When-Then) | Prio |
|
||||
|---|---------------------------|------|
|
||||
| 1 | Given User auf /automations, When Seite lädt, Then 2 Tabs sichtbar (Dashboard, Workflows) | must |
|
||||
| 2 | Given Dashboard-Tab aktiv, When Daten laden, Then Metriken + Runs-Tabelle mit Backend-Paginierung | must |
|
||||
| 3 | Given Workflows-Tab aktiv, When Daten laden, Then alle RBAC-berechtigten Workflows mit Mandant/Instanz-Spalten | must |
|
||||
| 4 | Given Workflow mit Edit-Recht, When Zeile angezeigt, Then Edit/Delete/Rename/Execute-Aktionen sichtbar | must |
|
||||
| 5 | Given Workflow ohne Edit-Recht, When Zeile angezeigt, Then nur View-Icon, keine Mutationsaktionen | must |
|
||||
| 6 | Given Filter "Aktiv" gewählt, When Tabelle aktualisiert, Then nur aktive Workflows | should |
|
||||
|
||||
## Links
|
||||
|
||||
- PR: ...
|
||||
- Issue: ...
|
||||
|
||||
## Abschluss
|
||||
|
||||
- [ ] b-reference/ aktualisiert (welche Seite?)
|
||||
- [ ] TOPICS.md aktualisiert (falls neues Thema)
|
||||
- [ ] Dieses Dokument → z-archive/ verschoben
|
||||
542
c-work/1-plan/2026-04-investor-demo-tuesday.md
Normal file
542
c-work/1-plan/2026-04-investor-demo-tuesday.md
Normal file
|
|
@ -0,0 +1,542 @@
|
|||
<!-- status: plan -->
|
||||
<!-- started: 2026-04-12 -->
|
||||
<!-- component: gateway | frontend-nyla | platform -->
|
||||
|
||||
# Investor-Demo Dienstag — Live Product Demo (20 Min)
|
||||
|
||||
## Beschreibung und Kontext
|
||||
|
||||
**Was:** 20-Minuten Live-Demo von PowerON PORTA für Investoren und Treuhänder am Dienstag.
|
||||
**Wer präsentiert:** Kollegen präsentieren Keynotes (Use Cases), Patrick (CTO/CEO) zeigt die Plattform live.
|
||||
**Publikum:** Investoren (ROI, Skalierbarkeit, Marktdifferenzierung) + Treuhänder (Praxisnutzen, Datenschutz, Zeitersparnis).
|
||||
|
||||
**Business-Treiber:** Die Demo muss in 20 Min zeigen, dass PowerON kein Konzept ist, sondern ein funktionierendes Produkt mit echtem Kundennutzen. Investoren wollen Traktion sehen, Treuhänder wollen sich wiedererkennen.
|
||||
|
||||
**Abhängigkeiten:**
|
||||
- Trustee-Tooling-Plan: `c-work/1-plan/2026-04-customer-trustee-tooling-and-demo-prep.md` (Phase 1–3 erledigt ✅)
|
||||
- Customer Demo Enablement: `c-work/1-plan/2026-04-customer-demo-enablement.md` (Analyse vorhanden)
|
||||
- UI-Enhancements: `c-work/1-plan/2026-04-porta-ui-enhancements-team-meeting.md`
|
||||
|
||||
**Risiko bei Nicht-Umsetzung:** Demo scheitert live, Investoren sehen nur Slides statt funktionierendes Produkt. Vertrauensverlust.
|
||||
|
||||
---
|
||||
|
||||
## Fokus und kritische Details
|
||||
|
||||
### Was die Audienz überzeugt (Schritt 1 — gemeinsam klären)
|
||||
|
||||
**Investoren wollen sehen:**
|
||||
1. **Funktionierendes Produkt** — kein Mockup, echte Datenverarbeitung
|
||||
2. **Marktdifferenzierung** — warum nicht ChatGPT/Copilot/Langdock?
|
||||
3. **Wiederholbarkeit** — keine Einmal-Demo, sondern konfigurierbare Workflows
|
||||
4. **Skalierbarkeit** — Multi-Tenant, Multi-LLM, Usage-Based
|
||||
5. **Internationalisierung** — neue Sprache in 5 Min, AI-übersetzt, kein Redeploy
|
||||
|
||||
**Treuhänder wollen sehen:**
|
||||
1. **Zeitersparnis** — vorher 5–15 Min/Beleg → nachher Sekunden
|
||||
2. **Datenschutz** — keine Kundendaten an OpenAI/Google
|
||||
3. **Integration** — Abacus/Bexio/SharePoint ohne Systemwechsel
|
||||
4. **Kontrolle** — Audit-Trail, Nachvollziehbarkeit
|
||||
|
||||
### Drei Live Use Cases (aus Keynote-Deck)
|
||||
|
||||
| # | Use Case | Dauer | Wow-Effekt | Technische Basis |
|
||||
|---|----------|-------|------------|------------------|
|
||||
| UC1 | **Treuhand: Automatisierte Spesenverarbeitung** | 6 Min | Beleg → OCR → Kontierung → Export in Sekunden | Trustee-Feature, Graph-Editor Workflow, SharePoint-Nodes |
|
||||
| UC2 | **Immobilien: Automatisierte Machbarkeitsstudie** | 4 Min | Grundstück eingeben → 6 Min statt 4 Std. Recherche | RealEstate-Feature, Agent + webSearch + readUrl |
|
||||
| UC3 | **Enterprise: AI Knowledge Chatbot** | 4 Min | Frage stellen → sofortige Antwort mit Quellenangabe | Chatbot-Feature, RAG, Neutralisierung |
|
||||
| UC4 | **Sprach-Deployment: Neue Sprache in 5 Minuten** | 3 Min | Sprache anlegen → AI übersetzt → UI sofort mehrsprachig | i18n-System, AI-Batch-Translation, Admin-UI |
|
||||
| UC5 | **Integrationen: Architektur-Visualisierung** | 1 Min | Komplette Integrationslandschaft auf einen Blick | Neue Systemseite, Custom React-Komponente |
|
||||
| — | **Neutralisierung (Querschnitt)** | 3 Min | PII live entfernen + Re-Personalisierung | Neutralisierung-Feature, Private LLM |
|
||||
|
||||
### Kritische Stellen
|
||||
|
||||
- **Graph-Editor Performance:** Workflow muss flüssig laufen (keine 15s-Wartezeiten)
|
||||
- **Neutralisierung live zeigen:** Muss am AI-Gate greifen, nicht nur im Playground
|
||||
- **Stabile Testdaten:** Jeder Demo-Lauf muss identische Ergebnisse liefern
|
||||
- **Internet-Abhängigkeit:** UC2 (webSearch) braucht stabiles Internet — Fallback vorbereiten
|
||||
- **LLM-Latenz:** Multi-LLM-Routing muss schnell sein — bevorzugt Azure OpenAI (geringste Latenz)
|
||||
|
||||
---
|
||||
|
||||
## Ziel und Nicht-Ziele
|
||||
|
||||
**Ziel:**
|
||||
- Drei Use Cases end-to-end live lauffähig auf einer Demo-Instanz
|
||||
- Bootstrap-Modul `demo` das den kompletten Demo-Zustand idempotent aufbaut
|
||||
- Detailliertes Drehbuch mit Timing, Talking Points und Fallbacks
|
||||
- Automatisiertes Testdrehbuch (pytest) das die Demo-Schritte verifiziert
|
||||
- Alles auf INT-Umgebung deployt und getestet bis Montag Abend
|
||||
|
||||
**Explizit NICHT:**
|
||||
- Keine neuen Features bauen (nutzen was da ist)
|
||||
- Kein neues Frontend (UI-Enhancements separat)
|
||||
- Keine neuen Connector-Implementierungen
|
||||
- Keine Änderung am Billing für die Demo
|
||||
|
||||
---
|
||||
|
||||
## Betroffene Module
|
||||
|
||||
- **Gateway:** `modules/bootstrap/bootstrapDemo.py` (neu), `modules/system/mainSystem.py` (Nav-Eintrag), `features/trustee/`, `features/realestate/`, `features/chatbot/`, `features/neutralization/`, `features/workspace/`, `features/graphicalEditor/`
|
||||
- **Frontend:** `pages/system/IntegrationsOverviewPage.tsx` (neu), `config/pageRegistry.tsx` (Eintrag)
|
||||
- **DB-Migration:** nein (nur Daten-Seeding)
|
||||
- **Andere Komponenten:** Testdaten (PDF, Excel, CSV), Demo-Skript (Markdown), Test-Suite (pytest)
|
||||
|
||||
---
|
||||
|
||||
## Entscheidungen
|
||||
|
||||
| Datum | Entscheidung | Begründung |
|
||||
|-------|-------------|------------|
|
||||
| 2026-04-12 | Bootstrap-Modul statt manuellem Setup | Idempotent, reproduzierbar, jeder kann die Demo aufsetzen |
|
||||
| 2026-04-12 | UC2 (Immobilien) als Agent-Demo statt RealEstate-Feature voll nutzen | RealEstate-Feature ist noch Shell; Agent + webSearch zeigt dieselbe Story |
|
||||
| 2026-04-12 | Neutralisierung als Querschnitt in UC1 + UC3 einbauen, nicht als eigenen Block | Natürlicher Flow, keine "Feature-Parade" |
|
||||
| 2026-04-12 | Testdrehbuch als pytest-Suite unter `gateway/tests/demo/` | Automatisch prüfbar, CI-fähig, reproduzierbar |
|
||||
| 2026-04-12 | Fallback-Screenshots für UC2 (Internet-abhängig) | Demo darf nicht an WLAN scheitern |
|
||||
|
||||
---
|
||||
|
||||
## Umsetzungs-Checkliste
|
||||
|
||||
### Phase 0: Klärung — Was zeigen wir? (So Abend / Mo Morgen)
|
||||
|
||||
- [ ] **Use-Case-Auswahl bestätigen** mit Kollegen (Keynote-Alignment)
|
||||
- UC1: Treuhand Spesenverarbeitung → zeigt Plug&Play + Workflow
|
||||
- UC2: Immobilien Machbarkeitsstudie → zeigt AI-Agent-Power + Zeitersparnis
|
||||
- UC3: Knowledge Chatbot → zeigt RAG + Enterprise-Readiness
|
||||
- UC4: Sprach-Deployment → zeigt Skalierbarkeit + Enterprise-Readiness (neue Sprache in 5 Min)
|
||||
- UC5: Integrationen → zeigt Plug&Play-Architektur visuell (Datenquellen → PORTA → Services)
|
||||
- Querschnitt: Neutralisierung → zeigt Privacy-First
|
||||
- [ ] **Demo-Storyline abstimmen:** Reihenfolge, Übergänge, wer was sagt
|
||||
- [ ] **Fallback-Strategie:** Was wenn ein UC live hängt? (→ vorbereitete Screenshots/Video)
|
||||
|
||||
### Phase 1: Bootstrap-Modul `demo` (Mo Vormittag)
|
||||
|
||||
- [ ] **`gateway/modules/bootstrap/bootstrapDemo.py`** erstellen
|
||||
- Funktion `bootstrapDemoEnvironment(db)` — idempotent, aufgerufen via CLI-Flag oder API
|
||||
- Erstellt Demo-Mandant "PowerON Demo" mit allen nötigen Feature-Instanzen
|
||||
- Seeded Demo-User: `demo@poweron.ch` (Admin), `treuhänder@demo.ch` (Rolle: Mandant)
|
||||
- Aktiviert Features: workspace, trustee, realestate, chatbot, neutralization, graphicalEditor
|
||||
- Lädt Demo-Testdaten (PDFs, Excel) in den Workspace
|
||||
- Konfiguriert Neutralisierung (enabled=true, Demo-Mappings)
|
||||
- Erstellt Graph-Editor Demo-Workflows aus System-Templates
|
||||
- Setzt Demo-Billing (Trial-Modus mit genügend Credits)
|
||||
|
||||
- [ ] **CLI-Einstiegspunkt** in `app.py` oder separates Script `scripts/bootstrapDemo.py`
|
||||
```
|
||||
python -m scripts.bootstrapDemo --env int --reset
|
||||
```
|
||||
- `--reset` löscht bestehenden Demo-Mandant und baut neu auf
|
||||
- `--env` wählt Zielumgebung (local, int)
|
||||
|
||||
- [ ] **Demo-Testdaten vorbereiten** (Ordner `gateway/demoData/`)
|
||||
- `invoices/` — 3 Muster-Rechnungen (PDF): Handwerker, Büromaterial, Versicherung
|
||||
- `expenses/` — 2 Spesenbelege (PDF): Reisekosten, Bewirtung
|
||||
- `tenant-dossier.pdf` — Fiktives Mieterdossier (Name, Adresse, Mietzins) für Neutralisierung
|
||||
- `knowledge-base/` — 3-4 Firmen-Dokumente (Handbuch, FAQ, Prozessbeschreibung) für RAG
|
||||
- `budget-2026.xlsx` — Budget-Soll-Werte für Trustee-Vergleich
|
||||
|
||||
### Phase 2: Demo-Konfiguration pro Use Case (Mo Nachmittag)
|
||||
|
||||
#### UC1: Treuhand — Spesenverarbeitung
|
||||
|
||||
- [ ] **Trustee-Instanz konfigurieren** (Connector: Bexio-Sandbox oder Mock)
|
||||
- [ ] **Graph-Editor Workflow erstellen/aktivieren:**
|
||||
Trigger (manual) → SharePoint listFiles → Loop → downloadFile → extractFromFiles → processDocuments → syncToAccounting
|
||||
(System-Template "Treuhand: PDF-Klassifizierung & Trustee-Import" als Basis nutzen)
|
||||
- [ ] **SharePoint-Demo-Ordner** mit 3 Musterbelegen befüllen (oder lokaler Upload-Pfad)
|
||||
- [ ] **Demo-Prompt** vorbereiten: "Verarbeite die Belege im Eingangsordner und erstelle die Buchungen"
|
||||
- [ ] **Erwartetes Ergebnis dokumentieren:** Beleg → extrahierte Positionen → MWST-Code → Kontierung
|
||||
|
||||
#### UC2: Immobilien — Machbarkeitsstudie
|
||||
|
||||
- [ ] **Workspace-Instanz** mit RealEstate-Kontext konfigurieren
|
||||
- [ ] **Demo-Prompt** vorbereiten: "Erstelle eine Machbarkeitsstudie für das Grundstück an der Musterstrasse 42, 8001 Zürich. Analysiere Zonierung, Baurecht und Nutzungspotential."
|
||||
- [ ] **Agent-Tools sicherstellen:** `webSearch`, `readUrl`, `createChart` verfügbar
|
||||
- [ ] **Fallback:** Vorbereitete Ergebnis-Screenshots falls Internet ausfällt
|
||||
- [ ] **Erwartetes Ergebnis dokumentieren:** Automatische Datensammlung → BZO-Analyse → Zusammenfassung
|
||||
|
||||
#### UC3: Enterprise — Knowledge Chatbot
|
||||
|
||||
- [ ] **Chatbot-Instanz konfigurieren** mit Demo-Datenbank (oder Workspace-RAG)
|
||||
- [ ] **Knowledge-Base befüllen:** 3-4 Dokumente hochladen + RAG-Index aufbauen
|
||||
- [ ] **Demo-Fragen vorbereiten:**
|
||||
- "Wie ist unser Reklamationsprozess?" (→ Antwort mit Quellenangabe)
|
||||
- "Welche Fristen gelten für Nebenkostenabrechnungen?" (→ zeigt domänenspezifisches Wissen)
|
||||
- "Erstelle eine Zusammenfassung der Q1-Ergebnisse" (→ zeigt Analyse-Fähigkeit)
|
||||
- [ ] **Neutralisierung aktivieren** und in einer Frage live demonstrieren
|
||||
- [ ] **Erwartetes Ergebnis dokumentieren:** Frage → Antwort mit Quellenangabe + Audit-Trail
|
||||
|
||||
#### UC5: Integrationen — Architektur-Visualisierung (neue Seite)
|
||||
|
||||
- [ ] **Neue Systemseite `page.system.integrations`** erstellen
|
||||
- Route: `/integrations` (unter "Meine Sicht" / System-Block)
|
||||
- Navigation-Eintrag in `mainSystem.py` → `NAVIGATION_SECTIONS`
|
||||
- Page-Registry-Eintrag in `pageRegistry.tsx` → Icon: `FaProjectDiagram` oder `FaCubes`
|
||||
|
||||
- [ ] **React-Komponente `IntegrationsOverviewPage.tsx`** bauen
|
||||
- **3-Schichten-Layout (vertikal, von unten nach oben):**
|
||||
- **Schicht 1 (unten): Datenquellen**
|
||||
- Box pro OAuth-Connection (Microsoft-Icon, Google-Icon) → persönliche Daten
|
||||
- Box pro System-Connector (Abacus-Instanz, Bexio-Instanz, RMA, SharePoint, etc.)
|
||||
- Daten kommen von `GET /api/connections` + Feature-Instanz-Configs
|
||||
- **Schicht 2 (Mitte): PORTA (PowerON)**
|
||||
- Zentrale Box mit PowerON-Logo
|
||||
- Darin: Sub-Boxes für jeden aktiven Workflow (System-Templates + Custom-Workflows)
|
||||
- Daten kommen von `GET /api/workflows` (Graph-Editor Workflows)
|
||||
- **Schicht 3 (oben): Services / Mandanten**
|
||||
- Box pro Mandant mit den aktivierten Features/Services darin
|
||||
- Daten kommen von Navigation-API (`GET /api/navigation` → dynamic block)
|
||||
- **Verbindungslinien** zwischen den Schichten (CSS/SVG, kein Canvas)
|
||||
- **Rendering-Technologie:** Custom React mit CSS Grid + `framer-motion` Animationen
|
||||
- Kein Mermaid (zu statisch, schwer zu stylen)
|
||||
- Kein xyflow (Overkill, neue Dependency)
|
||||
- Bestehende Libs nutzen: `react-icons` (Connector-Icons), `framer-motion` (Hover/Enter-Animationen)
|
||||
|
||||
- [ ] **API-Endpoint `GET /api/system/integrations-overview`** (optional)
|
||||
- Aggregiert: Connections, Feature-Instanzen, Workflows, Mandanten
|
||||
- Oder: Frontend aggregiert aus bestehenden APIs (einfacher, weniger Backend-Aufwand)
|
||||
|
||||
- [ ] **Demo-Daten sicherstellen:** Mindestens 2 Connections (Microsoft, Google), 2 System-Connectors (Abacus, Bexio), 3 Workflows, 2 Mandanten mit Features
|
||||
|
||||
#### UC4: Sprach-Deployment — Neue Sprache in 5 Minuten
|
||||
|
||||
- [ ] **Sicherstellen:** i18n Admin-UI erreichbar unter `/admin/languages`
|
||||
- [ ] **Bestehende Sprachen prüfen:** DE, EN, FR vorhanden und vollständig
|
||||
- [ ] **Demo-Sprache vorbereiten:** Italienisch (it) NICHT vorinstalliert lassen — wird live angelegt
|
||||
- [ ] **AI-Übersetzungs-Pipeline testen:** `POST /api/i18n/sets` mit `code: "it"` → async Translation → Ergebnis in <5 Min
|
||||
- [ ] **Sprachwechsel im UI testen:** Nach Anlage → Sprachselektor zeigt "it" → UI komplett auf Italienisch
|
||||
- [ ] **Fallback:** Falls AI-Translation zu lang dauert → Sprache vorher anlegen, live nur den Wechsel zeigen
|
||||
- [ ] **Billing sicherstellen:** Demo-Mandant hat genügend Credits für AI-Batch-Translation
|
||||
|
||||
#### Querschnitt: Neutralisierung
|
||||
|
||||
- [ ] **Demo-Flow vorbereiten:**
|
||||
1. Fiktives Mieterdossier (PDF) im Workspace öffnen
|
||||
2. Neutralisierung aktivieren → PII wird zu Platzhaltern
|
||||
3. AI-Analyse auf neutralisierten Daten ausführen
|
||||
4. Re-Personalisierung zeigen (Platzhalter → Originaldaten)
|
||||
- [ ] **NeutralizationPanel** im Frontend vorbereiten (Mappings sichtbar)
|
||||
|
||||
### Phase 3: Drehbuch der Demo (Mo Nachmittag)
|
||||
|
||||
- [ ] **Detailliertes Drehbuch erstellen** (siehe unten, Abschnitt "Demo-Drehbuch")
|
||||
- [ ] **Talking Points** für jede Szene (was sagen, was zeigen, was klicken)
|
||||
- [ ] **Timing-Markers** (Minute 0-20) mit Puffer
|
||||
|
||||
### Phase 4: Testdrehbuch — automatisiertes Testing (Mo Abend)
|
||||
|
||||
- [ ] **Test-Suite `gateway/tests/demo/`** erstellen
|
||||
- [ ] **`conftest.py`** mit Demo-Fixtures (Mandant, User, Feature-Instanzen)
|
||||
- [ ] **`test_demo_uc1_trustee.py`** — Trustee-Pipeline end-to-end
|
||||
- [ ] **`test_demo_uc2_realestate.py`** — Agent-basierte Machbarkeitsstudie
|
||||
- [ ] **`test_demo_uc3_chatbot.py`** — Knowledge-Chatbot mit RAG
|
||||
- [ ] **`test_demo_uc4_i18n.py`** — Sprach-Deployment + AI-Translation + UI-Wechsel
|
||||
- [ ] **`test_demo_neutralization.py`** — Neutralisierung roundtrip
|
||||
- [ ] **`test_demo_bootstrap.py`** — Bootstrap idempotent + Demo-Zustand korrekt
|
||||
- [ ] **Alle Tests grün** auf INT-Umgebung
|
||||
|
||||
### Phase 5: Generalprobe (Di Vormittag)
|
||||
|
||||
- [ ] **Komplette Demo 1x durchspielen** auf INT mit echtem Browser
|
||||
- [ ] **Timing messen** — muss in 20 Min passen (Ziel: 18 Min mit Puffer)
|
||||
- [ ] **Edge Cases testen:** Was wenn LLM langsam? Was wenn SharePoint-Timeout?
|
||||
- [ ] **Backup-Plan:** Browser-Tab mit vorbereiteten Ergebnissen für jeden UC
|
||||
|
||||
---
|
||||
|
||||
## Demo-Drehbuch (20 Minuten)
|
||||
|
||||
### Szene 0: Setup (vor der Demo, nicht sichtbar)
|
||||
|
||||
- Browser auf: PORTA Dashboard (Demo-Mandant eingeloggt als `demo@poweron.ch`)
|
||||
- Tabs vorbereitet: Dashboard, Workspace, Graph-Editor, Trustee, Chatbot
|
||||
- SharePoint-Demo-Ordner mit Belegen befüllt
|
||||
- Neutralisierung aktiviert
|
||||
- Knowledge-Base indexiert
|
||||
|
||||
### Szene 1: Intro & Integrationslandschaft (0:00 – 3:00)
|
||||
|
||||
**Was zeigen:** PORTA Dashboard → Integrationsseite — die Architektur auf einen Blick
|
||||
**Talking Points:**
|
||||
- "Das ist PORTA — unsere AI Execution Layer. Ein Login, alle AI-Workflows."
|
||||
- "Jeder Mandant hat seine eigenen Features, Daten, Berechtigungen — komplett getrennt."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Dashboard → Mandanten-Übersicht
|
||||
2. Feature-Store → aktivierte Features zeigen (Treuhand, Chatbot, Neutralisierung)
|
||||
3. **Integrationen öffnen** → "Hier sehen Sie die komplette Architektur auf einen Blick."
|
||||
4. **Schicht für Schicht erklären:**
|
||||
- Unten: "Das sind die Datenquellen — Microsoft, Google, Abacus, Bexio. Die stecken wir an wie Stecker."
|
||||
- Mitte: "Hier laufen die Workflows — visuell gebaut, AI-gesteuert. System-Templates und individuelle."
|
||||
- Oben: "Die Services pro Mandant — jeder bekommt nur, was er braucht."
|
||||
5. "50+ Konnektoren, keine Seat-Lizenzen, Bezahlung pro Workflow-Ausführung."
|
||||
6. → Überleitung: "Schauen wir uns an, wie das konkret funktioniert."
|
||||
|
||||
### Szene 2: UC1 — Treuhand Spesenverarbeitung (3:00 – 9:00)
|
||||
|
||||
**Was zeigen:** Beleg → OCR → KI-Kontierung → Export — in Sekunden statt Minuten
|
||||
**Talking Points:**
|
||||
- "Treuhänder verbringen 5-15 Min pro Beleg mit manueller Erfassung."
|
||||
- "PowerON automatisiert das: Beleg hochladen oder aus SharePoint holen, KI extrahiert und kontiert."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Graph-Editor öffnen → Demo-Workflow "Treuhand: Belegverarbeitung" zeigen
|
||||
2. "Das ist ein visueller Workflow — kein Code nötig. SharePoint → Loop → Extraktion → Kontierung."
|
||||
3. Workflow manuell starten → Live-Ausführung zeigen
|
||||
4. Trustee-Bereich öffnen → extrahierte Positionen zeigen (Beleg, MWST, Konto)
|
||||
5. "Das lief gerade in Sekunden. Vorher: 15 Minuten pro Beleg. Das ist 98% Zeiteinsparung."
|
||||
6. Audit-Trail zeigen: "Jeder Schritt ist nachvollziehbar — für Revision und Compliance."
|
||||
|
||||
**Transition:** "Und das Beste: Die Kundendaten verlassen nie die Schweiz. Schauen wir uns das an."
|
||||
|
||||
### Szene 3: Neutralisierung live (9:00 – 12:00)
|
||||
|
||||
**Was zeigen:** PII-Schutz in Echtzeit — Daten werden vor dem LLM-Call anonymisiert
|
||||
**Talking Points:**
|
||||
- "Treuhänder, Anwälte, Gesundheitssektor — die können keine Kundendaten an OpenAI senden."
|
||||
- "PowerON löst das architektonisch: PII wird entfernt, BEVOR Daten zum Modell gehen."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Workspace öffnen → Mieterdossier (PDF) hochladen
|
||||
2. Neutralisierungs-Panel zeigen: "Hier sehen Sie die Mappings — jeder Name, jede Adresse wird durch Platzhalter ersetzt."
|
||||
3. AI-Analyse starten: "Analysiere das Mieterdossier und erstelle eine Risikobewertung"
|
||||
4. Ergebnis zeigen: Analyse ist inhaltlich korrekt, aber keine echten Namen im LLM-Call
|
||||
5. Re-Personalisierung: "Im Ergebnis stehen wieder die echten Namen — der Platzhalter-Roundtrip ist transparent."
|
||||
6. "Das ist keine opt-in Checkbox. Das ist Architektur. PII kann physisch nicht zum Modell-Anbieter gelangen."
|
||||
|
||||
**Transition:** "Jetzt zeigen wir, wie die KI auch ausserhalb der Treuhand arbeitet."
|
||||
|
||||
### Szene 4: UC2 — Immobilien Machbarkeitsstudie (12:00 – 15:00)
|
||||
|
||||
**Was zeigen:** Grundstück → automatische Recherche → Analyse in Minuten statt Stunden
|
||||
**Talking Points:**
|
||||
- "Immobilienfirmen recherchieren 2-4 Stunden pro Grundstück. Manuell, über verschiedene Quellen."
|
||||
- "PowerON automatisiert die Recherche und erstellt eine Machbarkeitsstudie."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Workspace öffnen → Prompt eingeben: "Erstelle eine Machbarkeitsstudie für Musterstrasse 42, 8001 Zürich"
|
||||
2. Agent arbeitet live: "Der Agent sucht jetzt automatisch in öffentlichen Quellen — swisstopo, Zonenpläne, ÖREB."
|
||||
3. Ergebnis zeigen: Zusammenfassung mit Zonierung, Baurecht, Nutzungspotential
|
||||
4. Chart zeigen (falls generiert): Flächenaufteilung, Nutzungsmix
|
||||
5. "6 Minuten statt 4 Stunden. 92% Zeiteinsparung. Und das funktioniert für jedes Grundstück in der Schweiz."
|
||||
|
||||
**Transition:** "Letztes Beispiel — wie die KI als Firmen-Wissensbasis funktioniert."
|
||||
|
||||
### Szene 5: UC3 — Knowledge Chatbot (15:00 – 17:00)
|
||||
|
||||
**Was zeigen:** Firmenwissen sofort abrufbar — mit Quellenangabe
|
||||
**Talking Points:**
|
||||
- "Informationssilos sind der Produktivitätskiller Nr. 1. ERP, CRM, SharePoint — Daten überall."
|
||||
- "PowerON gibt ein einheitliches Interface auf alle Datenquellen."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Chatbot öffnen → "Wie ist unser Reklamationsprozess?"
|
||||
2. Antwort zeigen: Strukturiert, mit Quellenangabe (Dokument + Seite)
|
||||
3. Follow-up: "Welche Fristen gelten für Nebenkostenabrechnungen?"
|
||||
4. Antwort mit Rechtsgrundlage zeigen
|
||||
5. "Sofortige Antworten statt 10 Minuten Suche. Rollenbasierter Zugriff — jeder sieht nur, was er sehen darf."
|
||||
|
||||
### Szene 6: UC4 — Sprach-Deployment live (17:00 – 20:00)
|
||||
|
||||
**Was zeigen:** Neue Sprache in Minuten — AI übersetzt das komplette UI automatisch
|
||||
**Talking Points:**
|
||||
- "Europäische Kunden brauchen Mehrsprachigkeit. Deutsch, Französisch, Englisch — und morgen vielleicht Italienisch oder Portugiesisch."
|
||||
- "Bei PowerON legen Sie eine neue Sprache an, die AI übersetzt alle UI-Texte, und in 5 Minuten ist das System komplett in der neuen Sprache verfügbar. Ohne Code-Änderung, ohne Redeploy."
|
||||
- "Das ist kein Google Translate. Die AI versteht den Kontext — 'Offen' als Status vs. 'Offen' als Zustand wird korrekt übersetzt."
|
||||
|
||||
**Klick-Sequenz:**
|
||||
1. Administration → System → UI-Sprachen öffnen → bestehende Sprachen zeigen (DE, EN, FR)
|
||||
2. "Neue Sprache anlegen" klicken → z.B. **Italienisch** (it) wählen
|
||||
3. AI-Übersetzung startet → Fortschritt zeigen (Batch-Pipeline)
|
||||
4. Sprache wechseln → komplettes UI ist sofort auf Italienisch
|
||||
5. "Das hat gerade 5 Minuten gedauert. Für eine komplette Enterprise-Plattform. Kein Entwickler nötig."
|
||||
6. Optional: "Update All" zeigen — scannt die Codebase, synchronisiert neue Keys, übersetzt automatisch
|
||||
|
||||
**Transition:** "Das war PowerON PORTA — zurück zu den Zahlen."
|
||||
|
||||
### Szene 7: Closing (im Keynote-Deck, nicht in PORTA)
|
||||
|
||||
- Zurück zu den Keynote-Slides: Pricing, Roadmap, Next Steps
|
||||
- CTA für Investoren / Treuhänder
|
||||
|
||||
---
|
||||
|
||||
## Testdrehbuch (automatisiert)
|
||||
|
||||
### Architektur
|
||||
|
||||
```
|
||||
gateway/tests/demo/
|
||||
├── conftest.py # Demo-Fixtures, DB-Setup
|
||||
├── test_demo_bootstrap.py # Bootstrap idempotent, Demo-Zustand korrekt
|
||||
├── test_demo_uc1_trustee.py # UC1: Beleg → Extraktion → Kontierung
|
||||
├── test_demo_uc2_realestate.py # UC2: Agent → Web-Recherche → Analyse
|
||||
├── test_demo_uc3_chatbot.py # UC3: Frage → RAG → Antwort + Quelle
|
||||
├── test_demo_uc4_i18n.py # UC4: Sprache anlegen → AI-Translation → UI-Wechsel
|
||||
├── test_demo_neutralization.py # Neutralisierung: PII → Platzhalter → Roundtrip
|
||||
└── README.md # Ausführungshinweise
|
||||
```
|
||||
|
||||
### Test-Szenarien (Given-When-Then)
|
||||
|
||||
#### T-BOOT: Bootstrap
|
||||
|
||||
```
|
||||
Given keine Demo-Daten in der DB
|
||||
When bootstrapDemoEnvironment(db) ausgeführt wird
|
||||
Then Demo-Mandant existiert mit allen Feature-Instanzen
|
||||
AND Demo-User existiert mit korrekten Rollen
|
||||
AND Demo-Testdaten sind im Workspace geladen
|
||||
AND Neutralisierung ist aktiviert
|
||||
AND Graph-Editor hat Demo-Workflows
|
||||
|
||||
Given Demo-Daten bereits vorhanden
|
||||
When bootstrapDemoEnvironment(db) erneut ausgeführt wird
|
||||
Then kein Fehler (idempotent)
|
||||
AND Zustand ist identisch
|
||||
```
|
||||
|
||||
#### T-UC1: Treuhand Spesenverarbeitung
|
||||
|
||||
```
|
||||
Given Demo-Mandant mit Trustee-Instanz und 3 Musterbelegen im Workspace
|
||||
When Graph-Editor Workflow "Treuhand: Belegverarbeitung" gestartet wird
|
||||
Then alle 3 Belege werden extrahiert
|
||||
AND jeder Beleg hat mindestens 1 extrahierte Position
|
||||
AND jede Position hat: Betrag, MWST-Satz, Konto-Vorschlag
|
||||
AND Workflow-Status = completed
|
||||
AND Audit-Trail enthält alle Schritte
|
||||
|
||||
Given extrahierte Positionen vorhanden
|
||||
When syncToAccounting aufgerufen wird
|
||||
Then Positionen werden an Connector übergeben (Mock: Bexio-Sandbox)
|
||||
AND Sync-Status = "synced" für alle Positionen
|
||||
```
|
||||
|
||||
#### T-UC2: Immobilien Machbarkeitsstudie
|
||||
|
||||
```
|
||||
Given Demo-Mandant mit Workspace-Instanz
|
||||
When Agent-Prompt "Erstelle Machbarkeitsstudie für Musterstrasse 42, 8001 Zürich" ausgeführt wird
|
||||
Then Agent nutzt webSearch und/oder readUrl Tools
|
||||
AND Ergebnis enthält: Zonierung, Baurecht-Infos, Flächenanalyse
|
||||
AND Ergebnis ist strukturiert (Abschnitte, ggf. Chart)
|
||||
AND Antwortzeit < 120 Sekunden
|
||||
```
|
||||
|
||||
#### T-UC3: Knowledge Chatbot
|
||||
|
||||
```
|
||||
Given Demo-Mandant mit Chatbot-Instanz und indexierter Knowledge-Base (3+ Dokumente)
|
||||
When Frage "Wie ist unser Reklamationsprozess?" gestellt wird
|
||||
Then Antwort referenziert mindestens 1 Quell-Dokument
|
||||
AND Antwort ist inhaltlich korrekt (enthält Prozessschritte)
|
||||
AND Antwortzeit < 15 Sekunden
|
||||
|
||||
Given Chatbot mit RAG-Index
|
||||
When Frage zu Thema ausserhalb der Knowledge-Base gestellt wird
|
||||
Then Antwort zeigt an, dass keine relevante Quelle gefunden wurde (kein Halluzinieren)
|
||||
```
|
||||
|
||||
#### T-UC4: Sprach-Deployment
|
||||
|
||||
```
|
||||
Given Demo-Mandant mit i18n Admin-Zugriff und bestehenden Sprachen DE, EN, FR
|
||||
AND Sprache "it" (Italienisch) existiert NICHT
|
||||
When POST /api/i18n/sets mit code "it" ausgeführt wird
|
||||
Then AI-Batch-Translation startet
|
||||
AND nach Abschluss enthält das it-Set alle Keys aus dem de-Master-Set
|
||||
AND Übersetzungen sind kontextuell korrekt (Stichprobe: "Speichern" → "Salva", "Abbrechen" → "Annulla")
|
||||
AND Gesamtdauer < 5 Minuten
|
||||
|
||||
Given Sprache "it" vollständig übersetzt
|
||||
When User die Sprache im UI auf "it" wechselt
|
||||
Then alle UI-Elemente zeigen italienische Texte
|
||||
AND kein Fallback auf deutsche Keys sichtbar (ausser bei fehlenden Übersetzungen)
|
||||
```
|
||||
|
||||
#### T-NEU: Neutralisierung
|
||||
|
||||
```
|
||||
Given Demo-Mandant mit aktivierter Neutralisierung
|
||||
AND Mieterdossier-PDF mit PII (Name: "Hans Muster", Adresse: "Bahnhofstrasse 1")
|
||||
When PDF hochgeladen und Neutralisierung ausgeführt wird
|
||||
Then neutralisierter Text enthält Platzhalter statt "Hans Muster"
|
||||
AND Mapping-Tabelle enthält Zuordnung Platzhalter → Original
|
||||
AND resolveText() stellt Originaldaten korrekt wieder her
|
||||
|
||||
Given neutralisierter Text
|
||||
When AI-Analyse "Erstelle Risikobewertung" ausgeführt wird
|
||||
Then LLM erhält nur neutralisierten Text (kein PII im Request)
|
||||
AND Ergebnis nach Re-Personalisierung enthält "Hans Muster"
|
||||
```
|
||||
|
||||
### Ausführung
|
||||
|
||||
```bash
|
||||
cd gateway/
|
||||
|
||||
# Alle Demo-Tests:
|
||||
pytest tests/demo/ -v -m "not expensive"
|
||||
|
||||
# Nur Bootstrap:
|
||||
pytest tests/demo/test_demo_bootstrap.py -v
|
||||
|
||||
# Nur UC1:
|
||||
pytest tests/demo/test_demo_uc1_trustee.py -v
|
||||
|
||||
# Mit Live-AI-Calls (expensive, für Generalprobe):
|
||||
pytest tests/demo/ -v -m ""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium (Given-When-Then) | Prio |
|
||||
|---|---------------------------|------|
|
||||
| 1 | Given Demo-Mandant, When Bootstrap ausgeführt wird, Then alle Features aktiv + Testdaten geladen + Neutralisierung an | must |
|
||||
| 2 | Given 3 Musterbelege, When Trustee-Workflow läuft, Then Belege extrahiert + kontiert + Audit-Trail vorhanden | must |
|
||||
| 3 | Given Workspace mit Agent, When Machbarkeitsstudie-Prompt, Then strukturierte Analyse mit Quellen in <2 Min | must |
|
||||
| 4 | Given Chatbot mit Knowledge-Base, When Frage gestellt, Then Antwort mit Quellenangabe in <15s | must |
|
||||
| 5 | Given Mieterdossier-PDF, When Neutralisierung aktiv + AI-Analyse, Then PII nie an LLM gesendet + Re-Personalisierung korrekt | must |
|
||||
| 6 | Given i18n Admin-UI, When neue Sprache "it" angelegt wird, Then AI übersetzt alle Keys in <5 Min und UI zeigt Italienisch nach Sprachwechsel | must |
|
||||
| 7 | Given komplettes Drehbuch, When Demo komplett durchgespielt, Then Timing ≤ 20 Min mit Puffer | must |
|
||||
| 8 | Given pytest-Suite, When `pytest tests/demo/` ausgeführt, Then alle Tests grün (ohne expensive: Bootstrap + Struktur; mit expensive: Live AI) | should |
|
||||
|
||||
## Testplan
|
||||
|
||||
| ID | AC | Art | Automatisiert | Repo-Pfad | Status |
|
||||
|----|----|-----|--------------|-----------|--------|
|
||||
| T1 | 1 | integration | ja | gateway/tests/demo/test_demo_bootstrap.py | pending |
|
||||
| T2 | 2 | e2e | ja (teilweise, AI=expensive) | gateway/tests/demo/test_demo_uc1_trustee.py | pending |
|
||||
| T3 | 3 | e2e | ja (expensive) | gateway/tests/demo/test_demo_uc2_realestate.py | pending |
|
||||
| T4 | 4 | e2e | ja (expensive) | gateway/tests/demo/test_demo_uc3_chatbot.py | pending |
|
||||
| T5 | 5 | e2e | ja (expensive) | gateway/tests/demo/test_demo_neutralization.py | pending |
|
||||
| T6 | 6 | e2e | ja (expensive) | gateway/tests/demo/test_demo_uc4_i18n.py | pending |
|
||||
| T7 | 7 | manual | nein | — (Generalprobe Di Morgen) | pending |
|
||||
| T8 | 8 | ci | ja | `pytest tests/demo/ -v` | pending |
|
||||
|
||||
## Links
|
||||
|
||||
- Keynote Use Cases: `local/notes/use-cases-DEMO-TUE.md`
|
||||
- Customer Demo Enablement: `c-work/1-plan/2026-04-customer-demo-enablement.md`
|
||||
- Trustee Tooling Plan: `c-work/1-plan/2026-04-customer-trustee-tooling-and-demo-prep.md`
|
||||
- Bootstrap (bestehend): `gateway/modules/interfaces/interfaceBootstrap.py`
|
||||
- System-Templates (Treuhand): `interfaceBootstrap._buildSystemTemplates()`
|
||||
- Workflow-Engine: `b-reference/gateway/workflow.md`
|
||||
- Neutralisierung: `b-reference/platform/neutralization.md`
|
||||
- Testing-Strategie: `d-guides/testing-strategy.md`
|
||||
- Trustee-Feature: `gateway/modules/features/trustee/`
|
||||
- RealEstate-Feature: `gateway/modules/features/realEstate/`
|
||||
- Chatbot-Feature: `gateway/modules/features/chatbot/`
|
||||
- Neutralisierung-Feature: `gateway/modules/features/neutralization/`
|
||||
- Graph-Editor: `gateway/modules/features/graphicalEditor/`
|
||||
|
||||
## Abschluss
|
||||
|
||||
- [ ] b-reference/ aktualisiert (keine neuen Features, nur Demo-Config)
|
||||
- [ ] TOPICS.md aktualisiert (falls neues Thema)
|
||||
- [ ] Dieses Dokument → z-archive/ verschoben
|
||||
|
|
@ -1,140 +0,0 @@
|
|||
<!-- status: canonical -->
|
||||
<!-- lastReviewed: 2026-04-12 -->
|
||||
|
||||
# Ungenutzte API-Endpunkte — Kandidaten zum Loeschen
|
||||
|
||||
Analyse vom 2026-04-12. Geprueft gegen:
|
||||
- `frontend_nyla/src/` (UI)
|
||||
- `service-teams-browser-bot/` (Teams Bot)
|
||||
- `private-llm/` (Private LLM)
|
||||
|
||||
Keiner dieser Endpunkte wird in irgendeinem der drei Repos referenziert.
|
||||
|
||||
---
|
||||
|
||||
## Komplett ungenutzte Route-Module
|
||||
|
||||
### `routeMessaging.py` — 14 Endpunkte (alle loeschen)
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/messaging/subscriptions` | Subscriptions auflisten |
|
||||
| POST | `/api/messaging/subscriptions` | Subscription erstellen |
|
||||
| GET | `/api/messaging/subscriptions/{id}` | Subscription abrufen |
|
||||
| PUT | `/api/messaging/subscriptions/{id}` | Subscription aktualisieren |
|
||||
| DELETE | `/api/messaging/subscriptions/{id}` | Subscription loeschen |
|
||||
| GET | `/api/messaging/subscriptions/{id}/registrations` | Registrierungen auflisten |
|
||||
| POST | `/api/messaging/subscriptions/{id}/subscribe` | Registrierung erstellen |
|
||||
| DELETE | `/api/messaging/subscriptions/{id}/unsubscribe` | Abmelden |
|
||||
| GET | `/api/messaging/registrations` | Alle Registrierungen |
|
||||
| PUT | `/api/messaging/registrations/{id}` | Registrierung aktualisieren |
|
||||
| DELETE | `/api/messaging/registrations/{id}` | Registrierung loeschen |
|
||||
| POST | `/api/messaging/trigger/{id}` | Subscription ausloesen |
|
||||
| GET | `/api/messaging/deliveries` | Zustellungen auflisten |
|
||||
| GET | `/api/messaging/deliveries/{id}` | Zustellung abrufen |
|
||||
|
||||
### `routeSecurityAdmin.py` — 9 Endpunkte (alle loeschen)
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/admin/tokens` | Token/Sessions auflisten |
|
||||
| POST | `/api/admin/tokens/revoke/user` | Tokens per User widerrufen |
|
||||
| POST | `/api/admin/tokens/revoke/session` | Session widerrufen |
|
||||
| POST | `/api/admin/tokens/revoke/id` | Token per ID widerrufen |
|
||||
| POST | `/api/admin/tokens/revoke/mandate` | Tokens per Mandate widerrufen |
|
||||
| GET | `/api/admin/databases` | Datenbanken auflisten |
|
||||
| GET | `/api/admin/databases/{name}/tables` | Tabellen auflisten |
|
||||
| POST | `/api/admin/databases/{name}/tables/{table}/drop` | Tabelle loeschen |
|
||||
| POST | `/api/admin/databases/drop` | Datenbank loeschen |
|
||||
|
||||
### `routeAdminRbacExport.py` — 4 Endpunkte (alle loeschen)
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/rbac/export/global` | Globale RBAC exportieren |
|
||||
| POST | `/api/rbac/import/global` | Globale RBAC importieren |
|
||||
| GET | `/api/rbac/export/mandate` | Mandate RBAC exportieren |
|
||||
| POST | `/api/rbac/import/mandate` | Mandate RBAC importieren |
|
||||
|
||||
---
|
||||
|
||||
## Teilweise ungenutzte Route-Module
|
||||
|
||||
### `routeVoiceGoogle.py` — 8 Endpunkte loeschen
|
||||
|
||||
Genutzt werden: `GET /languages`, `GET /voices`, `POST /stt/token`.
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| POST | `/voice-google/speech-to-text` | Audio STT |
|
||||
| POST | `/voice-google/detect-language` | Sprache erkennen |
|
||||
| POST | `/voice-google/translate` | Text uebersetzen |
|
||||
| POST | `/voice-google/realtime-interpreter` | Interpreter-Pipeline |
|
||||
| POST | `/voice-google/text-to-speech` | TTS |
|
||||
| GET | `/voice-google/health` | Health Check |
|
||||
| GET | `/voice-google/settings` | Voice-Einstellungen lesen |
|
||||
| POST | `/voice-google/settings` | Voice-Einstellungen speichern |
|
||||
|
||||
### `routeClickup.py` — 10 Endpunkte loeschen
|
||||
|
||||
Genutzt werden: `GET /{id}/tasks/{taskId}`, `GET /{id}/lists/{listId}`, `GET /{id}/teams/{teamId}`, `GET /{id}/lists/{listId}/fields`, `GET /{id}/lists/{listId}/tasks`.
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/clickup/{id}/teams` | Teams auflisten |
|
||||
| GET | `/api/clickup/{id}/teams/{teamId}/spaces` | Spaces auflisten |
|
||||
| GET | `/api/clickup/{id}/spaces/{spaceId}/folders` | Folders auflisten |
|
||||
| GET | `/api/clickup/{id}/spaces/{spaceId}/lists` | Listen in Space |
|
||||
| GET | `/api/clickup/{id}/folders/{folderId}/lists` | Listen in Folder |
|
||||
| GET | `/api/clickup/{id}/teams/{teamId}/tasks/search` | Tasks suchen |
|
||||
| GET | `/api/clickup/{id}/user` | ClickUp User |
|
||||
| POST | `/api/clickup/{id}/lists/{listId}/tasks` | Task erstellen |
|
||||
| PUT | `/api/clickup/{id}/tasks/{taskId}` | Task aktualisieren |
|
||||
| DELETE | `/api/clickup/{id}/tasks/{taskId}` | Task loeschen |
|
||||
|
||||
### `routeSharepoint.py` — 3 Endpunkte loeschen
|
||||
|
||||
Genutzt wird: `GET /api/sharepoint/folder-options` (ohne connectionId).
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/sharepoint/{id}/sites` | SharePoint Sites |
|
||||
| GET | `/api/sharepoint/{id}/sites/{siteId}/folders` | Folders unter Site |
|
||||
| GET | `/api/sharepoint/{id}/folder-options` | Folder-Optionen (mit connectionId) |
|
||||
|
||||
### `routeFeatureGraphicalEditor.py` — 5 Endpunkte loeschen
|
||||
|
||||
| Method | Path | Funktion |
|
||||
|--------|------|----------|
|
||||
| GET | `/api/workflows/{id}/info` | Workflow-Engine Info |
|
||||
| POST | `/api/workflows/{id}/schedule-sync` | Schedule-Trigger sync |
|
||||
| POST | `/api/workflows/{id}/workflows/{wfId}/webhooks/{epId}` | Webhook registrieren |
|
||||
| POST | `/api/workflows/{id}/workflows/{wfId}/forms/{epId}/submit` | Formular-Submit |
|
||||
| POST | `/api/workflows/{id}/runs/{runId}/resume` | Pausierten Run fortsetzen |
|
||||
|
||||
---
|
||||
|
||||
## Einzelne ungenutzte Endpunkte
|
||||
|
||||
| Route-Datei | Method | Path | Funktion |
|
||||
|-------------|--------|------|----------|
|
||||
| `routeAdminRbacRules.py` | GET | `/api/rbac/catalog/stats` | RBAC Katalog-Statistiken |
|
||||
| `routeI18n.py` | GET | `/api/i18n/user-language-options` | Sprach-Optionen fuer User |
|
||||
| `routeI18n.py` | PUT | `/api/i18n/sets/update-all` | Alle Sprachsets aktualisieren |
|
||||
| `routeSecurityGoogle.py` | GET | `/api/google/config` | Google OAuth Config |
|
||||
| `routeSecurityGoogle.py` | POST | `/api/google/verify` | Token-Verifikation |
|
||||
| `routeSecurityMsft.py` | POST | `/api/msft/cleanup` | MSFT Auth Cleanup |
|
||||
| `routeAdminUserAccessOverview.py` | GET | `/api/admin/user-access-overview/{userId}/effective-permissions` | Effektive Berechtigungen |
|
||||
| `routeDataFiles.py` | GET | `/api/files/stats` | Datei-Statistiken |
|
||||
| `routeBilling.py` | GET | `/api/billing/admin/transactions/{id}/filter-values` | Filter-Werte Admin-Transaktionen |
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Kategorie | Endpunkte |
|
||||
|-----------|-----------|
|
||||
| Komplett ungenutzte Module | 27 |
|
||||
| Teilweise ungenutzte Module | 26 |
|
||||
| Einzelne Endpunkte | 9 |
|
||||
| **Total** | **62** |
|
||||
130
z-archive/post-cleanup-report-2026-04-12.md
Normal file
130
z-archive/post-cleanup-report-2026-04-12.md
Normal file
|
|
@ -0,0 +1,130 @@
|
|||
# Post-Cleanup Report: Entfernte API-Endpunkte
|
||||
|
||||
**Datum:** 2026-04-12
|
||||
**Scope:** Suche nach verwaisten Referenzen auf die am selben Tag entfernten Routen und Endpunkte (siehe `wiki/z-archive/unused-api-endpoints.md`).
|
||||
|
||||
---
|
||||
|
||||
## 1. Zusammenfassung
|
||||
|
||||
| Kategorie | Funde | Handlungsbedarf |
|
||||
|-----------|-------|-----------------|
|
||||
| Verwaiste Frontend-Komponenten (RBAC Export/Import) | 3 Dateien | **Hoch** — Code ruft gelöschte Backend-Endpunkte auf |
|
||||
| Datenmodell-Referenz auf entfernten i18n-Endpunkt | 1 Stelle | **Hoch** — `frontend_options` zeigt auf nicht mehr existierenden Pfad |
|
||||
| Billing filter-values (User-View) | 1 Stelle | **Kein** — Endpunkt existiert noch (nur Admin-Variante entfernt) |
|
||||
| Wiki-Dokumentation mit Verweisen auf gelöschte Module | 1 Datei | **Niedrig** — Doku-Aktualisierung |
|
||||
| Analyse-Artefakte (CSV/TXT) | 2 Dateien | **Keine** — Einmalige Analyse-Skripte |
|
||||
|
||||
---
|
||||
|
||||
## 2. Detaillierte Funde und Handlungsempfehlungen
|
||||
|
||||
### 2.1 RBAC Export/Import — Frontend-Code ohne Backend (HOCH)
|
||||
|
||||
**Problem:** Die gelöschte Route `routeAdminRbacExport.py` bediente die Endpunkte `/api/mandates/{id}/rbac/export`, `/api/admin/rbac/global/export` etc. Im Frontend existieren noch:
|
||||
|
||||
| Datei | Beschreibung |
|
||||
|-------|-------------|
|
||||
| `frontend_nyla/src/hooks/useRbacExportImport.ts` | Hook mit API-Calls zu `/api/mandates/{id}/rbac/export`, `/api/admin/rbac/global/export`, `/api/features/instances/{id}/rbac/export`, und den zugehörigen Import-Endpunkten |
|
||||
| `frontend_nyla/src/components/RbacExportImport/RbacExportImport.tsx` | UI-Komponente (Export-Button, Import-Upload, Vorschau, Ergebnis-Modal) |
|
||||
| `frontend_nyla/src/components/RbacExportImport/index.ts` | Re-Export |
|
||||
| `frontend_nyla/src/components/RbacExportImport/RbacExportImport.module.css` | Styles |
|
||||
|
||||
**Prüfung:** Die Komponente `RbacExportImport` wird aktuell **nirgendwo importiert oder eingebunden** — sie ist toter Code.
|
||||
|
||||
**Empfehlung:**
|
||||
- **Option A (empfohlen):** Alle vier Dateien löschen (`useRbacExportImport.ts`, `RbacExportImport.tsx`, `index.ts`, `RbacExportImport.module.css`). Der Code ist vollständig verwaist.
|
||||
- **Option B:** Falls RBAC-Export/Import in Zukunft wieder gebraucht wird, die Dateien in einen `_archive`-Ordner verschieben.
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Datenmodell `datamodelUam.py` — Verweis auf gelöschten i18n-Endpunkt (HOCH)
|
||||
|
||||
**Problem:** In `gateway/modules/datamodels/datamodelUam.py` (Zeile 246–252) verweist das Feld `language` des User-Modells auf den entfernten Endpunkt:
|
||||
|
||||
```
|
||||
"frontend_options": "/api/i18n/user-language-options"
|
||||
```
|
||||
|
||||
Dieser Endpunkt (`GET /user-language-options` in `routeI18n.py`) wurde entfernt.
|
||||
|
||||
**Auswirkung:** Wenn das Frontend `frontend_options` dynamisch auflöst (z. B. im FormGenerator), wird der Select-Dropdown für die Sprachauswahl beim User-Profil leer bleiben oder einen 404-Fehler auslösen.
|
||||
|
||||
**Empfehlung:**
|
||||
- Prüfen, ob `frontend_options` tatsächlich dynamisch aufgelöst wird (FormGenerator-Logik).
|
||||
- Falls ja: Entweder den Endpunkt wiederherstellen oder `frontend_options` auf einen existierenden Endpunkt umleiten (z. B. `GET /api/i18n/sets` mit Mapping auf `{value, label}`-Format).
|
||||
- Falls nein (statische Anzeige): Den `frontend_options`-Wert durch eine statische Liste ersetzen oder entfernen.
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Billing filter-values — KEIN Handlungsbedarf
|
||||
|
||||
**Befund:** `BillingDataView.tsx` ruft `/api/billing/view/users/transactions/filter-values` auf. Dieser Endpunkt existiert weiterhin in `routeBilling.py` (Zeile 1805). Es wurde nur der **Admin**-Endpunkt `GET /admin/transactions/{targetMandateId}/filter-values` entfernt, der im Frontend nirgends referenziert war.
|
||||
|
||||
**Empfehlung:** Kein Handlungsbedarf.
|
||||
|
||||
---
|
||||
|
||||
### 2.4 FormGeneratorTable — Generisches filter-values-Pattern
|
||||
|
||||
**Befund:** `FormGeneratorTable.tsx` baut generisch `{apiEndpoint}/filter-values`-URLs zusammen. Das ist ein allgemeines Pattern — jede Route, die als `apiEndpoint` übergeben wird, muss einen `/filter-values`-Subpfad anbieten.
|
||||
|
||||
**Empfehlung:** Kein direkter Handlungsbedarf durch die Cleanup-Aktion. Aber: Falls in Zukunft Endpunkte entfernt werden, die als `apiEndpoint` im FormGenerator genutzt werden, muss der zugehörige `filter-values`-Pfad mitberücksichtigt werden.
|
||||
|
||||
---
|
||||
|
||||
### 2.5 Wiki-Dokumentation — Verweis auf gelöschte `routeSecurityAdmin.py` (NIEDRIG)
|
||||
|
||||
**Datei:** `wiki/b-reference/platform/database-architecture.md`
|
||||
|
||||
In Zeile 251 und 270 wird `routeSecurityAdmin.py` als Admin-DB-Listing-Modul erwähnt.
|
||||
|
||||
**Empfehlung:** Die betroffenen Abschnitte aktualisieren — entweder den Verweis entfernen oder als „entfernt am 2026-04-12" markieren.
|
||||
|
||||
---
|
||||
|
||||
### 2.6 SharePoint folder-options — Funktioniert weiterhin
|
||||
|
||||
**Befund:** `NeutralizationView.tsx` und `TrusteeExpenseImportView.tsx` rufen `GET /api/sharepoint/folder-options?connectionReference=...` auf. Dieser Endpunkt wurde **beibehalten** — nur die alten Pfade mit `/{connectionId}/...` wurden entfernt.
|
||||
|
||||
**Empfehlung:** Kein Handlungsbedarf.
|
||||
|
||||
---
|
||||
|
||||
### 2.7 ClickUp — Funktioniert weiterhin
|
||||
|
||||
**Befund:** `workflowApi.ts` ruft `GET /api/clickup/{connectionId}/teams/{teamId}` auf. Dieser Endpunkt ist einer der fünf beibehaltenen Pfade.
|
||||
|
||||
**Empfehlung:** Kein Handlungsbedarf.
|
||||
|
||||
---
|
||||
|
||||
### 2.8 Analyse-Artefakte
|
||||
|
||||
**Dateien:**
|
||||
- `gateway/scripts/import_analysis.csv`
|
||||
- `gateway/scripts/function_imports_analysis.txt`
|
||||
|
||||
Diese enthalten Referenzen auf gelöschte Module, sind aber einmalige Analyse-Outputs.
|
||||
|
||||
**Empfehlung:** Optional löschen oder in `z-archive` verschieben, um Verwirrung zu vermeiden.
|
||||
|
||||
---
|
||||
|
||||
## 3. Priorisierte Aktionsliste
|
||||
|
||||
| Prio | Aktion | Status |
|
||||
|------|--------|--------|
|
||||
| 1 | `datamodelUam.py`: `frontend_options` auf `/api/i18n/codes` umgestellt + FormGenerator-Mapping erweitert (`code`/`id` Fallback) | **Erledigt** |
|
||||
| 2 | Frontend: `RbacExportImport`-Komponente + Hook gelöscht (4 Dateien) | **Erledigt** |
|
||||
| 3 | Wiki: `database-architecture.md` aktualisiert (routeSecurityAdmin-Verweis entfernt) | **Erledigt** |
|
||||
| 4 | Analyse-Artefakte gelöscht (`import_analysis.csv`, `function_imports_analysis.txt`) | **Erledigt** |
|
||||
|
||||
---
|
||||
|
||||
## 4. Verifizierung
|
||||
|
||||
- **Gateway-Import-Test:** `python -c "import app; print('ok')"` → Exit-Code 0, Ausgabe `ok`.
|
||||
- **Keine Laufzeitfehler** durch gelöschte Module (aiohttp/langchain_core-Fehler sind vorbestehend und betreffen optionale Features).
|
||||
- **Kein Frontend-Code** ruft die vollständig gelöschten Routen (Messaging, SecurityAdmin) auf.
|
||||
- **Kein Bot/LLM-Code** referenziert entfernte Endpunkte.
|
||||
36
z-archive/unused-api-endpoints.md
Normal file
36
z-archive/unused-api-endpoints.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
<!-- status: historical — endpoints below were removed from the gateway on 2026-04-12 -->
|
||||
<!-- lastReviewed: 2026-04-12 -->
|
||||
|
||||
# Entfernte ungenutzte API-Endpunkte (Archiv)
|
||||
|
||||
Die folgenden Routen wurden am **2026-04-12** aus dem Gateway entfernt, weil sie weder im UI (`frontend_nyla`), noch im Teams-Bot (`service-teams-browser-bot`), noch in `private-llm` referenziert wurden.
|
||||
|
||||
## Vollstaendig geloeschte Dateien
|
||||
|
||||
| Datei | Anmerkung |
|
||||
|-------|-----------|
|
||||
| `gateway/modules/routes/routeMessaging.py` | gesamtes Modul |
|
||||
| `gateway/modules/routes/routeSecurityAdmin.py` | gesamtes Modul |
|
||||
| `gateway/modules/routes/routeAdminRbacExport.py` | gesamtes Modul |
|
||||
|
||||
`gateway/app.py`: Imports und `include_router` fuer diese drei Router entfernt.
|
||||
|
||||
## Teilweise bereinigte Module
|
||||
|
||||
| Datei | Entfernt |
|
||||
|-------|----------|
|
||||
| `routeVoiceGoogle.py` | `POST /speech-to-text`, `detect-language`, `translate`, `realtime-interpreter`, `text-to-speech`, `GET/POST /settings`, `GET /health` — behalten: `languages`, `voices`, `stt/token`, WebSocket `stt/stream` |
|
||||
| `routeClickup.py` | alle Routen ausser: `teams/{teamId}`, `lists/{listId}`, `lists/{listId}/fields`, `lists/{listId}/tasks`, `tasks/{taskId}` |
|
||||
| `routeSharepoint.py` | `/{connectionId}/sites`, `sites/{siteId}/folders`, `/{connectionId}/folder-options` — behalten: `GET /folder-options` (connectionReference) |
|
||||
| `routeFeatureGraphicalEditor.py` | `GET .../info`, `POST .../schedule-sync`, Webhook- und Form-Submit-Routen, `POST .../runs/{runId}/resume` |
|
||||
| `routeAdminRbacRules.py` | `GET /catalog/stats` |
|
||||
| `routeI18n.py` | `GET /user-language-options`, `PUT /sets/update-all` |
|
||||
| `routeSecurityGoogle.py` | `GET /config`, `POST /verify` |
|
||||
| `routeSecurityMsft.py` | `POST /cleanup` |
|
||||
| `routeAdminUserAccessOverview.py` | `GET /{userId}/effective-permissions` |
|
||||
| `routeDataFiles.py` | `GET /stats` |
|
||||
| `routeBilling.py` | `GET /admin/transactions/{targetMandateId}/filter-values` |
|
||||
|
||||
## Skript-Anpassung
|
||||
|
||||
`gateway/scripts/migrate_async_to_sync.py`: Eintrag fuer `routeAdminRbacExport.py` entfernt.
|
||||
Loading…
Reference in a new issue