# 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.

## So deklariert ein Flow eine Freigabe

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

  - id: review
    use: system.approval@^0
    with:
      title: "Klassifikations-Output prüfen"
      details: "$classify.response"
      reviewer: "$inputs.reviewer"
      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. Klick
auf einen Eintrag, Titel + Details lesen, 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 Titel + Details-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.