diff --git a/docs/CORE-FLAKY-TEST-PRUEFPROTOKOLL.md b/docs/CORE-FLAKY-TEST-PRUEFPROTOKOLL.md
new file mode 100644
index 00000000..71dce044
--- /dev/null
+++ b/docs/CORE-FLAKY-TEST-PRUEFPROTOKOLL.md
@@ -0,0 +1,35 @@
+# Prüfprotokoll: flackernder Test `TestVerifyWithContext_RateSpikeTriggersAuditEvent`
+
+Fund aus dem Gesamtprojekt-Protokoll (`docs/GESAMTPROJEKT-PRUEFPROTOKOLL.md`, Abschnitt 16, integration/gesamtprojekt Head `94290aa`): Der Test schlug im vollen Core-Paketlauf unter Host-Last einmalig fehl, isoliert mit `-count=3` dreimal grün.
+
+## Root Cause
+
+`internal/serviceaccount/anomaly_test.go` baute die Ratenbasislinie über vier reale `time.Sleep(120ms)`-Abstände auf. Die anschließende "Spike"-Prüfung vergleicht den Abstand zum letzten Zugriff gegen `baseline/rateSpikeFactor` (`rateSpikeFactor = 5.0`), also eine Schwelle von **24 ms** bei einer 120-ms-Basislinie. Ein einzelner `VerifyWithContext`-Aufruf (Tokenprüfung plus mehrere DB-Round-Trips) kann diese 24 ms auf einem parallel stark ausgelasteten Testhost überschreiten — der Test maß damit eine reale Wettlaufbedingung gegen die Host-Last, nicht die Produktlogik.
+
+Die Produktionslogik selbst (`internal/serviceaccount/anomaly.go`) ist korrekt und wurde **nicht verändert**.
+
+## Fix
+
+`anomaly_test.go`: Die Basislinie wird nach einem einzigen realen Zugriff direkt in der Tabelle `api_token_rate_state` auf `baseline_interval_seconds = 5.0` gesetzt (Schwelle damit 1 s statt 24 ms). Ein einzelner DB-Round-Trip unterschreitet 1 s in jeder realistischen Lastsituation sicher und deterministisch — die Testgrenze wurde nicht aufgeweicht, sondern die künstliche Zeitabhängigkeit entfernt (gleiches Muster wie der DNS-Timeout-Fix in QA-14).
+
+## Nachweis
+
+**Reproduktion des ursprünglichen Fehlers:** Trotz kombinierter Last (4 CPU-Busyloops auf dem 4-Kern-Host plus 30 parallele PostgreSQL-Verbindungen mit `pg_sleep`-Churn) ließ sich der Fehler in 25 isolierten Wiederholungen (`-run TestVerifyWithContext_RateSpikeTriggersAuditEvent -count=10` und `-count=15`) auf dem unveränderten `integration/gesamtprojekt`-Stand **nicht reproduzieren** — alle 25 Läufe bestanden. Der ursprüngliche einmalige Fehlschlag im Merge-Fork-Bericht hing vermutlich an einer spezifischen Kontentionssituation (z. B. gleichzeitiger `core-cluster.sh reset` mehrerer paralleler Forks auf demselben Wegwerf-Cluster), die sich mit den hier verfügbaren Mitteln nicht gezielt nachstellen ließ. Das wird hier bewusst als Grenze dokumentiert statt einer erfundenen Vorher-Zahl.
+
+**Nachweis der Verbesserung:** Mit dem Fix liefen 10 weitere Wiederholungen unter derselben künstlichen CPU-Last stabil (0,10–0,16 s je Lauf statt 0,47–0,58 s vorher — auch spürbar schneller, weil kein `time.Sleep` mehr im Testpfad steht). Die Schwelle liegt jetzt bei 1 s statt 24 ms, eine rund 40-fache Sicherheitsmarge gegenüber der Ausgangslage.
+
+| Prüfung | Ergebnis |
+|---|---|
+| `gofmt -l internal/serviceaccount/anomaly_test.go` | leer |
+| `go vet ./internal/serviceaccount/...` | sauber |
+| `go build ./...` | sauber |
+| `TestVerifyWithContext_RateSpikeTriggersAuditEvent -count=10` unter CPU-Last (vorher, unverändert) | 10/10 PASS (keine Reproduktion des Fehlers) |
+| `TestVerifyWithContext_RateSpikeTriggersAuditEvent -count=15` unter CPU+DB-Last (vorher, unverändert) | 15/15 PASS (keine Reproduktion des Fehlers) |
+| `TestVerifyWithContext_RateSpikeTriggersAuditEvent -count=10` unter CPU-Last (nachher, mit Fix) | 10/10 PASS |
+| `scripts/e2e-core-dms.sh` (Regression) | 10/10 PASS |
+
+## QA und Entscheidungen
+
+- **Entscheidung:** Baseline deterministisch seeden statt Schwelle im Produktcode aufzuweichen — folgt dem Grundsatz, Testumgebungs-Zeitabhängigkeiten zu entfernen statt Toleranzen zu erhöhen.
+- **Iterationen:** 1 (Fix direkt beim ersten Versuch korrekt; Zusatzaufwand ging in den erfolglosen Reproduktionsversuch, siehe oben).
+- **Offen:** Die genaue Ursache des ursprünglichen einmaligen Fehlschlags bleibt ungeklärt. Sollte er erneut auftreten, deutet das eher auf Cluster-Reset-Kontention zwischen parallelen Forks als auf diesen Test selbst hin.