Gespiegelt von Core QA-01: Testpyramide, Pflichttest-Gate als technisch erzwungenes Merge-Gate (nicht nur Doku), Referenzdatensatz-Konzept.
Sicherheitskritische Bereiche: wormstore, rbacclient, retentionapi, tenantregistryclient, kekclient, backupcrypto — internal/pflichttestgate + cmd/pflichttestgate prüfen automatisiert gegen den PR-Diff, .gitea/workflows/archive-pflichttest-gate.yml führt es in CI aus (Pfad-Filter archive/**).
internal/referenceset liefert den synthetischen Referenzdatensatz (Retention-Objekte je Fristklasse, WORM-Nutzdaten in 3 Größenklassen, Backup-Generationen mit geteilten/eindeutigen Blöcken) — keine echten Kundendaten, reproduzierbar per festem Seed.
Offen — Gegenlesen durch zweite Person, wie bei Core QA-01 nachzutragen
Gate deckt QA-02 bis QA-06 relevante Bereiche ab — siehe docs/TESTSTRATEGIE-ARCHIVE.md Abschnitt 3
Gate zusätzlich real gegen echten Diff verifiziert: geänderte wormstore.go ohne Testdatei → Exit 1 mit korrekter Fehlermeldung.
## Umsetzung
Gespiegelt von Core QA-01: Testpyramide, Pflichttest-Gate als technisch erzwungenes Merge-Gate (nicht nur Doku), Referenzdatensatz-Konzept.
Sicherheitskritische Bereiche: wormstore, rbacclient, retentionapi, tenantregistryclient, kekclient, backupcrypto — internal/pflichttestgate + cmd/pflichttestgate prüfen automatisiert gegen den PR-Diff, .gitea/workflows/archive-pflichttest-gate.yml führt es in CI aus (Pfad-Filter archive/**).
internal/referenceset liefert den synthetischen Referenzdatensatz (Retention-Objekte je Fristklasse, WORM-Nutzdaten in 3 Größenklassen, Backup-Generationen mit geteilten/eindeutigen Blöcken) — keine echten Kundendaten, reproduzierbar per festem Seed.
## Prüfungen
1. Referenzdatensatz reproduzierbar aufsetzbar — TestReferenceSet_IsReproducibleAcrossIndependentBuilds PASS
2. **Offen** — Gegenlesen durch zweite Person, wie bei Core QA-01 nachzutragen
3. Gate deckt QA-02 bis QA-06 relevante Bereiche ab — siehe docs/TESTSTRATEGIE-ARCHIVE.md Abschnitt 3
Gate zusätzlich real gegen echten Diff verifiziert: geänderte wormstore.go ohne Testdatei → Exit 1 mit korrekter Fehlermeldung.
patrick
added 38 commits 2026-09-17 17:58:26 +02:00
Neues Modul-Verzeichnis code/archive/ (Monorepo-Muster wie code/dms/).
PostgreSQL-17-natives inkrementelles Backup (pg_basebackup --incremental,
WAL-Summarization) statt WAL-Archiving, um den geteilten Testhost ohne
Neustart umzustellen (summarize_wal=on per pg_reload_conf). Rolle
nexarch_backup mit REPLICATION-Attribut angelegt.
internal/backup: FullBackup/IncrementalBackup (pg_basebackup-Wrapper),
Verify (vollstaendiges Lesen von base.tar.gz, gzip+tar, nicht nur Header),
Rotate/ListGenerations (generationsbasiert, aeltere zuerst entfernt).
cmd/backup-cli fuer systemd-Timer-Aufruf (deploy/systemd/
nexarch-archive-backup-*.timer, taeglich/stuendlich/taeglich).
Auf 192.168.1.131 verifiziert: 4/4 Tests gegen echte Postgres-17-Instanz
(kein Mock) - inkrementelle Sicherung real kleiner als Vollsicherung,
Verifikation erkennt absichtlich beschaedigte Datei, Rotation entfernt nur
die aeltesten Generationen. Zusaetzlich ECHT verdrahtet: backup-cli gebaut,
3 systemd-Timer installiert+aktiviert, jeder der drei Dienste einmal ueber
systemctl start end-to-end ausgeloest (status=0/SUCCESS je Dienst) - nicht
nur go test, sondern der reale Automatisierungspfad selbst geprueft.
Siehe archive/docs/BAK-01-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
restic statt Eigenbau (Content-defined Chunking fuer Dedup, verschluesseltes
Repository ab Werk, geprueftes Tooling). internal/objectbackup wrapt
restic init/backup/check/forget ueber os/exec, cmd/objectbackup-cli fuer
systemd-Timer (stuendliche Sicherung, woechentliche Vollstaendigkeitspruefung,
taegliche Rotation).
Auf 192.168.1.131 real verifiziert (kein Mock): zweiter Lauf gegen
unveraenderten Bestand ueberraegt nichts (files_new=0), zwei identische
Dateien erzeugen nachweislich nur 1 data_blob (echter Dedup-Nachweis),
absichtlich gekipptes Byte in einer Pack-Datei wird von check --read-data
zuverlaessig erkannt. Echt verdrahtet: 3 systemd-Timer installiert+
aktiviert, jeder Dienst einmal end-to-end via systemctl start ausgeloest.
Im selben Rutsch BAK-01-Fund korrigiert: NEXARCH_BACKUP_DIR zeigte auf
/var/backups/nexarch (Root-Dateisystem, kein Dataset) statt auf das
persistente ZFS-Dataset /var/nexarch-archiv - korrigiert, erneut ausgeloest,
landet nachweislich am richtigen Ort. objectbackup-cli-Repository liegt von
Anfang an korrekt dort.
Siehe archive/docs/BAK-02-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
Deterministischer Abgleich zwischen DMS file_revisions und
Objekt-Storage-Verzeichnis, existenz-only (keine Inhaltspruefung,
saubere Abgrenzung zu BAK-08). Report sortiert nach storage_key fuer
stabile Weiterverarbeitung durch BAK-08. Systemd-Timer taeglich,
real auf 192.168.1.131 verdrahtet und ausgeloest.
Report enthielt bisher nur Abweichungen. BAK-08 braucht eine
deterministisch sortierte Liste bestaetigt existierender Objekte als
Stichprobengrundlage, nicht nur "keine Abweichung". Ergaenzt vor
BAK-08-Start, real neu getestet (9/9) und auf 131 erneut ausgeloest.
internal/restore: Atomarer Restore ueber Temp-Verzeichnis + Rename,
nicht-leeres Ziel ohne -force bricht VOR jeder Beruehrung ab, JSONL-
Protokoll jedes Laufs. Drei reale Defekte beim Bau gefunden und behoben:
pg_combinebackup braucht Plain- statt Tar-Format (Extraktionsschritt
ergaenzt), pg_wal.tar.gz wurde nie verifiziert/wiederhergestellt (BAK-01s
Verify jetzt erweitert), Go-exec haengt bei pg_ctl start wegen vererbter
Pipes (Testfix: echte Logdatei statt CombinedOutput). Beide Restore-Pfade
real auf 131 ueber restore-cli nachgewiesen, inkl. echtem Postgres-Start
aus wiederhergestelltem Verzeichnis.
internal/restoretest wiederholt BAK-03s eigene Pruefdiskt als
Produktcode: echter Restore der neuesten Sicherung, echter Kurzstart
einer isolierten Postgres-Instanz, echte SELECT-1-Abfrage; Objekt-Seite
echter restic-Restore + Inhaltspruefung. JSONL-Historie (append-only),
sichtbare Warnung ueber denselben OPS-05-Pull-Weg wie BAK-08, eigenes
/metrics-Modul (archive-restoretest). Zwei reale Defekte gefunden und
behoben: Unix-Socket-Pfadlaenge unter tief verschachtelten Testpfaden,
restic-stderr-Vermischung beim JSON-Parsen unter dem Dienstnutzer.
Real auf 131 verdrahtet und ausgeloest (beide Testarten erfolgreich,
End-zu-Ende ueber OPS-03 bestaetigt).
internal/tenantbackup: datenbank-scharfes pg_dump/pg_restore statt
BAK-01s Cluster-weitem pg_basebackup - bei Modell C (TEN-01, physisch
isolierte DB je Mandant) wuerde ein Cluster-Restore zwangslaeufig ALLE
Mandanten ueberschreiben. Objekt-Seite nutzt BAK-02 direkt (Mandanten
haben eigene Buckets/Pfad-Roots). Eigene Postgres-Rolle
nexarch_tenantbackup (CREATEDB, kein Superuser, getrennt von
nexarch_backup). Zwei-Tenant-Isolation real in beide Richtungen
bewiesen (Markerwert-Nachweis), JSONL-Protokoll fuer Sicherung UND
Restore. Realer End-zu-Ende-Lauf ueber tenantbackup-cli auf 131.
internal/backup.PruneTiered: reine GFS-Funktion (Tag/Woche/Monat) fuer
Datenbank-Generationen, behaelt strukturell immer die neueste Generation
(Sicherheitsnetz gegen Legal-Hold-Kollision). internal/objectbackup.
PruneTiered: duenner Wrapper um restics native --keep-daily/-weekly/
-monthly-Staffelung. Beide CLIs nutzen die Staffelung, wenn konfiguriert,
bleiben sonst abwaertskompatibel zur flachen "letzte N"-Regel. Real
gegen zeitversetzt erzeugte restic-Snapshots getestet (Fund: restics
--time-Flag erwartet eigenes Format, nicht RFC3339), Pruning-Sicherheit
nach dem Loeschen alter Snapshots ueber vollstaendigen Restore +
restic check --read-data bewiesen. Beide Rotationswege real ueber
systemd auf 131 ausgeloest.
Nutzerfrage: DB- und Objekt-Rotation laufen unabhaengig, kein Test/
Invariant stellt sicher, dass aeltester erreichbarer Snapshot und
aelteste erreichbare DB-Generation zeitlich zusammenpassen. Aktuell
identische keep-Werte sind Zufall, kein erzwungenes Verhalten - als
Folgepunkt dokumentiert, nicht Teil des Tickets.
Realer Restore-Testlauf (DB+Objekt) und Reconciliation frisch auf 131
ausgeloest, beide sauber (kein Fund). Fuenf offene Restrisiken
schriftlich benannt (Rotations-Kohaerenz, BAK-04-Rollenrechte fuer
produktive Mandanten, Storage-Provider-Grenze aus BAK-08, Core
FDN-03/FDN-09-Wiring-Luecke, leerer Testbestand). Unterschrift steht
aus - kann nicht durch das System selbst erfolgen.
internal/retention: object_type/object_reference als reine Textfelder
(Adapter-Muster, keine Fremdschluessel auf DMS-/Mail-Tabellen).
Aufbewahrungsklassen-Zuordnung historisiert (jede Zuordnung eigene,
unveraenderliche Zeile). Migration real vorwaerts+rueckwaerts gegen
die tatsaechlichen .sql-Dateien getestet, Mandantentrennung gegen
echtes zweites Tenant-DB bewiesen. Grundlage fuer RET-05 (Adapter-
Interface) und RET-02.
internal/moduleadapter: Registrierungs-API + Rueckruf-Ausloeser fuer
DMS/Mail, bewusst NUR Archives eigene Seite - keine Modul-Empfaenger-
Implementierung (Nutzervorgabe: Interface zuerst festlegen, damit
DMS/Mail spaeter nicht gegen ein sich noch aenderndes Interface bauen).
Register ist ON-CONFLICT-DO-NOTHING (erneute Registrierung aendert nie
bestehende callback_url), NotifyDestruction echter HTTP-POST mit festem
DestructionNotice-Vertrag. Idempotenz sowohl auf Go- als auch HTTP-
Ebene bewiesen, Rueckruf gegen echten Testendpunkt verifiziert.
Vor Board-Flip bemerkt: Akzeptanzkriterium 1 fordert Objekttyp MIT
Aufbewahrungsklasse UND Rueckruf-Adresse, retention_class fehlte im
ersten Entwurf komplett. Migration, Registration-Struct, Register,
ListRegistrations und RegisterHandler ergaenzt, Tests angepasst
(Idempotenz jetzt auch fuer retention_class geprueft, nicht nur
callback_url). Real auf 131 gedroppt und neu angewendet.
internal/retentionengine: Frist je Aufbewahrungsklasse als natives
Postgres-INTERVAL, Stichtagsberechnung an Postgres delegiert statt
eigener Kalenderrechnung (Schaltjahr/Monatsende-Referenzwerte real
verifiziert: 2024-02-29+1y=2025-02-28, 2026-01-31+1mo=2026-02-28).
Periodischer Job (ListExpiringObjects) beschraenkt sich per DISTINCT ON
auf die juengste Klassenzuordnung je Objekt - sonst wuerden Objekte mit
mehrfach geaenderter Klasse (RET-01-Historisierung) doppelt auftauchen,
real mit einem Zwei-Zuordnungen-Testobjekt bewiesen. Scope bewusst eng
gehalten: keine RET-05-Anbindung, keine Vernichtungslogik - das ist
Ticket-Scope, dependsOn ist nur RET-01.
Board-Entscheidung: Backend-API zuerst, echtes Next.js-Frontend als
separates Folgeticket - vermeidet Pseudo-Frontend-Protokoll.
internal/retentionapi: 4 Endpunkte (anlegen/aendern, deaktivieren,
liste, vorschau), Vorschau nutzt dieselbe ListExpiringObjects-Funktion
wie RET-02s periodischer Job (keine Doppel-Implementierung).
RequireRole ist AUSDRUECKLICH kein RBAC-02-Ersatz, sondern ein
dokumentiertes Provisorium (Header-Check) - RBAC-02 ist reiner
Core-interner Go-Code ohne HTTP-Schnittstelle fuer andere Module,
derselbe Befund wie FDN-03/FDN-09. Provisorium real getestet inkl.
Negativfall (403 ohne/mit falscher Rolle). retention_class_rules um
active-Flag erweitert (deaktivieren ohne Historienverlust). Real auf
131 deployed und per curl end-to-end verifiziert.
- internal/rbacclient: HTTP-Client fuer Core RBAC-06 (POST /authorize)
- retentionapi.RequireRole (Header-Provisorium) ersetzt durch
RequireRBAC, echter Aufruf gegen RBAC-06, fail-closed bei Fehlern
- Mount nimmt jetzt rbacclient.Client entgegen
- alle bestehenden RET-06-API-Tests weiterhin gruen
- neue Tests: verweigerte Rolle (403 gegen echte RBAC-06-Antwort),
erlaubte Rolle (200), RBAC-06 nicht erreichbar -> fail-closed (403)
- real deployed auf 131, end-zu-ende per curl nachgewiesen (403/403/200/403)
Pruefungen siehe archive/docs/RET-08-PRUEFPROTOKOLL.md
- archive/cmd/moduleadapter-api: startet den fertigen RET-05
RegisterHandler als eigenstaendigen HTTP-Dienst, Port 8095
- reines Wiring, kein Diff an internal/moduleadapter/ (verifiziert)
- real deployed auf 131, end-zu-ende per curl: Registrierung +
Idempotenz-Nachweis (widerspruechliche zweite Werte werden ignoriert,
urspruengliche Registrierung bleibt bestehen)
Pruefungen siehe archive/docs/RET-09-PRUEFPROTOKOLL.md
- archive/internal/retentionapi.CORS: erlaubt genau einen konfigurierten
Origin (kein Wildcard), beantwortet OPTIONS-Preflights direkt
- cmd/retention-api: neue Pflicht-Env NEXARCH_RETENTION_CORS_ALLOWED_ORIGIN,
mux mit CORS umschlossen
- gefunden durch Sichtpruefung des laufenden RET-06-Frontends: curl
umgeht CORS, ein echter Browser haette den Fetch blockiert - weder
Go- noch Vitest-Tests konnten das strukturell erfassen
- 3 Tests: erlaubter Origin bekommt Header, Preflight korrekt
beantwortet, fremder Origin bekommt keinen Header
- real deployed auf 131, genau der bei der Sichtpruefung fehlgeschlagene
Aufruf (Origin http://127.0.0.1:3099) liefert jetzt 200 mit korrektem
Access-Control-Allow-Origin
Pruefungen siehe archive/docs/RET-10-PRUEFPROTOKOLL.md
- archive/internal/wormstore.Store: Put schreibt einmalig (chmod 0400
danach, ErrAlreadyExists bei Ueberschreibversuch inkl. DB-seitiger
Sperre gegen Wettlaufsituationen), GetVerified prueft SHA-256 bei
jedem Zugriff, KEINE Delete-Funktion (strukturelle API-Grenze)
- migrations/0007_worm_objects: append-only Metadatentabelle
- AC2/Pruefung 3 vor Umsetzung praezisiert: Schutz ueber Go-API,
kein absoluter Schutz gegen root (Nutzerentscheidung: kein chattr +i,
nicht portabel/nicht ehrlich als absolut behauptbar)
- Reflection-Test beweist strukturell: keine Loesch-Methode vorhanden
- zusaetzlich echter Nachweis auf 131 als Nicht-Root-Betriebsnutzer
(sudo -u nexarch): direkter Ueberschreibversuch scheitert real,
Automatiktest selbst laeuft als root und uebersprang diesen Teil
bewusst
Pruefungen siehe archive/docs/RET-04-PRUEFPROTOKOLL.md
Migration 0008: retain_until/released_at fuer worm_objects.
wormstore.Put setzt zusaetzlich zu chmod 0400 (RET-04) das Linux-
immutable-Attribut (chattr +i) - verhindert auch Loeschen/Umbenennen,
nicht nur Ueberschreiben, und wirkt anders als chmod auch gegen root
ohne explizites chattr -i. Release/Destroy als kontrollierter, an
retain_until gebundener Freigabe-/Loeschpfad.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Tests je Akzeptanzkriterium: direkter Loesch-/Ueberschreibversuch am
Dateisystem scheitert an chattr +i (auch als root), Release verweigert
Freigabe vor Fristablauf, Release+Destroy loescht nach Fristablauf
real, Destroy ohne Release verweigert. Kapazitaets-Selbsttest
ImmutableLockSupported plus TEST_WORMSTORE_LOCK_DIR, damit der Test auf
tmpfs ehrlich uebersprungen statt falsch bestanden wird.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Build/vet clean, Modul-Testsuite gruen. wormstore-Tests fuer AC1/AC2
skippen ehrlich auf 131: unprivilegiertes LXC-Root auf ZFS erzwingt
chattr +i nicht (EPERM trotz cap_linux_immutable im Namespace-
Boundingset - Pruefung laeuft gegen die gemappte UID). Kein Codefehler,
sondern eine Infra-Grenze dieses Testhosts, dokumentiert als offen statt
erfunden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
RegisterHandler prueft den mitgelieferten tenant_slug jetzt ueber einen
TenantVerifier (Core TEN-01) unabhaengig gegen die Core-Tenant-Registry,
bevor eine Registrierung uebernommen wird - statt der Angabe von DMS/
Mail blind zu vertrauen. Unbekannter/fehlerhafter Tenant-Kontext wird
abgelehnt (403) und protokolliert; ein Verifikationsfehler selbst fuehrt
fail-closed zur Ablehnung (503), nie zur stillschweigenden Annahme.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
- kekclient: Archive-eigener HTTP-Client fuer Core API-10
(internal/kek.Handler.TenantKEKHandler), gespiegelt aus
dms/internal/crypto.HTTPKEKProvider (FDN-09) - Archive kann Cores
internal/kek nicht importieren (getrenntes Go-Modul)
- backupcrypto: AES-256-GCM-Envelope-Primitive (DEK generieren, mit
Tenant-KEK ver-/entpacken) sowie Datei-Ver-/Entschluesselung mit
Envelope-Metadaten-Sidecar
- backup: EncryptGeneration/DecryptedRestore verschluesseln bzw.
entschluesseln die BAK-01-Sicherungsdateien (base.tar.gz,
pg_wal.tar.gz) einer Generation mit dem Tenant-KEK, ohne die
bestehende Restore-Funktion zu veraendern
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
EncryptGeneration liess die von EncryptFile geschriebene Envelope-Sidecar-
Datei am tmp-Pfad zuruck statt sie mit der Hauptdatei an den finalen Ort
zu verschieben - Restore haette den DEK nicht mehr entpacken koennen.
TenantEncryptedConfig baut fuer objectbackup (BAK-01/02) ein Config mit
tenant-KEK-gebundenem restic-Passwort, analog zur DB-Backup-Verschluesselung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
auditclient ruft Core AUD-08 (POST /audit/ingest) per REST auf - Archive
ist physisch getrenntes Modul, kein direkter Import von Cores
internal/audit moeglich. audittrail.Recorder ist der outage-tolerante
Wrapper: ein nicht erreichbares Core blockiert den Fachvorgang nie
(Record liefert nie einen Fehler an den Aufrufer), sondern puffert das
Ereignis in archive_audit_outbox; Replay meldet gepufferte Ereignisse
vollstaendig und in Anlege-Reihenfolge nach, sobald Core wieder
erreichbar ist.
wormstore.Put/Destroy (bislang ohne Aufrufer) nehmen neu tenantSlug/actor
entgegen und melden Sperre (retention.worm_lock_set) bzw. Loeschung
(retention.object_destroyed).
Nicht umgesetzt, da die Fachfunktionen selbst noch fehlen: Audit-Hooks
fuer Legal-Hold/Sperre-Verwaltung (RET-03, nicht implementiert) und
eDiscovery-Export (CMP-03, nicht implementiert) - audittrail.Recorder
ist bereits so gebaut, dass beides ein Zwei-Zeiler wird, sobald diese
Kacheln existieren. Ausserdem fehlte bislang ein Schreib-Endpunkt in
Core fuer externe Module - siehe separater Commit AUD-08
(feature/aud-08-audit-ingest-endpoint-fuer-externe-module, eigener
Branch da Core-Modul).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gespiegelt von Core QA-01: Testpyramide (Unit/Integration/Wiederherstellungs-
test/Extern), Pflichttests fuer sicherheitskritischen Code als technisch
erzwungenes Merge-Gate statt Dokumentationsvorgabe.
Sicherheitskritische Bereiche fuer Archive (docs/TESTSTRATEGIE-ARCHIVE.md
Abschnitt 3): wormstore (WORM-Durchsetzung selbst), rbacclient/retentionapi
(Zugriffspruefung), tenantregistryclient/kekclient/backupcrypto (Tenant-/
Schluessel-Bezug). internal/pflichttestgate + cmd/pflichttestgate pruefen
das automatisiert gegen den PR-Diff, .gitea/workflows/archive-pflichttest-
gate.yml fuehrt es in CI aus (Pfad-Filter auf archive/**, da Monorepo mit
mehreren physisch getrennten Go-Modulen).
internal/referenceset liefert den in Abschnitt 4 definierten, synthetischen
Referenzdatensatz (Retention-Objekte je Fristklasse, WORM-Nutzdaten in drei
Groessenklassen, Backup-Generationen mit geteilten/eindeutigen Bloecken) -
keine echten Kunden-/Mandantendaten (DSGVO-Vorgabe), reproduzierbar per
festem Seed, Nachweis in referenceset_test.go.
Offen: Gegenlesen durch zweite Person (Akzeptanzkriterium 3) - wie bei
Core QA-01 im PR nachzutragen, blockiert nicht das technische Inkrafttreten
des Gates.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Umsetzung
Gespiegelt von Core QA-01: Testpyramide, Pflichttest-Gate als technisch erzwungenes Merge-Gate (nicht nur Doku), Referenzdatensatz-Konzept.
Sicherheitskritische Bereiche: wormstore, rbacclient, retentionapi, tenantregistryclient, kekclient, backupcrypto — internal/pflichttestgate + cmd/pflichttestgate prüfen automatisiert gegen den PR-Diff, .gitea/workflows/archive-pflichttest-gate.yml führt es in CI aus (Pfad-Filter archive/**).
internal/referenceset liefert den synthetischen Referenzdatensatz (Retention-Objekte je Fristklasse, WORM-Nutzdaten in 3 Größenklassen, Backup-Generationen mit geteilten/eindeutigen Blöcken) — keine echten Kundendaten, reproduzierbar per festem Seed.
Prüfungen
Gate zusätzlich real gegen echten Diff verifiziert: geänderte wormstore.go ohne Testdatei → Exit 1 mit korrekter Fehlermeldung.
Pull request closed