FDN-11: pruefprotokoll dokumentieren

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

dms/docs/FDN-11-PRUEFPROTOKOLL.md

@@ -0,0 +1,36 @@
+# FDN-11 – Prüfprotokoll: Ressourcenlimits für asynchrone Verarbeitungsjobs
+
+Stand: 2026-09-19. Testhost 192.168.1.131 (PostgreSQL), `go vet`, `go test -race`, 3 Läufe. Basis: FDN-09-Kette (enthält FDN-04).
+
+Die Implementierung lag seit 2026-09-17 als Commit `2a084cb` auf dem Branch, ohne Prüfprotokoll und ohne Pull Request.
+Dieses Protokoll dokumentiert die nachgeholte Abnahme (Code-Review + Testläufe); am Code wurde nichts geändert.
+
+## Umsetzung
+
+- `Limits` (Zeit, Speicher, Eingabegröße, Seitenzahl) mit `DefaultLimits` (5 min, 512 MiB, 200 MiB, 2000 Seiten);
+  konfigurierbar je Worker (`WithDefaultLimits`) und je Jobtyp (`WithJobTypeLimits`).
+- Größe/Seitenzahl werden vorab aus den Job-Metadaten (`size_bytes`, `pages` im Payload) geprüft: bei Überschreitung wird
+  der Handler nicht gestartet.
+- Zeit: `context.WithTimeout` plus Handler in eigener Goroutine; bei Überschreitung kehrt der Worker sofort zurück.
+- Speicher: Heap-Zuwachs seit Jobstart (`runtime.MemStats.Alloc`) wird alle 20 ms abgetastet.
+- Überschreitung → `Queue.FailPermanently` (sofort Dead-Letter, kein Retry) und `Notifier.NotifyJobAborted`
+  (Standard `LogNotifier`, austauschbar).
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---------|----------|
+| 1 | Datei über der Seitenobergrenze: Job wird kontrolliert abgebrochen, Handler läuft nicht (`TestWorker_InputLimitExceeded_AbortsWithoutRunningHandler`); Zeit- und Speicherüberschreitung ebenso (`..._HandlerExceedsMaxDuration_...`, `..._MemoryLimitExceeded_...`) | bestanden |
+| 2 | Lasttest: überschreitender Job blockiert parallele reguläre Jobs nicht (`TestWorker_ExceedingJobDoesNotBlockParallelRegularJobs`); derselbe Worker verarbeitet den Folgejob sofort (`..._DoesNotBlockNextJobOnSameWorker`) | bestanden |
+| 3 | Nutzerbenachrichtigung bei abgebrochenem Job wird mit Grund ausgelöst (Fake-Notifier in Test 1) | bestanden |
+
+Alle Tests des Pakets `internal/jobqueue` (auch FDN-04-Bestand) liefen in 3 Durchgängen mit `-race` grün.
+
+## Grenzen (bekannt, nicht Teil der Kachel)
+
+- Das Speicherlimit ist prozessweit angenähert, nicht pro Job: laufen mehrere Jobs in einem Worker-Prozess, kann der
+  Heap-Zuwachs eines Jobs einen anderen fälschlich abbrechen. Harte Isolation braucht Sub-Prozesse/cgroups.
+- Ein Handler, der seinen Kontext ignoriert, läuft nach dem Abbruch als Goroutine weiter.
+- Die tatsächliche Zustellung der Benachrichtigung (E-Mail/In-App) ist nicht umgesetzt; ausgelöst wird sie zuverlässig.
+- `cmd/worker` setzt die Limits noch nicht aus Umgebungsvariablen; die Defaults greifen, sobald der Worker sie nutzt.
+- Aufrufer müssen `size_bytes`/`pages` beim Enqueue mitgeben, sonst greift nur die Zeit-/Speichergrenze.