<!-- status: plan -->
<!-- started: 2026-04-16 -->
<!-- component: gateway | frontend-nyla | platform -->
<!-- replaces: local/notes/demo-tue-use-cases-inputs-customers.md, c-work/1-plan/2026-04-demo2-merged-customer-trustee-plan.md, c-work/1-plan/2026-04-porta-ui-enhancements-team-meeting.md -->

# Konsolidierter Kundenwünsche-Plan — PORTA Umsetzung

> **Stand:** 16. April 2026 (aktualisiert mit PWG-Workshop-Ergebnissen)
> **Zweck:** Einheitliche Übersicht aller Kundenwünsche, priorisiert und gegen die Codebase abgeglichen.
> **Ersetzt:** `local/notes/demo-tue-use-cases-inputs-customers.md`, `c-work/1-plan/2026-04-demo2-merged-customer-trustee-plan.md`, `c-work/1-plan/2026-04-porta-ui-enhancements-team-meeting.md`

---

## Kunden-Übersicht

| Kunde | Branche | Kontakte | Hauptinteresse | Status |
|-------|---------|----------|----------------|--------|
| **Bling** | Treuhandbüro | KJS | Belegverarbeitung, Budget, Dashboards, Mandantenmanagement | Trial geplant |
| **PWG** (Stiftung) | Immobilien/Wohnen (~300 Liegenschaften, 7–8 Pers.) | MB | **Pilot: Jahresmietzinsbestätigungen** (3'200/Jahr), Belegverarbeitung Abacus, CommCoach, Neutralisierung, Knowledge-Retrieval | Workshop 16.04.2026 ✅ — Pilot bestätigt, Versand Sommer 2026 |
| **Quid / ServiceHunter** | SaaS/Dienstleistung | DC | KPI-Dashboard, Zeiterfassung, Prognosen, Konsolidierung | Follow-up geplant |

---

## Legende Codebase-Status

| Symbol | Bedeutung |
|--------|-----------|
| ✅ | Im Code vorhanden und funktional |
| 🔧 | Grundstruktur vorhanden, Anpassung/Ergänzung nötig |
| ❌ | Noch nicht umgesetzt |
| ⏸️ | Bewusst zurückgestellt (wartet auf Input/Entscheid) |

---

## Teil 1: Feature-Anforderungen (Kunden-Use-Cases)

### 1.1 Automatisierte Belegverarbeitung & Spesenverwaltung

**Kunden:** Bling (Prio hoch), PWG, Quid (Spesen)

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.1.1 | Spesenbelege per Foto → automatische Klassifikation (Rechnung, Spesenbeleg, Bankauszug) | ✅ | `methodTrustee/actions/extractFromFiles.py` + `processDocuments.py` — Pipeline extrahiert, klassifiziert, verbucht |
| 1.1.2 | SharePoint-Synchronisation (automatisch, z.B. täglich 22:00) | ✅ | `nodeDefinitions/sharepoint.py` — 6 Nodes; `automation2/scheduleCron.py` für Zeitsteuerung; System-Template "Treuhand: PDF-Klassifizierung & Trustee-Import" in `interfaceBootstrap.py` |
| 1.1.3 | Automatische Kontierung basierend auf Kontoplan | ✅ | In `processDocuments.py` — AI-gestützte Kontierung gegen Feature-Daten (Kontoplan via Accounting-Bridge) |
| 1.1.4 | Firmen-Mapping zu Kunden/Lieferanten | 🔧 | Grundstruktur in Accounting-Bridge; kein dediziertes Mapping-UI oder regelbasiertes Matching |
| 1.1.5 | Optionales Tagging (z.B. "Fuel Station") | 🔧 | Tags auf Dokument-Ebene möglich; kein Beleg-spezifisches Tag-System |
| 1.1.6 | Buchungsregeln für wiederkehrende Belege | ❌ | Kein regelbasiertes Booking-Template-System |
| 1.1.7 | Vorsteuer automatisch hinterlegen und auslesen | 🔧 | Accounting-Connectors liefern Steuerdaten; automatische MWST-Zuordnung bei Belegverarbeitung nicht explizit |
| 1.1.8 | Integration RunMyAccounts | ✅ | `accountingConnectorRma.py` |
| 1.1.9 | Integration Bexio | ✅ | `accountingConnectorBexio.py` |
| 1.1.10 | Integration Abacus | ✅ | `accountingConnectorAbacus.py` |
| 1.1.11 | Integration Xero | ❌ | Kein `accountingConnectorXero.py` — kein Code vorhanden |
| 1.1.12 | PDF/Excel/Word/Zip Verarbeitung | ✅ | Extraktoren vorhanden; UDM-Konzept in `0-ideas/unified-document-model.md` |

### 1.2 Budget / Soll-Ist-Vergleich

**Kunden:** Bling (Prio hoch), Quid (KPI-Kontext)

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.2.1 | Budget-Excel hochladen und gegen Live-Daten prüfen | 🔧 | Prompt-Template "Budget-Vergleich" in `mainTrustee.py` (Quick Action + Template Workflow); Frontend `TrusteeAnalyseView.tsx` hat Budget-Tab mit Upload; **aber kein Demo-Budget-Excel vorhanden** |
| 1.2.2 | Vergleiche über Perioden (Q1 aktuell vs. Vorjahr vs. Budget) | ✅ | Im Prompt-Template als Anweisung an AI-Agent enthalten |
| 1.2.3 | Automatische Diagramm-Erstellung | ✅ | Agent erzeugt Charts via `aggregateTable` + AI-Prompt |
| 1.2.4 | Live-Daten via API (kein PDF-Export nötig) | ✅ | `refreshAccountingData` Action synct Live-Daten; API-basiert |
| 1.2.5 | Caching konfigurierbar | ✅ | `_featureQueryCache` mit TTL 300s in `_featureSubAgentTools.py` |
| 1.2.6 | Abweichungen mit Begründung | ✅ | Im Prompt-Template: Agent soll Abweichungen erklären |
| 1.2.7 | Vorausschauende Prognosen | ✅ | Separates Prompt-Template "Prognose/Trend-Analyse" |

### 1.3 Cashflow-Rechnung

**Kunden:** Bling

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.3.1 | Plausibilisierung und Erstellung Cashflow-Rechnung | ✅ | Prompt-Template "Cashflow-Rechnung" in `mainTrustee.py` |
| 1.3.2 | Nicht-relevante Positionen berücksichtigen | ✅ | Im Prompt-Template als Anweisung |
| 1.3.3 | Warnungen bei kritischen Werten | ✅ | Im Prompt-Template |

### 1.4 Dashboard — Bilanz- & Erfolgsrechnungsanalyse

**Kunden:** Bling, Quid

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.4.1 | KPI-Dashboard (Bruttogewinn, ROI, Gewinn etc.) | ✅ | Prompt-Template "KPI-Dashboard" + Quick Action + `TrusteeAnalyseView.tsx` KPI-Tab |
| 1.4.2 | Check hälftiger Kapitalverlust | ✅ | Im Jahresabschluss-Prompt enthalten |
| 1.4.3 | Überschuldungs-Check | ✅ | Im Jahresabschluss-Prompt enthalten |
| 1.4.4 | Durchschnittliche Zahlungsfrist | 🔧 | Nicht als dedizierter KPI; Agent kann es berechnen wenn Daten vorhanden |

### 1.5 Liquiditätsplanung

**Kunden:** Bling

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.5.1 | Liquiditätsplanung analog Budgetplanung | 🔧 | Kein dediziertes Prompt-Template; über Prognose-Template teilweise abdeckbar |
| 1.5.2 | Automatische Erstellung aus Vergangenheit | 🔧 | Agent kann historische Daten analysieren; kein dedizierter Workflow |
| 1.5.3 | Zusätzliche Inputs (z.B. ausserordentliche Dividende) | ❌ | Kein Mechanismus für manuelle Zusatz-Inputs in Prognose |

### 1.6 Gastro-Use-Case — Echtzeit-Rentabilitätsanalyse

**Kunden:** Bling (Prio hoch, bestes Beispiel für Kunden-Mehrwert)

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.6.1 | Integration Kassensystem + Lohndaten + Buchhaltung | ⏸️ | **Wartet auf Kevin-Input** — kein Connector für Kassensysteme/Virux |
| 1.6.2 | Tagesumsatz vs. Personalkosten vs. Wareneinsatz | ⏸️ | Konzeptionell über generischen Data-Import möglich |

### 1.7 Abschlussunterstützung

**Kunden:** Bling, allgemein Treuhand

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.7.1 | Jahresabschluss-Checks | ✅ | Prompt-Template "Jahresabschluss prüfen" in `mainTrustee.py` |
| 1.7.2 | Abgrenzungsbuchungen vorbereiten | 🔧 | Im Prompt adressiert; keine dedizierte Automation |
| 1.7.3 | Bilanzkonti prüfen / Saldovalidierung | ✅ | Im Jahresabschluss-Prompt |
| 1.7.4 | Vorjahresvergleiche | ✅ | In mehreren Prompt-Templates |

### 1.8 Zentrales Mandantenmanagement

**Kunden:** Bling (verschiedene Systeme über eine Schaltzentrale)

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.8.1 | Verschiedene Kunden auf verschiedenen Systemen verwalten | ✅ | Multi-Tenant-Plattform ist Kernarchitektur; `accountingRegistry.py` unterstützt verschiedene Connectors pro Mandant |
| 1.8.2 | Ein Login, alle Mandanten | ✅ | Plattform-Feature: Mandantenwechsel im UI |
| 1.8.3 | Strikte Datentrennung | ✅ | Mandantenisolation auf DB- und API-Ebene |

---

### 1.9 PWG — Stiftung für preisgünstiges Wohnen

**Kontext:** ~300 Liegenschaften, Team 7–8 Personen. IT-Leiter Markus Brütsch (seit 2+ Jahren). Neue Rolle "Organella" für Digitalisierung (Schnittstelle Technologie/Betrieb, kein IT-Hintergrund). PWG evaluiert AI-Lösungen offen, noch keine Entscheidung getroffen. Workshop 16.04.2026 durchgeführt.

**Pilotprojekt bestätigt:** Jahresmietzinsbestätigungen (siehe 1.9.9).

#### 1.9a Plattform-Features (bestehend)

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.9.1 | Automatisierte Belegverarbeitung mit Abacus | ✅ | `accountingConnectorAbacus.py` + Trustee-Pipeline |
| 1.9.2 | Kommunikations-Coach für Mietergespräche | ✅ | `features/commcoach/` — komplett inkl. 10+ Personas |
| 1.9.3 | Immobilien-Personas (Zahlungsrückstand, Nebenkosten, Einzug, Lärm) | ✅ | 4 PWG-Personas in `BUILTIN_PERSONAS` + Seeding |
| 1.9.4 | KI-Arbeitsplatz mit Datenneutralisierung | ✅ | `features/neutralization/` — PII-Masking, Playground, Private-LLM; Daten-Residency Schweiz |
| 1.9.5 | PWG-Agent (Stiftungsstil, öffentliche PDFs als Futter) | 🔧 | Knowledge-Base-Feature vorhanden; kein PWG-spezifisches Knowledge-Set (Geschäftsberichte, Vermietungsreglement, Führungshandbuch etc.) |
| 1.9.6 | M365-Anbindung (SharePoint, Outlook, OneDrive, Teams) | ✅ | SharePoint-Nodes + Outlook-Methode in Workflows; nutzt nativen SharePoint-Index |
| 1.9.7 | KI-Auswertung Abacus-Daten/Reports | ✅ | Über Trustee-Feature + `aggregateTable` + AI-Prompts; Read/Write via Abacus-API |
| 1.9.8 | Grundstücksanalyse (öffentliche Daten: GIS, Maps, Grundbuch) | ❌ | Kein Connector/Workflow für öffentliche Geodaten |

#### 1.9b Neue Anforderungen aus Workshop 16.04.2026

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.9.9 | **Pilotprojekt: Jahresmietzinsbestätigungen** (ca. 700–800 Schreiben/Quartal, Versand Sommer 2026) | ❌ | Kein dedizierter Workflow — siehe Workflow-Design unten |
| 1.9.10 | FileMaker-Integration (Portfolio, Liegenschaften, Erneuerungsplanung, Bauprojekte, Akquisition) | ❌ | Kein FileMaker-Connector; Datenmenge/-qualität muss geprüft werden |
| 1.9.11 | Template-basierte Dokumentenerstellung (HTML-Templates → Word mit Corporate Design) | 🔧 | Code-Editor mit Claude vorhanden; kein Template-to-Word-Pipeline |
| 1.9.12 | Notification-System (reagiert auf DB-Änderungen, Berichte per E-Mail, Workflow-Trigger) | 🔧 | E-Mail-Versand in Workflows vorhanden (`methodOutlook`); kein generisches DB-Change-Detection-System |
| 1.9.13 | Information Retrieval über diverse Wissensquellen (Guidelines, Handbücher, SharePoint) | 🔧 | Knowledge-Base + SharePoint-Index vorhanden; kein PWG-spezifisches Datenset geladen |
| 1.9.14 | Datenvalidierung als Erst-Schritt (welche Daten korrekt/aktuell?) | ❌ | Kein Daten-Audit-Workflow |
| 1.9.15 | Compliance & Audit: vollständiges Tracking aller AI-Transaktionen | ✅ | `ComplianceAuditPage.tsx` + Gateway-Logging; jede Anfrage protokolliert |
| 1.9.16 | Granulare Neutralisierungs-Kontrolle pro Datenquelle | ✅ | In Neutralisierungs-Feature konfigurierbar pro Source |

#### 1.9c Pilot-Workflow: Jahresmietzinsbestätigungen

**Business Case:** 4 × 800 Schreiben/Jahr = 3'200 Schreiben. Aktuell: Serienbrief → manueller Versand → Scan der Rückantworten → manuelle Verarbeitung. Ziel: AI-gestützte Verarbeitung der gescannten Rückantworten mit Antwortvorschlägen.

**Workflow-Design (6–7 Schritte, davon 1 mit AI):**

```
┌─────────────────────────────────────────────────────────────────┐
│  PWG Pilot: Jahresmietzinsbestätigungen                         │
│                                                                 │
│  Phase 1: Generierung (bestehend bei PWG)                       │
│  ┌──────────────────────────────────────┐                       │
│  │ System generiert Serienbrief         │ (PWG-internes System) │
│  │ mit aktuellen Mietdaten             │                       │
│  └──────────┬───────────────────────────┘                       │
│             ▼                                                   │
│  Phase 2: Versand & Rücklauf (manuell)                          │
│  ┌──────────────────────────────────────┐                       │
│  │ Manueller Versand + Scan der         │                       │
│  │ Rückantworten → SharePoint-Ordner    │                       │
│  └──────────┬───────────────────────────┘                       │
│             ▼                                                   │
│  Phase 3: PowerOn-Workflow (automatisiert)                      │
│                                                                 │
│  Step 1: trigger.schedule (täglich oder on-demand)              │
│       ▼                                                         │
│  Step 2: sharepoint.listFiles (Scan-Ordner, neue Dokumente)     │
│       ▼                                                         │
│  Step 3: flow.loop (für jedes gescannte Dokument)               │
│       ▼                                                         │
│  Step 4: sharepoint.downloadFile + trustee.extractFromFiles     │
│          → OCR/Extraktion: Mietername, Adresse, Bestätigung,    │
│            Anmerkungen, Unterschrift ja/nein                     │
│       ▼                                                         │
│  Step 5: ai.prompt ← EINZIGER AI-SCHRITT                       │
│          → Gescannte Daten gegen Originaldaten prüfen           │
│          → Status klassifizieren (bestätigt / Abweichung /      │
│            fehlende Unterschrift / unleserlich)                  │
│          → Antwortvorschlag generieren bei Abweichung           │
│       ▼                                                         │
│  Step 6: data.writeToTable (Ergebnis in Übersichtstabelle)      │
│       ▼                                                         │
│  Step 7: email.send (Zusammenfassung an Sachbearbeiter)         │
│          → Audit-Log für jeden Verarbeitungsschritt              │
└─────────────────────────────────────────────────────────────────┘
```

**Benötigte Komponenten für den Pilot-Workflow:**

| # | Komponente | Codebase-Status | Was zu tun ist |
|---|-----------|-----------------|----------------|
| W1 | `trigger.schedule` oder `trigger.manual` | ✅ | Vorhanden in `nodeDefinitions/triggers.py` |
| W2 | `sharepoint.listFiles` + `sharepoint.downloadFile` | ✅ | Vorhanden in `nodeDefinitions/sharepoint.py` |
| W3 | `flow.loop` | ✅ | Vorhanden in `nodeDefinitions/flow.py` |
| W4 | `trustee.extractFromFiles` (OCR/Extraktion gescannter Dokumente) | ✅ | Vorhanden; OCR für einseitige Scans unterstützt |
| W5 | `ai.prompt` — Prompt-Template "Mietzinsbestätigung prüfen" | ❌ | **Neues Prompt-Template** nötig: Scan-Daten gegen Originaldaten abgleichen, Status klassifizieren, Antwortvorschlag generieren |
| W6 | Ergebnis-Tabelle / Übersichtsliste (verarbeitete Bestätigungen) | 🔧 | `data`-Nodes existieren; kein dedizierter "Mietzinsbestätigungs-Report"-Output |
| W7 | `email.send` (Zusammenfassung an Sachbearbeiter) | ✅ | Vorhanden via `methodOutlook` |
| W8 | Abacus-Referenzdaten (Original-Mietzinsdaten für Abgleich) | 🔧 | Abacus-Connector vorhanden; Abfrage der Mietzins-Stammdaten muss konfiguriert werden |
| W9 | Audit-Logging für gesamten Prozess | ✅ | Plattform-Feature: alle AI-Transaktionen geloggt |
| W10 | Graph-Editor Workflow als Template speichern | ❌ | Workflow muss im Editor gebaut und als System-Template gespeichert werden |

**Voraussetzungen (Action Items aus Workshop):**

| # | Action Item | Verantwortlich | Status |
|---|------------|----------------|--------|
| AI1 | API-Zugang zu Abacus-Testmandant einrichten | Patrick Motsch | ❌ offen — Patrick koordiniert mit Abacus |
| AI2 | PWG muss Zugriff auf Testmandant bestätigen | PWG (Markus) | ❌ offen |
| AI3 | Preismodell bereitstellen (Grundgebühr/User/Monat + Token-Gebühr) | PowerOn | ❌ offen |
| AI4 | Datenschutzanforderungen und Vertragsklauseln für Lieferanten prüfen | PWG | ❌ offen |
| AI5 | Prozessschritte Pilot ausarbeiten und Kalkulation erstellen | PowerOn | 🔧 Workflow-Design in diesem Dokument; Kalkulation offen |
| AI6 | FileMaker-Datenmenge und -qualität prüfen (potenzielle Integration) | PWG + PowerOn | ❌ offen |

---

### 1.10 Quid / ServiceHunter Use Cases

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 1.10.1 | KPI-Dashboard (Kundenmargen, ACV, Lifetime Value, Produktionsmarge) | 🔧 | Generisches KPI-Prompt-Template vorhanden; kundenspezifische KPIs brauchen Daten-Import |
| 1.10.2 | Zeiterfassung & Support-Analyse (Zendesk-Verknüpfung) | ⏸️ | **Kein Zendesk-Connector** — bewusst CSV-Upload-Workaround |
| 1.10.3 | Prognosen & Proaktive Steuerung | ✅ | Prognose-Prompt-Template vorhanden |
| 1.10.4 | Konsolidierung international (CH, DE, UK) | ⏸️ | **Wartet auf Lars-Meeting** — hohe Komplexität |
| 1.10.5 | Spesen-Automatisierung (SharePoint/Drive → verbuchen) | ✅ | SharePoint-Pipeline + Trustee-Import vorhanden |

---

## Teil 2: UI/UX-Anforderungen (aus Team-Meeting / Nutzertests)

### 2.1 AI-Workspace Usability

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 2.1.1 | Primäre Prompt-Zeile dominant sichtbar (kein "Wo tippe ich?") | 🔧 | `WorkspaceInput.tsx` funktional komplett; **Placeholder auf Englisch**, keine Hero-Eingabe, sekundäre Aktionen in einer Zeile |
| 2.1.2 | Empty State im Chat (Orientierung für Erstnutzer) | ❌ | `ChatStream.tsx` zeigt blank area wenn `messages.length === 0` — **kein Welcome/Empty-State** |
| 2.1.3 | "Neuer Chat" sichtbar ohne UDB-Sidebar | ❌ | Nur `+` in `ChatsTab` Toolbar; kein zentraler CTA |
| 2.1.4 | Datei-Drop Entdeckbarkeit | 🔧 | Vollflächen-Drop existiert in `WorkspacePage.tsx`; kein dauerhafter Hinweis im leeren Chat |
| 2.1.5 | DE-Placeholder und i18n | ❌ | Placeholder noch auf Englisch (`Type a message...`) |

### 2.2 Responsive Layout & Breakpoints

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 2.2.1 | Zwischen-Breakpoint (1025–1280px): Sidebars auto-einklappen | ❌ | `isMobile` nur bei `≤1024px`; schmale Desktop-Fenster → Mittelspalte zu schmal |
| 2.2.2 | Visuelle Hierarchie Prompt (Schatten/Rand, minHeight) | ❌ | `WorkspaceInput.tsx` ohne besondere Hervorhebung |
| 2.2.3 | Viewport-Testmatrix (1100/1200/1280/1440) | ❌ | Kein Test-Setup dafür |

### 2.3 Vertrauen & Marketing-UI

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 2.3.1 | Trust-Badges (Daten hosted in der Schweiz, Anbieter/Standort) | ❌ | Login: **kein** Hosting-Hinweis; keine `TrustFooter`/`TrustStrip` Komponente |
| 2.3.2 | "Recommended by" Partner-Strip (Valion, PamoCreate, Swiss AI Association etc.) | ❌ | Keine Partner-Logos/Links |
| 2.3.3 | Swiss ® am Logo | ❌ | Nur im Bildasset, nicht in UI sichtbar (Legal klären) |
| 2.3.4 | Sicherheits-Banner in SourcesTab ("Verbindung ist read-only") | ❌ | `SourcesTab.tsx` ohne Info-Banner |

### 2.4 Billing & Pricing Auffindbarkeit

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 2.4.1 | Billing-Funktionalität (komplett) | ✅ | `BillingDataView.tsx` mit Tabs, Balance Cards, Transaktionen |
| 2.4.2 | Einstieg Billing nach Login (Teaser/Banner) | ❌ | Kein Dashboard-Teaser; Zugang nur via Nav-Baum + User-Menü |
| 2.4.3 | Balance im UserSection (neben Avatar) | ❌ | Nur Menü-Eintrag "Guthaben" |
| 2.4.4 | Billing-Copy für Nicht-Admins | ❌ | Kein Hinweis "Frag deinen Admin" |

### 2.5 Onboarding & Erstnutzung

| # | Anforderung | Codebase-Status | Evidenz / Bemerkung |
|---|-------------|-----------------|---------------------|
| 2.5.1 | Connector-Onboarding ("sicher verbinden, nichts kaputt") | ❌ | Keine Microcopy in SourcesTab |
| 2.5.2 | Progressive Offenlegung (weniger gleichzeitig auf Startscreens) | ❌ | Workspace zeigt alles parallel |

---

## Teil 3: Infrastruktur & Demo-Vorbereitung

### 3.1 Demo-Konfigurationen

| # | Item | Codebase-Status | Evidenz / Bemerkung |
|---|------|-----------------|---------------------|
| 3.1.1 | Demo-Config-Infrastruktur (Base + Admin API) | ✅ | `_baseDemoConfig.py`, `routeAdminDemoConfig.py` |
| 3.1.2 | Referenz: `investorDemo2026.py` | ✅ | Vollständiges Muster mit Mandant, User, Features, Billing |
| 3.1.3 | Demo-Mandant "Bling Demo" | ❌ | Kein `blingDemo2026.py` |
| 3.1.4 | Demo-Mandant "PWG Demo" | ❌ | Kein `pwgDemo2026.py` |
| 3.1.5 | Demo-Mandant "Quid Demo" | ❌ | Kein `quidDemo2026.py` |

### 3.2 Testdaten

| # | Item | Codebase-Status | Evidenz / Bemerkung |
|---|------|-----------------|---------------------|
| 3.2.1 | Fiktives Mieterdossier (Neutralisierung) | ✅ | `demoData/neutralizer/tenant-dossier.pdf` + Generator |
| 3.2.2 | Knowledge-Base Demo-Dateien | ✅ | `demoData/knowledge-base/` — 4 Dateien |
| 3.2.3 | Budget-Excel (Soll-Werte) | ❌ | Kein `.xlsx` im Repo |
| 3.2.4 | Musterbelege (Rechnung, Spesen, Bank, Versicherung) | ❌ | Keine Demo-Belege |
| 3.2.5 | Quid-Testdaten (CSV: Umsatz, Kunden, Support) | ❌ | Keine kundenspezifischen Testdaten |
| 3.2.6 | Bling-Testdaten (Bexio-kompatibel) | ❌ | Keine Bexio-Testdaten |
| 3.2.7 | PWG-Testdaten (Abacus-kompatibel) | ❌ | Keine Abacus-Testdaten |

### 3.3 Demo-Workflows & Skripte

| # | Item | Codebase-Status | Evidenz / Bemerkung |
|---|------|-----------------|---------------------|
| 3.3.1 | System-Template "Treuhand: PDF-Klassifizierung" | ✅ | In `interfaceBootstrap.py` |
| 3.3.2 | Demo-Workflow (manual trigger → SharePoint → Trustee Pipeline) | ❌ | System-Template existiert, aber kein dedizierter Demo-Workflow |
| 3.3.3 | Demo-Skript Bling | ❌ | |
| 3.3.4 | Demo-Skript PWG | ❌ | |
| 3.3.5 | Demo-Skript Quid | ❌ | |
| 3.3.6 | Neutralisierungs-Demo-Flow (Schritt-für-Schritt) | ❌ | Kein Skript |

---

## Teil 4: Allgemeine Treuhand-Use-Cases (Prozessdokumentation)

Diese Use Cases stammen aus der allgemeinen Treuhand-Prozessdokumentation und sind für **alle** Kunden relevant.

### 4.1 Datenerfassung — Kleine Unternehmen

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.1.1 | Belege sortieren & mit Banktransaktionen referenzieren | 🔧 — Belegverarbeitung vorhanden; kein Bank-Statement-Matching |
| 4.1.2 | Import Banktransaktionen via Excel/CSV | 🔧 — File-Upload + Extraktion vorhanden; kein dedizierter Bank-Import |
| 4.1.3 | Automatisierte Rückfragen an Kunden bei fehlenden Belegen | ❌ |

### 4.2 Lohnbuchhaltung

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.2.1 | Überleitung Lohnaufwand (Fibu vs. Lohnbuchhaltung) | ❌ — Kein Lohn-Feature |
| 4.2.2 | Nicht-lohnwirksame Buchungen identifizieren | ❌ |
| 4.2.3 | Fehlende Lohnmeldungen erkennen | ❌ |

### 4.3 Steuererklärung

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.3.1 | Belege nach Kategorien ordnen | 🔧 — Klassifikation vorhanden |
| 4.3.2 | Steuererklärung erstellen | ❌ — Kein Steuer-Feature |
| 4.3.3 | Vorjahresvergleich und Plausibilisierung | ✅ — In Analyse-Prompts |

### 4.4 Jahresabschluss (Mittlere/Grosse Unternehmen)

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.4.1 | Banksalden abgleichen (Buchhaltung vs. Bank) | 🔧 — Konzeptionell via Agent; kein dedizierter Check |
| 4.4.2 | PayPal, Revolut, ausländische Konten nachbuchen | ❌ |
| 4.4.3 | Wertschriftendepot nachbuchen | ❌ |
| 4.4.4 | Fehlerkonto-Transaktionen bereinigen | ❌ |
| 4.4.5 | Kreditkartenkonto abstimmen | ❌ |
| 4.4.6 | Zahlungsanbieter prüfen (Stripe, Amex) | ❌ |
| 4.4.7 | Nebenbücher mit Fibu abstimmen | ❌ |
| 4.4.8 | Skonto-Differenzen ausbuchen | ❌ |
| 4.4.9 | Konzerninterne Abstimmung | ❌ |
| 4.4.10 | Darlehenskonten abgleichen, Zinsen berechnen | ❌ |
| 4.4.11 | Fremdwährungsbewertung gemäss ESTV | ❌ |
| 4.4.12 | Eigenkapitalveränderungen mit HR abgleichen | ❌ |
| 4.4.13 | Umsatz-/Aufwandsplausibilisierung | ✅ — Im Jahresabschluss-Prompt |
| 4.4.14 | Rechnungsabgrenzungen (aktiv/passiv) | 🔧 — Im Prompt adressiert |
| 4.4.15 | Abschreibungen erfassen | ❌ |
| 4.4.16 | MWST-Jahresabstimmung | ❌ |
| 4.4.17 | Steueraufwand-Rückstellungen berechnen | ❌ |
| 4.4.18 | Bilanz und ER plausibilisieren | ✅ — Im Jahresabschluss-Prompt |
| 4.4.19 | Analyse gesetzliche Bestimmungen (Kapitalverlust, Überschuldung) | ✅ — Im Jahresabschluss-Prompt |

### 4.5 Finanzielle Führung & Controlling

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.5.1 | Businessplan → Absatzplanung → Ertragsplanung | ❌ |
| 4.5.2 | Investitionsplan und Finanzplan | ❌ |
| 4.5.3 | Budget mit Szenarien | 🔧 — Budget-Prompt vorhanden; Szenarien via Chat |
| 4.5.4 | Soll/Ist-Vergleich mit Abweichungsanalyse | ✅ — Budget-Vergleich Prompt-Template |
| 4.5.5 | Deckungsbeitragsrechnung | ❌ |
| 4.5.6 | Projekt-Controlling | ❌ |
| 4.5.7 | Benchmarkanalyse | ❌ |
| 4.5.8 | KPI-Monitoring mit proaktiver Benachrichtigung | 🔧 — KPIs via Agent; kein proaktives Alert-System |

### 4.6 Revisionen

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.6.1 | Ordentliche Revisionen unterstützen | ❌ — Kein Revisions-Feature |

### 4.7 Steueroptimierung & Simulationen

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.7.1 | Jahresrechnung auf steuerliche Probleme prüfen | ❌ |
| 4.7.2 | Simulationen (Lohn vs. Dividende, Umzug, 3. Säule, BVG) | ❌ |
| 4.7.3 | MWST-Prüfung, VST-Korrekturen | ❌ |
| 4.7.4 | Steuerausscheidungen auf verschiedene Kantone | ❌ |

### 4.8 Interdisziplinäre Themen

| # | Anforderung | Codebase-Status |
|---|-------------|-----------------|
| 4.8.1 | Umstrukturierungen | ❌ |
| 4.8.2 | Steuer-/Vorsorgestrategien | ❌ |
| 4.8.3 | Nachfolgeplanung | ❌ |
| 4.8.4 | Unternehmensbewertungen | ❌ |

---

## Zusammenfassung: Status-Überblick

### Fertig (✅) — Kernplattform funktioniert

| Bereich | Was steht |
|---------|-----------|
| **Trustee Agent-Tools** | `refreshTrusteeData`, `aggregateTable`, Connection-Pooling, Result-Caching |
| **Graph-Editor** | Trustee-Kategorie + 4 Nodes, SharePoint-Nodes, Flow-Nodes (Loop, If/Else, Switch, Merge) |
| **Prompt-Templates** | 5 Analyse-Typen (Budget, KPI, Cashflow, Prognose, Jahresabschluss) als Quick Actions + Template Workflows |
| **Accounting-Connectors** | Bexio, Abacus, RunMyAccounts |
| **Belegverarbeitung** | Extraktion → Klassifikation → Kontierung → Sync (end-to-end) |
| **CommCoach** | Feature komplett, 10+ Personas inkl. 4 Immobilien-Personas (PWG), Gamification, Seeding |
| **Neutralisierung** | PII-Masking, Playground, Private-LLM, Mieterdossier-PDF |
| **Multi-Tenancy** | Mandantenisolation, Datentrennung, Rollenwechsel |
| **Billing** | BillingDataView, Balance, Transaktionen, useBilling |
| **SharePoint-Integration** | 6 Workflow-Nodes + Automation |
| **Demo-Infrastruktur** | Base-Config, Admin-API, Investor-Demo als Referenz |

### Teilweise (🔧) — Grundstruktur steht, Erweiterung nötig

| Bereich | Was fehlt |
|---------|-----------|
| Firmen-Mapping Kunden/Lieferanten | Regelbasiertes Matching-UI |
| Beleg-Tagging | Beleg-spezifisches Tag-System |
| Vorsteuer-Automatisierung | MWST-Zuordnung bei Belegverarbeitung |
| Liquiditätsplanung | Dediziertes Prompt-Template |
| Workspace-Prompt | DE-Placeholder, visuelle Hervorhebung |
| Datei-Drop | Hinweis im Empty State |
| Budget-Prompt | Demo-Excel-Datei fehlt |

### Offen (❌) — Noch zu bauen

#### Prio 0: PWG-Pilot (Versand Sommer 2026 — Deadline-gebunden)

| Item | Aufwand | Beschreibung |
|------|---------|-------------|
| Abacus-Testmandant API-Zugang | Extern | Patrick koordiniert mit Abacus; PWG muss Zugriff bestätigen |
| Prompt-Template "Mietzinsbestätigung prüfen" | Mittel | Neues Template: Scan vs. Originaldaten, Status-Klassifikation, Antwortvorschlag |
| Pilot-Workflow im Graph-Editor | Mittel | trigger → sharepoint.listFiles → loop → download → extract → ai.prompt → report → email |
| Abacus-Mietzins-Stammdaten-Abfrage | Klein | Konfiguration im Abacus-Connector für Mietzins-Referenzdaten |
| Demo-Mandant PWG | Mittel | `pwgDemo2026.py` — Trustee (Abacus), CommCoach, Neutralisierung, Workspace |
| PWG Knowledge-Set | Klein | Öffentliche PDFs (Geschäftsberichte, Vermietungsreglement) in Knowledge-Base laden |
| Preismodell / Kalkulation Pilot | Extern | Grundgebühr/User/Monat + Token-Gebühr; basierend auf 4×800 Schreiben/Jahr |

#### Prio 1: Demo-Blocker / Weitere Kunden-Demos

| Item | Aufwand | Beschreibung |
|------|---------|-------------|
| Demo-Mandant Bling | Mittel | `blingDemo2026.py` — Trustee (Bexio), Workspace, Graph-Editor |
| Demo-Mandant Quid | Klein | `quidDemo2026.py` — Workspace, Graph-Editor, CSV-Upload |
| Budget-Excel | Klein | Soll-Werte 2026 für Demo |
| Musterbelege (PDFs) | Klein | 3–5 Belege (Rechnung, Spesen, Bank, Versicherung) |
| Demo-Skripte | Klein | Schritt-für-Schritt pro Kunde |
| Neutralisierungs-Demo-Flow | Klein | Dokumentation |
| Demo-Workflow Graph-Editor (generisch) | Mittel | trigger.manual → SharePoint → Trustee Pipeline |

#### Prio 2: UI/UX-Verbesserungen (Erstnutzer-Hürde senken)

| Item | Aufwand | Beschreibung |
|------|---------|-------------|
| Empty State ChatStream | Klein | Titel, Bullets, "Neuer Chat" Button |
| DE-Placeholder + i18n | Klein | `WorkspaceInput.tsx` |
| "Neuer Chat" CTA in Mitte | Klein | `WorkspacePage.tsx` |
| Zwischen-Breakpoint (1025–1280px) | Mittel | Sidebar-Auto-Collapse |
| Trust-Strip/Footer (Login, Landing) | Mittel | Hosting Schweiz, Partner-Logos (Legal nötig) |
| Billing-Teaser nach Login | Klein | Link oder Banner |
| Connector-Onboarding Copy | Klein | Sicherheits-Banner in SourcesTab |
| Balance im UserSection | Klein | Zahl neben Avatar |

#### Prio 3: Feature-Erweiterungen (Roadmap)

| Item | Aufwand | Beschreibung |
|------|---------|-------------|
| Xero-Connector | Gross | Neuer Accounting-Connector |
| FileMaker-Connector (PWG) | Gross | Portfolio, Liegenschaften, Erneuerungsplanung; Datenmenge/-qualität erst prüfen |
| Buchungsregeln für wiederkehrende Belege | Mittel | Regel-Engine |
| Liquiditätsplanungs-Template | Klein | Neues Prompt-Template |
| KPI-Monitoring mit Alerts | Gross | Proaktives Benachrichtigungssystem |
| Template-basierte Dokumentenerstellung (HTML → Word) | Mittel | Erneuerungsstrategien, Corporate Design |
| DB-Change-Detection / Notification-Trigger | Mittel | Reagiert auf Datenbank-Änderungen, triggert Workflows |
| Datenvalidierungs-Workflow | Klein | Erst-Audit: welche Daten korrekt/aktuell |

#### Prio 4: Zurückgestellt (wartet auf externen Input)

| Item | Wartet auf | Kunde |
|------|-----------|-------|
| Gastro-Echtzeit-Integration | Kevin (Bling) soll UC ausformulieren | Bling |
| Zendesk-Connector | Bewusst CSV-Workaround | Quid |
| Regelbasierte Konsolidierung | Lars-Meeting | Quid |
| Grundstücksanalyse (GIS etc.) | Kundenpräzisierung | PWG |
| FileMaker-Integration (PWG) | Datenmenge/-qualität prüfen (PWG + PowerOn) | PWG |
| PWG Datenschutz-/Vertragsklauseln | PWG prüft intern (genossenschaftliche Struktur) | PWG |

#### Langfristig: Allgemeine Treuhand-Automatisierung

Die Use Cases aus Teil 4 (Lohnbuchhaltung, Steuererklärung, detaillierter Jahresabschluss, Revisionen, Steueroptimierung, interdisziplinäre Themen) sind **konzeptionell dokumentiert** aber noch **nicht in der Codebase**. Diese bilden die Langfrist-Roadmap und werden schrittweise über AI-Prompt-Templates und dedizierte Workflows umgesetzt, sobald die Kern-Use-Cases bei den ersten Kunden validiert sind.

---

## Entscheidungen

| Datum | Entscheidung | Begründung |
|-------|-------------|------------|
| 2026-04-07 | Prompt-Templates als Code in `mainTrustee.py` | Wartbar und versioniert statt externe Dateien |
| 2026-04-07 | `refreshTrusteeData` als separate Action | Separation of Concerns: Sync = schreibend, Query = lesend |
| 2026-04-07 | DB-Connection-Pooling statt Connection-per-Call | Grösster Performance-Hebel (~200ms pro Connection) |
| 2026-04-09 | Quid ohne Zendesk-Connector — CSV-Upload | Gleicher Analyse-Mehrwert, viel weniger Aufwand |
| 2026-04-09 | Gastro-UC und Konsolidierung auf Prio 4 | Warten auf Kunden-Input |
| 2026-04-09 | CommCoach-Personas als schnellster Wow-Effekt für PWG | Feature gebaut, nur Persona-Definitionen nötig |
| 2026-04-07 | UI-Enhancements: Fokus Erstnutzer-Hürde | Ohne klare Userführung springen Kunden ab |
| 2026-04-07 | Trust-Badges: kein ISO, sondern "Daten in CH" | Konkreter Nutzen > abstraktes Zertifikat |
| 2026-04-16 | PWG-Pilot = Jahresmietzinsbestätigungen als erster Produktiv-UC | Konkreter, messbarer Business Case (4×800 Schreiben); Deadline Sommer 2026 |
| 2026-04-16 | Workflow-Philosophie PWG: erst manuell testen, dann automatisieren | Agent wird aus manuell getesteten Prozessen erstellt; Workflows für wiederkehrende Aufgaben |
| 2026-04-16 | FileMaker-Integration auf Prio 4 | Datenmenge/-qualität muss erst geprüft werden; kein Blocker für Pilot |
| 2026-04-16 | Abacus-Testmandant als Voraussetzung für Pilot | Patrick koordiniert API-Zugang direkt mit Abacus |

---

## Betroffene Module

- **Gateway:** `features/trustee/` (Prompts, Quick Actions, Connectors), `features/commcoach/` (Personas), `features/neutralization/` (Demo-Config), `features/graphicalEditor/` (Nodes), `serviceCenter/services/serviceAgent/` (Tools, Caching), `demoConfigs/` (neue Configs), `workflows/methods/methodTrustee/` (Actions), `demoData/` (Testdaten)
- **Frontend Nyla:** `WorkspacePage.tsx` (Layout, Breakpoints, Empty State), `WorkspaceInput.tsx` (Prompt, i18n), `ChatStream.tsx` (Empty State), `Login.tsx` (Trust-UI), `UserSection.tsx` (Balance), `SourcesTab.tsx` (Onboarding-Copy), `BillingDataView.tsx` (Discovery)
- **DB-Migration:** Nein
- **Platform/Wiki:** Nach Release `b-reference/` aktualisieren

## Links

- PWG Workshop-Inputs (16.04.2026): `pamocreate/projects/poweron/customer-pwg/20260415-inputs-pwg.txt`
- Originale Kunden-Inputs: `local/notes/demo-tue-use-cases-inputs-customers.md`
- Merged Demo-Plan (ersetzt): `c-work/1-plan/2026-04-demo2-merged-customer-trustee-plan.md`
- UI-Enhancements Plan (ersetzt): `c-work/1-plan/2026-04-porta-ui-enhancements-team-meeting.md`
- Investor-Demo (Referenz): `gateway/modules/demoConfigs/investorDemo2026.py`
- Frontend-Referenz: `b-reference/frontend-nyla/architecture.md`
- Trustee Main (Prompts): `gateway/modules/features/trustee/mainTrustee.py`
- CommCoach Personas: `gateway/modules/features/commcoach/serviceCommcoachPersonas.py`
- Neutralisierung: `gateway/modules/features/neutralization/`
- Graph-Editor Nodes: `gateway/modules/features/graphicalEditor/nodeDefinitions/`
- Demo-Daten: `gateway/demoData/`
- UDM-Konzept: `c-work/0-ideas/unified-document-model.md`

## Abschluss

- [ ] Quell-Dokumente als "superseded by this document" markieren
- [ ] b-reference/ aktualisiert nach Umsetzung
- [ ] TOPICS.md aktualisiert
- [ ] Dieses Dokument → `1-plan/` verschieben wenn Umsetzung startet