Dattavani Backend: Background Jobs Diagram

Each job is a CLI: python -m app.jobs.run_<name> from core-service, with the same .env as the API.
The host crontab runs in UTC (CRON_TZ=UTC). Two jobs are SQL in Supabase pg_cron, scheduled by migrations.
Most CLIs take --dry-run and print a JSON summary to /var/log/dattavani-*.log. run_tataji_prompt has no dry run and no dedup, so a second run notifies every kid again.
Cache warm, analytics backfill and schedule repair are manual. They are not in the crontab.

Deletion purge runs only when R2 is configured; otherwise it aborts the whole run.
A parent with an active Stripe or RevenueCat subscription is skipped and flagged for manual review.
Order: encrypted archive to R2, then Stripe PII scrub and RevenueCat delete, then DB rows and the Supabase auth user.
Chat anonymization keeps messages; it unlinks kid_id and strips kid_id and user_id from message metadata.

get_last_activity_by_kid reads all of activity_logs with no paging. PostgREST caps a response (max_rows = 1000 in config.toml), so inactivity days can be wrong once the table grows.
Reconciliation runs with --dry-run in cron, so it writes nothing; mismatches appear only in the log.
pg_cron blocks schedule only if the extension is already on when the migration runs; otherwise they print a notice and skip.
Weekly leaderboard ranks are computed at read time; run_leaderboard_rank only sends the LDR-03 reset notice.

CRON_JOBS_SETUP.md names migration 20260706140000_ask_tataji_conversation_anonymization.sql; the block now lives in 20260706150000_ask_tataji.sql.
The doc lists EML-27 as pending, but routers/ask_tataji.py now schedules it after a sensitive answer.
run_inactivity_nudge and run_inactive_catchup still exist but are marked deprecated; do not schedule them.