PowerOn/wiki
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki/c-work/0-ideas/2026-06-CustomerCases-step3-features-plan.md

16 KiB
Raw Blame History

Plan: Features & Plattform-Bausteine — der Code hinter den Solutions

Baut auf: 2026-06-CustomerCases-step1-architecture.md (Schichten L1–L4, Feature-vs-Solution-Grenze). Schwester-Plan: 2026-06-CustomerCases-step3-solutions-plan.md (die konfigurierten Use Cases, die diesen Code konsumieren). Konsolidiert/ersetzt: Lawyer-Feature-Plan + die Code-/Plattform-Teile aus Umsystem-Integration und konsolidiertem Kundenwünsche-Plan.

Beschreibung und Kontext

Ein Feature ist Code: eigenes Datenmodell und/oder tiefe, opinionated UI / Domänenlogik, die ein Graph nicht ausdrücken kann (step1-architecture, Entscheidungsmatrix). Dazu zählen auch die Plattform-Bausteine, die die Solutions erst möglich machen — sie sind generischer Code (L1/L2/L3/L4), ohne Kundennamen.

Dieser Plan bündelt allen Code, der zu bauen ist, in zwei Teilen:

  • Teil A — Plattform-Enabler: die Solution-Schicht selbst (L3/L4), generische Workflow-Bausteine, Connectors, das «Datenquelle = Seite»-Muster. Voraussetzung für alle Solutions.
  • Teil B — Vertikale Code-Features: Module mit eigenem Datenmodell/UI (lawyer), bestehende Features (commcoach, trustee, neutralization) und ihre Erweiterungen.

Leitsatz (step1-architecture): Solution-first. Code bauen wir nur, wenn (a) es ein generischer Baustein ist, den viele Solutions teilen, oder (b) der Use Case nachweislich nicht als Solution trägt.

Fokus und kritische Details

  • Generisch, nie kundenspezifisch. Connectors = reine API-Adapter (Auth + Lesen/Schreiben + Mapping auf kanonische Modelle), keine Geschäftsregeln, keine Kundennamen. Kundenlogik lebt als Solution (Daten).
  • Eine Workflow-Wahrheit. Die Solution-Schicht ist eine dünne Erweiterung von AutoWorkflow + Settings-Record, keine Parallel-Welt → Scheduler/Runs/Versioning unverändert.
  • Source vs. Target ist die wichtigste neue Connector-Achse (macht aus dem Push-Framework ein bidirektionales Integrations-Framework).
  • RBAC strikt feature-instance-scoped, nicht mit Mandate-Rollen vermischen (.cursor/rules/rbac-role-separation.mdc).
  • Neutralisierung + Private LLM zwingend für jeden LLM-Pfad mit Personendaten (Trustee, Lawyer/Berufsgeheimnis StGB 321).
  • YAGNI bei Connector-Abstraktion: beim bestehenden BaseAccountingConnector bleiben und nur die Source-Rolle ergänzen; das generische «Capability-Mixin»-Framework erst ziehen, wenn die zweite Kategorie (Saläre) real wird.

Teil A — Plattform-Enabler (macht Solutions möglich)

A1 — Solution-Schicht (L3/L4)

  • AutoWorkflow erweitern um settingsSchema, outputBinding, customerFacing-Flag, Instanz-Set (Multi-Instanz-Fan-out). DB-Migration: ja (Greenfield, additiv).
  • Settings-Record-Modell (settingsValues pro Solution/Instanz; Secrets verschlüsselt wie Connector-Configs).
  • settingsSchema automatisch ableiten aus trigger.form + als «exposed» markierten Node-Params (kuratierte Overrides später).
  • Solution-Routes (dünn über bestehende Editor-/Run-Routes): CRUD Settings, Test-Run, Activate/Deactivate.
  • SolutionsView (ui-nyla): generische «Lösungen»-Seite pro Feature — Liste · Katalog/Neu · Detail mit Tabs (Einstellungen · Testlauf · Läufe · Ausgabe). Settings-Formular aus settingsSchema (FrontendType-getrieben). Registriert wie andere Views (FeatureView.tsx + UI-Areas in main<Feature>.py).
  • Use-Case-Katalog als System-Templates (interfaces/interfaceBootstrap.py).
  • AI: Use Case → Workflow über bestehenden Workflow-Agent (Toolbox workflow), Draft + Review vor Aktivierung.
  • Output-Renderer für outputBinding.kind = file (Datenraum/TrusteeDocument), table (FormGenerator/Data-Tables), summary (AutoRun/AutoStepLog). dashboard später (AI-Report/Canvas-Pipeline).

A2 — Generische Workflow-Bausteine (Nodes/Actions)

Baustein Zweck Status
rbac.queryUsersByRole rollenbasierte Empfänger-Auflösung (Verteiler aus Feature-Rollen statt Listen) neu
Trigger-accessControl.requiredRoles (in triggerExecutor) nur erlaubte Rolle darf manuell auslösen neu
run-level testMode Testlauf real, Kommunikations-/Seiteneffekt-Nodes (Mail/Outlook/Teams/Webhook) unterdrücken Versand (loggen «würde senden …») neu
integration.fetchFromSource / integration.mapAccounts / integration.pushToTarget system-agnostischer Source→Target-Import (Quelle/Ziel = Config) neu
data.consolidate (sumByKey) Aggregation mehrerer Instanzen (Pling Holding-Konsolidierung) prüfen/ggf. neu
data.writeToTable / Tabellen-Output Ergebnistabellen (PWG-Übersicht) prüfen/ggf. neu
trigger.event / DB-Change-Detection ereignisgetriggerte Solutions (Notification) neu (Roadmap)

Alle erscheinen über den Editor-Adapter (graphicalEditor/nodeDefinitions/) als Bausteine.

A3 — Connectors (L1, generische API-Adapter)

  • SelectLine-Connector (Quelle): accountingConnectorSelectline.py, implementiert BaseAccountingConnector, Auto-Discovery via accountingRegistry.py. Methoden: testConnection, getChartOfAccounts, getCustomers/getVendors, Lese-Seite für Belege (getOutgoingInvoices, Default [] in Base). Config: baseUrl, username, password (secret), optional mandant.
  • TrusteeAccountingConfig.role (source | target) → mehrere Connector-Configs pro Instanz (eine Quelle + ein Ziel); getActiveConfig/_resolveConnectorAndConfig um role filtern. Optional connectorCategory (accounting | payroll | invoicing). DB-Migration: ja.
  • Kanonisches Invoice-Modell prüfen/ergänzen (falls RMA als AR-Rechnung statt GL-Buchung).
  • Source-Pfad in accountingBridge.py additiv (Push-Pfad unverändert).
  • Roadmap-Connectors (generisch, je 1 Datei + Config): Xero (1.1.11), FileMaker (PWG 1.9.10), Kassensystem/Gastro (1.6, wartet auf Input), Lohn/Swissdec (4.2), Bank-Statement-Import (4.1.2). Je neuer Connector schaltet neue Solutions frei, ohne Architekturänderung.

A4 — «Datenquelle = Seite» (generische Connector-UI)

  • TrusteeAccountingSettingsView → generische IntegrationSettingsView (category-Prop): Verbindungen (Connector + Rolle Quelle/Ziel + Credentials + Test), Datenfluss/Import, Daten-Spiegel.
  • Neue UI-Areas in mainTrustee.py (z. B. ui.feature.trustee.payroll) + Mapping in FeatureView.tsx → gleiche Komponente, andere category.
  • «Buchhaltungssystem» existiert; «Saläre»/«Fakturierung» als Folge-Kategorien (Platzhalter, nicht erste Umsetzung).

Teil B — Vertikale Code-Features

B1 — lawyer (Mandatsvorbereitung + Dashboards) — NEU

Echtes Feature (eigene Modelle + opinionated UI), das die Plattform-Bausteine bündelt; konsumiert die Solution-Schicht (Matter-Prep/Dashboard-Refresh als interne Solutions/Actions).

  • Datenmodell (datamodelLawyer.py): LawyerMatter, LawyerPreparation, LawyerDashboardSnapshot, LawyerKpi, LawyerSourceMap. Migration: ja.
  • Feature-Modul mainLawyer.py + Template-Rollen lawyer-admin / lawyer-user / lawyer-viewer (feature-instance-scoped).
  • Actions (methodLawyer/): lawyer.prepareMatter, lawyer.refreshDashboard, lawyer.queryData.
  • UI (ui-nyla/src/components/Lawyer/): Dashboard-View (Tabs HR/Business/IT/Finance) + Matter-Preparation-View (opinionated, analog Workspace).
  • Connectors: DMS (SharePoint vorhanden, iManage neu?), E-Mail (Outlook/Exchange), KYC/AML, Konflikt-Check — als generische L1-Bausteine (Teil A3-Muster).
  • Neutralisierung zwingend (Berufsgeheimnis); Sprache UI primär Englisch (WW/Investor).
  • Demo-Asset: synthetic Matter M-DEMO-001 für WW-Präsentation (statisches Briefing-JSON, Backend-frei).

Begründung Feature statt Solution: eigene Datenmodelle (LawyerMatter…), tiefe opinionated UI (Matter-Preparation), Domänenlogik. Dashboards/Matter-Prep dürfen intern Solutions/Actions nutzen — das Feature ist der opinionated Rahmen.

B2 — commcoach (bestehend)

  • Feature komplett (10+ Personas inkl. 4 PWG-Immobilien-Personas, Gamification, Seeding). Erweiterungen: kundenspezifische Persona-Sets als Daten (z. B. PWG-Knowledge-Set). Kein Neubau.

B3 — trustee (Core, bestehend) — Erweiterungen

  • Engine + Accounting-Bridge + Pipeline (extractFromFiles/processDocuments/syncToAccounting) + Connectors (RMA/Bexio/Abacus) bestehen.
  • Erweiterungen als Bausteine (nicht als Kundenlogik): Firmen-/Lieferanten-Mapping-UI (1.1.4), Buchungsregeln-Engine (1.1.6), Vorsteuer-Automatik (1.1.7), Bank-Statement-Matching (4.1).
  • Migration: Analyse-Prompt-Templates (Budget/KPI/Cashflow/Prognose/Jahresabschluss) aus mainTrustee.py → kuratierte Solution-Templates (→ solutions-plan S5). Trustee bleibt Daten-/Connector-Heimat, die Analysen werden Solutions.

B4 — Plattform-Features (bestehend, Querschnitt)

  • neutralization (PII-Masking, Private-LLM, Compliance-Audit) — vorhanden; pro Solution/Feature nur konfigurieren.
  • Knowledge/RAG, Billing, Multi-Tenancy, Workspace — vorhanden.
  • UI/UX-Härtung (aus altem Kundenplan Teil 2, plattformweit, nicht Solution/Feature-spezifisch): Empty-State, DE-Placeholder/i18n, Zwischen-Breakpoint 1025–1280px, Trust-Strip, Billing-Discovery, Connector-Onboarding-Copy. → separate UX-Charge, hier nur referenziert.

Feature-vs-Solution — Recap (Entscheidungsmatrix)

Kriterium → Solution (Daten) → Feature (Code)
Eigenes Datenmodell? nein ja (LawyerMatter)
Tiefe opinionated UI? nein ja (Matter-Preparation)
Aus Bausteinen komponierbar? ja nein (Domänenlogik)
Beispiel SelectLine→RMA, Pling, PWG, Analysen lawyer, commcoach, trustee-Core

Betroffene Module

  • Gateway (platform-core):
    • features/graphicalEditor/ — AutoWorkflow-Erweiterung + Settings-Record + Solution-Routes (A1). Migration: ja.
    • workflows/methods/ + graphicalEditor/nodeDefinitions/ — generische Nodes (A2).
    • workflows/.../triggerExecutor — accessControl.requiredRoles + testMode (A2).
    • features/trustee/accounting/connectors/accountingConnectorSelectline.py (neu), accountingConnectorBase.py (Source-Methode), accountingBridge.py (Source-Pfad), datamodelFeatureTrustee.py (role [+ connectorCategory]) — Migration: ja (A3).
    • features/lawyer/ (neu, B1) — mainLawyer.py, datamodelLawyer.py, methodLawyer/, Routes. Migration: ja.
    • interfaces/interfaceBootstrap.py — Use-Case-Katalog/System-Templates (A1).
    • serviceCenter/services/serviceAgent/ (Toolbox workflow) — Use-Case→Graph (A1).
  • Frontend (ui-nyla):
    • SolutionsView (A1), IntegrationSettingsView (A4), Lawyer/-Komponenten (B1), FeatureView.tsx-Registry + UI-Areas.
  • DB-Migration: ja (Solution-Schicht, TrusteeAccountingConfig.role, Lawyer-Modelle).
  • Andere: RBAC (neue UI-Areas, bestehende Feature-Rollen), Neutralisierung, Billing (Run-/Sync-Volumen).

Entscheidungen

Datum Entscheidung Begründung
2026-06-04 Plattform-Bausteine + Solution-Schicht als generischer Code, nie kundenspezifisch macht alle Solutions möglich, hält «kein Kunden-Code» real
2026-06-04 Connectors = reine Adapter; source/target-Rolle als neue Achse bidirektionales Integrations-Framework, additive Erweiterung
2026-06-04 lawyer bleibt Feature (eigene Modelle + opinionated UI), nutzt Solution-Schicht intern Entscheidungsmatrix; Domänenlogik nicht als Graph abbildbar
2026-06-04 Trustee-Analyse-Prompt-Templates → Solution-Templates migrieren kundentauglich machen; Trustee bleibt Daten-/Connector-Heimat
2026-06-04 Connector-Abstraktion erst bei zweiter Kategorie (Saläre) generalisieren YAGNI

Umsetzungs-Checkliste

Teil A (Enabler, zuerst):

  • AutoWorkflow-Erweiterung (settingsSchema/outputBinding/customerFacing/Instanz-Set) + Settings-Record + Migration
  • Solution-Routes (CRUD/Test/Activate) + SolutionsView + Settings-Formular-Renderer
  • Output-Renderer file/table/summary
  • rbac.queryUsersByRole, Trigger-accessControl, run-level testMode
  • Integration-Nodes fetchFromSource/mapAccounts/pushToTarget + Editor-Adapter
  • data.consolidate / data.writeToTable prüfen/ergänzen
  • SelectLine-Connector + TrusteeAccountingConfig.role (+ optional connectorCategory) + Migration
  • kanonisches Invoice-Modell prüfen; Source-Pfad in accountingBridge (additiv)
  • IntegrationSettingsView (category) generalisieren
  • Use-Case-Katalog/System-Templates + Workflow-Agent-Pfad

Teil B (Features):

  • lawyer: Datenmodell (5 Modelle) + mainLawyer.py + 3 Actions + UI (Dashboard/Matter-Prep) + RBAC + Neutralisierung + Demo-Asset
  • trustee: Analyse-Templates → Solution-Templates; optional Mapping-UI/Buchungsregeln/Vorsteuer/Bank-Matching
  • commcoach: kundenspezifische Persona-/Knowledge-Sets als Daten
  • Roadmap-Connectors nach Bedarf (Xero, FileMaker, Lohn, Kassensystem, Bank-Import)

Akzeptanzkriterien

# Kriterium (Given-When-Then) Prio
1 Given ein neues Umsystem, When ein Connector-File + Config ergänzt wird, Then ohne Änderung an Registry/Bridge/Editor verfügbar must
2 Given testMode, When eine Solution testweise läuft, Then erzeugt sie Artefakte, sendet aber keine Kommunikation must
3 Given rbac.queryUsersByRole, When mit Rollen-Set aufgerufen, Then dedupliziert die korrekten Empfänger (Pling-Verteiler) must
4 Given Anwalt mit lawyer-user, When Matter-Preparation getriggert, Then strukturiertes Briefing in <90s, PII vor LLM neutralisiert must
5 Given Mandate-Rolle ohne lawyer-*, When Lawyer-Feature geöffnet, Then Access Denied must
6 Given Solution-Schicht, When ein Kunde Settings ändert, Then ohne Code-Deploy wirksam must

Offene Fragen

  1. Solution-Daten-Heimat: AutoWorkflow-Erweiterung (empfohlen) — Settings-Record als eigenes Modell oder JSON-Feld?
  2. outputBinding-Schema: Artefakt-Referenz (Run-Output-Key vs. Document-Query); table-Spalten aus Node-Output ableiten?
  3. SelectLine: on-prem-Erreichbarkeit (VPN/Tunnel/Agent); Zielart RMA (AR vs. GL).
  4. Lawyer-Connectors: iManage/KYC/Konflikt-Check-APIs — welche mandantenspezifisch, welche generisch?
  5. Connector-Generalisierung: wann Capability-Mixins (AccountingCapable/PayrollCapable) ziehen?

Links

  • Architektur: c-work/0-ideas/2026-06-CustomerCases-step1-architecture.md
  • Solutions: c-work/0-ideas/2026-06-CustomerCases-step3-solutions-plan.md
  • Bausteine: b-reference/platform-core/workflow.md, b-reference/platform-core/automation.md, b-reference/platform-core/features/trustee.md
  • RBAC/Neutralisierung: b-reference/platform/rbac.md, b-reference/platform/neutralization.md, .cursor/rules/rbac-role-separation.mdc
  • Lawyer-Kontext (WW): pamocreate/projects/poweron/customer-walderwyss/
  • Code: platform-core/modules/features/trustee/accounting/ (Bridge/Base/Registry/Connectors), features/graphicalEditor/

Abschluss

  • Bei Annahme → Build in c-work/2-build/ (Teil A vor Teil B)
  • b-reference/ Kanon-Seiten: «Solutions / Customer Workflows», features/lawyer.md, Trustee «Source-Connectors»
  • TOPICS.md + _CHANGELOG.md pro Phase