Robots

• Source data: tools_visits, fed by the beacon in /assets/eo-theme.js (one hit per page, per browser, per day, never from an iframe) and tools_pages, rewritten at every deploy by scripts/pages-inventory.js.
• The same numbers sit next to every link on /alllinks (grey: last visit and 90-day count, red: no visit in 90 days) and behind GET /api/visits?days=90.
• Manual trigger: POST /admin/unused-pages-now?token=… on the worker, &dry=1 computes without sending.

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

• Why it was stopped. Forja moved to a two-event international setup on 23/08/2026 (EU + Americas, and APAC) with dedicated schedules 2273434 and 2273427 that this robot does not know about. Leaving it running would have kept rewriting three schedules nobody uses for Forja any more.
• Second reason. The STARTS hours were tuned against AL's Google Calendar, now read in Vietnam time (email routines 09:00-09:45, Posting 18:00-18:30, evening emails 20:30-21:00). AL has lived in Vietnam since June 2026, so those bounds are a leftover, not a real constraint.
• How the stop is implemented. A STANDBY = true constant at the top of src/cal-randomize.js. The function logs and returns before any Cal.com call. The cron trigger itself is untouched in wrangler.toml, so re-arming is a one-line flip plus a redeploy.
• Careful with the Run now button above. It still fires the endpoint, which now returns {"standby": true} and does nothing. That is expected, not a failure.
• Historic behaviour, for reference: randomized MON afternoon / WED morning / FRI evening over 4 weeks and rotated byCaliber / Forja / EO across the 3 daily slots, to make the calendar look like a real busy life rather than three fixed slots.

• 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 < <current month start - 6 months> (6-month rolling retention in D1 since 2026-08-27; the R2 dump still covers everything before the current month, a strict superset of the delete).
• 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).
• Closed loop since 2026-08-09: when a run reaches 100% on the video board, PATCH /api/admin/video-runs/:id flips the matching planner row to Status = Posted (functions/_lib/notion-planner.js), so the row drops out of the Ongoing/Planned filter this cron reads and no empty V{N} shell is recreated for an already published video (the V8 - Beating Women shell used to come back every hour). Match is exact on the V number parsed from the run label, never on the title; 0 or 2+ candidates write nothing and log the reason; the Notion call is fire-and-forget and never fails a board save; only the transition to completed fires it, past runs are not backfilled.
• 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 (table oauth_tokens, row service='google_calendar', migration 0010). The robot refreshes the access token itself when it has expired.
• Pipeline, 4 steps: read the oauth_tokens row and refresh the access token if needed → list the primary calendar from now to now + 28 days → for each event, match any attendee email against the contacts table (keywords mentorship / mentoring / coaching / EO / elite outsiders also classify) → UPSERT into bookings, idempotent on external_id prefixed gcal:. The is_mentorship marker goes in raw_json because the bookings schema has no dedicated column for it.
• Secrets required: GOOGLE_OAUTH_CLIENT_ID and GOOGLE_OAUTH_CLIENT_SECRET on the worker. If either is missing the run is skipped with a non-fatal warning in the logs, so the cron never enters an error loop. A silent skip looks exactly like a clean run in the dashboard: check the logs, not the absence of an alert.

• 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.
• Transitions-only dedup (2026-08-27): last breach fingerprint persisted in KV BACKUP_STATE key error-events-watchdog:v1. Identical breach = suppressed. New error_events rows (max id change), a changed breach set, or a recovery each trigger exactly one mail. Fix for the identical daily bounce_rate alert sent since 2026-05-13.

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

• Same SQL and same metric names as the tools endpoint /api/admin/social/youtube-fetch, so the cron and the Run now button produce indistinguishable rows. If one changes, change the other in the same commit.
• Writes through the worker EO_DB binding, which is SELECT-only by convention everywhere else. This is the single documented exception, and it touches only social_snapshots and social_posts.
• Quota: roughly 4 units per run against the YouTube Data API daily budget of 10 000. The expensive search call is a fallback only, used if the channel has no uploads playlist.
• Shorts versus long is a duration heuristic at 180s, accurate to about 85-90 percent. A vertical video under 3 minutes can be misfiled.

• Upsert on (code, platform), never a DELETE; a field Notion leaves empty never erases a stored value. Rows without a Code are counted per base, not written. Other D1 rows of the same code and planner row get the new date and status.
• Status: backup (Status Backup, SBY, Backlog), posted (Done or Posted, or in PostFast with a past date), scheduled (PostFast Post Id, Posted Platforms, Posted At or Kit Broadcast ID with a future date), planned otherwise. Dates rewritten in Vietnam local time.
• Second documented write exception of the worker EO_DB binding (after CRON19): only content_posts and content_posts_sync_runs (migration 0057, one row per run, read back by GET /api/content-posts as sync).
• Manual trigger: POST /admin/content-posts-sync-now?token=… on the worker, &dry=1 reads Notion and builds the rows without writing. Fallback: node scripts/content-posts-import.mjs in eliteoutsiders-tools.