Delivery Credential Preflight
Delivery-Credential-Preflight: 1 von 7 Zielsystemtypen voll konfiguriert, 0 teilweise, native Runner-Ziele 1, Versandfreigabe nicht aktiv.
Dieser Preflight zeigt nur Credential-Referenzen, Gate-Status und Betriebsnachweise. Er veröffentlicht keine Webhook-URLs, API-Keys, Tokens, E-Mail-Empfänger, Slack-/Teams-Ziel-URLs oder privaten Rohpayloads.
Delivery-Verantwortungs-Handoff
Delivery-Handoff für Betreiber, Receiver-Verantwortung und Security: Zielsysteme, Empfänger, Approval, HMAC, Dry-run und Claims werden no-secret getrennt.
Kanal, Eventtypen, Testempfänger, Zweck und Eskalationsfenster privat festlegen.
Abnahme: Scope nennt Zielsystemtyp, Rollenempfänger, Eventtypen, Testfenster und Rollback-Verantwortlichkeit. Grenze: Öffentlich erscheinen Rollen und Status, keine echten Empfänger oder Ziel-URLs.Webhook-, Slack-, Teams-, Jira-, SMTP- oder SendGrid-Refs nur in sicherer Server-Env oder Secret Manager setzen.
Abnahme: Preflight zeigt present/missing-Status; Public Exports enthalten keine Zielwerte. Grenze: Env-Template bleibt Placeholder; echte Werte dürfen nie committed oder publiziert werden.HMAC, Idempotency-Key, Body-SHA-256, Retry, Fehlercodes und Dedupe im Testreceiver prüfen.
Abnahme: Receiver akzeptiert signierte Testpayloads, dedupliziert Wiederholungen und liefert definierte Fehlerantworten. Grenze: Payload-Fixture beweist Vertrag, aber keine erfolgreiche Produktivzustellung.Alert-Dispatch-Dry-run und Readiness-Smoke ausführen, bevor Approval gesetzt wird.
Abnahme: sent_count=0, external_send_attempt_count=0, failed_check_count=0; erwartete Blocker bleiben sichtbar. Grenze: Dry-run ist keine Zustellung an Betreiberkanal.SAFERPAGE_ALERT_DISPATCH_APPROVED erst nach Receiver-, Empfänger-, Datenschutz- und Stop-Bedingungsfreigabe aktivieren.
Abnahme: Approval-Record nennt Scope, Testrefs, Smoke-Refs, Rollback-Verantwortlichkeit und Review-Ablauf. Grenze: Freigabestatus darf öffentlich sein; Personen, Empfänger und interne Nachweis-URLs bleiben privat.Ersten produktionsnahen Test mit begrenztem Scope ausführen und Runner-State, Zielsystem-Dedupe und Fehlerquote prüfen.
Abnahme: sent_count steigt nur für freigegebenen Scope; error_count=0; Dedupe und Pausepfad sind belegt. Grenze: Canary ist begrenzter Test, kein pauschales Support-Ziel- oder Alert-Versprechen.Webhook-/Slack-/Teams-/Jira-Ziel-URL
Nie öffentlich ausgeben; nur Zielsystemtyp und present/missing zeigen.HMAC-/Webhook-Secret
Nur Signaturalgorithmus und Headernamen zeigen.Empfänger-/Channel-Freigabe
Nur Rollen, Zweck und Freigabestatus zeigen.Dispatch-Approval-Record
Nur Status, Scope-Klasse, Evidence-Refs und Reviewdatum öffentlich.Privates Receiver-Testlog
Nur aggregierte Abnahme und Hash-/Request-ID-Referenzen zeigen.Rollback-/Pause-Verantwortlichkeit
Nur Rolle und Stop-Bedingungen öffentlich zeigen.Env-Referenzstatus
Preflight kann ready/missing zeigen, ohne Werte offenzulegen.Receiver-Vertrag
HMAC, Idempotency und Body-SHA-256 sind prüfbare Integrationsanforderungen.Dry-run-Zähler
No-Send-Guardrails sind messbar.Runner-Statuszähler
sent/error/outbox zeigen Betriebszustand ohne Zielsystemdetails.Stop-Bedingungen
Betreiber sehen, wann Versand pausiert werden muss.Approval-Status
Go-live-Gate ist nachvollziehbar, ohne Empfänger zu nennen.SaferPage-Evidence-URLs
Abnahme bleibt verlinkbar und maschinenlesbar.Webhook-, Slack-, Teams-, Jira-, SMTP- oder SendGrid-Ziel-URLs
API-Keys, Tokens, HMAC-Secrets, SMTP-Passwörter oder Authorization-Header
E-Mail-Adressen, Slack-Channels, Teams-Channel-IDs oder echte Empfängerlisten
Private Alert-Payloads, Rohpayloads, Kundendokumente oder interne Nachweispositionstexte
Zielsystem-Testlogs mit Personen, Hostnamen, internen URLs oder Request-Body
Secret-Manager-Pfade, Environment-Dateien mit echten Werten oder Shell-History
Betreiberentscheidung mit Personennamen, privaten Nachweis-URLs oder internen Kommentaren
Behauptung erfolgreicher Produktivzustellung ohne Approval, Receiver-Abnahme und Runner-Evidence
Delivery-Preflight zeigt blocked_gate_count > 0, solange Zielsystem oder Approval fehlt.
Alert-Delivery-Smoke zeigt dry_run_sent_count=0 und runner_sent_count=0 vor Approval.
Public Exports enthalten keine Webhook-/Slack-/Teams-URLs, Tokens, API-Keys oder Empfänger.
Receiver-Fixture enthält Idempotency-Key, Body-SHA-256 und HMAC-Vertrag.
Go-live-Center verlinkt Delivery-Phase, Rollback und Nachlaufbeobachtung.
Mindestens ein natives Zielsystem ist privat konfiguriert oder bewusst blockiert dokumentiert.
Receiver prüft Idempotency-Key und optional HMAC-Signatur.
Dry-run-Smoke bleibt ohne externe Sendung grün.
Dispatch-Approval ist erst nach Zielsystem-, Empfänger-, Datenschutz- und Security-Freigabe aktiv.
Public Evidence enthält keine Ziel-URLs, Tokens, Empfänger, Secrets oder Rohpayloads.
Runner-State nach Canary zeigt begrenzten Scope, keine Fehler und nachvollziehbare Dedupe-Referenz.
Produktclaims bleiben auf vorbereitet/no-secret belegbar begrenzt, bis echte Zustellung belegt ist.
Delivery-Signoff-Receipt
Maschinenlesbares Betreiber-Receipt für Delivery-Go-live: private Zielsystemdaten bleiben privat; öffentlich werden nur Status, Evidence-Refs, Hash-/Dedupe-Referenzen und Stop-Bedingungen.
receipt_id
scope_class
approved_at
event_types
receiver_contract_status
dry_run_smoke_url
runner_state_url
go_live_board_url
Keine Webhook-, Slack-, Teams-, Jira-, SMTP- oder SendGrid-Ziel-URL öffentlich.
Keine Tokens, API-Keys, HMAC-Secrets oder Authorization-Header öffentlich.
Keine E-Mail-Adressen, Channel-IDs oder Empfängerlisten öffentlich.
Keine privaten Payloads, Receiver-Testlogs oder internen Nachweispositionstexte öffentlich.
Keine Secret-Manager-Pfade oder Environment-Dateien mit echten Werten öffentlich.
Keine Behauptung erfolgreicher Produktivzustellung ohne Runner-Evidence.
Mindestens ein natives Zielsystem ist privat konfiguriert.
SAFERPAGE_ALERT_DISPATCH_APPROVED=yes wurde nach Betreiberfreigabe gesetzt.
Receiver-Vertrag ist mit Testpayload abgenommen.
Dry-run- und Readiness-Smoke sind ohne Fehler.
Rollback, Pause Policy und Nachlaufbeobachtung sind dokumentiert.
Konsolidierung
Diese Sicht trennt Delivery-Verträge und Dry-run-Evidence von echtem Betreiber-Versand. Das ist entscheidend für Wettbewerbsclaims zu automatischen Alerts.
8 Runtime-Controls, Receiver-Vertrag, Idempotency-Key und Body-SHA-256 sind öffentlich belegbar.
Grenze: Das ist ein Integrationsvertrag, keine echte Zustellung an Betreiberzielsysteme. Nächster Schritt: Receiver mit Testziel prüfen: HMAC, Idempotency, Dedupe, Retry und Fehlerantworten dokumentieren.dispatch_approved=no, runner_sent_count=0, native_ready_channel_count=1.
Grenze: Nicht behaupten: Betreiber erhalten produktive Alerts, solange SAFERPAGE_ALERT_DISPATCH_APPROVED nicht aktiv ist. Nächster Schritt: Betreiberfreigabe, Zielsystem, Empfänger, Datenschutz-/Security-Abnahme und Monitoring signieren; erst danach Approval setzen.1/7 Zielsystemtypen sind voll konfiguriert; 1 sind nativ durch den Runner sendbar.
Grenze: Öffentliche Evidence zeigt nur Env-Referenzen und Status; echte Webhook-URLs, Tokens, Channels und Empfänger bleiben privat. Nächster Schritt: Mindestens ein natives Ziel mit Testempfänger einrichten und Zielsystem-Dedupe gegen Idempotency-Key prüfen.Letzter Smoke: dry_run_sent=0, runner_sent=0, failed_checks=0.
Grenze: Smokes und Preflight senden nicht, setzen keine Secrets und prüfen keine privaten Zielsysteme. Nächster Schritt: Nach jeder Zielsystem- oder Runner-Änderung zuerst Dry-run-Smoke, dann Go-live-Center und Alerting-Digest prüfen.6/9 Delivery-Gates passed; 1 Blocker und 2 Warnungen bleiben sichtbar.
Grenze: Nicht behaupten: automatische Alerts, Support-Ziel-Eskalation oder Nachweispositions-Zustellung sind live, solange Zielsystem- und Approval-Gates offen sind. Nächster Schritt: Vergleichs- und Betreibertexte nur mit Claim-Grenzen ausgeben; blockierte Gates im Go-live-Board offen lassen.Claim-Grenzen
Diese Grenzen gelten für Kurzreports, Betreiberseiten, Vergleichsseiten und Integrationsunterlagen.
Nicht behaupten: Betreiber erhalten produktive Alerts.
Produktiver Versand braucht Zielsystem, Empfängerfreigabe, SAFERPAGE_ALERT_DISPATCH_APPROVED=yes, Receiver-Abnahme und Nachlaufkontrolle.Nicht behaupten: Webhook-URLs, Slack-/Teams-Ziele, E-Mail-Empfänger, Tokens oder API-Keys sind öffentliche Evidence.
Zielsystemdaten sind Secrets bzw. personenbezogene oder sicherheitsrelevante Betriebsdaten.Nicht behaupten: Dry-run beweist erfolgreiche Zustellung im Betreiberkanal.
Dry-run darf keine externen Sends, keine produktiven Sinks und keine privaten Zielsysteme auslösen.Nicht behaupten: Jedes Zielsystem ist automatisch kompatibel.
Zielsysteme müssen Signatur, Dedupe, Fehlercodes und Rate-Limits selbst validieren.Nicht behaupten: Support-Ziel-Eskalation ist produktiv garantiert.
Support-Ziel-Claims brauchen echten Versand, Monitoring, Fehlerbudget, Pausenpolicy und Betreiber-Nachlauf.Letzter Smoke-Lauf
No-Secret-Smoke für Alert-Delivery-Preflight, Dispatch-Runner, Runtime-Kontrollen, Delivery-Fixture, Operator-Go-live und isolierten Dry-run.
Dieser Smoke setzt keine Delivery-Secrets, konfiguriert keine Zielsysteme, versendet keine Alerts, schreibt keinen produktiven Sink und veröffentlicht keine Webhook-URLs, Tokens, Empfänger oder Rohpayloads.
Approval-Paket
Dieses Paket exportiert nur Env-Referenzen, Placeholder, Smoke-Kommandos und Abnahmekriterien; keine echten URLs, Tokens, Empfänger oder Payload-Rohdaten.
Finales Betreiber-Go-live-Gate; erst nach Dry-run, Empfänger- und Datenschutzfreigabe auf yes setzen.
Beispielwert: noGenerisches Betreiber-Webhook-Ziel.
Beispielwert: __SET_IN_SECRET_MANAGER_OR_SECURE_SERVER_ENV__HMAC-SHA256-Secret für generische Webhook-Payloads.
Beispielwert: __SET_IN_SECRET_MANAGER_OR_SECURE_SERVER_ENV__Slack Incoming Webhook für PrivacyOps-/Security-Alerts.
Beispielwert: __SET_IN_SECRET_MANAGER_OR_SECURE_SERVER_ENV__Microsoft Teams Incoming Webhook für Betreiber-Alerts.
Beispielwert: __SET_IN_SECRET_MANAGER_OR_SECURE_SERVER_ENV__Optionaler lokaler Audit-Sink für sanitisierte Zustellnachweise.
Beispielwert: /var/www/saferpage.de/runtime/alert_delivery_sink.jsonlscripts/run-alert-dispatch-dry-run-smoke.sh
python3 scripts/run-alert-dispatch.py anrufer.info --base-url http://127.0.0.1 --max 1 --timeout 15 --execute-ready
curl -fsS https://saferpage.de/alarme/anrufer.info/delivery-json
curl -fsS https://saferpage.de/alarme/dispatch-runner-json
Zielsysteme
Alle Angaben sind Referenznamen. Werte, URLs, Empfänger und Tokens werden nicht ausgegeben.
Interne, secretfreie Zustell-Evidence als JSONL schreiben, ohne externe Ziel-URL, Empfänger oder Payload-Rohdaten zu veröffentlichen.
Alerts, Nachweispositionen, Portfolio-Digests und Scan-Dispatches an eine eigene Orchestrierung senden.
PrivacyOps- und Security-Kanaele mit priorisierten Alerts, Verantwortlichkeiten und Support-Ziel-Kontext informieren.
Adaptive Cards für Betreiber-, Datenschutz- oder Security-Teams vorbereiten.
Nachweis- und Alert-Aufgaben mit External-ID, Labels, Prioritaet und Akzeptanzkriterien anlegen.
Portfolio-Digests und Eskalationen an Management, Datenschutz und Webbetrieb zustellen.
Wiederkehrende Portfolio-Digests über einen Mail-Provider ausliefern.
Readiness-Gates
SAFERPAGE_ALERT_DISPATCH_APPROVED ist nicht aktiv; Runner bleibt Dry-run/Outbox.
1 native(s) Zielsystem(e) sind voll konfiguriert: Webhook, Slack oder Teams.
Kein HMAC-Secret gesetzt; generische Webhooks können nicht signiert werden.
State alert_dispatch_runner_state.json ist lesbar; sent=0, deliverable=0, errors=50.
0 Outbox-Einträge im letzten Runner-State.
Dieser Preflight zeigt nur Env-Referenzen und present/missing-Status, keine Werte, Ziel-URLs, Empfänger, Tokens oder API-Keys.
8 Delivery-Runtime-Kontrolle(n) im Evidence-Manifest dokumentiert.
Delivery-Payloads und Runner-State nutzen Idempotency-Key, Body-SHA-256, Status und Stop-Bedingungen.
1 ready, 0 teilweise, 7 Zielsystemtypen im Preflight.
Runner-Snapshot
Runtime Controls
Diese Kontrollen beschreiben, wann der Runner senden darf und welche Receiver-Prüfung erwartet wird.
--execute-ready was passed, SAFERPAGE_ALERT_DISPATCH_APPROVED=yes and the channel target is configured
HMAC-SHA256 over the compact JSON request body, formatted as sha256=<hex>.
Explicit approval gate for productive alert delivery.
Generic operator webhook target.
HMAC-SHA256 signing secret for generic webhook deliveries.
Slack incoming webhook target.
Microsoft Teams incoming webhook target.
Optional override for sanitized local JSONL audit sink; default path is used when absent.
Aktivierung
Produktiver Versand wird erst aktiviert, wenn Testempfänger, Signatur, Dedupe und Betreiberfreigabe dokumentiert sind.
Diese Signale blockieren oder stoppen die produktive Zustellung.