Robots

• 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.
• Runs 4h BEFORE the weekly-snapshot (08h UTC) so the weekly report benefits from a freshly updated inventory.
• Automatic stale-cleanup: any page removed from the sitemap is removed from the inventory (with its buttons). Skipped if the sitemap fails (guard against accidental wipe).
• Read by tools.eliteoutsiders.com/page-flow (User Journey / Traffic Flow). Also triggerable manually via the "Refresh now" button on that page.

• On the 1st of each month at 04h UTC (1h after the backup 0 3 1 * * to avoid loading the network during the R2 upload), this robot crawls every known URL of the site (open + me + admin + tools), compares against the EXPECTED baseline in the code, and sends a Resend email summary to AL.
• Performs ZERO auto-fix. Pure audit: "here are the URLs that respond differently than expected, up to you whether you fix or update the baseline".
• To extend the URL list: edit EXPECTED in 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.

• Why: AL's rule is "1 planner row = 1 folder, name carries the video number + current title". Before this cron the folder names drifted from the planner titles silently (V8 was created by hand). Now Notion is the single source of the name and Finder follows within the hour.
• Source of truth: Notion Long Form Content Planner DB 04428224657182ee8f3d81fc0fbe50b0, rows with Status = Ongoing or Planned. Folder name = V{N} - sanitize(title) (slashes/colons stripped, length capped).
• Behavior: missing folder → created by copying _template · folder found under an old title → renamed in place (contents untouched) · row removed or status changed → folder LEFT ALONE (no deletion, ever — cleanup stays a human decision).
• Known limit (audit 26/07, finding 10): FINDER buttons on the LF board store absolute paths; a rename here does not rewrite them. Mitigation today: board buttons point at stable parents (ongoing/), not at V{N} folders. Fix tracked in backlog.
• Not on /crons live status: launchd has no pulse endpoint yet (audit finding 22, backlog) — check the log file to confirm the last run.

• 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.

• Why: server-side errors logged via functions/_lib/log-error.js (e.g. 500 on /api/admin/trauma-maps/[id]) are silent until AL clicks the broken thing. This watchdog flags them within 24h of occurrence.
• Sources currently wired: /api/events, /api/auth/magic-link (Resend fail), /api/trauma-map/save (DB error), /api/admin/trauma-maps/[id]. Any new endpoint can opt-in by importing logError and calling it in the catch block.
• Email shows: total count + breakdown by level + breakdown by source + latest 20 errors with timestamp/level/source/status/path.
• "Silent on zero" by design — if you go a week without an email, all good. If you want to test, hit the manual trigger.

• Why: a Notion page that moves or gets deleted turns into a silent dead button on the board. Three such dead IDs were found by hand on 2026-07-25 after a hub reset. This makes it automatic.
• Checks: dead Notion links · empty enabled buttons · XXX placeholders · tasks with neither prompt nor URL · wave distribution · phases with zero step · SBY parking size. SBY content is excluded from drift on purpose.
• False-positive guard: the Notion API answers 404 both for a deleted page and for a page not shared with the worker integration. If more than 40% of checked links answer 404, the run flags notion_access: limited, moves them to unverified_links and stays silent instead of crying wolf.
• To enable real dead-link detection: share the EO Notion hub with the worker's integration (NOTION_API_KEY). Until then the structural checks still run.
• Persistence alert (added 26/07): if notion_access: limited persists over 2 consecutive runs, the cron emails AL with the fix instruction instead of staying silent — the main check is never allowed to be a silent no-op for weeks.
• Report readable in D1: SELECT value_json FROM intranet_state WHERE key='content_sync_check'.

• Why: AL hand-dates every Notion page title so staleness is visible at a glance, but nothing propagated that to the architecture page. A prompt updated in a week would have shown as current here, in silence. This makes the page reflect reality instead of a snapshot.
• Self-feeding list: on load, /architecture writes the Notion page ids it displays into D1 key architecture_notion_ids. Add a link tomorrow, it is tracked the day after. No manual list to maintain.
• Output: D1 key notion_freshness (per page: real last_edited_time, current title, and the date parsed out of that title). The page only renders it, it never calls Notion itself.
• First run (28/07): 82 pages read in 3 seconds, 34 titles whose hand-typed date lags behind the real edit.
• Known gap: 2 real pages are unreachable because they are not shared with the worker's Notion integration (X posts DB, Threads posts DB). The other 12 misses are Notion column wrappers, not pages, and are expected.

• Why it exists: on 2026-05-28 a real person completed the Trauma Map quiz, ticked the consent box, and never reached Kit. Nobody knew for two months. Root cause: /api/trauma-map/save threw away the result of its Kit call, so a failure left no trace anywhere. Fixed the same day (3 retries + a row in error_events + kit_subscriber_id written back), but a code fix only protects the future. This robot is the net that catches whatever still slips.
• Test addresses are excluded by pattern (@eliteoutsiders.test, @example.com, smoke-, e2e-, mail-tester, and friends) so the report only ever counts real humans.
• Three gaps measured: missing in Kit (repaired), present in Kit but no kit_subscriber_id in D1 (back-filled), present in Kit but absent from D1 (reported only, never inserted blind).
• D1 writes are deliberately narrow: the report key, plus kit_subscriber_id and kit_synced_at on existing rows. No INSERT into contacts, no other column touched.
• First run (28/07, manual): 14 consenting contacts against 27 Kit subscribers, 3 pushed into Kit including the person lost on 28/05, 1 Kit id back-filled, 0 failures.

• Why: before 28/07 nothing read the drafts base. Kit had 3 broadcasts ever (2 April tests + 1 unsent draft). The pipeline wrote newsletters that could not physically leave.
• Guards, in order of what AL fears most: Validation = Yes is mandatory. The send date must be at least 1 hour in the future, a past date is reported and NEVER sent (no wrong-moment post, ever). A row that already has a Kit Broadcast ID is skipped, so nothing is ever scheduled twice.
• The body is taken verbatim from the row's Description. The robot converts line breaks and links to email HTML, it never rewrites a word.
• Columns added to the base on 28/07: Subject, Preview Text, Kit Broadcast ID. Subject and preview live on the row, the row title stays "Newsletter W31" style.
• First run (28/07, manual): Newsletter W31 scheduled, Kit broadcast 25188287, send Saturday 01/08 14:00 Paris (day fixed by AL 28/07: Saturday, Sunday belongs to the long form), all subscribers, content checks clean (0 em-dash, video link present).

• The content guards live in the n8n robot itself: future dates only, past date raises, APPROVED direct, Done + Posted At written back. This cron only presses the button, and mails AL ONLY if the press itself fails (the n8n error notifier covers the rest).
• Idempotent: rows already Done are never picked up again.