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

1. Stammdaten persistent cachen und automatisch/periodisch aktualisieren.
2. Regelreihenfolge, Stop/Continue, Fallback- und Default-Regeln ausbauen.
3. Zusätzliche Divera247 Alarmfelder wie Alarmvorlage, Einsatznummer, Objekt, Anrufer, Patient und Rückmeldezeit als strukturierte UI-Felder ergänzen.
4. Divera247 v3 vollständig typisieren.
5. SQLite + Audit/Outbox/Retry/Deduplizierung.
6. Security-Härtung (Argon2id/bcrypt, CSRF, Secret-Verschlüsselung, Rate Limits).
7. 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.