- tools/monitor.py: weekly SQL digest over bot_traces/bot_trace_events —
pipeline funnel, Jev health (failures/latency/tokens/model drift vs pinned
jev-1.13.0), user-choice quality proxy (Jev↔user A/B), difflib fallback
volume, STT provider health, and the plan-§4.5 archive guard (>5GB or
>100k events/month -> «archive, do not delete» session); real-traffic only
by default (calibration/test traces excluded, --include-calibration shows
all); writes markdown to data/reports/; --check exits 1 on warnings
- docs/DEPLOY-AND-MONITORING.md: deploy checklist — server env vars (TypeSafe
key via Coolify env or bot/.env), recreate-not-restart for new mounts,
single-Bale-poller rule, smoke tests per plan §7.12, one-env rollback
(JEV_ENABLED/OBS_ENABLED=false); bot server deployment deliberately stays
an owner decision (no service added to the Coolify compose)
The bot service in docker-compose.yml builds from ./bot, but the agent code lived in 'ai procurement/' and ./bot was only a Windows junction on reza.g's machine (and was gitignored) — exactly as the team reported: 'bot/ was never committed — prod-v7's bot is un-buildable from the repo.'
- junction removed; 'ai procurement/' renamed to 'bot/' via git mv (all 41 files keep their history as pure renames)
- 'bot/' dropped from .gitignore (voice/ stays ignored — runtime voice notes; bot/.env stays ignored by bot/.gitignore)
- compose needs no change: context: ./bot and ./bot/app now resolve to committed files
- bot/INTEGRATION-REPORT.md added: full story (problem, root cause, git state, security note on the committed BALE_BOT_TOKEN / AI_API_KEY compose defaults, and usage instructions for the team)
Verified: 41 renames staged with zero secret/cache files; voice/ and bot/.env still ignored.
whqreza