--- project: workout-log-bulletproof-plan classification: forward · comprehensive analysis + implementation roadmap status: authored 2026-05-29 by MBP-Cowork deep-read session last_updated: 2026-05-29 owner: MBP (authors) · mini (executes) · Ken (ratifies) related: - state/projects/workout-log.md (canonical project spec) - state/projects/workout-rebuild-full-spec-2026-05-08.md (Path A architecture) - state/projects/workout-page-deep-analysis-2026-05-20.md (T206 analysis) - state/projects/workout-page-implementation-plan-2026-05-20.md (T210 plan) - state/projects/workout-v3-triage-and-fix-plan-2026-05-12.md (triage) - state/projects/workout-log-xls-db-reconciliation-2026-05-12.md (reconcile design) - state/projects/synthesis/workout-log-synthesis-2026-05-16.md (state of the union) --- # Workout Log System — Bulletproof Plan ## Executive Summary The workout log has been through **70+ trigger scripts, 80+ dispatches, 16+ spec/analysis files, and 8 weeks of iteration** since April 4, 2026. Despite that effort, Ken's lived experience remains: "barely functional" (May 10), "not saving to a database" (May 10), "Failed to fetch" (May 25), wrong day-of-week defaults, and a trust gap that forces continued manual Excel curation. This document is a forensic audit of what exists, what works, what's broken, and a sequenced plan to make the system bulletproof. --- ## Part 1: What Exists (Forensic Inventory) ### 1.1 Two Services, Two Databases, One Excel File | Component | Port | Path | DB | Status | |---|---|---|---|---| | **workout-log app** (daily-driver) | 8080 | `~/Projects/workout-log/` | `workout_log.db` (canonical for app writes) | LIVE via launchd; crash-prone (exit=-15 SIGTERM pattern) | | **command-post** (CP) | 5001 | `~/Projects/command-post/` | `command_post.db` | LIVE; hosts `/workout/v3` route (dark, non-functional save) | | **Excel** | — | `~/...OneDrive.../Documents/Logs/Workout Log/Workout Log.xlsx` | — | **Ken's ground truth**. 7,116 rows, 219 columns. Modified May 28. | **Caddy routing:** `/workout/*` → strip prefix → port 8080 (daily-driver). Bare `/workout` (no slash) falls through to CP on 5001 → 404. This URL nuance has caused repeated confusion. ### 1.2 Database State (OneDrive backup copy, verified 2026-05-29) | Table | Rows | Date Range | Notes | |---|---|---|---| | `daily_log` | 6,812 | 1901-01-01 to 2026-05-26 | Wide scalar table. Only 16 rows in May 2026. **11 Excel-only days not mirrored.** | | `exercises` | 26,281 | 1901-01-01 to 2026-05-08 | Multi-row per date. **Frozen at May 8** — no new exercise rows since. | | `workout_log_atomized` | 76,670 | 2007-09-23 to 2026-05-27 | M.81c Excel parser output. 6,721+ distinct dates, 37 exercises. **This is fresh** (May 27). | | `work_segments` | 73 | 2013-08-20 to 2026-05-29 | Dynamic work time segments. Active. | | `sleep_segments` | 5,940 | 2009-04-08 to 2026-04-04 | **Frozen at April 4.** Backend done; UI never wired. All rows are legacy migration (`source='manual_legacy'`). | | `medications` | 1 | 2026-04-18 | Effectively dead. | | `meds_log` | 131 | 2026-04-24 to 2026-05-28 | Active via morning page meds card. | | `meds_stack` | exists | — | Ken's authoritative daily stack definition. | **Missing tables that specs call for but don't exist:** - `whoop_daily` — spec'd in workout-rebuild-full-spec §4.2. Never created. - `workout_verification_diffs` — spec'd in §2.4. Never created. - `needs_reconciliation_queue` — spec'd in v3-triage §2.3. Never created. - `workout_state_in_progress` — spec'd in §6.1 autosave. Never created. ### 1.3 The Excel File - **3.08 MB**, last modified **May 28, 2026** (yesterday — Ken is actively maintaining it) - 7,116 rows × 219 columns - Contains Rehab PT blocks, single-exercise blocks, simple metrics, body comp — the full picture - The atomizer successfully parses it into 76,670 rows in `workout_log_atomized` - **One OneDrive conflict copy from 2014** exists (harmless) - One manual backup from April 17 exists ### 1.4 The Daily-Driver Page (`daily_log_v2.html`) Served by Flask at port 8080 as a static file via `send_from_directory`. Key characteristics: - **8-stage linear state machine** with collapsible `

` cards - Stage order mismatch: visual position ≠ `data-stage` number (core confusion) - **Three competing prefill mechanisms**: same-DOW defaults, today's saved data, and canonical autofill (runs 1800ms late via setTimeout — guaranteed to lose the race) - **Day-of-week bug confirmed**: canonical endpoint returns wrong day - **Exercise name mismatches**: canonical JSON uses different names than `EX_DEFS` (e.g., "L Side Pulls" vs "Left Side Pulls") — silent autofill failures - **Save toast shipped** (May 22) — green banner, persistent "Last saved at" indicator, `updated_at` column - **Cascade checkboxes shipped** (May 22) — section-level skip - **Saturday/Home defaults fixed** (May 26) — added Chest Press, Back One Arm Row to `EX_DEFS.curls` - **Save indicator shipped** (May 24) — persistent green line survives reload ### 1.5 The v3 Page (dark, non-functional) At `/workout/v3` on command-post (port 5001): - **Light theme** (only light page in the dark system) - **No nav bar** - **Save button disabled** with "Coming soon" tooltip - **9 fields only** (sit_ups, mason_twists, ab_wheel, pushups_actual, pushups_per_set, cardio_time_min, cardio_calories, weighted_vest_lb, location) - **No WHOOP/Withings data** - **Staged fixes exist** in `triggers-staged/workout_v3_fixes/` (CSS, HTML, Python) — never applied ### 1.6 Mockups That Exist | File | What | |---|---| | `Claude/mockups/redesign-options/workout-dark.html` | Dark theme mockup | | `Claude/mockups/redesign-options/workout-light.html` | Light theme mockup | | `Claude/mockups/redesign-options/workout-hybrid.html` | Hybrid mockup | | `Claude/mockups/workout-trust-surface-mockup-2026-05-26.html` | Trust surface mockup (latest, May 26) | | `Claude/state/mockups/workout-log-v2-8stage-mockup-RESTORED-2026-05-17.html` | v2 8-stage restored | **No KL v7 design language page exists.** All mockups are standalone HTML files, none use the paper bg / ink text / Big Shoulders Display / crimson accent / E10b-B mark pattern. --- ## Part 2: What's Worked ### 2.1 Wins 1. **M.81c Excel atomization** — 76,670 rows, 37 exercises, 6,721 dates. Clean, idempotent, fast (0.9s). The single most valuable piece of infrastructure. Last run May 27, data is fresh. 2. **Save pipeline** — POST `/api/log` → `daily_log` works. The May 22 save toast + May 24 persistent indicator closed the UX gap. Ken's May 22 data DID land in the DB (proof: `daily_log` has the row with all values matching). The "not saving" complaints were often UX feedback gaps, not data loss. 3. **Meds logging** — `meds_log` has 131 entries through May 28. The `/morning` meds card integration works. 4. **Work segments** — Dynamic segment UI, 73 rows, active through May 29. Relational Freedom pattern validated. 5. **Caddy routing** — Funnel URL works from any device. No Tailscale required on client. 6. **Saturday/Home defaults** — Fixed May 26. API returns correct 16 exercises; page now has DOM rows for them. 7. **Cascade checkboxes** — Section-level completion tracking shipped May 22. ### 2.2 What Ken Actually Uses Based on `daily_log` entries in May 2026 (16 rows) and `workout_log_atomized` (27 days in May): - Ken logs **most days via Excel** (27 days in atomized table for May) - Ken logs **some days via the app** (16 daily_log rows in May) - The 11-day gap (atomized has data, daily_log doesn't) means **Ken logged those days in Excel only, never through the app** - When Ken does use the app, it's primarily for scalar fields (cardio time, weight, travel status) + work segments - The `exercises` table is frozen at May 8 — **Ken hasn't entered exercise-level data through the app since the atomizer was built** **Implication:** Ken's actual workflow is Excel-first, app-second. The app is a convenience for quick scalar logging, not the primary data entry surface. This matches the "Excel-wins" rule but contradicts the vision of the app as the daily-driver replacement. --- ## Part 3: What's Failed ### 3.1 Chronic Service Instability The workout-log Flask process crashes repeatedly. Evidence: - **exit=-15 (SIGTERM)** pattern in launchd — seen April 28 (RCA runbook authored), May 10, May 25 (18:00 heartbeat: "LAST-EXIT-FAILED") - **May 25 CRITICAL**: Ken's Save returned "Failed to fetch" — browser-level fetch failure, service not responding to POST - **MLX-WAL-contention**: mini's MLX receipt-content-classifier holds WAL locks on SQLite, blocking Flask writes. This is a **system-wide pattern** (also hit `/pm/blockers`) — not workout-specific, but workout eats the pain hardest because Ken uses it during the morning window when the classifier may be running - **No automatic recovery mechanism**: when the process dies, it stays dead until `launchctl kickstart` runs. The launchd `ThrottleInterval` and `SoftResourceLimits.NumberOfFiles` knobs were identified April 19 but never applied ### 3.2 WHOOP/Withings Prefill Never Shipped **Task #20 has been pending since April 22 — 37 days.** The problem is well-understood: - morning-briefing TokenStore refreshes WHOOP + Withings tokens daily ✓ - morning-briefing writes cache files ✓ - workout-log app doesn't read those cache files ✗ - `/workout/api/whoop/today` route doesn't exist (mini probed a phantom endpoint May 10) - The `api_data/.json` cache file path may be misaligned **Impact:** Ken opens /workout/, expects WHOOP recovery score and Withings weight. Sees empty fields. "The page doesn't trust me to fill it for me." This is the single biggest daily trust erosion. ### 3.3 Excel↔DB Reconciliation Never Applied - `reconcile.py` is **staged** in `triggers-staged/workout-log-xls-db-reconciliation/` - Awaiting Ken ratification before `--apply` runs (P-9 gate) - Ken hasn't ratified - The weekly Sunday 05:00 ET cron via launchd is **staged, not installed** - Drift accumulates silently: 11 days in May where Excel has data but `daily_log` doesn't ### 3.4 Day-of-Week Bug (Confirmed, Unfixed) The `/api/log/defaults/canonical` endpoint returns wrong day. On May 20 (Wednesday), it returned "Tue." On May 25 (Monday), it returned "Tue." Root cause unknown — likely either: - Off-by-one in weekday index - Cached at server start on a Tuesday - Using `date - 1` logic somewhere This means Ken gets the wrong exercises filled in every day. Direct source of his "not clean" complaint. ### 3.5 Sleep Segments UI Never Wired Backend shipped April 22 (table, endpoints, 5,940 migrated rows). The HTML form still writes to old single-row schema. **5 weeks idle.** The `sleep_segments` table is frozen at April 4. ### 3.6 v3 Parallel Surface — Stalled - First cut shipped May 10 (dark surface, read-only) - Ken saw it: "stuck on its first cut, not saving to a database, no nav at the top, only light theme page in the set" - Triage plan authored May 12 (4.7 hrs estimated) - **Amendment H dropped v3 polish** on May 11 ("parallel-version creep") - Staged fixes exist but were never applied - Task #253 ("/workout v3 first cut") entered selector queue May 18 — no build since ### 3.7 The Spec Proliferation Problem **16 spec/analysis files** exist for the workout system: ``` workout-log.md (canonical) workout-rebuild-full-spec-2026-05-08.md workout-page-deep-analysis-2026-05-20.md workout-page-implementation-plan-2026-05-20.md workout-v3-triage-and-fix-plan-2026-05-12.md workout-log-xls-db-reconciliation-2026-05-12.md workout-rebuild-deep-analysis-2026-05-10.md workout-log-rebuild-2026-05-08.md workout-log-redesign.md workout-log-v2-design.md workout-log-refinements-H-2026-04-28.md workout-log-rolling-week-comparison.md workout-log-weekend-default-bug.md workout-log-codebase-map-2026-04-28.md workout-v3-mobile-polish-design-2026-05-12.md synthesis/workout-log-synthesis-2026-05-16.md ``` The architectural direction has been analyzed, re-analyzed, specced, re-specced, and triaged — but the critical pieces (WHOOP prefill, reconciliation, day-of-week fix, service stability) haven't shipped. **The system has more specs than shipped fixes in May.** --- ## Part 4: Root Cause Analysis ### 4.1 Why The System Isn't Bulletproof Three compounding factors: 1. **Decision bottleneck**: 6+ tasks stuck in `awaiting=Ken` state (per May 16 synthesis). Ken's decision bandwidth is the constraint, and the system doesn't have a good mechanism for defaults-if-silent beyond the 24h auto-proceed. 2. **Two-service architecture complexity**: workout-log (port 8080) and command-post (port 5001) share data via Caddy routing but have separate databases, separate launchd plists, separate failure modes. When one dies, the other may appear to work partially (Caddy still routes, GET works, POST fails). This makes diagnosis hard. 3. **Excel-canonical creates a hidden second step**: Even when the app saves successfully, Ken still has to update Excel. Until the reconciliation pipeline runs automatically, every app-save is "half done" from Ken's perspective. This is why the `exercises` table is frozen at May 8 — Ken stopped entering exercise data through the app and went back to Excel-only. ### 4.2 Why WHOOP Prefill Has Been Pending 37 Days - It's task #20, low in the priority stack - Other work (v3 first cut, meds card, morning page, PM surfaces) consumed mini's build time - MBP's May 10 recommendation ("Option A first — fix prefill") was correct but mini had bigger fish - No one escalated it as a Ken-pain-point until Ken himself called it out May 10 ### 4.3 Why the Service Crashes - **SIGTERM (exit=-15)** means the process received signal 15 (SIGTERM). Sources: launchd `ThrottleInterval` too short (rapid respawn → throttle → kill), system sleep/wake, OOM, manual `kickstart -k` - **MLX-WAL-contention**: the receipt classifier locks `workout_log.db` via WAL mode. Flask's write path doesn't have retry-with-backoff. When the lock is held, POST hangs → browser times out → "Failed to fetch" - **No watchdog**: unlike command-post (which has a trigger-watcher), workout-log has no health-check or auto-recovery mechanism --- ## Part 5: The Bulletproof Plan ### Priority Sequence (do these IN ORDER) #### P1: Service Stability (immediate — 2 hours) **Goal:** workout-log Flask never crashes silently and always recovers. 1. **Apply launchd plist knobs** (identified April 19, never applied): ```xml SoftResourceLimits NumberOfFiles 4096 ThrottleInterval 15 KeepAlive SuccessfulExit ``` 2. **Add SQLite WAL-contention retry to POST /api/log**: ```python # In app.py, wrap all DB writes: def db_write_with_retry(db, sql, params, max_retries=3): for attempt in range(max_retries): try: db.execute(sql, params) db.commit() return except sqlite3.OperationalError as e: if "database is locked" in str(e) and attempt < max_retries - 1: time.sleep(0.5 * (attempt + 1)) # backoff continue raise ``` 3. **Add a health-check endpoint** (`GET /api/health`) that returns 200 + timestamp. Wire a launchd watchdog plist that curls every 5 minutes; on failure, `kickstart -k`. 4. **Set `busy_timeout` on all DB connections** to 5000ms (5 seconds): ```python conn = sqlite3.connect(DB_PATH) conn.execute("PRAGMA busy_timeout = 5000") ``` **Acceptance:** workout-log survives 24 hours without exit=-15. `launchctl list | grep workout` shows `status=0` or running PID. #### P2: WHOOP/Withings Prefill (immediate — 3 hours) **Goal:** Ken opens /workout/ and sees today's WHOOP recovery score + Withings weight pre-filled. 1. **Find morning-briefing's token cache** — read the TokenStore output path, format, and refresh cadence 2. **Add a reader in workout-log app.py** that loads the cache file on form load: ```python @app.route('/api/whoop-withings/') def whoop_withings_data(log_date): # Read from morning-briefing's cache cache = load_morning_briefing_cache(log_date) return jsonify({ 'whoop_recovery': cache.get('recovery_pct'), 'whoop_hrv': cache.get('hrv_rmssd'), 'withings_weight': cache.get('weight_lbs'), 'withings_body_fat': cache.get('body_fat_pct'), }) ``` 3. **Wire the frontend** to call this endpoint on load and populate the form fields 4. **Graceful degrade**: if cache missing or stale, show dash + "No data — check WHOOP app" tooltip **Acceptance:** `curl /api/whoop-withings/$(date +%Y-%m-%d)` returns non-null values. Form shows green-highlighted prefilled WHOOP + Withings fields. #### P3: Day-of-Week Fix (immediate — 1 hour) **Goal:** Canonical endpoint returns the correct day's exercises. 1. **Read `/api/log/defaults/canonical` route in app.py** 2. **Fix the weekday calculation** to use the request's `?date=` parameter (or today if omitted): ```python target = request.args.get('date', date.today().isoformat()) d = date.fromisoformat(target) day_of_week = d.strftime('%a') # 'Mon', 'Tue', etc. ``` 3. **Fix exercise name mismatches** — add normalization map: ```python NAME_MAP = { 'L Side Pulls': 'Left Side Pulls', 'R Side Pulls': 'Right Side Pulls', 'Curls (both arms)': 'Curls', '1 Arm Row': 'One Arm Row', } ``` 4. **Promote canonical to primary** data source in daily_log_v2.html — remove the 1800ms setTimeout, fetch canonical FIRST, demote same-DOW to fallback **Acceptance:** On any day, `curl /api/log/defaults/canonical?date=$(date +%Y-%m-%d)` returns today's correct weekday and exercises. Load page → correct day's exercises appear immediately (not 1.8s late). #### P4: Reconciliation Pipeline — Install and Run (this week — 2 hours) **Goal:** Excel↔DB drift is measured and eliminated. 1. **Install the staged reconciliation script**: move `triggers-staged/workout-log-xls-db-reconciliation/reconcile.py.staged` to live 2. **Run in dry-run mode** — produces a drift report 3. **Surface the report to Ken** for ratification before `--apply` 4. **Install the launchd plist** for weekly Sunday 05:00 ET dry-run cron 5. **After Ken ratifies**: run `--apply` once to sync the 11 missing May days from Excel into `daily_log` **Acceptance:** `reconcile.py --smoke` passes. Dry-run report shows exact drift count. After `--apply`, `daily_log` row count for May matches atomized date count. #### P5: Retire v3 Surface / Consolidate to One Page (this week — decision) **Goal:** Stop the two-surface confusion. **Ken decision required:** The v3 surface on port 5001 is stalled, light-themed, no nav, no save. Meanwhile the daily-driver on port 8080 actually works (save, toast, cascade, Saturday defaults). Options: - **Option A (recommended): Kill v3.** Focus all effort on making the daily-driver bulletproof. The daily-driver has 8 weeks of battle-tested fixes. v3 has 3 weeks of stalled specs. - **Option B: Finish v3.** Apply the staged fixes (dark theme, nav, POST handler). ~4.7 hours per the triage plan. Risk: two surfaces diverge again. - **Option C: Rebuild from scratch** as a KL v7 design language page inside command-post. Clean architecture, but ~15-20 hours and no backward compatibility. **Recommendation:** Option A. The daily-driver works. Make it better rather than maintaining two surfaces. If Ken wants v7 design language, that's a future sprint after the daily-driver is bulletproof. #### P6: Wire Sleep Segments UI (next sprint — 3 hours) **Goal:** Sleep tracking fully functional. 1. Replace single-row sleep fields in daily_log_v2.html with multi-segment UI (same pattern as work_segments) 2. Wire to existing `GET/POST /api/sleep-segments` endpoints 3. WHOOP sleep data writes `source='whoop'` rows when WHOOP integration is live **Acceptance:** Ken can add/remove sleep segments. Data round-trips through the API. Sleep section shows today's segments on reload. #### P7: Automated Excel→DB Sync (next sprint — 4 hours) **Goal:** When Ken updates Excel, the DB mirrors it within 24 hours. 1. Run the M.81c atomizer as a nightly launchd job (01:00 ET): ```bash python3 ~/Projects/workout-log/atomize_excel.py \ --xlsx "~/...OneDrive.../Workout Log.xlsx" \ --db ~/Projects/workout-log/workout_log.db ``` 2. The atomizer is already idempotent (`INSERT OR REPLACE` with `UNIQUE(date, exercise_name)`) 3. After nightly atomization, run `reconcile.py` dry-run and log drift 4. Surface drift count on `/morning` dashboard (M.46 candidate) **Acceptance:** After Ken logs in Excel, next morning's `/morning` shows the data. Nightly atomizer log shows 0 errors. #### P8: Body Comp Integration via Withings (future — 2 hours) **Goal:** Weight, body fat, fat mass flow from Withings API into daily_log automatically. 1. Withings OAuth is LIVE (tokens in `~/Scripts/.env`, per `state/setups/withings-oauth.md`) 2. morning-briefing already pulls Withings data daily 3. Wire workout-log to read the cached weight/body-fat values and auto-populate `daily_log.weight_lbs` and `daily_log.body_fat_pct` 4. This eliminates Ken's need to manually enter body comp data **Acceptance:** `daily_log` rows auto-populate weight_lbs and body_fat_pct from Withings data within 1 hour of Ken's weigh-in. #### P9: WHOOP Recovery Context on Page (future — 2 hours) **Goal:** Ken sees recovery status before starting workout. Per workout-rebuild-full-spec §4.3, render at top of page: ``` ┌──────────────────────────────────────────────┐ │ Recovery 73% · Green zone │ │ HRV 62ms (3-day avg 58) · Sleep 87 · 7h 12m │ │ ↑ Prescribed intensity OK │ └──────────────────────────────────────────────┘ ``` If recovery <50%, yellow/red banner. Ken-decision, not auto-modify program. **Depends on:** P2 (WHOOP prefill working first). --- ## Part 6: How Workout Fits Into the Daily Flow ### Ken's Morning Arc ``` 5:30 AM — WHOOP updates overnight recovery score 6:00 AM — /morning briefing generates (includes WHOOP + Withings) 6:25 AM — Ken wakes, checks phone 6:30 AM — Ken opens /workout/ on phone → WHOOP recovery + Withings weight pre-filled (P2) → Correct day's exercises loaded (P3) → "Last saved: yesterday 7:15 AM" indicator visible 6:30-8:00 — Ken works out, logging as he goes → Save button → green toast → persistent indicator → Exercise checkboxes cascade up to section level 8:00 AM — Ken hits final Save → daily_log + exercises rows written to SQLite → Overnight atomizer will reconcile with Excel (P7) 8:15 AM — Shower → commute → hot chocolate → first meeting ``` ### Data Flow Architecture (target state) ``` Excel (Ken's hand-entered ground truth) ↓ (nightly atomize_excel.py at 01:00) workout_log_atomized (76K+ rows, read-only mirror) ↓ (weekly reconcile.py at Sun 05:00) daily_log + exercises (app-writable tables) ↑ (real-time via POST /api/log) /workout/ daily-driver page ↑ (prefill on load) morning-briefing TokenStore cache ↑ (daily 05:00 pull) WHOOP API + Withings API ``` ### What Feeds What | Source | Consumer | Current State | Target State | |---|---|---|---| | WHOOP API → morning-briefing cache | /workout/ prefill | ❌ Not wired (P2) | ✅ Auto-prefill | | Withings API → morning-briefing cache | /workout/ body comp | ❌ Not wired (P8) | ✅ Auto-prefill | | Excel → atomize_excel.py | workout_log_atomized | ✅ Works (manual run) | ✅ Nightly cron (P7) | | /workout/ Save → daily_log | CP health tiles | ✅ Works (when service up) | ✅ Stable (P1) | | daily_log → /morning briefing | Morning health section | ⚠️ Partial (weight only) | ✅ Full (after P2/P8) | | workout_log_atomized → /morning | Exercise history trends | ❌ Not wired | Future sprint | --- ## Part 7: Timeline | Week | Priority | Hours | Outcome | |---|---|---|---| | **This week (W1)** | P1 Service stability | 2h | No more SIGTERM crashes | | | P2 WHOOP/Withings prefill | 3h | Ken sees recovery + weight on load | | | P3 Day-of-week fix | 1h | Correct exercises every day | | | P4 Reconciliation install | 2h | Drift measured + first sync | | | P5 v3 decision | 15min | One page, not two | | **Next week (W2)** | P6 Sleep segments UI | 3h | Sleep tracking works | | | P7 Nightly atomizer cron | 4h | Excel→DB auto-sync | | **Sprint after (W3+)** | P8 Withings auto-populate | 2h | No manual body comp entry | | | P9 WHOOP recovery banner | 2h | Recovery context on page | **Total to bulletproof: ~19 hours across 2-3 weeks.** W1 is the critical path — after P1-P4 ship, the daily-driver will feel trustworthy. W2-W3 are quality-of-life improvements. --- ## Part 8: Ken Decisions Required 1. **P5 — Kill v3 or finish it?** Recommendation: kill it, focus on daily-driver. 2. **P4 — Ratify reconcile.py --apply?** Staged script is ready. Running it syncs 11 missing May days. 3. **P7 — Nightly atomizer cadence?** Recommendation: 01:00 ET daily. Alternative: weekly Sunday 05:00. 4. **Excel retirement timeline** — Spec says 30-day verification window before SQLite becomes canonical. When P4 is running and drift is zero for 30 days, Ken ratifies cutover. Until then, Excel stays canonical. 5. **H#1 ab wheel dedupe** — still awaiting Ken confirmation of which exercise is the actual duplicate. --- ## Part 9: What NOT to Do 1. **Don't build another spec file.** There are 16 already. Execute the plan. 2. **Don't start a v4/v5/v7 rebuild** until the daily-driver is bulletproof and Ken's trust is restored. 3. **Don't dual-write to Excel from the app** until reconciliation has proven the round-trip works. 4. **Don't add more tables** until existing ones are populated and consuming surfaces exist. 5. **Don't touch the atomizer** — it works. 76,670 rows, 0.9 seconds, idempotent. Leave it alone. --- ## RULE 12 Acceptance Criteria (for the whole plan) ```bash # A. Service stability (P1) launchctl list | grep workout-log # expect: running PID, status=0 curl -s http://localhost:8080/api/health | jq . # expect: {"status":"ok","timestamp":"..."} # B. WHOOP prefill (P2) curl -s http://localhost:8080/api/whoop-withings/$(date +%Y-%m-%d) | jq . # expect: recovery_pct, hrv, weight non-null # C. Day-of-week correct (P3) curl -s "http://localhost:8080/api/log/defaults/canonical?date=$(date +%Y-%m-%d)" | jq .day_of_week # expect: today's actual weekday abbreviation # D. Reconciliation (P4) python3 ~/triggers-staged/.../reconcile.py --smoke # expect: PASS python3 ~/triggers-staged/.../reconcile.py # dry-run, expect: drift report # E. Save round-trip (existing, verify stable) curl -X POST http://localhost:8080/api/log \ -d '{"date":"'$(date +%Y-%m-%d)'","cardio_time_min":30}' | jq . # expect: {"status":"ok","updated_at":"..."} # F. 24-hour stability # Check after 24h: launchctl list | grep workout shows status=0 or running PID # Check: no exit=-15 in past 24h in ~/Library/Logs/workout-log.err ``` --- — Authored by MBP-Cowork · Thursday, May 29, 2026 · Deep read of 16 spec files, 80+ dispatches, DB forensics, Memex search, and full state tree audit