ledger: gate 5, and the coverage metric reads one for the first time

Fifty-four of fifty-four targets scanned, nothing missing, nothing orphaned.
Since the target set became derived rather than maintained, that number has
never been whole before.

Two of the six criteria I could not check. Grafana answers me with 401, so what
I have is that provisioning ran, read out of grafana's own log in loki —
provisioned is not rendered, and the two dashboards on ancient schema versions
only fail when somebody opens them. That is written down as a gap rather than
reported as eleven of eleven.

The counter I built the same evening turned out blind to its own case, and the
test I wrote for it could not see that, because it reimplements the arithmetic
and the faulty line never existed in the copy. Second time in two days for that
failure class, in the same project.

Also worth keeping: my filter for loki errors returned fifteen hits, thirteen of
which were loki logging my own query back at me.

docs/ledger/2026-08-22-betriebs-stack-upgrade.md

@@ -2,7 +2,7 @@
 type: ledger
 date: 2026-08-22
 size: M
-status: open
+status: closed
 related:
   - "docs/issues/0051-cve-remediation-pass.md"
   - "docs/wiki/admin/cve-durchgang.md"
@@ -84,11 +84,15 @@ Minor-Sprünge ohne Zustand, der wandern müsste.
 | gate | commit | approval | status | note |
 |---|---|---|---|---|
 | 1 | 370a678 | sorb | DONE | Umfang, sechs Abnahmekriterien, Rückweg benannt; die Ablehnung von 13.x vom Vortag als Fehlvergleich richtiggestellt. |
+| 5 | PENDING | sorb | DONE_WITH_CONCERNS | Vier von sechs Kriterien gemessen erfüllt, Deckung erstmals **1,0**; ⚠️ zwei Kriterien konnte ich nicht prüfen (Grafana-API antwortet mir 401) und zwei Commits sind noch nicht ausgerollt. |
 
 ## Slices
 
 | slice | commit | status | note |
 |---|---|---|---|
+| Fassungen | 3aee138 | DONE | grafana 13.2.0, loki 3.7.6, alloy v1.18.1; Migration 19 Schritte in 353 ms, `database: ok`. |
+| Zähler entblindet | d689916 | DONE_WITH_CONCERNS | ⚠️ Fehler in eigenem Code vom selben Abend; wirkt erst nach dem Pull auf dem Host. |
+| Zählweise dokumentiert | c7aaf38 | DONE | 162 Vorkommen = 63 Serien = 28 CVEs; auf dem Dashboard steht der Sprung als 70 → 63. |
 
 ## Ladder
 
@@ -98,7 +102,10 @@ Minor-Sprünge ohne Zustand, der wandern müsste.
 | ob es ein neueres 12.x gibt, bevor der Major gewaehlt wird | 12.4.9 ist das Ende der Reihe (12.4.2 … 12.4.9), kein 12.5 | reused: die Messung statt der Annahme — der Major ist nicht Geschmack, sondern der einzige Weg zu 0 CRITICAL | |
 | ob uns die Abschaltung der numerischen Datenquellen-IDs trifft | 702 uid-Objekte, 38 Namens-Strings, **0** Zahlen ueber alle 11 Dashboards | reused: der eigene Bestand als Pruefmassstab statt vorsorglicher Anpassungen (dieselbe Methode wie bei den Authentik-Bruchstellen) | |
 | die Bruchstellen von 13.0, bevor gesprungen wird | Image-Renderer ersatzlos entfernt (nutzen wir nicht), `/api` zugunsten `/apis` veraltet, Git-Sync-Datenverlust nur in 13.0.0 | reused: die Herausgeber-Notizen; 13.2.0 laesst den fehlerhaften Zwischenstand aus | |
-| ob Trivys eigene Zahl den Vergleich hergibt | nein — die Gesamtzahl vergleicht Images mit verschiedenem Inhalt; erst die Aufteilung nach Fundort (Kern vs. `plugins-bundled`) macht daraus eine Aussage | built: nichts, aber die Auswertung nach Fundort gehoert in den Runbook-Schritt „vor jedem Update das Zielimage scannen" | |
+| ob Trivys eigene Zahl den Vergleich hergibt | nein — die Gesamtzahl vergleicht Images mit verschiedenem Inhalt; erst die Aufteilung nach Fundort (Kern vs. `plugins-bundled`) macht daraus eine Aussage | built: nichts, aber die Auswertung nach Fundort gehoert in den Runbook-Schritt „vor jedem Update das Zielimage scannen" | 3aee138 |
+| einen Weg, Grafanas Protokoll zu lesen, obwohl die API mich mit 401 abweist | alle Container-Logs liegen ohnehin in Loki, und dorthin komme ich ueber den privaten Weg | reused: die vorhandene Log-Strecke als Zugang statt nach Zugangsdaten zu fragen — Bereitstellung, Migration und Datenquellen-Fehler stehen dort vollstaendig | c7aaf38 |
+| ob der eine Bereitstellungsfehler neu ist, bevor er dem Sprung angelastet wird | dieselbe Zeile um 11:04, elf Stunden VOR dem Sprung, an einem Gameserver-Dashboard | reused: das Protokoll als Zeitachse statt einer Vermutung — dieselbe Frage, die am Vortag vier Fehldiagnosen gekostet hat | c7aaf38 |
+| warum die Anlage 63 HIGH meldet, wo ich 162 gemessen hatte | Prometheus zaehlt SERIEN (CVE + Paket + Fassung je Ziel), Trivy zaehlt VORKOMMEN; dieselbe Go-stdlib wiederholt sich ueber 13 Plugin-Binaries | reused: nichts gebaut — die Zahl war nie falsch, nur die Frage. Auf dem Dashboard steht der Sprung als 70 -> 63 | c7aaf38 |
 
 ## Notes
 
@@ -112,3 +119,57 @@ dann ein Vergleich, wenn beide Seiten dieselbe Menge Dinge enthalten.
 **Kein Issue dahinter.** Dieser Lauf entstand aus sorbs Ansage im Anschluss an
 #0051, nicht aus einem Eintrag im Bestand. Ob er einen bekommt, entscheidet
 sorb — ohne Zustimmung wird hier keiner angelegt.
+
+## Gate 5 — Abnahme
+
+| | Kriterium | Ergebnis |
+|---|---|---|
+| 1 | `cve_critical_offen` bleibt 0 | ✅ **0**; Soll wieder 54 |
+| 2 | Alle 11 Dashboards laden | ⚠️ **nicht prüfbar** — siehe unten |
+| 3 | Datenquellen zeigen Daten | ⚠️ **nicht prüfbar** — siehe unten |
+| 4 | Loki nimmt Logs an | ✅ Betriebs-Host 7 s, k3s-Cluster 2 s frisch |
+| 5 | Loki ≤ 8 HIGH, Alloy ≤ 14, Grafana-Kern 0 CRITICAL | ✅ **8 / 14 / 0** |
+| 6 | Rückweg vor dem Start | ✗ von sorb ausdrücklich abgeräumt |
+
+**Und eine Zahl, die es vorher nie gab:** `cve_target_coverage_ratio` steht nach
+dieser Runde auf **1,0** — 54 von 54, `cve_targets_missing` 0,
+`cve_targets_orphaned` 0. Seit die Zielmenge abgeleitet wird (#0106), ist das
+der erste vollständig gedeckte Stand.
+
+⚠️ **Zu 2 und 3: Ich habe sie NICHT geprüft, sondern etwas Schwächeres.** Die
+Grafana-API antwortet mir mit 401; belegen kann ich nur, dass die
+*Bereitstellung* durchlief — aus Grafanas Protokoll in Loki. **Bereitgestellt
+ist nicht dargestellt.** Genau die beiden Dashboards mit altem Schema (12 und
+32) fallen erst beim Öffnen auf, und das kann nur jemand mit Anmeldedaten. Das
+gehört als Lücke benannt und nicht als „11 von 11" gemeldet.
+
+**Der einzige Bereitstellungsfehler ist nicht unserer:**
+`pterodactyl-server.json` — „A dashboard with the same uid already exists".
+Dieselbe Zeile steht um 11:04 desselben Tages, elf Stunden vor dem Sprung, und
+betrifft ein Gameserver-Dashboard, das ohnehin außerhalb des Auftrags liegt.
+
+⚠️ **Zwei Commits sind noch nicht ausgerollt** (`d689916`, `c7aaf38`): Auf dem
+Host laufen weiter der blinde Zähler und die zwei toten Grafana-Einträge
+(`cve_entscheidungen_total` = 93 statt 86). Ein `git pull` genügt, kein
+Neustart.
+
+## Notes (Nachtrag)
+
+⚠️ **Ein Zähler, den ich am selben Abend gebaut habe, war blind für genau
+seinen Fall.** `cve_entscheidungen_ohne_befund` trug ein `and ziel in soll` —
+eine veraltete Entscheidung fiel also aus der Prüfung, sobald ihr Image aus dem
+Bestand verschwand. Das ist der Normalfall, nicht die Ausnahme: Entscheidungen
+veralten *durch* Fassungssprünge. Belegt binnen Stunden an den Einträgen zu
+Grafana 12.0.0 und 12.4.9.
+
+**Und der eigene Test konnte es nicht sehen**, weil er die Rechnung nachbaut
+und die fehlerhafte Bedingung in der Kopie gar nicht vorkam — dieselbe
+Fehlerklasse wie beim Scan-Loop am Vortag
+(`docs/wiki/stolpersteine/nachgebauter-test-prueft-den-nachbau.md`), im selben
+Projekt, innerhalb eines Tages. Die neuen Zusicherungen fahren die echte
+`collect()`; die alte Fassung fällt darin durch.
+
+**Eine Messfalle bei mir selbst:** Mein Filter „Loki-Fehler" fand 15 Treffer —
+13 davon waren Lokis Protokoll **meiner eigenen Abfrage**, in der `level=error`
+als Zeichenkette vorkam. Wer Logs nach Wörtern filtert, filtert auch sich
+selbst.