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.4 KiB

Raw Blame History

Approvals

An approval is a deliberate human-in-the-loop checkpoint inside a flow. When a step needs a human decision before it proceeds, the flow pauses at that step until a reviewer approves or rejects it.

When to use one

Add an approval step before:

writing to a system of record (cases, contracts, mailings)
spending money (LLM tokens above a threshold, API quotas)
destructive actions (delete, archive, send)
anything the operator's compliance owner asked you to gate

The approval is a recorded event — every approval shows up in the audit log with the reviewer, decision, and reason.

How a flow declares one

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

  - id: review
    use: system.approval@^0
    with:
      title: "Review the classifier output"
      details: "$classify.response"
      reviewer: "$inputs.reviewer"
      timeout_seconds: 600

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

system.approval is a built-in capability — no module install needed. It blocks the flow's run until the matching approval record reaches a decision (approved / rejected) or the configured timeout_seconds elapses.

How an operator answers one

The Approvals page lists every pending approval. Click an entry, read the title + details, decide:

Approve — the flow resumes from this step with the approval's payload as the step output.
Reject — the flow fails at this step with the reviewer's reason; the audit log records the rejection.

Timeouts

If no decision arrives within timeout_seconds, the engine returns ApprovalTimedOut and the flow fails. Set a timeout that reflects how long a reviewer can realistically take.

What gets logged

Every approval write hits the audit log:

approval requested (with the title + details snapshot)
reviewer-decision recorded (with reason on reject)
payload + signature on accept

The hash chain catches tampering — an entry that was approved yesterday can't be quietly flipped to rejected today without breaking the chain.

Architecture trade-off

Approvals are stored alongside events in the SQLite audit DB. For higher-assurance deployments, mirror the audit DB to a WORM sink (Compliance Gap 3, option 2). The approval contract is the same either way — the WORM sink just makes the audit trail tamper-evident to outside reviewers, not just to the hub itself.

2.4 KiB Raw Blame History