sysops
b3c8d36b58
mailrules.Store (IMP-03) bekommt Update (bislang nur Create/List/
Delete) — gleiches Muster wie Create: Musterprüfung vor dem Schreiben,
streng auf tenant_slug+id beschränkt, ErrNotFound bei fremder/nicht
existierender ID.
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 ist strukturell garantiert: mailrulesapi ruft
ausschließlich mailrules.Store auf, denselben Store, den IMP-03s
Import-Pfad ohnehin verwendet — kein zweiter, paralleler Schreibpfad.
Alle drei Pflichtprüfungen mit echten Nachweisen: vollständiger
Anlegen/Priorisieren/Einsehen/Löschen-Zyklus über echte HTTP-Requests;
eine über die API angelegte Regel wird über genau den Weg gelesen und
ausgewertet, den IMP-03s Import-Pfad geht (Store.List ->
mailrules.NewEngine -> Evaluate) und liefert das korrekte
Klassifizierungsergebnis; Mandant Bs Update-Versuch mit der echten,
bekannten ID von Mandant As Regel liefert 404, Mandant As Regel bleibt
unverändert.
go build/go vet/golangci-lint clean, gesamtes Mail-Modul
regressionsfrei getestet — bestehende mailrules-Tests (IMP-03/IMP-09)
bleiben nach der Update-Erweiterung unverändert grün.
3.5 KiB
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
- Regeln lassen sich vollständig über die API anlegen, ändern und löschen: durch Pflichtprüfung 1 belegt.
- Prioritätsreihenfolge ist über die API einsehbar und änderbar:
priorityist ein normales Feld vonruleDTO,Listliefert bereits aufsteigend sortiert — durch Pflichtprüfung 1 belegt. - 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).