# INT-06 — E-Mail-Regel-Engine über API steuerbar: Prüfprotokoll

Datum: 2026-09-01
Host: 192.168.1.131 (Build/Test/Lint), rsync + ssh
Pakete: `mail/internal/mailrulesapi` (neu), `mail/internal/mailrules` (erweitert)

## Umsetzung

`mailrules.Store` (IMP-03) hatte bislang nur `Create`/`List`/`Delete` —
kein `Update`. Ergänzt um `Store.Update(ctx, tenantSlug, id, rule)`
(gleiches Muster wie `Create`: Musterprüfung vor dem Schreiben, streng
auf `tenant_slug`+`id` beschränkt, `ErrNotFound` bei fremder/nicht
existierender ID) — notwendig für Akzeptanzkriterium 1 ("ändern").

Neues Paket `mail/internal/mailrulesapi`: vier Endpunkte
(`GET`/`POST /api/v1/mail/rules`, `PUT`/`DELETE
/api/v1/mail/rules/{id}`), `tenant`-Query-Parameter Pflicht, gleiche
Konvention wie `mailapi` (INT-01). **Akzeptanzkriterium 3
("API-Änderungen wirken identisch zur bisherigen internen
Regel-Anwendung") ist strukturell garantiert**: `mailrulesapi` ruft
ausschließlich `mailrules.Store` auf — denselben Store, den IMP-03s
Import-Pfad ohnehin verwendet. Es gibt keinen zweiten,
parallelen Schreibpfad, der abweichen könnte.

## Pflichtprüfung 1: Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab

`TestContract_CreateUpdateDeletePrioritize`: vollständiger Zyklus über
echte HTTP-Requests — Anlegen (201), Priorität ändern (200, `Priority:
10 → 1`), Einsehen (Liste zeigt aktualisierten Wert), Löschen (204),
erneutes Einsehen (leere Liste).

Ergebnis: **BESTANDEN**.

## Pflichtprüfung 2: über API gesetzte Regel wird beim nächsten Import korrekt angewendet

`TestIntegration_RuleSetViaAPIAppliedCorrectlyByEngine`: Regel über
einen echten HTTP-`POST`-Request angelegt, danach über GENAU DEN WEG
gelesen und ausgewertet, den IMP-03s Import-Pfad geht
(`store.List` → `mailrules.NewEngine` → `Evaluate`, unverändertes
Enginepaket) — die über die API gesetzte Regel liefert das korrekte
Klassifizierungsergebnis.

Ergebnis: **BESTANDEN**.

## Pflichtprüfung 3: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten

`TestIntegration_RuleChangeIsolatedPerTenant`: Mandant A legt eine
Regel über die API an; Mandant B sieht sie nicht in seiner Liste;
Mandant Bs Update-Versuch mit der ECHTEN, bekannten ID von Mandant As
Regel liefert `404` (nicht etwa eine stillschweigend erfolgreiche
Übernahme); Mandant As Regel bleibt danach nachweislich unverändert.

Ergebnis: **BESTANDEN**.

## Akzeptanzkriterien

1. **Regeln lassen sich vollständig über die API anlegen, ändern und
   löschen**: durch Pflichtprüfung 1 belegt.
2. **Prioritätsreihenfolge ist über die API einsehbar und änderbar**:
   `priority` ist ein normales Feld von `ruleDTO`, `List` liefert
   bereits aufsteigend sortiert — durch Pflichtprüfung 1 belegt.
3. **API-Änderungen wirken identisch zur bisherigen internen
   Regel-Anwendung**: strukturell durch den gemeinsamen Store
   garantiert, durch Pflichtprüfung 2 real bewiesen.

## Build/Vet/Lint/Test — Gesamtmodul

```
go build ./...    → OK
go vet ./...      → OK
golangci-lint run ./... → 0 issues
go test ./... -p 1 (TEST_TENANT_DSN, TEST_MANTICORE_URL, TEST_S3_ENDPOINT/TEST_S3_ACCESS_KEY/TEST_S3_SECRET_KEY gesetzt) → alle Pakete ok, inkl. neuem internal/mailrulesapi
```

Keine Regression — insbesondere die bestehenden `mailrules`-Tests
(IMP-03/IMP-09) bleiben nach der `Update`-Erweiterung unverändert grün.

## Ergebnis

INT-06 erfüllt alle Akzeptanzkriterien mit echten, ausgeführten
Nachweisen. Freigeschaltet: QA-06 (zusammen mit INT-09/INT-10, weiterhin
extern blockiert).