Test-Audit einführen: Prüfstatus je Testfall im Prüfstand sichtbar machen

Ticket #16. docs/status/testpruefungen.json hält je Testfall Datum und
Kurzprüfsumme der letzten fachlichen Prüfung fest; scripts/testkatalog.py
liest das und zeigt es als eigene Spalte/Pille (nie geprüft / geprüft am …
/ veraltet seit Änderung …), unabhängig vom Baseline-Status. Neues Skript
scripts/test_audit.py (status/markieren) pflegt die Datei; erste Tests für
scripts/ unter scripts/tests/.

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

docs/leitfaden/06_tests.md

@@ -1,7 +1,7 @@
 # Tests: was geprüft wird, wie man es liest, was Pflicht ist
 
 Stand 04.09.2026. Für alle, die an den LNO-Plugins mitarbeiten — auch für Fachleute ohne Programmiererfahrung.
-Der Abschnitt 7 ist ausdrücklich für Sie geschrieben: dort geht es darum, zu **beurteilen**, ob eine Testsuite
+Der Abschnitt 8 ist ausdrücklich für Sie geschrieben: dort geht es darum, zu **beurteilen**, ob eine Testsuite
 fachlich das Richtige prüft. Dafür muss man keinen Code lesen können.
 
 ## 1. Warum das hier ernster genommen wird als sonst
@@ -116,7 +116,34 @@ vollständig lesbar zu machen.
 Nach dem Hinzufügen von Tests den Katalog neu erzeugen und mit committen. `python scripts/testkatalog.py --pruefen`
 meldet, wenn er veraltet ist.
 
-## 7. Testkonzepte: prüfen, ob die Tests fachlich sinnvoll sind
+## 7. Test-Audit: wann wurde ein Test zuletzt fachlich geprüft?
+
+Der Testkatalog beantwortet „was prüft die Suite" und „läuft der Test durch" (Baseline, Abschnitt 8). Er
+beantwortet **nicht** „hat das ein Mensch fachlich bestätigt". Ein Agent kann einen überzeugenden, aber
+fachlich falschen Test schreiben (Abschnitt 1) — weder Docstring noch Baseline zeigen das. Das Test-Audit
+schließt diese Lücke: `docs/status/testpruefungen.json` hält je Testfall Datum und Kurzprüfsumme der letzten
+Prüfung fest. Ändert sich der Testcode danach, erkennt der Prüfstand das automatisch als **veraltet** — die
+Prüfsumme stimmt nicht mehr überein.
+
+Im Prüfstand (`docs/tests/testkatalog.html`) erscheint das als eigene Spalte/Pille je Testfall (unabhängig vom
+Baseline-Status: ein grüner Test kann nie geprüft sein, ein roter Baseline-Test kann bereits geprüft sein) und
+als eigene Filter-Chips „Nie geprüft" / „Veraltet geprüft".
+
+```bash
+python scripts/test_audit.py status sn_verfahrensgebiet          # Prüfstatus je Testfall anzeigen
+python scripts/test_audit.py status --nur ungeprueft             # nur ungeprüfte Testfälle
+python scripts/test_audit.py markieren sn_basis TestX.test_y     # als heute geprüft markieren
+```
+
+`markieren` nimmt exakte Bezeichner oder `fnmatch`-Muster (z. B. `"TestX.*"`) entgegen; `--trocken` zeigt die
+Treffer, ohne zu schreiben — vor einem Muster mit vielen Treffern empfohlen. Das Skript importiert die
+Katalog-Logik aus `scripts/testkatalog.py`, statt sie zu duplizieren.
+
+Abgrenzung zu Abschnitt 8 (Testkonzepte): Das Audit bestätigt, dass **vorhandene** Tests noch fachlich
+zutreffen. Ob überhaupt genug getestet wird, zeigen die Testkonzept-Seiten — das ist der nächste, gesonderte
+Schritt, kein Ersatz für das Audit.
+
+## 8. Testkonzepte: prüfen, ob die Tests fachlich sinnvoll sind
 
 Der Katalog beantwortet „was wird getestet". Er beantwortet **nicht** „ist das genug". Dafür gibt es je
 wichtigem Fachablauf eine eigene Seite in [`docs/tests/`](../tests/), nach der Vorlage
@@ -143,7 +170,7 @@ Ein Beispiel liegt in [`docs/tests/verfahrensgebiet-shape-import.md`](../tests/v
 Wenn Sie eine Lücke finden: Issue aufmachen (`python scripts/gitea.py entwurf issue Verfahrensgebiet` legt einen
 Entwurf an). Eine gefundene Testlücke ist ein vollwertiges Ticket.
 
-## 8. Die Baseline
+## 9. Die Baseline
 
 Nicht alle Tests sind grün. Der Ist-Stand steht in [`docs/status/testbaseline.json`](../status/testbaseline.json)
 und wirkt als Sperrklinke: **bekannte rote Tests dürfen bleiben, neue nicht dazukommen.**
@@ -159,7 +186,7 @@ python scripts/run_tests.py sn_verfahrensgebiet --baseline
 Die Baseline ändert **nur ein Maintainer** mit `--update-baseline`, nach Absprache. Ein Agent fasst sie nicht an.
 Das Grünmachen der bekannten roten Tests läuft über eigene Issues, nicht nebenbei.
 
-## 9. Wenn ein Test rot ist
+## 10. Wenn ein Test rot ist
 
 Erst die Frage beantworten: **Ist der Test veraltet oder ist der Code falsch?**
 
@@ -177,7 +204,7 @@ das ist das Verstecken des Problems vor dem nächsten Leser.
 
 Details zum Deuten einzelner Fehler: Skill `sn-tests`.
 
-## 10. Vor dem Pull Request
+## 11. Vor dem Pull Request
 
 - [ ] `python scripts/run_tests.py <paket> --baseline` ohne `NEU ROT`
 - [ ] Neue Funktionalität hat mindestens einen Test je neuem Verhalten