archive-kanban: RET-15/RET-16 Ursachenbeschreibung korrigiert (Container statt ZFS)

Nach PR #312 (RET-11-Nachtrag): nicht ZFS verhindert chattr +i, sondern
unprivilegierte LXC-Container (CAP_LINUX_IMMUTABLE nicht namespace-bewusst,
Kernel-Design). Tickettexte entsprechend korrigiert.

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

archive-kanban/tickets/RET-15.md

@@ -9,12 +9,12 @@ Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Ret
 Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
 
 ## Auftrag
-RET-11 implementiert Storage-Object-Lock über `chattr +i`. Auf beiden bisher geprüften Hosts (131, 204) scheitert `chattr +i` strukturell mit `EPERM`, weil beide unprivilegierte LXC-Container auf ZFS-Root sind (RET-11-PRUEFPROTOKOLL.md, bestätigt erneut in QA-02/QA-07/QA-05, Archive-Board). Der erfolgreiche Pfad (chattr-fähiger, privilegierter Host bzw. chattr-fähiges Dateisystem) wurde in diesem Projekt bislang auf keinem Host real bestätigt. `wormstore.Store.Put` ist fail-closed: schlägt `chattr +i` fehl, wird der Schreibvorgang verworfen — das ist technisch sicher (kein stiller Integritätsverlust), aber die eigentliche WORM-Garantie (Akzeptanzkriterium 1/2 aus RET-11) ist bislang nur per Code-Analyse, nicht per echtem End-zu-Ende-Test belegt.
+RET-11 implementiert Storage-Object-Lock über `chattr +i`. Auf beiden bisher geprüften Hosts (131, 204) scheitert `chattr +i` strukturell mit `EPERM` — die Untersuchung in `RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` hat die Ursache geklärt: **nicht das Dateisystem (ZFS)**, sondern dass beide Hosts **unprivilegierte LXC-Container** sind. `CAP_LINUX_IMMUTABLE` wird im Kernel bewusst nicht namespace-bewusst geprüft (per rohem ioctl bestätigt, nicht nur am `chattr`-Binary), 8 Alternativen wurden geprüft und als unzureichend befunden (einzige strukturell gleichwertige Alternative: echtes S3/MinIO-Object-Lock-Backend, Architekturwechsel). Der erfolgreiche Pfad (ein tatsächlich privilegierter Host/Container) wurde in diesem Projekt bislang nirgends real bestätigt. `wormstore.Store.Put` ist fail-closed: schlägt `chattr +i` fehl, wird der Schreibvorgang verworfen — das ist technisch sicher (kein stiller Integritätsverlust), aber die eigentliche WORM-Garantie (Akzeptanzkriterium 1/2 aus RET-11) ist bislang nur per Code-/Kernel-Analyse, nicht per echtem End-zu-Ende-Test auf einem funktionierenden Host belegt.
 
-**Technische Grundlage:** chattr-fähiger Host oder chattr-fähiges Dateisystem (z. B. ext4 statt ZFS), oder eine der in der Untersuchung (siehe Nachtrag-Dokument, falls vorhanden) geprüften Alternativen.
+**Technische Grundlage:** ein tatsächlich privilegierter Host/Container (`CAP_LINUX_IMMUTABLE` im Host-Namespace), unabhängig vom Dateisystem — oder das in RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md als einzige gleichwertige Alternative genannte externe Object-Lock-Backend (S3/MinIO Compliance-Mode), falls ein privilegierter Host nicht verfügbar gemacht werden kann.
 
 ## Ausgangslage
-Setzt auf folgenden bereits fertigen Kacheln auf: RET-11, QA-02, QA-07, QA-05 (alle Archive-Board). Prüfe vor Beginn, ob zwischenzeitlich ein Nachtrag-Dokument zur chattr-Untersuchung existiert (`archive/docs/RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` oder ähnlich benannt) und baue darauf auf, statt die Untersuchung zu wiederholen.
+Setzt auf folgenden bereits fertigen Kacheln auf: RET-11, QA-02, QA-07, QA-05 (alle Archive-Board). Lies vor Beginn `archive/docs/RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` vollständig (PR #312) — die Ursachenanalyse und alle 8 geprüften Alternativen sind dort bereits dokumentiert, nicht wiederholen.
 
 ## Akzeptanzkriterien
 1. Ein Host oder eine Umgebung mit tatsächlich wirksamem `chattr +i` (oder einer als gleichwertig befundenen Alternative) ist identifiziert und dokumentiert

archive-kanban/tickets/RET-16.md

@@ -1,4 +1,4 @@
-# RET-16 – STORAGE-KONZEPT.md: Widerspruch ZFS als WORM-Backend klären
+# RET-16 – STORAGE-KONZEPT.md: Voraussetzung für Storage-Object-Lock (unprivilegierter Container statt ZFS) klären
 
 **Epic:** ⏳ Retention & WORM  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 0,5 Personentage  |  **Welle:** 9
 
@@ -8,15 +8,15 @@
 Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
 
 ## Auftrag
-`STORAGE-KONZEPT.md` (Abschnitt 2) listet ZFS als gleichwertige Stufe-1-Backend-Option. `RET-11-PRUEFPROTOKOLL.md` (Prüfung 3) sieht das WORM-Basisverzeichnis ausdrücklich NICHT auf ZFS vor, weil `chattr +i` auf ZFS strukturell nicht funktioniert (bestätigt auf Host 131 und 204, siehe QA-02/QA-05/QA-07-Nachträge Archive-Board). Dieser Widerspruch zwischen Betriebsdokumentation und tatsächlicher technischer Einschränkung muss aufgelöst werden, bevor eine produktive Stufe-1-Inbetriebnahme auf ZFS-Basis erfolgt.
+`STORAGE-KONZEPT.md` (Abschnitt 2) listet ZFS als gleichwertige Stufe-1-Backend-Option, ohne auf eine Einschränkung bei Storage-Object-Lock hinzuweisen. `RET-11-PRUEFPROTOKOLL.md` samt Nachtrag (`RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md`) hat die tatsächliche Ursache geklärt: **nicht ZFS** verhindert `chattr +i`, sondern dass Host 131/204 **unprivilegierte LXC-Container** sind — `CAP_LINUX_IMMUTABLE` wird im Kernel bewusst nicht namespace-bewusst geprüft (Kernel-Design-Entscheidung, Patch dafür 2014 abgelehnt). Das Problem träte identisch auf ext4/XFS/Btrfs auf, solange der Container unprivilegiert ist. Dieser Zusammenhang muss in der Betriebsdokumentation korrekt stehen, bevor eine produktive Stufe-1-Inbetriebnahme erfolgt — sonst wird fälschlich am Dateisystem statt an der Container-Privilegierung gesucht.
 
 ## Akzeptanzkriterien
-1. `STORAGE-KONZEPT.md` Abschnitt 2 enthält einen expliziten Ausnahmevermerk: ZFS ist für das WORM-Basisverzeichnis (Archive-Modul) nicht geeignet, sofern keine alternative Durchsetzung (siehe RET-15) nachgewiesen ist
-2. Verweis auf RET-11-PRUEFPROTOKOLL.md als Quelle des Befundes ist im Dokument ergänzt
+1. `STORAGE-KONZEPT.md` Abschnitt 2 enthält einen expliziten Hinweis: Storage-Object-Lock (`chattr +i`, RET-11) setzt einen privilegierten Host/Container voraus (oder ein alternatives, von RET-15 nachgewiesenes Verfahren) — unabhängig vom gewählten Dateisystem (ZFS, ext4, XFS, Btrfs)
+2. Verweis auf RET-11-PRUEFPROTOKOLL.md und dessen Nachtrag als Quelle des Befundes ist im Dokument ergänzt
 3. Keine andere inhaltliche Aussage von STORAGE-KONZEPT.md wird verändert
 
 ## Prüfungen vor der Abnahme
-1. Dokument-Review: Ausnahmevermerk ist vorhanden, eindeutig und widerspricht keiner anderen Stelle im Dokument
+1. Dokument-Review: Hinweis ist vorhanden, eindeutig, nennt die richtige Ursache (Container-Privilegierung, nicht Dateisystem) und widerspricht keiner anderen Stelle im Dokument
 2. Diff-Prüfung: keine ungewollten Änderungen außerhalb des betroffenen Abschnitts
 
 ## Nicht Bestandteil dieser Kachel