Same cron rendered different ways. The first one (A+) shows what Option A looks like with family/system context layered on top — the answer to "where does this fit in the bigger picture?" Below that, the original A/B/C/D for reference.
Same 3-column workflow as A, plus a family banner and step strip on top so you can see where this cron sits inside its pipeline. Example: pbr-pipeline-daily, step 3 of the PBR Recruiting Pipeline.
What you get from the family layer: a one-glance answer to "what does this thing belong to?" The banner names the system in plain English. The step strip shows the whole pipeline with this cron highlighted. The prev/next links let you walk the chain like a checkout flow.
How it adapts: sequential pipelines (PBR, daily-pipeline, program-end-dates) render as a step strip. Networked clusters (Program Writer, Chip Agent) would render as a small node-and-arrow map instead of a strip. Standalone crons with no family hide the banner entirely.
What you'd need to build it: two new optional fields on registry.yaml — system: pbr-recruiting (group key) and system_step: 3 (sequence). Plus one new file tools/cron-map/systems.yaml mapping each system key → name + plain-English purpose. The strip and banner auto-render from those.
Three columns flowing left to right: Triggered By, This Cron, Effects.
What's good: Reads exactly like a HubSpot workflow. Eye flows left to right. Easy to scan.
What's not: Three columns get cramped on phone. Long property names wrap awkwardly. Needs a collapse-to-stacked treatment for narrow screens.
Top to bottom. Each section a labeled block, chevrons between. Mobile-friendly by default.
program_end_dates_per_athlete()pw_workouts.calendar_date (grouped by stream)What's good: Reads cleanly at any width. Each section has room to breathe. Empty sections degrade gracefully ("none known"). Easy to add new section types later.
What's not: Less workflow-y feeling than Option A. Five sections is a lot of vertical real estate before you see the whole picture.
Cron sits in the center, sources fan in from the left, effects fan out to the right.
program_end_dates_per_athlete()
What's good: Most "Miro-like." The cron's place in the network is instantly visual. Looks great when the panel is wide.
What's not: Doesn't reflow on narrow screens — desktop only. SVG curve positioning has to be computed per cron based on how many upstream/downstream items it has, which is the most engineering work of the four. Aesthetic ceiling is high but so is the cost.
No diagram. Just structured, scannable text. Like a great GitHub issue body or readme block.
Refreshes each athlete's throwing and strength program end dates by reading the latest workout in each stream from PW Supabase, then writes the dates to HubSpot contacts. Property-write only. Fast.
0 4 * * * — 4:00 AM CT dailypython3 tools/contacts/sync_program_end_dates.pyprograms-sync-midday — runs the same script via the 1pm pipelineprogram_end_dates_per_athlete()pw_workouts.calendar_date grouped by streamthrowing_program_end_datestrength_program_end_dateprograms-sync-midday cron cross-checks against this outputWhat's good: Cheapest to build, easiest to keep accurate, scales to 100+ crons without breaking. Reads great on any device. Empty fields just collapse.
What's not: No actual visual. Doesn't fully satisfy the "I want to SEE how this fits in" instinct that prompted the question.