dev: Deploy v1.7.0 im Git-Deploy-Protokoll, Spamschutz-Nacharbeiten erledigt

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev/betrieb/git-deploy.md

@@ -265,3 +265,4 @@ Ausfall des Anbieters keinen Deploy abbricht.
 | 08.10.2026 | `v1.5.0` | API-Zugang an die Buchung gebunden (403 ohne Abo/Buchung, Tokens bleiben), optionales Token-Ablaufdatum, `sanctum:prune-expired` täglich 04:10. Vorab auf Live geprüft: nginx antwortet direkt, kein Proxy/CDN; Cookies `secure`/`httponly`/`samesite=lax`, HSTS fehlte. Nach dem Deploy: `strict-transport-security: max-age=31536000`, `trustedproxy.proxies` = `null`. Auswirkung der Buchungsprüfung: 2 Konten haben die API in den letzten 30 Tagen genutzt, beide weiterhin mit Zugang. Keine Migration. |
 | 08.10.2026 | `v1.6.0` | Mit Migration (`users.sessions_revoked_at_ms`, Batch 22). Härtung aus Phase 4 des Sicherheitsaudits: „Andere Geräte abmelden“, IP-weites Login-Limit (20 Fehlversuche in 15 Minuten), dauerhafte Session-Sperrmarke, Passwörter ab 12 Zeichen mit Leak-Abgleich, CSP im Melde-Modus (`storage/logs/csp-*.log`), npm `shell-quote`/`source-map-js`. Nach dem Deploy: Header `content-security-policy-report-only` vorhanden, Umami- und GlitchTip-Host in `script-src`/`connect-src`. CSP-Log in einigen Tagen auswerten. |
 | 08.10.2026 | `v1.6.1` | Vorher auf dem Server `php8.4-imagick` installiert und FPM neu geladen: Die Erweiterung fehlte auf Live, Herkunftsprüfung und KI-Vorab-Check der Bilder liefen seitdem ins Leere. Release: Zeile „PHP-Erweiterung Imagick“ in der Betriebsüberwachung, gebaute Livewire-Anfragen von Scannern (GlitchTip 38, 39) als 400 statt 500/419, Browser-Filter für abgebrochene Alpine-Übergänge (GlitchTip 18). Keine Migration. Nach dem Deploy: Betriebsüberwachung „Imagick ist geladen“. |
+| 09.10.2026 | `v1.7.0` | Spamschutz für Kontakt-Widget und Registrierung (Cloudflare Turnstile, Inhaltsfilter mit Spam-Quarantäne, Namensregel bei der Registrierung). Bei nicht erreichbarem Cloudflare wird durchgelassen und markiert. Keine Migration. Vorher: Turnstile-Keys in der `.env`, Widget im Cloudflare-Dashboard mit allen drei Live-Hostnamen. Nach dem Deploy: Kontakt-Widget im Browser getestet, Betriebsüberwachung „Spamschutz (Cloudflare Turnstile)“ grün. `contact-messages:quarantine-spam`: 152 Anliegen in die Quarantäne, 130 offen (Rest per Sammelaktion), echte Korrekturanfragen blieben offen. `users:prune-bot-registrations` nach freigegebenem Probelauf ausgeführt, danach `USERS_PRUNE_BOT_REGISTRATIONS=true` und `config:cache`. |

dev/sicherheit/ENTWICKLUNGSPLAN-SICHERHEIT-2026-10-07.md

@@ -12,8 +12,8 @@
 | **ab 15.10.2026** | CSP-Meldungen auswerten (Melde-Modus seit `v1.6.0`). | Auf Live `tail -n 200 storage/logs/csp-*.log`; fehlende Quellen in `App\Support\ContentSecurityPolicy` ergänzen, danach über das Scharfschalten entscheiden (`'unsafe-inline'`/`'unsafe-eval'` bleiben bis zu einer Nonce-Lösung). |
 | nächstes Release | Übergangs-Fallback der Sperrmarke entfernen. | `SessionRevocation::legacyCachedMark()` und den Test „a revocation from before v1.6.0 …“ streichen. |
 | nächstes Release | Liste und Kennzahl „Aktive Sessions“ auf der Sicherheitsseite lesen die Tabelle `sessions`, Live speichert Sessions in Redis — dort immer leer. | Korrigieren oder entfernen; der Knopf „Andere Geräte abmelden“ ist davon unabhängig. |
-| nach Deploy Spamschutz | Altbestand und Bot-Konten aufräumen, Datenschutztext freigeben. | Schritte in [ENTWICKLUNGSPLAN-SPAMSCHUTZ-2026-10-09.md](ENTWICKLUNGSPLAN-SPAMSCHUTZ-2026-10-09.md), Abschnitt 0: beide Befehle erst mit `--dry-run`, dann `USERS_PRUNE_BOT_REGISTRATIONS=true`; Abschnitt 6a der Datenschutzerklärung juristisch prüfen lassen. |
-| 7 Tage nach Deploy Spamschutz | Wirkung auswerten. | Spam-Filter der Kontakt-Queue, `storage/logs/spam-*.log`, Betriebsüberwachung „Formulare ohne Bot-Prüfung“; Regeln nachschärfen oder lockern. |
+| ~~nach Deploy Spamschutz~~ | ✅ 09.10.2026 (`v1.7.0`): Altbestand in die Quarantäne (152), Bot-Konten gelöscht, täglicher Lauf an. **Offen:** Abschnitt 6a der Datenschutzerklärung juristisch freigeben lassen. | [ENTWICKLUNGSPLAN-SPAMSCHUTZ-2026-10-09.md](ENTWICKLUNGSPLAN-SPAMSCHUTZ-2026-10-09.md), Abschnitt 0. |
+| **ab 16.10.2026** | Wirkung des Spamschutzes auswerten. | Spam-Filter der Kontakt-Queue, `storage/logs/spam-*.log`, Betriebsüberwachung „Formulare ohne Bot-Prüfung“; Regeln nachschärfen oder lockern. |
 | bei Gelegenheit | Außerhalb des Audits: eigene MySQL-Benutzer je Projekt auf `global-mysql`, MySQL-Root-Passwort ändern (steht in der Git-Historie), lokalen `APP_KEY` reparieren. | – |
 
 **Ausführung:** Befehle direkt im Dev-Container (`php artisan …`, ohne Sail – siehe `.ai/rules/general.md`)

dev/sicherheit/ENTWICKLUNGSPLAN-SPAMSCHUTZ-2026-10-09.md

@@ -4,7 +4,7 @@
 
 **Datengrundlage:** lokale Datenbank, Stand 07.10.2026, Zeitraum der letzten 30 Tage.
 
-**Stand:** 09.10.2026 – Phasen 1 bis 3 umgesetzt (noch nicht released), Entscheidungen am 09.10.2026 getroffen (Abschnitt 4). Umsetzung und Schritte nach dem Deploy: Abschnitt 0.
+**Stand:** 09.10.2026 – Phasen 1 bis 3 live seit `v1.7.0` (09.10.2026), Altbestand und Bot-Konten auf Live aufgeräumt. Offen: juristische Freigabe von Abschnitt 6a der Datenschutzerklärung, Auswertung nach 7 Tagen (ab 16.10.2026).
 
 ## 0. Umsetzungsstand
 
@@ -30,12 +30,13 @@ Das gilt in drei Fällen: Siteverify antwortet nicht, Cloudflare lehnt unseren S
 - Was der Filter nicht erkennt, wird über die Sammelaktion markiert. Das sind vor allem die Preisfragen in wechselnden Sprachen und die Newsletter-Bitten.
 - `users:prune-bot-registrations --dry-run` findet 392 Konten. 379 davon haben einen Zufallsnamen, 13 sind echt wirkende, aber seit über 14 Tagen unbestätigte und ungenutzte Konten.
 
-**Nach dem Deploy auf Live:**
-1. Im Cloudflare-Dashboard prüfen, dass das Turnstile-Widget alle drei Live-Hostnamen kennt. Danach einmal das Kontakt-Widget öffnen und absenden.
-2. `php artisan contact-messages:quarantine-spam --dry-run` ausführen, die Liste prüfen, dann ohne `--dry-run` ausführen.
-3. `php artisan users:prune-bot-registrations --dry-run` ausführen. Nach Freigabe der Liste einmal ohne `--dry-run` ausführen und `USERS_PRUNE_BOT_REGISTRATIONS=true` in die `.env` setzen (`config:cache` läuft im Deploy-Skript).
-4. Lokal die Cloudflare-Testkeys in die `.env` eintragen, weil die echten Keys an die Live-Hostnamen gebunden sind.
-5. Nach 7 Tagen auswerten: Spam-Filter in der Kontakt-Queue, `storage/logs/spam-*.log` und die Betriebsüberwachung.
+**Nach dem Deploy auf Live (09.10.2026, `v1.7.0`):**
+1. ✅ Turnstile-Widget im Cloudflare-Dashboard mit allen drei Live-Hostnamen, Kontakt-Widget im Browser getestet, Betriebsüberwachung grün.
+2. ✅ `contact-messages:quarantine-spam`: 152 Anliegen in die Quarantäne, darunter eine neue Welle „XEvil … löst Captchas“ vom 08./09.10. 130 blieben offen, vor allem Preisfragen in wechselnden Sprachen und Newsletter-Bitten; die kommen per Sammelaktion in die Quarantäne. Die echten Korrekturanfragen KT-32, KT-33 und KT-161 blieben offen.
+3. ✅ `users:prune-bot-registrations`: Probelauf geprüft und freigegeben, ausgeführt, täglicher Lauf eingeschaltet (`USERS_PRUNE_BOT_REGISTRATIONS=true`). Die Liste bestätigte das Sign-up-Bombing: Zufallsnamen mit fremden Adressen, darunter Behörden (`state.gov`, `usdoj.gov`) und SMS-Gateways (`vtext.com`, `tmomail.net`).
+4. Lokal die Cloudflare-Testkeys in die `.env` eintragen (die echten Keys sind an die Live-Hostnamen gebunden).
+5. **Ab 16.10.2026:** Wirkung auswerten — Spam-Filter in der Kontakt-Queue, `storage/logs/spam-*.log`, Betriebsüberwachung „Formulare ohne Bot-Prüfung“.
+6. Abschnitt 6a der Datenschutzerklärung juristisch freigeben lassen.
 
 ## 1. Befund