Produktentscheidung 07/2026: ungenutzte Credits verfallen zum
Periodenende, es gilt der harte Monatsdeckel wie verkauft. Der
Uebertrag (credits_rollover/credits_carried) fliegt komplett raus:
roll_credit_period setzt nur noch Verbrauch + Warnflag zurueck,
check_license rechnet verfuegbar = credits_total, die Migration legt
die beiden Spalten gar nicht erst an (Live hat sie nie bekommen, die
Promote-Warteschlange enthielt sie noch). ABRECHNUNG.md angepasst.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ergaenzt phone im telegram_session-Status, damit das Portal die
Telegram-Zeile im Reiter Recherche-Zugaenge vollstaendig fuellen kann.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Key-Value-Tabelle system_status (idempotente Migration). Der Monitor
prueft die Telethon-Session beim Start und taeglich um 04:30 (eigener
Scheduler-Job) und schreibt ok/account/error unter dem Key
telegram_session. Das Verwaltungsportal zeigt den Eintrag im Reiter
Recherche-Zugaenge an, damit ein Session-Ausfall sichtbar wird statt
nur im Server-Log zu stehen. Fehler beim Pruefen stoeren den Betrieb
nie (try/except, eigene DB-Connection wie beim Health-Nachtjob).
Promote-Reihenfolge wie gehabt: Monitor VOR Verwaltung (Migration).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bisher fiel eine 0 durch das or-80-Muster still auf die Voreinstellung
zurück, ein Abschalten der Warnung war unmöglich. Jetzt gilt, 0 = aus,
NULL = Voreinstellung 80, alles andere wie gehabt. Das Verwaltungsportal
bietet die 0 in seinen Formularen an.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Tabelle user_activity_days (user_id, day, tenant_id, ein Eintrag je
Nutzer und Kalendertag), angelegt per idempotenter Startup-Migration.
Geschrieben wird sie in get_current_user bei jeder authentifizierten
Nutzung, ein In-Memory-Tagesmerker begrenzt das auf einen INSERT OR
IGNORE je Nutzer und Tag, Fehler werden geschluckt und blockieren nie
eine Anfrage. Gelesen wird die Tabelle nur vom Verwaltungsportal für
die neue MAU/DAU-Statistik. Ein reines Login-Protokoll wäre zu grob,
weil das JWT 24 Stunden hält.
Getestet gegen eine DB-Kopie, Tabelle entsteht, je Nutzer und Tag
genau ein Eintrag trotz Mehrfachaufruf.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die Credits-Sätze je Aktion stehen jetzt in der geteilten Tabelle
billing_tariff statt nur in der Konfiguration. Die Migration legt die
Tabelle an und befüllt sie einmalig mit den wirksamen CREDIT_TARIFF-
Werten, danach liest _charge_credits() bei jeder Buchung die Tabelle,
fehlende Schlüssel oder eine fehlende Tabelle fallen auf die
Konfiguration zurück. Damit können Monitor und Verwaltungsportal
dieselben Sätze anzeigen und das Portal kann sie künftig pflegen,
eine Preisänderung braucht keinen Server-Eingriff mehr.
Getestet gegen eine Kopie der Staging-DB. Seed mit 7 Sätzen (45/40/
12/12/1/1/1), Buchung nach Tabelle, Tabellenänderung greift sofort,
Rückfall auf die Konfiguration ohne Tabelle.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
