(1) requirements.lock: 323 Pakete exakt gepinnt auf das heute getestete Set (fastapi==0.141.1, starlette==1.3.1, sqlalchemy==2.0.35, alembic==1.19.1, asyncpg==0.31.0, pydantic==2.13.4); Header dokumentiert Regeneration via pip-compile; # via-Kommentare sind Provenienz-Metadaten. (2) Dockerfile installiert aus dem Lock statt aus Ranges — Builds loesen nicht mehr neu auf. (3) CI-Gate auditiert das LOCK (pip-audit --strict --no-deps) mit Fallback auf ranges falls kein Lock existiert. (4) deploy-guide.md: Dependencies-aendern-Workflow dokumentiert.
Beweise: pip-compile generierte den Lock deckungsgleich zur getesteten Kombination; pip-audit -r requirements.lock = No known vulnerabilities; bash -n Syntax OK.
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