Files

T

sysops ee98efb51e ARC-01: objekt-speicher-anbindung-fuer-mails-anhaenge

- 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

2026-08-30 23:43:12 +02:00

3.3 KiB

Raw Blame History

ARC-01 – Prüfprotokoll: Objekt-Speicher-Anbindung für Mails/Anhänge

Voraussetzung ING-04 – bereits Fertig. ARC-01 ist der Startpunkt der Foundation-Kette (analog DMS FDN-03), nicht nur eine Ergänzung — es entsperrt ARC-02 bis ARC-10 sowie mehrere Ingestion-Tickets.

Umsetzung

Bewährtes Muster aus DMS FDN-03 (LocalDriver/S3Driver-Abstraktion) übernommen — bewusste Neuimplementierung statt Cross-Modul-Import (Mail ist eigenständiges Go-Modul, kann DMS' internal/ nicht importieren):

mail/internal/storage.Driver — Put/Get/Delete, zwei Implementierungen (LocalDriver, S3Driver).
ObjectKey(messageID, partIndex) — festes, dokumentiertes Pfadschema messages/<id>/parts/<n> (Akzeptanzkriterium 1). Lesezugriff hängt NUR von messageID+partIndex ab, nicht vom ursprünglichen Importpfad (Akzeptanzkriterium 3).
Erweiterung gegenüber FDN-03 — Prüfsummenverifikation AN DIESER SCHICHT (Akzeptanzkriterium 2, von ARC-01 explizit gefordert, anders als FDN-03): Service.Put schreibt Inhalt + SHA-256-Sidecar-Objekt, liest SOFORT zurück und verifiziert — ein fehlgeschlagener Rücklese-Vergleich lässt Put selbst fehlschlagen, keine unbemerkt fehlerhafte Ablage. Service.GetVerified wiederholt die Prüfung bei jedem späteren Lesezugriff.
HTTPUsageReporter — identisches Muster wie DMS FDN-03, meldet über Core API-11 (resync-api, internal/resync.Handler.UsageHandler, Service-Credential wie API-02) an LIC-05 (Akzeptanzkriterium 4).

Prüfungen

#	Prüfung	Ergebnis
1	Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt	bestanden – `TestPut_ReadBackIsByteIdentical`: `GetVerified` liefert exakt den geschriebenen Inhalt
2	Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt	bestanden – `TestGetVerified_DetectsTamperedObject`: Objekt direkt am Dateisystem manipuliert (umgeht `Service` vollständig), `GetVerified` liefert real `ErrChecksumMismatch`
3	Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz	bestanden – `TestPut_ManySmallObjectsAcceptableLatency`: 500 reale `Put`-Aufrufe (inkl. Schreiben+Sidecar+Rücklese-Verifikation) in 52,9 ms — 105,8 µs/Objekt, weit unter der 10-ms-Grenze
4	Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe	bestanden – `TestPut_ReportsUsageOnWriteAndDelete` (Fake-Reporter, exakte Delta-Werte); ZUSÄTZLICH real auf 131 gegen den laufenden `nexarch-resync-api.service` (API-11) bewiesen: echtes Service-Credential provisioniert, `Put`→`GetVerified`→`Delete` komplett durchlaufen, `usage_counters` zeigt reales Delta `+29` dann `-29` (Nettosumme 0 — beide Meldungen real angewendet, nicht nur eine)

Build/Test-Ergebnis (192.168.1.131)

go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./...  -> 0 issues
go test ./... -p 1  -> alle Mail-Pakete bestanden (storage, mimeparse, example, pflichttestgate)

Gesamtergebnis

Bestanden. Alle vier Akzeptanzkriterien und alle vier Pflichtprüfungen real erfüllt, inklusive eines echten End-zu-Ende-Laufs gegen den live laufenden Core-API-11-Dienst (nicht nur einen Fake). Entsperrt ARC-02–ARC-10 sowie mehrere Ingestion-Tickets.

3.3 KiB Raw Blame History Unescape Escape