Fitness OS
A training system built from logged workouts and nutrition.
- Claude API
- Fitbee (nutrition) + Hevy CSV export (workouts) ingest
- programming loop
- Supabase (heartbeat)
The Pitch
Problem. This system is early and still being built. Training is a domain where I have real data flowing (workouts logged in Hevy, calories and macros logged in Fitbee, a weekly weigh-in) but no system tying it together yet. Rather than wait until it’s polished, the page shows the current state and tracks progress in the changelog.
System. The blueprint is a standardization loop, built in stages: ingest the raw signals (workouts from a Hevy CSV export and nutrition actuals from Fitbee, joined to the weekly weigh-in), then a weekly programming loop where the AI drafts next week’s training from last week’s actuals and a human approves it, a monthly performance-review memo, and a quarterly program redesign. Today only the early pieces exist; the rest is roadmap. The maturity score is 2.
Payoff. A training system that programs itself from what I actually did, rather than from a generic plan. Because it’s early, the changelog tracks what changes week to week.
The Loops
The weekly weigh-in and macro-adjustment cadence is running today; the automated ingest and programming loops are defined but not yet built.
| Cadence | What happens | Automation |
|---|---|---|
| continuous | Ingest — workouts (Hevy CSV export) + calories/macros (Fitbee), joined to the weekly weigh-in (v1 loop being defined) | full |
| weekly | Programming loop — AI drafts next week from last week's actuals | human-approve |
| weekly | Weigh-in + calorie adjustment vs the 12-week glide path | human-approve |
| monthly | Performance-review memo — trends, adherence, what to change (draft auto-generated; acting on it is human-approve) | full |
| quarterly | Program redesign | human-approve |
AI Architecture
Three named roles. Most are still on the roadmap; this is the design, not the current state:
- ingest
- programmer
- reviewer
- Ingest. Normalizes the raw exports — the Hevy workout CSV and Fitbee nutrition log — into a clean weekly picture of actuals: what got trained (sets, loads, RPE), calories and protein actually logged, and the bodyweight trend from the weekly weigh-in. The foundation everything else reads from. (v1 in definition.)
- Programmer. The weekly draft engine: takes last week’s actuals and proposes next week’s training and macro targets. It produces a draft and never auto-applies.
- Reviewer. Writes the monthly performance-review memo from the trend data and flags what to change heading into the next block.
Where the human gate sits. This is a heavily human-gated system by design, which fits a domain where the cost of a bad automated call is real fatigue or injury. Ingest and the memo draft can run automatically; every programming and nutrition change is human-approve. The AI proposes the week; the human accepts it.
This page surfaces trends and adherence %, never raw body data: no weights, no measurements, no raw health numbers, only whether the system is being followed and which way the trend points.
The Flowchart
flowchart TD
EXPORT["Hevy CSV (workouts)<br/>+ Fitbee (nutrition)"] --> INGEST["Ingest<br/>(normalize actuals)"]
INGEST --> ACTUALS[("Last week's actuals")]
ACTUALS --> PROG["Programmer<br/>drafts next week"]
PROG --> GATE{"Human<br/>approve?"}
GATE -->|approved| WEEK["Next week's<br/>training + macros"]
GATE -->|adjust| PROG
WEEK --> TRAIN["Train + log<br/>(Hevy + Fitbee)"]
TRAIN --> EXPORT
ACTUALS --> MEMO["Reviewer<br/>monthly memo"]
MEMO --> QTR["Quarterly redesign"]
QTR -.->|resets| PROG
TRAIN --> METRICS["Adherence % · trends"]
METRICS --> HEART[("Heartbeat")]
Challenges & Lessons
- Publishing it early. Rather than wait until it’s impressive, the system is published unfinished and labeled, with the changelog showing progress over time.
- Start the loop small. The temptation with fitness data is to ingest everything and build the full programmer on day one, which is how a project like this stalls. The v1 loop is the smallest thing that closes: pull the Hevy export + Fitbee actuals → draft a week → approve. Complexity comes later.
- Privacy is a design constraint. Health data is the most sensitive data any of these systems touch, so surfacing only trends and adherence % (never raw body metrics) is built in from the start.
- What I’d redo. Nothing yet; the system is too early. This will fill in as the loops run.
Live
60–90s screen capture stands in until a live surface exists.
What you see (v1): a short 60–90s screen-capture video walking through the system as it stands, plus a simple metrics panel showing adherence % and trend direction, not raw numbers. The panel is sparse now and grows as the loops come online.
What you do: check back. For now the changelog and roadmap below are the main thing to follow. As the ingest and programming loops ship, this section moves from video to a live metrics panel.
Changelog & Metrics
Recent activity (newest first — final entries come from CHANGELOG.md)
- 2026-06-13 — Cut underway (~week 3 of 12); weekly meal-optimization cadence established.
- 2026-06 — Week-4 cut meal plan + macro refresh; weekly weigh-in vs the 12-week glide path running.
- 2026-06 — Fitness OS capsule scoped for the Portfolio Hub.
- 2026-05 — Project opened; v1 ingest loop being defined.
Metrics this page surfaces (trends/adherence only — no raw body data is ever surfaced)
-
adherence_pctheartbeat - Adherence (this block)
-
weeks_programmedheartbeat - Weeks programmed by the loop
-
phase_labelheartbeat - Current phase
Roadmap
- Define the v1 ingest loop — the smallest closed loop: normalize the Hevy workout export and Fitbee nutrition log into a weekly picture of actuals. (First milestone.)
- Weekly programming loop — AI drafts next week from last week’s actuals; human approves.
- Monthly performance-review memo — auto-drafted trends + recommendations.
- Quarterly program redesign — the long-horizon reset.
- Meal-Prep Loop — Sunday: macro targets + preferences → menu, grocery list, cook plan.