- mail/internal/storage: LocalDriver/S3Driver (bewaehrtes Muster aus
DMS FDN-03, bewusste Neuimplementierung - Mail kann DMS nicht
importieren), ObjectKey mit festem Pfadschema
- Service.Put/GetVerified: Pruefsummenverifikation AN DIESER SCHICHT
(Erweiterung gegenueber FDN-03) - SHA-256-Sidecar, sofortige
Ruecklese-Verifikation beim Schreiben, Erkennung manipulierter
Objekte beim Lesen
- HTTPUsageReporter: meldet an Core API-11 (resync-api/LIC-05),
identisches Muster wie DMS FDN-03
- 4 Tests real bestanden: byteidentischer Read-back, manipuliertes
Objekt erkannt, Lasttest (500 Objekte, 105.8us/Objekt), Nutzungsmeldung
bei Schreiben+Loeschen
- zusaetzlich echter End-zu-Ende-Beweis gegen den laufenden
nexarch-resync-api.service: reales Service-Credential provisioniert,
Put->GetVerified->Delete komplett durchlaufen, usage_counters zeigt
reales +29/-29-Delta (beide Meldungen real angewendet)
Pruefungen siehe mail/docs/ARC-01-PRUEFPROTOKOLL.md
- mail/go.mod: erstes eigenstaendiges Go-Modul fuer NEXARCH Mail
- mail/docs/TESTSTRATEGIE-MAIL.md: Testpyramide (Unit/Integration/
Protokoll-Zustandsmaschinen/E2E/Vertragstests), Pflichttest-Merge-Gate,
Bug-Tracking-Konvention (Gitea-Issues), analog Core QA-01
- mail/internal/example: ein reales, kleines Beispiel (Adress-
Normalisierung) mit je einem Test pro Testart (Unit/Integration/E2E),
6 Tests real bestanden
- mail/internal/pflichttestgate + cmd/pflichttestgate: Merge-Gate-CLI,
echter End-zu-Ende-Beweis (Binary lehnt Verstoss ab, akzeptiert
begleiteten Test), .gitea/workflows/mail-pflichttest-gate.yml
- Ehrlich dokumentiert: kein Gitea-API-Token verfuegbar, daher kein
echter Issue angelegt - Bug-Tracking-Vorgehen stattdessen anhand
eines realen, bereits dokumentierten Befunds (RET-10) durchgespielt,
als offener Punkt vermerkt
- Gegenlesen durch zweite Person (Nutzer) noch ausstehend
Pruefungen siehe mail/docs/TESTSTRATEGIE-MAIL.md