flemming-it 28f6fe1a9a feat(approvals,runs): explain approvals in place + one-click hub update (0.81.0)

Approvals: the pending card now shows its full origin — flow, step,
run id (previously dropped at the Dart mapping layer), project, and
requested-at — under an ORIGIN heading, led by a one-line intro strip
that says what the inbox is and what Approve/Reject do. Approve/Reject
buttons carry tooltips; the history dialog gains project + run id.
Fixes the approvals doc drift (title/details/reviewer ->
prompt/show/timeout_seconds). Guard: approvals_origin_test renders the
card via the hermetic fake hub and pins every origin fact.

Runs: the "hub too old" state now leads with an in-place update button
(same `chain update apply` path as the Diagnose page), the Diagnose
deeplink demoted to secondary, with a CLI-absent fallback. Guard: two
new RunsLoadErrorView widget tests.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>

2026-07-26 15:50:41 +02:00

2.8 KiB

Raw Blame History

Freigaben

Eine Freigabe ist ein bewusster Human-in-the-Loop-Checkpoint innerhalb eines Flows. Wenn ein Step eine menschliche Entscheidung benötigt, pausiert der Flow an dieser Stelle, bis ein Reviewer freigibt oder ablehnt.

Wann nutzen?

Setze eine Freigabe vor:

Schreibzugriffe auf Bestandssysteme (Akten, Verträge, Versand)
Geldausgaben (LLM-Tokens jenseits einer Schwelle, API-Quotas)
destruktiven Aktionen (löschen, archivieren, senden)
alles, was dein Compliance-Verantwortlicher abgesichert sehen möchte

Die Freigabe ist ein protokolliertes Ereignis — jeder Freigabe-Vorgang landet im Audit-Log mit Reviewer, Entscheidung und Begründung. Das prompt ist der Satz, den der Reviewer sieht; show wählt die Daten, die ihm vorgelegt werden (der Output eines vorherigen Steps).

So deklariert ein Flow eine Freigabe

steps:
  - id: classify
    use: text.classify@^1

  - id: review
    use: system.approval@^0
    with:
      prompt: "Klassifikations-Output prüfen"
      show: "$classify.response"
      timeout_seconds: 600

  - id: write
    use: erp.write@^1
    with:
      record: "$review.payload"

system.approval ist eine eingebaute Capability — keine Modul-Installation nötig. Sie blockiert den Flow-Lauf, bis der zugehörige Freigabe-Eintrag eine decision erhält (freigegeben / abgelehnt) oder das konfigurierte timeout_seconds ausläuft.

So beantwortet der Operator eine Freigabe

Die Freigaben-Seite listet jede ausstehende Freigabe. Jede Karte zeigt ihre Herkunft (Flow, Step, Lauf, Projekt, Anforderungszeit), das prompt und die show-Daten. Lesen, dann entscheiden:

Freigeben — der Flow läuft ab diesem Step weiter, das payload der Freigabe wird zum Step-Output.
Ablehnen — der Flow scheitert an diesem Step mit der Begründung des Reviewers; die Ablehnung wird im Audit-Log protokolliert.

Timeouts

Wenn keine Entscheidung innerhalb timeout_seconds eintrifft, liefert die Engine ApprovalTimedOut und der Flow scheitert. Setze einen Timeout, der zeigt wie lange ein Reviewer realistisch brauchen darf.

Was protokolliert wird

Jeder Schreibvorgang einer Freigabe landet im Audit-Log:

Freigabe angefordert (mit Prompt + show-Daten-Snapshot)
Reviewer-Entscheidung aufgezeichnet (mit Begründung bei Ablehnung)
Payload + Signatur bei Freigabe

Die Hash-Chain fängt Manipulationen ab — ein gestern freigegebener Eintrag kann nicht heimlich heute auf "abgelehnt" gedreht werden, ohne die Kette zu brechen.

Architektur-Abwägung

Freigaben liegen in derselben SQLite-Audit-DB wie die Ereignisse. Für Deployments mit höherem Sicherheitsbedarf spiegelt man die Audit-DB auf eine WORM-Senke (Compliance-Gap 3, Option 2). Der Freigabe-Kontrakt bleibt gleich — die WORM-Senke macht den Audit-Trail nur tamper-evident gegenüber externen Prüfern, nicht nur für den Hub selbst.

2.8 KiB Raw Blame History