konzept vertraulich owner: matus

Aufgaben-Lebenszyklus im Prozess-Cockpit — bewusst nicht gebaut

Status: ausgespart (2026-08-15), keine Lücke · Art: Scope-Entscheidung, kein Versäumnis · Priorität: keine — es gibt hier nichts zu bedienen · Auslösebedingung: siehe unten

Dieses Dokument gehört zum Wiederanschluss des Prozess-Cockpits (process-hub-wiederanschluss.md, am 2026-08-15 umgesetzt). Es hält fest, was dabei nicht mitgemacht wurde, damit die Auslassung eine Entscheidung bleibt und nicht als vergessener Rest gelesen wird.

Was fehlt

@zwirn/bpmn bringt sechs Seiten mit. Vier sind gemountet (Modul-/Cockpit-Übersicht, Definitions-Detail mit BPMN-Diagramm, Prozessliste, Instanz-Detail). Zwei sind es nicht: ProcessTasksPage (Aufgabenliste) und TaskDetailPage (Aufgaben-Detail mit Claim / Complete / Unclaim).

Technisch ist das ein Filter über das Routen-Array, das createProcessHubRoutes(config) liefert (tuxametrics-ui/src/App.tsx). Eine feinere Schnittstelle bietet das Paket nicht — config kennt nur taskBasePath, um die Aufgaben-Routen zu verschieben, nicht um sie wegzulassen. Das ist keine Schwäche des Pakets: für seine bisherigen Konsumenten sind die Seiten der Hauptzweck.

Warum nicht

1. Es gibt keinen Vertrag, gegen den man bauen könnte.

Der Aufgaben-Lebenszyklus ist in dev.zwirn:zwirn-process-api gar nicht enthalten: ProcessObservationPort hat keine Task-Methoden, ZwirnProcessApiProperties kennt keinen Task-Capability-Schlüssel, und zwirn-process-hub-router-spring routet folgerichtig nichts dergleichen (dessen pom.xml sagt das ausdrücklich, ADR-0042 dort grenzt es ab). Der Name des Ports ist ehrlich: Observation, nicht Steuerung.

Was @zwirn/bpmn unter /{tenantKey}/tasks erwartet, ist deshalb heute das bespoke Muster eines Produkts (dot-process-hub, GG-ARCH-PROCESS-0003) — produktspezifisch und nie generalisiert. Es hier nachzubauen hieße, aus einer einzigen fremden Implementierung einen Vertrag zu raten. Genau diese Reihenfolge hat Zwirn mit ADR-0018 → ADR-0019 schon einmal zurücknehmen müssen.

2. Es wird hier nie eine Aufgabe geben.

tuxametrics-process-hub-cockpit läuft mit async-executor-activate: false, und kein Code dieses Repos ruft runtimeService.startProcessInstance*. Es gibt eine deployte Prozessdefinition und null Instanzen; ohne Instanz keine User Task. Die zwei Seiten wären nicht „leer, aber korrekt" — sie wären ein Menüpunkt, der eine Fähigkeit behauptet, die das Produkt nicht hat. Dieselbe Haltung, mit der am 2026-08-13 die anderen Seiten abgehängt wurden: eine Route, die garantiert ins Leere läuft, ist schlechter als eine Route, die es nicht gibt.

3. Der Gold Path läuft nicht über die Engine.

Patient → Befund → Auswertung → Empfehlung → Freigabe ist ein linearer REST-Ablauf über tuxametrics-laborauswertung-service. Das BPMN-Modell dokumentiert ihn, es treibt ihn nicht. Eine Aufgabenliste im Cockpit würde eine zweite, konkurrierende Arbeitsvorrat-Oberfläche neben den fachlichen Seiten aufmachen — für dieselben Schritte, aber ohne deren fachlichen Kontext.

4. Und der Punkt, der schwerer wiegt als die drei anderen zusammen: GM-7.

„Aufgabe abschließen" ist im Gold Path nicht neutral. Die Schritte, die eine Prozess-Engine als User Task modellieren würde, sind unter anderem Therapeutenentscheidung, informierte Übersteuerung und ärztliche Freigabe — also exakt die drei Capabilities, die dauerhaft allowedActors=[USER] tragen und nie an einen AGENT grantbar sind (tuxametrics-platform-service/util/Gm7Schutz, ADR-0005). Ein generischer „Aufgabe abschließen"-Knopf im Cockpit wäre ein zweiter Weg an diesen Schritten vorbei, mit einer generischen Capability davor statt der fachlich richtigen. Das ist keine UI-Frage. Wer den Aufgaben-Lebenszyklus hier baut, muss zuerst beantworten, wie sich der generische Task-Schlüssel zur GM-7-Kette verhält — und diese Antwort gehört in ein ADR, nicht in einen Commit.

Was stattdessen da ist

Die Aufgabenhistorie einer Instanz (GET .../process-instances/{id}/tasks) ist Teil des Vertrags, ist gemountet und wird auf der Instanz-Detailseite als Reiter angezeigt. Sie ist reine Anzeige: wer wann welche Aufgabe hatte und wann sie endete. Das ist die Beobachtung, um die es geht — nicht die Steuerung. Nicht mit /{tenantKey}/tasks verwechseln; ProzessHubKontextTest hält beide Aussagen (die eine Route existiert, die andere nicht) als Test fest.

Auslösebedingung

Gebaut wird das erst, wenn beides zutrifft — nicht eines von beiden:

Zwirn generalisiert den Task-Vertrag. Konkret: ProcessObservationPort (oder ein neuer ProcessTaskPort) bekommt claim/complete/unclaim, ZwirnProcessApiProperties bekommt die zugehörigen Capability-Schlüssel, und der Router routet sie. Das ist eine Zwirn-Entscheidung mit ADR-Charakter und braucht dort einen zweiten Beleg — heute gibt es genau eine Implementierung (dot-process-hub).
tuxametrics startet tatsächlich Prozessinstanzen. Also: async-executor-activate: true, ein Auslöser, der startProcessInstance* ruft, und eine beantwortete Frage „soll die Engine den Gold Path treiben, statt ihn nur zu zeigen?" — die ist bis heute nicht gestellt worden, geschweige denn entschieden (audit-feedback-processhub-integration.md).

Kommt (1) ohne (2), gibt es einen Vertrag ohne Daten. Kommt (2) ohne (1), ist der richtige nächste Schritt nicht das Cockpit, sondern die GM-7-Frage aus Punkt 4 oben.