Crons

• Photocopies the Kit newsletter (all subscribers + tags) and the site DB (D1), stores 4 files in a private Cloudflare R2 drawer. Like a family photo kept safe.
• 12-month retention. On Jan/Apr/Jul/Oct 1st, runs a restore dry-run on a preview DB to verify backups are readable (quarterly dry-run).
• Each run sends a Resend recap email (✅ ok / ⚠️ partial / ❌ failed) listing what was backed up.

• Watches the 3 public Cal.com pages (byCaliber / Forja / EO) and counts available slots over the next 4 weeks.
• If a slot is dead (another booking blocks it), sends a "DEAD" email so you can decide what to do.
• If you fix the conflict (or weekly chaos moves the slot), you get a "REVIVED" email at next check. No email when all is well — radio silence.
• Memory in Cloudflare KV (key cal_slot_health:v2) — stores state per (event × date) to detect transitions.

• Randomizes slot times for MON afternoon / WED morning / FRI evening over the next 4 weeks, and rotates byCaliber / Forja / EO across the 3 daily 30-min slots.
• Goal: every visitor returning to cal.com a week later sees different times. Creates a "real busy life" feel rather than "well-oiled 3 fixed slots machine".
• Time bounds in the STARTS constant in code (MON 13:00-16:00 / WED 10:00-11:00 / FRI 18:30-19:00). Edit + redeploy to change a bound. Recap email after each run.

• Every Monday morning, reads the DB directly (D1 binding, not via dashboard — gated by CF Access), builds a Markdown with 7d counters + delta vs prior 7d + top 10 pages, and creates a Notion sub-page under the operational hub. Then sends a recap email to alexandre.corne.ac@gmail.com (override via NOTIFY_TO_WEEKLY).
• Resilience: if Notion is down (token/parent_id missing or integration not connected), the email goes out anyway with the markdown embedded — AL never loses the info.
• Code: eo-backup-worker/src/weekly-snapshot.js + Notion helper src/notion.js. Email subject: EO weekly — YYYY-WXX.

⚠ Heads-up — this cron DELETEs rows from the live events D1 table after archiving them to R2. Safe in normal conditions (R2 backup-first, current-month events untouched, R2-fail-HARD prevents data loss), but it's the only cron on this page that touches data destructively. Yellow button = think before you click.

• On the 1st of each month at 02h UTC (1h BEFORE the monthly backup 0 3 1 * * — by design so the R2 dump captures an already-cleaned table), takes prior-month events, dumps JSON to R2 (eo-backups/events-archive/YYYY-MM/), creates a Notion archive page with aggregations (event_type / top paths / activity per day), then only after that runs DELETE FROM events WHERE created_at < <month_start>.
• Why: the D1 base grows fast (5,518 rows in 15 pre-launch days). Without cleanup we pay to store data we never look at live — aggregates land in the Notion page + the weekly report.
• Manual precedent: Analytics Archive — Pre-2026-05-01 (5,518 rows archived 2026-04-30) — format mirrored by renderNotionBlocks().
• Absolute safety (backup-first): R2 fail = HARD, the DELETE doesn't run. Notion fail = soft, the DELETE runs anyway (the JSON on R2 is the official safety net; Notion is read comfort). The recap email always shows the exact state of the 3 steps (R2 / Notion / DELETE).
• Pull an archive: wrangler r2 object get eo-backups/events-archive/2026-04/events-archive-2026-05-01.json

• Every Monday at 04h UTC, this robot fetches eliteoutsiders.com/sitemap.xml, walks each public page, and extracts every clickable element (<a> / <button> / [role="button"] / [data-track-id]). Result: complete inventory of pages + buttons in D1 (page_inventory + button_inventory), even buttons that have never been clicked.
• Tourne 4h AVANT le weekly-snapshot (08h UTC) pour que le rapport hebdo bénéficie d'un inventaire fraîchement mis à jour.
• Stale-cleanup automatique: toute page disparue du sitemap est supprimée de l'inventaire (avec ses boutons). Skippé si le sitemap fail (sécurité contre wipe accidentel).
• Lit par tools.eliteoutsiders.com/page-flow (User Journey / Traffic Flow). Aussi déclenchable manuellement via le bouton "Refresh now" sur cette page-là.

• Le 1er de chaque mois à 04h UTC (1h après le backup 0 3 1 * * pour ne pas charger le réseau pendant l'upload R2), ce robot crawl toutes les URLs connues du site (open + me + admin + tools), compare au baseline EXPECTED dans le code, et envoie un récap mail Resend à AL.
• Ne fait AUCUN auto-fix. C'est de l'audit pur : "voici les URLs qui répondent autrement qu'attendu, à toi de décider si tu corriges ou si tu update le baseline".
• To extend the URL list: edit EXPECTED dans eo-backup-worker/src/url-audit.js.

• Twice a year (1st of January + 1st of July, 05:00 UTC), this robot queries D1 for row counts + last-write timestamp on every analytics table, and the breakdown of event_type values in the events table (30d + total). It then appends a snapshot block to the Notion source-of-truth page 📊 EO Analytics — Source of truth so AL has a history of how the analytics stack has grown over time.
• Companion live mirror: tools.eliteoutsiders.com/backdata/analytics-map queries D1 in real time on every page load (no scheduled refresh needed for the live numbers — they're always fresh).
• To extend the inventory: edit the TABLES list in eo-backup-worker/src/analytics-map-refresh.js AND the mirror in eliteoutsiders-tools/functions/api/admin/analytics-map.js. Keep both in sync.

• Every 30 min, this robot looks in your 3 working dirs (eliteoutsiders-site, eliteoutsiders-tools, eo-backup-worker) and copies anything not yet in Git into a parallel GitHub box called wip-autosave. Like a photocopier passing through your office every 30 min, photographing what's lying on the table without touching anything. If your Mac dies or you close by mistake, max 30 min of lost work.
• Architecture: 3 mirror clones live in ~/Library/Application Support/eo-wip-autosave/. Each run rsyncs your working tree (excluding node_modules, .wrangler, dist, logs) to its mirror, commits + pushes to the wip-autosave branch (never main). Your main working tree is NEVER touched. No main history pollution.
• Recover a copy: git fetch origin wip-autosave && git checkout wip-autosave in any clone of the repo, or directly on GitHub. Commits are timestamped: WIP autosave 2026-05-02T01:39:59Z.

• The robot reads your Google Calendar, detects "client mentorship" RDVs (tagged or with participant email matching an EO user), and inserts/updates the row in bookings with is_mentorship=1. So the "Your Bookings" cell turns green in the client's /me without you touching the DB by hand.
• Why: today bookings rows are created only by the Cal.com webhook. If you book with a client outside Cal.com (manual email, direct GCal event), the client sees nothing in their /me. This robot fills that gap.
• Prereq: Google Calendar OAuth already set up (table oauth_tokens with service='google_calendar', see migration 0010). Code to write: eo-backup-worker/src/gcal-scan.js running on 30-min cron, calls Google Calendar API, normalizes events, INSERT/UPSERT in D1 bookings with idempotency on external_id.