# 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.