dms-kanban: Ticket VER-09 (Audit-Ereignisse fuer alle relevanten Aktionen) anlegen

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

dms-kanban/tickets/VER-09.md

@@ -0,0 +1,58 @@
+# VER-09 – Audit-Ereignisse für alle relevanten Aktionen
+
+**Epic:** 🔄 Versionierung & Audit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+VER-05 liefert das manipulationssichere Audit-Log (Hash-Kette, Append-only), aber außer Bulk-Edit (VER-02-Umfeld) und Malware-Scan (DOC-17) schreibt keine Aktion hinein. Gefunden bei der Vorbereitung von QA-08 (2026-09-19): Upload, neue Revision, Wiederherstellen, Signieren, Download-URL/Download, Papierkorb (löschen/wiederherstellen/endgültig löschen), Metadaten- und Tag-Änderungen, Export-Anforderung und automatische Endgültig-Löschung erzeugen keinen Eintrag. Alle diese Aktionen protokollieren, mit Akteur, Objekt und Aktion, im selben Protokoll.
+
+**Technische Grundlage:** `internal/audittrail` (Append), Akteur je Aufrufkontext (Parameter `caller` nach dem in `versioningapi`/`downloadapi` etablierten Muster, Systemakteur für automatische Vorgänge)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Alfresco: lückenloser Audit-Trail als Voraussetzung für Revisionssicherheit.
+
+**Bewusst vermeiden:**
+- Ein Protokoll, das nur formal manipulationssicher ist, aber die eigentlichen Aktionen nicht enthält.
+- Stilles Weiterlaufen ohne Protokolleintrag: schlägt das Protokollieren fehl, ist das ein Fehler, kein Log-Hinweis.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: VER-05, VER-07, VER-08, DOC-01, DOC-11, DOC-15, DOC-16.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede der folgenden Aktionen erzeugt genau einen Protokolleintrag mit Akteur, Objekt und Aktion: Dokument angelegt (Upload), neue Revision, Revision wiederhergestellt, Dokument signiert, Download-URL ausgestellt, Download durchgeführt, Dokument in Papierkorb, aus Papierkorb wiederhergestellt, endgültig gelöscht (manuell und automatisch), Metadaten geändert, Tag zugewiesen/entfernt, Export angefordert
+2. Das Protokollieren schlägt sichtbar fehl (Fehler an den Aufrufer), wenn der Eintrag nicht geschrieben werden kann
+3. Rein lesende Vorschau-Zugriffe (`GET /documents/{id}/content`) werden bewusst nicht protokolliert; die Entscheidung ist dokumentiert
+4. Die Hash-Kette bleibt nach allen Aktionen lückenlos gültig (`VerifyChain`)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Referenzablauf über alle genannten Aktionen: das Protokoll enthält exakt die erwarteten Einträge in der erwarteten Reihenfolge
+2. Test: Protokollierung nicht möglich (z. B. Rolle ohne INSERT-Recht) — die Aktion meldet einen Fehler
+3. `VerifyChain` nach dem Referenzablauf fehlerfrei
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-08` Revisionssicherheits-Prüfung (nutzt diese Einträge)
+- Atomarität von Aktion und Protokolleintrag in einer Transaktion (bekannte Einschränkung, siehe Prüfprotokoll)
+- Authentifizierte Akteursidentität aus dem Core (bis dahin `caller`-Parameter)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VER-09: audit-ereignisse-aller-relevanten-aktionen`
+- Branch: `feature/ver-09-audit-ereignisse-aller-relevanten-aktionen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.