docs(issues): close #0082 - its headline was fixed the day it was written

"Alert delivery is disconnected" was true when the issue was filed and untrue by
that evening. I carried it as a production blocker on the strength of the issue text
alone, which was wrong: the rules aggregate per target, save_state runs inside the
loop including the failure branch, the security null route is gone, and coturn is
pinned. All of it verified in the code, not inferred.

What genuinely remained were the two smaller review points, and both are done now.
The exporter no longer erases first-seen timestamps when a report fails to parse -
pruning is limited to targets actually read this round, proven in both directions.
And because TrivyScanStale cannot by construction report a target that never
produced a report, the exporter now emits trivy_reports_total and
trivy_report_read_errors with an alert on each.

Priority corrected from high to medium to match what was actually open.

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

STATUS.md

@@ -2,9 +2,9 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (63 open, 36 closed)
+## Issues (62 open, 37 closed)
 
-Verteilung: M1 16 · M2 17 · M3 4 · M4 11 · M5 15
+Verteilung: M1 15 · M2 17 · M3 4 · M4 11 · M5 15
 
 | Issue | Status | Meilenstein | Priorität | Title |
 |---|---|---|---|---|
@@ -50,7 +50,6 @@ Verteilung: M1 16 · M2 17 · M3 4 · M4 11 · M5 15
 | [0078](docs/issues/0078-gitops-45-cve-meldeweg-v2-metriken-grafana-dashboard-al.md) | open | M1 | medium | CVE-Meldeweg v2: Metriken, Grafana-Dashboard, Alerts in eigenen Matrix-Raum |
 | [0080](docs/issues/0080-gitops-47-raidplaner-mit-sozialer-komponente-verfuegbar.md) | open | M3 | medium | Raidplaner mit sozialer Komponente (Verfügbarkeiten, Aufgaben, Roadmap, Fotoalbum) |
 | [0081](docs/issues/0081-gitops-48-gaeste-invite-workflow-per-bot-3-tage-account.md) | open | M3 | medium | Gäste-Invite-Workflow per Bot (3-Tage-Accounts, Admin-Freischaltung, begrenzte Reaktivierung) |
-| [0082](docs/issues/0082-gitops-49-cve-alarme-eine-matrix-nachricht-pro-cve-flut.md) | open | M1 | high | CVE-Alarme: eine Matrix-Nachricht pro CVE flutet den Security-Raum -- Zustellung derzeit stumm |
 | [0083](docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md) | open | M1 | medium | Monitoring-Deploy: geaenderte Configs greifen nicht ohne --force-recreate (Inode-Falle bei Einzeldatei-Mounts) |
 | [0085](docs/issues/0085-gitops-52-docs-traegt-zwei-altbestaende-abgeschlossener.md) | open | M2 | low | docs/ trägt zwei Altbestände abgeschlossener Umzüge: TASKS.md und oldwiki/ |
 | [0086](docs/issues/0086-gitops-53-k8s-ressourcen-heissen-noch-element-web-docs.md) | open | M4 | low | k8s-Ressourcen heißen noch element-web-docs (Rest des ThreadNet-Rebrands) |

docs/issues/0082-gitops-49-cve-alarme-eine-matrix-nachricht-pro-cve-flut.md

@@ -1,10 +1,10 @@
 ---
 type: issue
 id: "0082"
-status: open
+status: done
 created: 2026-08-01
 milestone: M1
-priority: high
+priority: medium
 projekt: gitops
 gitlab_iid: "49"
 related: []
@@ -53,3 +53,42 @@ Scanner, Exporter, Scrape-Job und Dashboard laufen und sind verifiziert -- Expor
 ---
 *Migriert aus Gitea `sorb/axion1337.chat-gitops#51` — dort erstellt am 2026-08-01 von sorb.*
 <!-- gitea-migration: sorb/axion1337.chat-gitops#51 -->
+
+## Richtigstellung + Abschluss 2026-08-19
+
+**Die Kernaussage des Issues war überholt.** „Die Alarm-Zustellung ist abgeklemmt"
+stimmte am Tag der Erstellung — und wurde noch **am selben Tag** behoben, ohne dass das
+Issue geschlossen wurde. Ich habe es zwischenzeitlich als Produktionsblocker geführt
+(„CVE-Alarme werden gar nicht zugestellt"); das war falsch, nachgeprüft am Code:
+
+| Forderung | Stand |
+|---|---|
+| Zustellung bündeln | ✅ Weg 2 gewählt: Regeln aggregieren per `count by (target, target_type, host)`, Details im Dashboard (`alerts.yml`) |
+| State inkrementell speichern | ✅ `save_state()` steht **in** der Schleife, auch im Fehlerzweig; dazu `time.sleep(1)` gegen `rc_message` |
+| `room="security"`-Null-Route entfernen | ✅ In `alertmanager.yml` nicht mehr vorhanden; der Kommentar dort hält die Historie fest |
+| `coturn:latest` pinnen | ✅ gitops `b4650dc` |
+
+Alles vier per Commit `ff87cb2` (2026-08-01) bzw. gitops.
+
+### Heute erledigt: die beiden verbliebenen Review-Punkte
+
+**Der Exporter löschte Erstfund-Zeitstempel bei jedem Lesefehler.** `first_seen` wurde
+bei **jedem** Scrape auf das reduziert, was gerade gesehen wurde — und ein Bericht, der
+sich nicht parsen ließ, wurde per stillem `continue` übersprungen. Seine Findings kamen
+damit nicht in `seen_keys`, ihre Zeitstempel waren dauerhaft weg, und „erstmals gesehen"
+fing danach bei *jetzt* an. Gemeldet hat das nichts.
+
+Geprunt wird jetzt nur noch für Targets, deren Bericht in diesem Durchgang **wirklich
+gelesen** wurde. Beidseitig gegen eine Wegwerf-Ablage belegt, nicht argumentiert: ein
+unlesbarer Bericht lässt seinen Eintrag stehen (`read_errors 1`), ein lesbarer Bericht
+ohne das Finding räumt ihn weiterhin ab.
+
+**`TrivyScanStale` hat eine Blindstelle, die es prinzipiell nicht schließen kann:** Ein
+Target ohne je erfolgreichen Bericht hat keine Serie, an der `time() - …` hängen könnte —
+es bleibt still, egal wie lange es kaputt ist. Dafür verlassen den Exporter jetzt zwei
+Zahlen (`trivy_reports_total`, `trivy_report_read_errors`) mit je einer Regel:
+`TrivyReportUnreadable` (>0 für 30 min) und `TrivyNoReports` (==0 für 1 h). Das schließt
+die Lücke so weit, wie sie **ohne Soll-Liste der erwarteten Targets** zu schließen ist —
+eine solche Liste wäre der nächste Schritt, ist aber ein eigener Umfang.
+
+Commit `9a10615` in `threadnet-operating`.