28f6fe1a9a
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>
91 lines
2.8 KiB
Markdown
91 lines
2.8 KiB
Markdown
# 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
|
|
|
|
```yaml
|
|
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.
|