internal/channels: konkrete Zustellkanaele fuer CFG-02s Dispatcher.
TemplateStore.Resolve loest Vorlagen pro Tenant auf und faellt auf
GlobalTemplateScope zurueck, wenn ein Tenant keine eigene gesetzt hat
(Akzeptanzkriterium 3). Render nutzt text/template mit
Option("missingkey=error") — ein fehlender Platzhalter bricht das Rendering
MIT FEHLER ab, statt eine unvollstaendige Nachricht zu erzeugen
(Akzeptanzkriterium 1).
EmailSender implementiert notify.Sender: rendert ZUERST die Vorlage, bevor
ueberhaupt eine SMTP-Verbindung aufgebaut wird — schlaegt das Rendering
fehl, wird nie ein Netzwerkzugriff versucht. Ein anschliessend fehl-
schlagender SMTP-Versand liefert einen Fehler, den CFG-02s bereits
getestete Wiederholungslogik verarbeitet (kein zweiter Retry-Mechanismus
hier). InAppSender persistiert In-App-Nachrichten ueber InAppStore
(Akzeptanzkriterium 2, ueber API abrufbar/als gelesen markierbar). Router
waehlt den Kanal anhand Notification.Channel — ein neuer Kanal wird per
Register() ergaenzt, ohne Dispatcher oder Router umzubauen.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Vorlagenrendering mit fehlenden Platzhaltern bricht kontrolliert ab —
TestRender_MissingPlaceholderAborts und
TestEmailSender_AbortsBeforeSMTPWhenTemplateMissing (Fehler kommt von der
Vorlagenaufloesung, kein SMTP-Verbindungsversuch). PASS.
2. In-App-Benachrichtigung nach Markierung als gelesen korrekt gefuehrt —
TestInAppStore_MarkReadIsReflectedCorrectly. PASS.
3. E-Mail-Versand bei nicht erreichbarem SMTP-Server loest dokumentiertes
Retry-Verhalten ueber CFG-02 aus —
TestEmailSender_TriggersDispatcherRetryOnUnreachableSMTP: echter
EmailSender gegen unerreichbaren Host, ueber notify.Dispatcher
eingereiht, nach ausgeschoepften Wiederholungen status=failed mit
korrekter Versuchszahl. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/cfgservice: Store (Schreiben/Historie) + Service (Lesen mit
Vorrangregel + TTL-Cache, Default 5s, analog internal/flag). Genannt
"cfgservice" statt "config", da internal/config bereits die Bootstrap-
Konfiguration des Core-Prozesses selbst belegt.
Store.Set schreibt aktuellen Stand (config_values) und Historieneintrag
(config_value_history) atomar in einer Transaktion — eine Aenderung ohne
Versionshistorie ist strukturell ausgeschlossen (Akzeptanzkriterium 2).
Version wird pro (key, scope) monoton hochgezaehlt.
Service.Resolve wendet die Vorrangregel an: Tenant-spezifischer Override
(scope = Tenant-Slug) hat Vorrang vor globalem Default (scope = 'global'),
faellt sauber zurueck wenn kein Override existiert (Akzeptanzkriterium 1).
Invalidate erzwingt sofortiges Neuladen fuer den Schreiber, andere Instanzen
sehen Aenderungen spaetestens nach der TTL.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Vorrangregel automatisiert getestet —
TestService_TenantOverrideTakesPrecedenceOverGlobal: Tenant mit Override
bekommt Tenant-Wert, Tenant ohne Override bekommt Global-Default. PASS.
2. Cache-Invalidierung nach Aenderung innerhalb dokumentierter Zeit
gemessen — TestService_CacheInvalidationTiming: wirksam nach 154ms bei
TTL=150ms (innerhalb Ziel+Toleranz), vorher nachweislich noch alter
Stand. PASS.
3. Versionierungshistorie ueber mehrere Aenderungen nachvollzogen —
TestStore_HistoryTracksAllChanges: 3 aufeinanderfolgende Aenderungen,
Historie liefert alle 3 in korrekter Reihenfolge mit korrekten
Versionsnummern. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
