Projektstand

Version: 0.1.0-alpha.5 Datum: 2026-09-15

Fertig in diesem Snapshot

Outbox, Mail, weitere Provider und Betrieb (alpha.5)

SQLite-Outbox mit atomarer Annahme, expliziter Deduplizierung, Lease-Recovery und Retry/Backoff.
Pro Ziel gespeicherter Versandauftrag einschließlich ursprünglicher Live-/Dry-Run-Einstellung.
SMTP-Ausgang mit TLS/STARTTLS, IMAP-Eingang mit UID-/UIDVALIDITY-Checkpoint und MIME-Text.
ntfy- und Gotify-Ausgänge sowie signierter Discord-Slash-Command-Eingang.
WebUI für neue Provider, Mail-/Discord-Eingänge, Historie und manuelle Wiederholung.
Readiness, geschützte Prometheus-Zustandsmetriken und graceful Shutdown.
bcrypt mit Legacy-Migration, CSRF/Origin-Prüfung, CSP, Login- und Body-Limits, env:-Secrets.
Betrieb, Konfiguration und Grenzen dokumentiert in OPERATIONS.md.
API-Änderung: HTTP-Eingänge liefern 202 nach Speicherung; Versandstatus steht in der Historie.

Provider-Erweiterung (2026-09-15, auf Basis alpha.4)

Benannte Discord-/HTTP-Webhook-Ausgänge mit Live-Opt-in, Timeout und optionalem Bearer-Token.
Neuer WebUI-Bereich Ausgänge, Zuordnung pro Regel und Vorschau für beide Provider.
Unabhängige Zustellung über mehrere Regeln mit Einzelergebnissen bei Teilfehlern.
Discord-Mentions deaktiviert, Längenlimit geprüft; HTTP-Redirects blockiert und neue Transportfehler ohne URL-/Token-Leaks.
Regression behoben: identische Regex für mehrere Felder werden jeweils ausgewertet.
Ausbauplan für Outbox, Mail und weitere Ein-/Ausgänge: PROVIDER_PLAN.md.

Bisheriger Funktionsumfang

Go-Server mit persistentem JSON-Store und Admin-Authentifizierung
neue formularbasierte WebUI statt JSON-Texteditor
getrennte Bereiche für Divera247, Eingänge, Zuordnungen und Server/Sicherheit
Divera247-Zugang mit Accesskey, UCR, Timeout und Dry-Run konfigurierbar
Divera247 pull/all aus der WebUI; lesende Aufrufe bleiben auch im Dry-Run möglich
Personenabruf primär über v2 pull/all aus data.cluster.consumer; numerische Collection-Keys werden als UCR-IDs verwendet
robuster v2-Fallback: numerische cluster.consumer-Schlüssel werden als UCR-ID erhalten und nicht mit globalen User-IDs verwechselt
automatische Aufbereitung geladener Stammdaten für Einheiten, Gruppen, Personen und Fahrzeuge
Mehrfacheinheiten werden über data.ucr erkannt und parallel mit begrenzter Konkurrenz über v2 pull/all?ucr=... geladen
visueller Regel-Editor für Quelle/Kanal/Titel/Meldung/Priorität
Divera247-Stichwort, Meldung, Adresse, Zieltyp und Versandwege als Formularfelder
einheitsübergreifende Alarmierung mit Empfängerart Alle/Gruppen/Personen pro Einheit
durchsuchbare Auswahl von Gruppen, Personen und Fahrzeugen mit manueller ID als Fallback
Vorschau einer Testmeldung auf das resultierende Divera247-Payload ohne Versand
Browser-Konfigurations-API liefert weder Admin-Passwort-Hash noch Session-Secret aus
ntfy-Ingress: Text, JSON, GET-Trigger und Aliase
Gotify-Ingress: POST /message
generischer Webhook-Ingress
Bearer/Basic/Token-Authentifizierung für Ingress
Divera247 v2 Client für Alarm/News/Event CRUD und Zusatzfunktionen sowie Pull
Dry-Run, Dockerfile, Compose, Makefile und Linux-amd64-Build

Geprüft

Alpha.5:

go test ./..., go vet ./..., UI-Syntaxprüfung und Linux-amd64-Build ohne CGO erfolgreich.
Unit-/Integrationstests für Outbox-Neustart, parallele Deduplizierung, Lease-Recovery und selektive Wiederholung.
Lokale SMTP-Server: TLS/STARTTLS, fehlendes STARTTLS, Zertifikatsfehler, temporäre/permanente Fehler und MIME.
Lokaler IMAP-Server: neue Nachrichten, Checkpoints, erneuter Abruf nach simuliertem Absturz, fehlende Zuordnung.
Discord-Signaturen, Allowlist, Replay, CSRF, Login-Limit, Body-Limit und geschützte Metriken.
Echter Chrome-Test: Login, SMTP-/Mail-Formulare, Zuordnung, Vorschau, CSRF-Speichern, Queue und Historie.
Ausschließlich lokale Testdaten und Dry-Run; keine echten Provider-Nachrichten.

Provider-Erweiterung:

go test ./... und go vet ./...: erfolgreich.
node scripts/check-ui.cjs: JavaScript-Syntax und eindeutige DOM-IDs erfolgreich geprüft; kein Browser-Interaktionstest.
Integration: Admin-Konfiguration inklusive Persistenz, Vorschau und authentifizierter ntfy-Eingang → Discord-Dry-Run.
HTTP-Testserver: POST/Auth, Dry-Run ohne Netzwerk, Teilfehler, HTTP 429/500, Redirect-Blockierung und Secret-Redaktion.
Bestehende Divera247-Tests weiterhin erfolgreich; ausschließlich lokale Testserver/Dry-Run genutzt.

Bisherige Snapshot-Prüfungen:

go test ./...: erfolgreich
go vet ./...: erfolgreich
JavaScript-Syntax der eingebetteten WebUI: erfolgreich geprüft
Regressionstest UCR-ID vs. globale User-ID: erfolgreich
Mock-Integrationstest für mehrere v2-UCRs mit cluster.consumer, korrekten UCR-IDs und ohne v3-Zugriff: erfolgreich
Regressionstest: v3 HTTP 403 wird nach einem Versuch kompakt gemeldet statt pro Einheit wiederholt
lokaler Healthcheck: erfolgreich
Admin-Login und Laden der neuen WebUI: erfolgreich
Konfigurations-API: sensible interne Auth-Werte werden nicht ausgegeben
Regelvorschau ntfy → Divera247 Alarm: erfolgreich
ntfy/Gotify/Webhook → Divera247 Dry-Run aus dem vorherigen Snapshot weiterhin durch Unit-/Dispatcher-Tests abgedeckt

Noch offen / nächste sinnvolle Schritte

Aktuelle Prioritäten: Retention/Archivierung, OAuth2/HTML-Mail/Quarantäne, Secret-Verschlüsselung und automatisierte Backups/CI/Lasttests. Die nachfolgende Liste stammt aus alpha.4; Queue, bcrypt, CSRF, Readiness und Basis-Metriken sind inzwischen wie oben beschrieben umgesetzt.

Stammdaten persistent cachen und automatisch/periodisch aktualisieren.
Regelreihenfolge, Stop/Continue, Fallback- und Default-Regeln ausbauen.
Zusätzliche Divera247 Alarmfelder wie Alarmvorlage, Einsatznummer, Objekt, Anrufer, Patient und Rückmeldezeit als strukturierte UI-Felder ergänzen.
Divera247 v3 vollständig typisieren.
SQLite + Audit/Outbox/Retry/Deduplizierung.
Security-Härtung (Argon2id/bcrypt, CSRF, Secret-Verschlüsselung, Rate Limits).
Prometheus/Readiness/strukturierte Logs und CI.

Wichtiger Hinweis

Es wurde kein echter Alarm an Divera247 gesendet, da kein realer Accesskey vorliegt. Der Default bleibt divera.dry_run=true. Lesende Stammdaten-Aufrufe sind davon bewusst ausgenommen. Vor produktiver Alarmierung sollte mit einer Testeinheit und kontrollierten Empfängern verifiziert werden.

6.4 KiB Raw Permalink Blame History