How this
site works

Every public page — home, workouts, exercises, generator, about, this page — is prerendered at build time. No database, no API calls, no cold starts in the visitor path. The rule is enforced socially by me and mechanically by an AI reviewer that flags any runtime fetch added to a public page.

The entire training log lives in lib/workouts/data/weeks.json. A library module derives everything else when the site builds: week tags, home-page stats, per-day workout pages, the exercise library, the contribution graph. Add a workout, commit, and every number on the site updates itself. There's a { view json } toggle on every workout page because the data being inspectable is the point.

The workout generator is rule-based and fully client-side: a curated exercise pool with equipment/area metadata, a seeded deterministic builder, zero network. Its input/output contract (options in, structured workout out) is deliberately stable — a future AI coach replaces the selection logic behind the same seam without touching the page.

One corner still talks to a server: the coach section (authoring CRUD behind a login) and some personal logs hit a legacy serverless API. It's quarantined in a single client module and no public page imports it. It shrinks over time; the visitor experience never depends on it.

The chess leaderboard polls the Chess.com public API on a schedule (a real cron, with Telegram alerts for live games), and the strength/running tools are pure client-side math. They predate the redesign and were deliberately preserved — working software doesn't get rewritten for aesthetics.

Every PR runs lint plus a type-checked build, and an AI code reviewer reads the diff against this architecture — static-first contract, data-shape consistency, the don't-break list — then files a formal approve or request-changes verdict. Merge to main deploys production. The training log has better CI than some products I've worked on.