Security / Security check (push) Failing after 1s

Details

feat(studio): localise Settings sidebar + add inline help docs + Approvals doc

Three operator-UX gaps closed:

  - Settings dialog's six-category sidebar (General / Appearance /
    System AI / Integrations / Security / Maintenance) was
    hardcoded English; now flows through AppLocalizations
    ("Allgemein" / "Darstellung" / "System-KI" / "Integrationen" /
    "Sicherheit" / "Wartung"). Same for the per-panel title +
    description.
  - Per-channel daemon-action labels ('enable autostart' /
    'disable autostart' / 'daemon restart' etc.) and the
    OK / Failed result line in the toast also moved to l10n,
    so the system-action feedback reads as one language.
  - New 'Approvals' doc bundle (en + de) under assets/docs/,
    registered as a fifth doc card on Welcome plus exposed via
    the new public  helper. The
    Approvals, Audit and Doctor app-bars grow a Help icon button
    next to Refresh that opens the matching doc in the existing
    bottom-sheet reader — no extra screen, no learning curve.

Studio bumped to 0.67.0; editor path-override pulls in 0.20.1
(flow-list row polish).

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

2026-06-09 01:57:46 +02:00

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

So deklariert ein Flow eine Freigabe

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.

2.7 KiB Raw Blame History