ValueOn AG c3e1eb74e8 customer cases soluttion architecture

2026-06-04 23:20:41 +02:00

30 KiB

Raw Blame History

Architektur: Vom Kundenbedürfnis zur Lösung — generische Workflow-/Solution-Schicht

Ebene: App-/Plattform-Architektur (eine Stufe über den Feature-/Connector-Plänen). Frage, die wir lösen: Wie erfüllt PORTA jedes wiederkehrende Kundenbedürfnis ohne kundenspezifischen Code — als konfigurierte Komposition vorhandener Bausteine?

Vision: Konfigurierte Use Cases statt geschriebener Applikationen

Der eigentliche Paradigmenwechsel hinter diesem Plan:

Klassische Software ist von gestern. Bisher löst man ein Geschäftsproblem, indem jemand eine Applikation schreibt — pro Problem, pro Kunde, in Wochen/Monaten. Die Software ist das Asset; jede Anpassung kostet Engineering.

Wir drehen das um: wir konfigurieren komplexe Use Cases, statt Applikationen zu schreiben. Genau das, was eine AI heute schon tut, wenn sie assistiert: Du beschreibst eine Absicht, das System komponiert vorhandene Fähigkeiten (Tools, Daten, Logik) zu einem Ergebnis — niemand baut dafür eine App. Diese Architektur ist dieses Prinzip, produktisiert:

AI-Assistenz (heute, z. B. Cursor)	PORTA Solution-Schicht
Du beschreibst die Absicht	Business-User beschreibt den Use Case (L4)
AI plant die Schritte	Workflow-Agent komponiert den Graph (L2/L3)
AI nutzt Tools (lesen, schreiben, ausführen)	Graph nutzt Actions/Connectors (L1)
Ergebnis: einmalig, im Chat	Ergebnis: dauerhaft — konfiguriert, geplant, governt, mandantenfähig, dem Kunden gehörend

Was das für Kunden bedeutet — «next level»:

Massgeschneidert ohne Massanzug-Kosten: der exakte Fall (Plings 5 Stores, ihre Konten-Ranges) ohne bespoke Entwicklung.
Tage statt Monate, Self-Service statt Vendor-Backlog.
Grenzkosten eines neuen Use Cases → nahe null: Konfiguration, nicht Code.

Zu Ende gedacht (ehrlich, kein Hype):

Es verschwindet nicht alle Software. Die Bausteine (Connectors, Actions, Engine) und einige tiefe Features (eigenes Datenmodell/UI, z. B. lawyer) bleiben klassisch geschriebene Software. Der Wechsel passiert in der Mitte: die vielen massgeschneiderten Einzellösungen, die man bisher pro Kunde gebaut hat, werden zu Konfiguration. Engineering wandert nach unten (haltbare, wiederverwendbare Primitive) und nach oben (AI-gestützte Konfiguration) — und verschwindet aus der teuren Mitte. Das ist exakt die Feature-vs-Solution-Grenze.
Vertrauen ist Voraussetzung, kein Nachgedanke. Wenn AI/Konfiguration komponiert, braucht es Leitplanken — typisierte Actions, Neutralisierung, Review-vor-Aktivierung, Testlauf ohne Versand. Im Treuhand-/Finanzkontext ist das Pflicht. PORTA hat diese Leitplanken bereits — das macht «konfigurieren statt coden» hier seriös möglich.
Der Moat ist nicht ein einzelnes Feature, sondern die Toolbox + Kompositions-Engine + die AI, die Absicht → Komposition übersetzt.

In einem Satz: PORTA verkauft künftig nicht «eine App», sondern die Fähigkeit, jeden wiederkehrenden Geschäfts-Use-Case zu konfigurieren — der konfigurierte Use Case ist das Asset, nicht der handgeschriebene Code.

Beschreibung und Kontext

Viele Kunden (v. a. im Feature Trustee) haben dasselbe Grundmuster an Bedürfnissen. Die Kern-Logik:

Ein Kunde hat kein «Workflow-Problem», sondern ein Bedürfnis. Dieses Bedürfnis lässt sich als Use Case formulieren, daraus wird — AI-gestützt — ein Workflow aus vorhandenen Bausteinen komponiert, einmal konfiguriert, getriggert (manuell oder per Zeitplan) und dessen Ergebnis angesehen. Drumherum braucht es eine Verwaltung, mit der ein Business-User genau das selbst tut — ohne dass wir pro Kunde Code schreiben.

Konkrete Bedürfnisse, immer dieselbe Logik:

Zwei Systeme synchronisieren, einmal einstellen, täglich um 06:00 via Scheduler (Solution S1, → 0-ideas/2026-06-CustomerCases-step3-solutions-plan.md).
Monatsreporting über mehrere Buchhaltungen (Pling «Kaffee-Klatsch»): am 15. des Monats aus 5 RMA-Buchhaltungen konsolidieren, 6 PDF-Reports erzeugen, rollenbasiert per Mail verteilen (Solution S2, → 0-ideas/2026-06-CustomerCases-step3-solutions-plan.md; Spec: pamocreate/projects/poweron/customer-pling/20-spezifikation/20260522-workflow-spec-kaffee-klatsch.md + Anhang).
Gescannte Jahresmietzinsbestätigungen verarbeiten + Antwortvorschläge (PWG-Pilot, Solution S3, → 0-ideas/2026-06-CustomerCases-step3-solutions-plan.md).
Mandatsvorbereitung + Dashboards (Feature, → 0-ideas/2026-06-CustomerCases-step3-features-plan.md, B1).

Beobachtung: Alle vier Beispiele sind Instanzen desselben Musters: ein Bedürfnis wird durch eine Komposition vorhandener Bausteine (Connectors, Actions/Nodes, AI, Neutralisierung, Dashboards) erfüllt — nicht durch neuen, kundenspezifischen Code. Die Bausteine existieren bereits (Action Library, Graphical Editor, Scheduler, Templates, Connectors, Toolbox). Was fehlt, ist die Schicht darüber: eine generische, kundentaugliche Oberfläche, mit der ein Business-User (kein Techniker) eigene Workflows anlegen lässt (AI), konfiguriert, testet, ausführt, ansieht und verwaltet.

Business-Treiber:

Skaliert ohne Engineering pro Kunde/Workflow (das eigentliche Plattform-Versprechen).
Verwandelt jedes Kunden-«Bedürfnis» in ein Self-Service-Produkt → kürzeres Onboarding, höhere Marge.
Macht die bereits gebauten Bausteine endlich für Endkunden zugänglich (heute nur über den technischen Editor).

Fokus und kritische Details

Das Problem ist NICHT «noch ein Feature», sondern eine fehlende Produkt-Schicht. Wir bauen kein viertes Buchhaltungs-Detail, sondern die generische Lifecycle-Verwaltung für kundeneigene Workflows.
Trennung Baustein ↔ Kundenlogik ist Plattform-Gesetz (gilt schon für Connectors): Bausteine = Code; konkrete Kundenlösung = Daten (Graph + Settings + Trigger + Output-Bindung).
«Settings in den Notes» ist die falsche Abkürzung. Einstellungen in Freitext-Notes abzulegen ist verlockend, aber ein Hack. Architektonisch braucht es ein strukturiertes, validiertes Settings-Modell pro Workflow (typisiert, versioniert).
Feature vs. Solution — die wichtigste Grenze. Nicht jedes Bedürfnis rechtfertigt ein Code-Feature (wie lawyer). Default ist eine konfigurierte Solution (Template + Settings). Ein Code-Feature nur, wenn eigene Datenmodelle / tiefe opinionated UI / Domänenlogik nötig sind, die der Graph nicht ausdrücken kann (siehe Entscheidungstabelle).
Zwei Personas, zwei Oberflächen: Der Graphical Editor bleibt das technische Authoring-Tool (n8n-Stil). Neu kommt eine Business-Oberfläche (Lösungen verwalten), die den Graph kapselt. Sie ist die Antwort auf «wo stelle ich meine Sachen ein?».
Fragile/relevante Stellen: AutoWorkflow/AutoVersion/AutoRun (Greenfield-DB poweron_graphicaleditor), Scheduler (mainScheduler.py), Template-Scopes (user|instance|mandate|system), Action-Catalog (/api/automation2/catalog), Workflow-Agent-Toolbox (workflow-Tools: addNode, bindNodeParameter, …). Wir bauen auf diesen, nicht daneben.

Ziel und Nicht-Ziele

Ziel: Ein generisches Solution-Konzept definieren: «konfigurierte, getriggerte, kundentaugliche Verpackung eines Workflows», mit Settings-Schema, Trigger-Policy und Output-/Dashboard-Bindung — als Daten pro Feature-Instanz.
Ziel: Eine kundenseitige Verwaltungs-Oberfläche (Lifecycle: anlegen → konfigurieren → testen → aktivieren → ausführen → ansehen → verwalten), zuerst im Feature Trustee, dann feature-übergreifend wiederverwendbar.
Ziel: AI-gestützte Erzeugung «Use Case → Workflow» über den bestehenden Workflow-Agent.
Ziel: Ein Use-Case-Katalog (kuratierte System-Templates) als Startpunkt für die häufigsten Bedürfnisse.
Ziel: Architektur so, dass die vier Beispiele sauber als Spezialfälle abbildbar sind (Validierung unten).
Explizit NICHT: kundenspezifischer Code pro Workflow.
Explizit NICHT: den Graphical Editor ersetzen — wir kapseln ihn.
Explizit NICHT: Settings in Notes/Freitext.
Explizit NICHT (jetzt): Marktplatz/Sharing zwischen Mandanten, Billing-Redesign — später.

Das wiederkehrende Muster (Kern der Architektur)

Jedes Kundenbedürfnis hat dieselbe Form:

BEDÜRFNIS  ──(als Use Case formuliert)──►  WORKFLOW (Komposition von Bausteinen)
                                              │
        ┌───────────────┬───────────────┬────┴────────┬──────────────┐
     SETTINGS        TRIGGER          DATENQUELLEN     AI/LOGIK     OUTPUT/VIEW
   (einmal einst.)  (manuell/Zeit/   (Connectors;     (Nodes/      (Dashboard/
                     Event/Form)      eigener Plan)    Agent)        Report/Mail/Tabelle)

Beispiele auf dieselbe Form gebracht:

Bedürfnis	Trigger	Bausteine (Nodes)	Settings	Output
2 Systeme synchronisieren	`trigger.schedule` 06:00	source-connector → `mapAccounts` → target-connector	Quelle/Ziel, Mapping	Sync-Log/Status
Monatsreporting 5 Buchhaltungen (Pling)	`trigger.schedule` 15./06:00 + `trigger.manual` (rollen-beschränkt)	`loop`(5 Instanzen) → `refreshAccountingData` → `queryData`(Salden akt.+VJ) → `data.consolidate` → `ai.generateDocument`×6 → `rbac.queryUsersByRole` → `outlook.send` → `file.create`	Perioden, Konten-Ranges, Empfänger-Rollen, Cron, Branding	6 PDFs + Mails + Lauf-Protokoll
Mietzinsbestätigungen (PWG)	`trigger.schedule`	`sharepoint.listFiles` → `loop` → `extractFromFiles` → `ai.prompt` → `data.write` → `email.send`	Ordner, Abacus-Mandant, Empfänger	Übersichtstabelle + Mail
Matter Preparation (Lawyer)	`trigger.manual/form`	`lawyer.prepareMatter` (Agent über Quellen)	Lookback, Quellen	Briefing + Dashboards

→ 90 % des Kundenwerts ist Komposition, nicht Code. Die Bausteine sind da. Die Verpackung + Verwaltung fehlt.

Was der Pling-Fall zusätzlich schärft

Der Pling-«Kaffee-Klatsch»-Fall (vollständig spezifiziert inkl. Graph, Configs, Build-Items) zeigt zwei Verfeinerungen, die das Schema bestätigen statt es zu brechen:

Eine Solution kann über mehrere Feature-Instanzen fan-out-en. Ein Mandant hat hier 5 Trustee-Instanzen (1 pro Store); die Solution läuft per flow.loop über alle. → Solution-Scope ist nicht zwingend «1 Instanz», sondern «ein Set von Instanzen eines Mandanten». Das Settings-Modell muss eine Instanz-Auswahl tragen.
Die «Kundenspezifika» sind durchweg Daten — die Lücken sind generische Bausteine. Was Pling besonders macht (5 Stores, Konten-Ranges 3000–3999/6000–6299/5000–5099, Empfänger, Cron), ist Settings. Was im Code fehlt, sind zwei generische Plattform-Bausteine, kein Kunden-Code:
- rbac.queryUsersByRole — rollenbasierte Empfänger-Auflösung (Verteiler aus Trustee-Rollen statt gepflegter Listen). Wiederverwendbar für jedes Report-/Notification-Bedürfnis.
- Trigger-Zugriffskontrolle (accessControl.requiredRoles im triggerExecutor) — damit nur z. B. trustee-admin den manuellen Lauf auslösen darf.
Genau diese Trennung ist die Architektur-These: Kundenspezifika → Settings/Graph (Daten); was fehlt → generische L1/L2-Bausteine.

Weitere wiederverwendbare Muster aus dem Fall: Konsolidierung mehrerer Instanzen (data.consolidate sumByKey), selektive Neutralisierung (nur Namen/Beschreibungen pseudonymisiert, Zahlen/Konten lesbar), Teil-Resultat-Toleranz (unvollständige Buchhaltung → durchlaufen mit Markierung, steuerbar per Settings-Flag stopOnIncomplete), Archivierung der Outputs als TrusteeDocument.

Schichten-Modell (Zielarchitektur)

┌───────────────────────────────────────────────────────────────────────────┐
│ L4  SOLUTION SURFACE  (kundentaugliche UX, pro Feature-Seite)        NEU    │
│     «Lösungen»: Katalog · Anlegen(AI) · Settings · Test · Runs · View       │
├───────────────────────────────────────────────────────────────────────────┤
│ L3  SOLUTION DEFINITION  (Use Case → konfigurierter Workflow)       NEU     │
│     Solution = Template/Version + Settings-Schema + Trigger-Policy + Output  │
│     Use-Case-Katalog · AI-Generierung · strukturierte Settings (kein Notes) │
├───────────────────────────────────────────────────────────────────────────┤
│ L2  COMPOSITION  (Graph)                                          VORHANDEN  │
│     AutoWorkflow/Version/Run · Graphical Editor · Templates (scopes)         │
├───────────────────────────────────────────────────────────────────────────┤
│ L1  PLATTFORM-TOOLBOX (Bausteine)                                VORHANDEN  │
│     Connectors/Datenquellen · Action Library (Methods/Actions=Nodes) ·       │
│     AI/Agent+Toolbox · Neutralisierung · Knowledge/RAG · Scheduler ·         │
│     Dashboards-Primitive · RBAC · Multi-Tenancy                              │
└───────────────────────────────────────────────────────────────────────────┘

L1/L2 existieren (siehe b-reference/platform-core/workflow.md, automation.md). L3/L4 sind neu und der eigentliche Gegenstand dieses Dokuments.

L3 — Solution Definition (das neue Kern-Konzept)

Eine Solution ist die kundentaugliche Verpackung eines Workflows:

Bestandteil	Inhalt	Baut auf
Workflow-Bindung	Referenz auf `AutoWorkflow` + `PUBLISHED` `AutoVersion`	vorhanden
Settings-Schema	typisierte, validierte Parameter, die der Kunde einstellen darf (z. B. «SharePoint-Ordner», «Empfänger», «Periode», «Konten-Mapping»)	`FrontendType`/Typed-Action-System, `trigger.form`-Schema
Settings-Werte	konkrete Belegung pro Solution (inkl. Instanz-Auswahl bei Multi-Instanz-Fan-out, z. B. Pling 5 Stores)	neu (Record)
Trigger-Policy	manuell / Zeitplan / Event / Form, inkl. Zugriffskontrolle (welche Rolle darf manuell auslösen)	Scheduler + Trigger-Nodes (+ `accessControl`)
Output-/View-Bindung	was der Kunde nach dem Lauf sieht — `kind: file \| table \| summary` (Dashboard später); siehe «Output-Bindung — Empfehlung»	`file.create`/Datenraum, FormGenerator/Data-Tables, `AutoRun`/`AutoStepLog`
Katalog-Herkunft	aus Use-Case-Template instanziiert ODER per AI generiert	System-Templates + Workflow-Agent

Designentscheidung (bestätigt 2026-06-04): Solution nicht als grosse neue Parallel-Welt bauen, sondern als dünne Erweiterung auf AutoWorkflow (Settings-Schema + Presentation-Binding + «is customer-facing»-Flag) plus einen Settings-Record. Das hält eine einzige Workflow-Wahrheit (Scheduler, Runs, Versioning greifen unverändert).

Settings statt Notes: Das Settings-Schema wird aus dem Graphen abgeleitet (Trigger-Form / als «exposed» markierte Node-Parameter) und/oder kuratiert. Validierung + Verschlüsselung (für Secrets) wie bei Connector-Configs. Das ist die saubere, wartbare Alternative zu Einstellungen in Freitext-Notes.

L4 — Solution Surface (kundentaugliche UX)

Eine Seite pro Feature (Start: Trustee), Name «Lösungen», mit dem Lifecycle:

[Katalog/Neu]                [Meine Lösungen]              [Detail einer Lösung]
 ├─ Use-Case wählen           ├─ Liste (aktiv/inaktiv)      ├─ Settings (Formular)
 ├─ oder beschreiben (AI)     ├─ Status letzter Lauf        ├─ Test / Probelauf
 └─ → erzeugt Workflow        ├─ nächster geplanter Lauf    ├─ Aktivieren + Zeitplan
                              └─ Run-Historie               ├─ Run-Trace (lesbar)
                                                            ├─ Output/Dashboard
                                                            └─ «Im Editor öffnen» (Advanced)

UI-Struktur (Antwort auf Frage 1): Eine Seite «Lösungen» pro Feature — kein Seiten-Wildwuchs und keine Aufblähung der technischen Automation-UI. Diese eine Seite hat Unteransichten (Liste · Katalog/Neu · Detail) und das Detail hat Tabs: Einstellungen · Testlauf · Läufe · Ausgabe.
Business-User bleibt in L4; «Im Editor öffnen» ist die Escape-Hatch nach L2 für Power-User/uns.
Wiederverwendung: Run-Historie/Trace existiert (AutoRun/AutoStepLog, SSE runs/{runId}/stream); wir rendern es nur kundentauglich statt technisch.
Verknüpfung zum Datenquellen-Plan: «Datenquellen» (Connectors) ist eine Schwester-Seite; «Lösungen» nutzt die dort konfigurierten Quellen.

AI: Use Case → Workflow

Der bestehende Workflow-Agent (Toolbox workflow: readWorkflowGraph, addNode, bindNodeParameter, listUpstreamPaths, …) ist bereits der Mechanismus, um aus einer Beschreibung einen Graphen zu bauen/ändern. L3 stellt ihm:

den Use-Case-Text des Kunden,
den Action-Catalog (verfügbare Bausteine, /api/automation2/catalog),
die konfigurierten Datenquellen der Instanz, bereit und lässt ihn einen Graphen erzeugen → als Draft-Version speichern → der Kunde konfiguriert nur noch die Settings. Kuratierte System-Templates decken die häufigsten Fälle deterministisch ab (kein AI-Risiko); AI nur für Neues/Abweichendes, mit Review-/Freigabe-Schritt vor Aktivierung.

Feature vs. Solution — die Architektur-Entscheidung

Kriterium	→ Solution (Daten/Config)	→ Feature (Code)
Eigene Datenmodelle nötig?	nein (nutzt bestehende)	ja (z. B. `LawyerMatter`)
Tiefe, opinionated UI?	nein (generische Solution-UX)	ja (z. B. Matter-Preparation-View)
Aus Bausteinen komponierbar?	ja	nein (Domänenlogik)
Time-to-value	Tage	Wochen
Beispiel	SelectLine→RMA-Sync, Monatsbericht, PWG-Pilot	`lawyer`, `commcoach`, `trustee` selbst

Leitsatz: Solution-first. Ein Code-Feature wird nur gebaut, wenn die Solution-Schicht es nachweislich nicht trägt. So bleibt die Plattform schlank und die «keine Kundenlogik im Code»-Regel real.

Validierung an den Beispielen

Beispiel	Abbildung in dieser Architektur
Umsystem-Integration (SelectLine→RMA)	L1: SelectLine/RMA-Connectors · L2: Import-Graph · L3: Solution «Systeme synchronisieren» (Settings: Quelle/Ziel/Mapping/Zeitplan) · L4: erscheint unter «Lösungen» neben «Datenquellen»
Pling Kaffee-Klatsch (Monatsreporting)	L1: 5× RMA-Connector, Outlook, `data.consolidate`, `ai.generateDocument` · L2: Fan-out-Graph (`loop` über 5 Instanzen, Konsolidierung, 2 Report-Loops, Verteilung) · L3: Solution mit Settings (5 Instanzen, Konten-Ranges, Cron, Empfänger-Rollen, `stopOnIncomplete`) + Output (6 PDFs, archiviert) · L4: «Jetzt ausführen» (rollen-beschränkt), Run-Historie, Status. Deckt 2 generische Bausteinlücken auf (`rbac.queryUsersByRole`, Trigger-`accessControl`) — kein Kunden-Code.
PWG-Pilot (Mietzinsbestätigungen)	L1: SharePoint/Abacus/Email/extract/ai · L2: 7-Schritt-Graph · L3: Solution mit Settings (Ordner, Mandant, Empfänger) + Output-Tabelle · L4: Test/Aktivieren/Run-Historie
Lawyer-Feature	Mischfall: Feature (eigene Modelle + opinionated UI) plus Solutions darin (Matter-Prep, Dashboard-Refresh). Bestätigt die Feature-vs-Solution-Grenze.

→ Alle vier passen ohne Architektur-Bruch. Das Muster trägt. Der Pling-Fall ist der stärkste Beleg: vollständig spezifiziert, ~2 Wochen Build, fast ausschliesslich vorhandene Bausteine — und die einzigen Code-Lücken sind generisch, nicht kundenspezifisch.

Betroffene Module (Skizze)

Gateway:
- features/graphicalEditor/ — AutoWorkflow um Settings-Schema + Presentation-Binding + customerFacing-Flag erweitern; Settings-Record-Modell. DB-Migration: ja (Greenfield, additiv).
- workflows/scheduler/mainScheduler.py — unverändert nutzbar (Trigger-Policy mappt auf bestehende Schedule-Logik).
- interfaces/interfaceBootstrap.py — Use-Case-Katalog als System-Templates.
- serviceCenter/services/serviceAgent/ (Toolbox workflow) — Use-Case→Graph-Generierung; ggf. Prompt/Guardrails ergänzen.
- Solution-Routes (CRUD Settings, Test-Run, Activate) — dünn über bestehende Editor-/Run-Routes.
- Generische Bausteine aus dem Pling-Fall (wiederverwendbar, kein Kunden-Code): neue Action rbac.queryUsersByRole (rollenbasierte Empfänger-Auflösung) und triggerExecutor-Erweiterung um accessControl.requiredRoles (Rollen-Check beim manuellen Trigger).
- Testlauf-Modus: run-level testMode im Run-Context; kommunikations-/seiteneffekt-Actions (Mail/Outlook/Teams/Webhook) prüfen das Flag und unterdrücken den ausgehenden Versand (loggen «würde senden an …»). Reports/Dateien werden trotzdem erzeugt (siehe Frage 7).
- Solution-Scope: Settings müssen ein Set von Feature-Instanzen referenzieren können (Multi-Instanz-Fan-out, z. B. 5 Stores).
Frontend (ui-nyla):
- Neue generische SolutionsView (Katalog · Liste · Detail mit Settings-Formular · Test · Runs · Output), als Feature-Seite registriert (analog FeatureView.tsx VIEW_COMPONENTS + UI-Areas in main<Feature>.py).
- Settings-Formular-Renderer aus dem Settings-Schema (FrontendType-getrieben).
DB-Migration: ja (additiv auf Greenfield-DB).
Andere: RBAC (neue UI-Area, customer-facing Rollen), Neutralisierung (unverändert über Services), Billing (Run-Volumen).

Entscheidungen (Vorschläge — zu bestätigen)

Datum	Entscheidung	Begründung
2026-06-04	Neue Solution-Schicht (L3/L4) statt neues Feature pro Bedürfnis	Skaliert ohne Code pro Kunde
2026-06-04	Solution = dünne Erweiterung von `AutoWorkflow` + Settings-Record (keine Parallel-Welt)	Eine Workflow-Wahrheit; Scheduler/Runs/Versioning unverändert
2026-06-04	Strukturierte Settings statt Notes	Validierbar, versioniert, sicher (Secrets)
2026-06-04	Solution-first, Feature nur bei eigenem Datenmodell/Tiefe	«keine Kundenlogik im Code» real halten
2026-06-04	Start im Feature Trustee, Schicht aber feature-übergreifend designen	breiteste Wiederverwendung
2026-06-04	Solution-Scope = Set von Feature-Instanzen (nicht nur eine)	Pling-Fan-out (5 Stores) bricht sonst das Modell
2026-06-04	Rollenbasierte Verteilung als generischer Baustein (`rbac.queryUsersByRole`)	aus Pling abgeleitet, wiederverwendbar für jedes Report-/Notification-Bedürfnis
2026-06-04	UI = eine «Lösungen»-Seite pro Feature mit Unteransichten (Liste/Detail) + Tabs im Detail	kein Seiten-Wildwuchs; Technik-UI bleibt unangetastet (Frage 1)
2026-06-04	Settings-Schema automatisch abgeleitet (aus `trigger.form`/exposed Params)	minimaler Pflegeaufwand; Overrides später (Frage 2)
2026-06-04	AI-Generierung ja — Templates deterministisch, AI nur für Neues + Review vor Aktivierung	Geschwindigkeit ohne Kontrollverlust (Frage 3)
2026-06-04	RBAC: bestehende Feature-Rollen nutzen, keine neuen customer-facing Rollen	weniger Komplexität; konsistent zu Feature (Frage 5)
2026-06-04	Naming: «Lösungen» (engl. Solutions)	bestätigt (Frage 6)
2026-06-04	Testlauf = realer Lauf mit `testMode` (Kommunikation unterdrückt, Artefakte erzeugt)	echtes Verhalten testen, ohne ungewollte Mails (Frage 7)
2026-06-04	Output-Bindung gestuft (`file`/`table`/`summary` jetzt, `dashboard` später)	nutzt Vorhandenes; keine BI-Engine bauen (Frage 4 — Detail offen)

Beantwortete Fragen (Entscheid 2026-06-04)

Daten-Heimat: ✅ AutoWorkflow erweitern (kein eigenes Solution-Modell). UI-Konsequenz (deine Frage): Die Backend-Erweiterung berührt die technische Automation-UI (Graphical Editor / Ops) nicht — es entstehen nicht «viele Automation-Seiten». Stattdessen eine neue kundentaugliche Seite «Lösungen» pro Feature, die denselben AutoWorkflow nur anders präsentiert. Aufbau: Liste (aktiv/inaktiv, letzter/nächster Lauf) · Katalog/Neu (Vorlage oder AI) · Detail mit Tabs (Einstellungen · Testlauf · Läufe · Ausgabe). Also: eine Seite pro Feature, Unteransichten + Tabs im Detail — siehe Mockup.
Settings-Schema-Quelle: ✅ Automatisch abgeleitet aus trigger.form + als «exposed» markierten Node-Parametern. (Kuratierte Overrides bei Bedarf später.)
AI-Generierung: ✅ Ja. Katalog-Templates deterministisch; AI nur für Neues, mit Review-/Freigabe-Schritt vor Aktivierung.
Output/Dashboard: ⚠️ Richtung entschieden, Detail offen — Empfehlung im nächsten Abschnitt.
RBAC: ✅ Bestehende Feature-Rollen (z. B. trustee-admin anlegen/aktivieren/manuell starten; trustee-* ansehen). Keine neuen customer-facing Rollen.
Naming: ✅ «Lösungen» (engl. Solutions).
Test/Probelauf: ✅ Realer Lauf, Kommunikation blockierbar. Der Testlauf läuft echt (echte Daten/Bausteine), nur ausgehende Kommunikation wird unterdrückt via run-level testMode: Mail/Outlook/Teams/Webhook-Actions prüfen das Flag und senden nicht (loggen «würde senden an …»). Reports/Dateien entstehen trotzdem. Sauberer als ein vollständig isolierter Mock-Run.

Output-Bindung — Empfehlung (Frage 4)

Der schwierigste Punkt, weil «Output» von «PDF im Mail-Anhang» bis «interaktives Dashboard» reicht. Empfehlung: gestuft, kleinster tragfähiger Kern zuerst — keine generische Dashboard-Engine bauen. Eine Solution deklariert eine outputBinding mit einem kind:

`kind`	Was der Kunde sieht	Baut auf (vorhanden)	deckt ab
`file`	Liste erzeugter Dokumente (PDF/XLSX), Öffnen/Download	`file.create` → `TrusteeDocument` / Datenraum	Pling, SelectLine-Log
`table`	Ergebnis-Tabelle (sortier-/filterbar)	FormGenerator / Data-Tables (`queryData`)	PWG-Übersicht
`summary`	Status/Kennzahlen + Lauf-Protokoll	`AutoRun`/`AutoStepLog` (Run-Trace)	jeder Sync/Lauf
`none`	nur Lauf-Status	—	reine Mail-Workflows

Jetzt bauen: file, table, summary — alle nutzen Vorhandenes, kein neuer Renderer-Stack. Deckt alle vier Cases ab.
Später: Rich-Dashboards über die bestehende AI-Report-/Canvas-Pipeline wiederverwenden (kind: dashboard), nicht neu erfinden.
Abgrenzung (wichtig): Braucht ein Kunde eine tiefe, opinionated Dashboard-UI, ist das das Signal für ein Feature (Code), nicht für eine Solution. Die Output-Bindung bleibt bewusst schlank — sie zeigt Ergebnisse, sie ist keine BI-Engine.
Detail beim Bauen (offen): genaues outputBinding-Schema (wie referenzieren wir das Artefakt — Run-Output-Key vs. Document-Query) und ob table-Spalten frei konfigurierbar sind oder aus dem Node-Output abgeleitet werden. Vorschlag: aus Node-Output ableiten (konsistent zu Frage 2).

Meine Gedanken / Empfehlung

Das ist kein Feature, das ist die Produktisierung der Plattform. Bisher ist PORTA ein Werkzeugkasten mit zwei Enden (technischer Editor + Ops-Dashboard). Die fehlende Mitte — eine kundentaugliche Solution-Schicht — ist der Hebel, der aus «wir bauen pro Kunde» ein skalierendes SaaS macht.
Nichts Neues erfinden, verpacken. Alle Bausteine (Graph, Templates, Scheduler, Agent, Connectors) sind da. Der Aufwand liegt in L3 (Settings/Trigger/Output als Daten) und L4 (eine gute, einfache UX) — nicht in neuer Engine.
Die wichtigste Disziplin ist die Feature-vs-Solution-Grenze. Ohne sie bauen wir wieder pro Kunde ein Feature (siehe die Klassifikationstabelle im CustomerCases-step3-solutions-plan). Mit ihr wird der Default «konfigurieren statt coden».
Settings strukturieren, nicht in Notes. Das ist die kleine Entscheidung mit grosser Wirkung: sie macht Solutions wartbar, sicher und versionierbar.
Pling als idealer erster realer Beleg. Der Fall ist bereits voll spezifiziert (~2 Wochen Build) und braucht nur zwei generische Ergänzungen (rbac.queryUsersByRole, Trigger-accessControl). Er beweist die These am konkreten Geld-Use-Case und liefert nebenbei wiederverwendbare Bausteine.
Inkrementeller erster Schnitt: (1) AutoWorkflow um Settings-Schema + customerFacing + Instanz-Set erweitern; (2) 1–2 kuratierte System-Templates (z. B. «Systeme synchronisieren» und «Periodisches Reporting» aus Pling); (3) minimale SolutionsView (Liste + Settings + Test + Aktivieren + Run-Historie) im Trustee. Damit ist das Muster end-to-end belegt — demonstrierbar am SelectLine→RMA- und am Pling-Fall.
Verhältnis zu den anderen Plänen: Der Umsystem-/Datenquellen-Plan liefert L1-Connectors; dieser Plan liefert L3/L4. Lawyer ist ein Feature, das L1–L4 konsumiert. Drei Pläne, eine Architektur.

Abschluss

Offene Fragen beantwortet (Entscheid 2026-06-04); Detail Output-Bindung beim Bauen
Bei Annahme → Plan-Dokument in c-work/1-plan/ (erster Schnitt, Trustee)
b-reference/ Kanon-Seite «Solutions / Customer Workflows» nach Umsetzung
TOPICS.md Eintrag

30 KiB Raw Blame History Unescape Escape