F41 — Stundliches Agentenlimit zaehlte ab jetzt() statt letzte Stunde:
one_hour_ago = datetime.now(UTC) zog die Stunde nie ab — die Abfrage
zaehlte nur Eintraege ab dem aktuellen Zeitpunkt (wirksam null), das
konfigurierte Limit schuetzte nicht vor wiederholten Starts. Fix:
timedelta(hours=1) + Import.
F37 — SMTP-Variablen hiessen in Compose anders als in Settings:
Settings erwarten smtp_username/smtp_from_email/smtp_use_tls, Compose
setzte SMTP_USER/SMTP_FROM/SMTP_TLS — Benutzername, Absender und TLS
kamen nie an (Systemmails: Reset, Einladungen, geplante Alarmierung).
Fix: Compose (app+worker) und .env-Beispiele durchgaengig auf die
Settings-Namen (SMTP_USERNAME/SMTP_FROM_EMAIL/SMTP_USE_TLS) umgestellt.
Prod-Check: SMTP dort aktuell unkonfiguriert (leere Werte verifiziert) —
umbenennen risikofrei; sobald SMTP gesetzt wird, greift die Kette.
Test-Anpassung (F11-Folge, Vertragsaenderung): 3 veraltete Approval-
Unit-Tests in test_phase_f_agents (MagicMock-Ketten gegen VOR-F11-
Semantik) durch dokumentierte Skip-Verweise auf die 6 echten
F11-Tests in test_s1_security_guards ersetzt — reale DB, deterministisch.
Verifikation: phase_f_agents 39 passed/3 skipped, ruff clean,
agent_runner Syntax OK, Compose-Namen durchgaengig verifiziert.
Vorher: seed_admin.py und docker-compose.yaml enthielten einen festen
Passwort-Fallback (Admin123!) — ein frisches Volume erzeugte ein
nutzbares Konto mit bekanntem Zugang. Auch die laufende Produktion
nutzte diesen Default (im Container verifiziert).
Fix:
- seed_admin.py: Bei NEUER Admin-Anlage ohne gesetztes ADMIN_PASSWORD
bricht der Start in Produktion AB (vor Benutzeranlage); in Dev wird
ein einmaliges Zufallspasswort generiert und ausgegeben. Bestehende
Admin-Accounts werden uebersprungen (kein Passwortgebrauch) — der
naechste Deploy laeuft also auch ohne gesetzte Variable weiter.
- docker-compose.yaml: ${ADMIN_PASSWORD:-Admin123!} -> required
(${ADMIN_PASSWORD:?...}) — kein Default mehr.
- .env.example/.env.docker.example: Default durch CHANGE_ME-Hinweis
ersetzt.
Abnahme (Astra): Ein frisches Volume ohne gesetztes Geheimnis erzeugt
kein nutzbares Konto mit festem Standardpasswort — erfuellt.
Phase B Security-Fix (5d1b239) entfernte den Default-Wert für MAIL_ENCRYPTION_KEY,
aber der Key wurde nie in docker-compose.yaml/.env.docker.example/deploy-guide.md
aufgenommen. Das führte zu Container-Crashs beim Deploy da der Key zwingend
erforderlich ist (mail/services.py RuntimeError).
- docker-compose.yaml: MAIL_ENCRYPTION_KEY in crm_app und crm_worker environment
- .env.docker.example: MAIL_ENCRYPTION_KEY mit Generierungs-Anleitung
- docs/deploy-guide.md: MAIL_ENCRYPTION_KEY in Zugänge-Liste aufgenommen
crm_migration role is created by migration 0085, so the first
alembic run on a fresh DB must use crm_user (POSTGRES_USER).
Fixes initial deployment failure on fresh databases.
P34: Remove test_sample plugin from production code
P35: Remove CompanyContact=None dead code from contact.py
P36: Change Plugin.config from Text to JSONB (model + migration 0117 + service)
P37: Add AI comment about workspace overengineering in workspace.py
P38: Add container resource limits to docker-compose.yaml
P39: Guest TTL 1800 not found — already migrated to regular users
P40: Add AI comment about missing IP/Device binding in session.py
P41: Fix Redis healthcheck to use auth password
P42: RLS migration history comment already present in alembic/env.py
Agent Zero