Migrationsplan: Workflow → Kaskaden

Zusammenfuehrung der zwei Ablauf-Systeme. Kaskaden bleiben als einziger Graph-Editor. Workflow-Features werden portiert, Workflow-Code wird entfernt.

Ausgangslage

System	Technik	LOC	Staerken	Schwaechen
Kaskaden	React Flow, Element-Registry, Player	3.631	Graph-Editor, Player, Chat-Linsen, Variablen, 12 Element-Typen	Kein Backend-Execution, keine Versionierung, keine Approvals
Workflow	Custom SVG, Backend State Machine	1.760 + 2.300 Konzepte	Backend-Execution, Versionierung, Approvals, SLA, Konzepte	Fragiler SVG-Editor, kein Player, keine Chat-Integration

Entscheidung: Kaskaden behalten, Workflow-Features integrieren, Workflow-Code entfernen.

---

Integrationspunkte des Workflow-Systems

Bevor wir Code loeschen, muessen alle Abhaengigkeiten umgezogen werden:

Integration	Wo	Was passiert	Migration
Konzept-Bausteine	baustein-intervention.tsx	Workflow-Template wird beim Aktivieren provisioniert, Runs angezeigt	→ Kaskaden-Board statt Workflow-Template
Konzept-Dokumentation	baustein-dokumentation.tsx	Report aus Workflow-Run generiert	→ Report aus FlowResult
Konzept-Seed	seed-templates.ts	defaultWorkflowGraphs pro Template	→ defaultCascadeBoards
Krisen-Szenarien	crisis-management	Optional workflowTemplateId auf CrisisScenario	→ cascadeBoardId (oder entfernen, n8n uebernimmt)
SSE-Events	workflow-events.ts	19 Event-Typen, genutzt in vielen Modulen	→ Event-System bleibt, wird von Workflow entkoppelt
App-Route	App.tsx	/workflow/:templateId → LazyWorkflowEditor	→ Entfernen, /kaskaden reicht
Sidebar	app-sidebar.tsx	hub_workflows Visibility-Key	→ Bleibt, zeigt Kaskaden
n8n Callbacks	n8n-callback.router.ts	Webhook fuer Workflow-Aktionen	→ Bleibt bei n8n/Krisen, unabhaengig

---

Migrations-Phasen

Phase 1: Kaskaden-Luecken schliessen (Features portieren)

Bevor Workflow entfernt werden kann, muessen Kaskaden diese Features haben:

1.1 Backend-Execution (~3-5 Tage)

Aktuell laeuft der Player nur im Browser. Fuer automatisierte Ablaeufe brauchen wir Server-seitige Ausfuehrung.

Was gebaut wird:

• CascadeRun Modell: boardId, status (running/waiting/completed/failed), activeColumnId, context (JSON), startedAt, completedAt
• Service: cascade-execution.service.ts — evaluiert Bedingungen server-seitig, navigiert durch den Graphen
• API: POST /cascade-boards/:id/runs (starten), GET /runs/:id (Status), POST /runs/:id/advance (weiter)
• Trigger: manuell, per Event (Chat-Nachricht), per Cron

Was sich aendert:

• Player kann weiterhin client-seitig laufen (wie bisher)
• ZUSAETZLICH: Server kann Flows ohne Browser ausfuehren
• FlowResult wird vom Server geschrieben, nicht nur vom Player

1.2 Versionierung (~1-2 Tage)

Was gebaut wird:

• version + status Felder auf CascadeBoard: draft → active → archived
• Beim Speichern: Version inkrementieren
• "Veroeffentlichen"-Button im Graph-Editor
• Nur active Boards im Player startbar

Datenmodell:

CascadeBoard += version Int @default(1), status String @default('draft')

1.3 Rollen-basierte Checkpoints (~2-3 Tage)

Was gebaut wird:

• Neuer Element-Typ checkpoint in der Element-Registry
• Config: assignedRole, requiredApprovals, dueAt
• Im Player: Checkpoint-Screen mit "Freigeben" / "Ablehnen"
• Im Backend: Checkpoint-Tabelle, analog zu WorkflowCheckpoint
• Multi-Approval: mehrere Personen muessen freigeben

1.4 Formular-Element (~2-3 Tage)

Was gebaut wird:

• Neuer Element-Typ form in der Element-Registry
• Designer: dynamischer Formular-Builder (Felder hinzufuegen: Text, Zahl, Datum, Auswahl, Datei, Unterschrift)
• Player: Formular ausfuellen, alle Felder werden als Variablen gespeichert
• Ersetzt die 12 Feld-Typen des Workflow-Formulars

Hinweis: Die bestehenden Elemente (Dropdown, Textfeld, Checklist) decken einfache Faelle ab. Das form-Element ist fuer komplexe Formulare mit Validierung.

1.5 Parallele Pfade (~2-3 Tage)

Was gebaut wird:

• Neuer Element-Typ parallel_split und parallel_join
• React Flow unterstuetzt mehrere ausgehende Kanten nativ
• Backend-Execution: activeColumnIds (Array statt einzelne ID)
• Player: zeigt parallele Pfade als Tabs oder nacheinander

1.6 SLA / Eskalation (~1-2 Tage)

Was gebaut wird:

• slaDeadline, slaWarningAt Felder auf CascadeRun
• Cron-Job: prueft ueberfaellige Runs, sendet Eskalations-Nachricht
• Im Designer: SLA-Einstellung pro Knoten (Warnung nach X Stunden, Eskalation nach Y Stunden)

1.7 Report-Generierung (~1-2 Tage)

Was gebaut wird:

• Template mit {variableName} Platzhaltern (Tiptap-Dokument)
• Service ersetzt Platzhalter aus FlowResult.variables
• Export als Markdown → DMS, oder als HTML → PDF (spaeter)
• Ersetzt den bestehenden ReportTemplate-Mechanismus

1.8 UX-Redesign: Element-Palette im Designer (~2-3 Tage)

Aktuell werden Elemente ueber ein kleines "+" im Knoten hinzugefuegt — versteckt, kleine Schrift, nicht intuitiv. Der Workflow-Editor hat eine permanente Palette links — das ist besser fuer Entdeckbarkeit.

Was gebaut wird:

• Designer-Palette am unteren Rand des Designer-Panels (klappbar)
• Elemente kategorisiert:
  • Eingabe: Entscheidung, Dropdown, Checkboxen, Optionsliste, Textfeld, Formular (neu)
  • Logik: If-Then-Else, Zeitstempel, Bedingung
  • Aktionen: Link, Space oeffnen, Space erstellen, Aufgaben erstellen, Button
  • Freigabe: Checkpoint (neu)
• Jede Kategorie mit Icon, Elemente mit Kurzbeschreibung
• Ein Klick fuegt das Element am Ende der Liste hinzu
• Drag aus der Palette in die Element-Liste (optional, spaeter)

Was sich aendert:

• Das "+" im Graph-Editor bleibt als Quick-Add (fuer erfahrene Nutzer)
• Der Designer bekommt die ausfuehrliche Palette (fuer neue Nutzer)
• Kategorien machen die 14+ Elemente uebersichtlich
• Konsistent mit dem UX-Pattern das Lehrer von anderen Tools kennen (Figma, n8n, Miro)

Gesamt Phase 1: ~3-4 Wochen

---

Phase 2: Konzepte umziehen (~3-5 Tage)

2.1 ConceptBaustein → Kaskaden

Aenderungen:

• ConceptBaustein.workflowTemplateId → ConceptBaustein.cascadeBoardId
• baustein-intervention.tsx: Workflow-Integration ersetzen durch Kaskaden-Integration
  • Statt WorkflowRun-Liste: FlowResult-Liste anzeigen
  • Statt Workflow-Editor-Link: Kaskaden-Board-Link
  • Statt Checkpoint-UI: Kaskaden-Player einbetten
• baustein-dokumentation.tsx: Report aus FlowResult statt WorkflowRun

2.2 Seed-Templates umschreiben

Aenderungen:

• seed-templates.ts: defaultWorkflowGraphs → defaultCascadeBoards
• Jeder Workflow-Graph wird als Kaskaden-Board mit Columns + Elements + Edges abgebildet
• 6 Templates betroffen (Kinderschutz, Gewaltpraevention, etc.)

2.3 Konzept-Aktivierung

Aenderungen:

• concept-orchestration.service.ts: statt WorkflowTemplate erstellen → CascadeBoard erstellen
• Board wird im Space des Konzepts erstellt
• Elements werden aus dem Seed-Template uebernommen

---

Phase 3: Events entkoppeln (~1 Tag)

Aenderungen:

• workflow-events.ts → prilog-events.ts (Rename)
• Event-Typen bleiben gleich (space.changed, contacts.changed, etc.)
• Workflow-spezifische Events (run.updated, checkpoint.created) → werden zu cascade-spezifischen Events
• SSE-Endpoint bleibt gleich (/platform/v1/workflow/events/stream → /platform/v1/events/stream)
• Frontend useWorkflowEvents → usePrilogEvents (Rename)

---

Phase 4: Aufraumen — Workflow entfernen (~2 Tage)

4.1 Frontend loeschen

Datei	Zeilen	Aktion
src/features/workflow/*.ts(x)	1.760	Loeschen
App.tsx: LazyWorkflowEditor	2	Entfernen
baustein-intervention.tsx: Workflow-Imports	~100	Bereits in Phase 2 ersetzt
baustein-dokumentation.tsx: Workflow-Events	~30	Bereits in Phase 2 ersetzt

4.2 Backend loeschen

Datei/Modul	Groesse	Aktion
src/modules/workflow-engine/	~90 KB (10 Dateien)	Loeschen
prilog-module.json (workflow)	-	Modul-Registrierung entfernen

4.3 Datenbank aufraumen

-- Daten archivieren (falls vorhanden)
CREATE TABLE _archive_workflow_templates AS SELECT * FROM workflow_templates;
CREATE TABLE _archive_workflow_runs AS SELECT * FROM workflow_runs;
-- ... weitere Tabellen

-- Tabellen loeschen (Migration)
DROP TABLE workflow_timeline_entries;
DROP TABLE workflow_approvals;
DROP TABLE workflow_checkpoints;
DROP TABLE workflow_form_responses;
DROP TABLE workflow_runs;
DROP TABLE workflow_templates;
DROP TABLE report_templates;

4.4 Referenzen bereinigen

• CrisisScenario.workflowTemplateId → entfernen oder auf cascadeBoardId umstellen
• ConceptBaustein.workflowTemplateId → bereits in Phase 2 auf cascadeBoardId umgestellt
• SSE-Endpoint URL aendern (oder alten Pfad als Alias behalten)

---

Phase 5: Polish + Dokumentation (~1 Tag)

• Handbuch aktualisieren: Kaskaden als einziges Ablauf-System
• Architektur-Doku: Workflow-Seiten entfernen oder als "Legacy" markieren
• Konzepte-Doku: Baustein-Intervention mit Kaskaden-Screenshots

---

Zeitplan

Phase	Inhalt	Aufwand	Abhaengigkeiten
1.1	Backend-Execution	3-5 Tage	Keine
1.2	Versionierung	1-2 Tage	Keine
1.3	Checkpoints	2-3 Tage	1.1 (Backend-Execution)
1.4	Formular-Element	2-3 Tage	Keine
1.5	Parallele Pfade	2-3 Tage	1.1 (Backend-Execution)
1.6	SLA/Eskalation	1-2 Tage	1.1 + 1.3
1.7	Report-Generierung	1-2 Tage	Variablen-System (bereits fertig)
1.8	UX: Element-Palette im Designer	2-3 Tage	Keine
2	Konzepte umziehen	3-5 Tage	Phase 1 komplett
3	Events entkoppeln	1 Tag	Phase 2
4	Workflow entfernen	2 Tage	Phase 3
5	Polish + Doku	1 Tag	Phase 4

Gesamt: ~5-6 Wochen (urspruengliche Schaetzung)

Status 27. April 2026: Phase 1-4 komplett in einer Session umgesetzt. Phase 5 (Doku) ebenfalls fertig. Der alte Workflow-Editor-Pfad /workflow/* redirected auf /kaskaden. Das Event-System hat Re-Export-Aliase unter core/events/. Der Workflow-Backend-Code bleibt vorerst als SSE-Host bestehen — wird in einem spaeteren Cleanup entfernt wenn alle Imports auf core/events/prilog-events.ts umgestellt sind.

---

Risiken

Risiko	Wahrscheinlichkeit	Auswirkung	Mitigation
Bestehende Workflow-Runs in Produktion	Niedrig (wahrscheinlich keine)	Datenverlust	Vor Phase 4: DB pruefen, archivieren
Konzept-Templates brechen	Mittel	Konzepte nicht aktivierbar	Phase 2 gruendlich testen
SSE-Events brechen	Niedrig	Echtzeit-Updates fehlen	Phase 3: schrittweise migrieren
n8n-Callbacks brechen	Niedrig	Krisen-Workflows stoppen	n8n ist unabhaengig vom Workflow-System
Kaskaden-Player reicht nicht	Niedrig	Features fehlen fuer Konzepte	Phase 1 schliesst die Luecken

---

Empfohlene Reihenfolge

1. Sofort starten mit Phase 1.8 (UX-Palette) + 1.2 (Versionierung) + 1.4 (Formular-Element) — keine Abhaengigkeiten, schnelle Ergebnisse, sichtbare Verbesserung
2. Dann 1.1 (Backend-Execution) — die Grundlage fuer Checkpoints, SLA, Parallele Pfade
3. Parallel 1.7 (Reports) — nutzt das fertige Variablen-System
4. Dann 1.3 (Checkpoints) + 1.5 (Parallele Pfade) + 1.6 (SLA)
5. Phase 2-5 am Stueck wenn Phase 1 komplett ist

Der Workflow-Code wird erst in Phase 4 geloescht — bis dahin laeuft er parallel weiter und nichts bricht.