RegisterRoutes ruft jetzt verifier.Expect("mail", "", true) selbst auf, statt sich auf den
Aufrufer zu verlassen. Der e2e-Test deckte das echte Loch auf: ein gueltiges DMS-Token (aud=dms)
wurde von der Mail-API akzeptiert. Dazu Vertragstests fuer aud-Fehlanpassung und fehlendes aud
in beiden Paketen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mandant kommt ausschliesslich aus dem Core-Modul-Token (mail/internal/moduleauth,
Kopie des DMS-Verfahrens, eigenstaendig weil separates Go-Modul); der
tenant-Query-Parameter wird nicht mehr gelesen. Jede Route in mailapi und
mailrulesapi verlangt einzeln ein gueltiges Token.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
patrickandClaude Sonnet 5