Live
Powered by

TrainingPeaks Evidence Protocol

  • Owner: Coach Luca
  • Last updated: 2026-04-10
  • Purpose: Defines how the evening workflow retrieves. interprets, and classifies TrainingPeaks activity data
  • Gate: Evening skill cannot claim activity confirmation until this protocol is validated

Evidence Path Priority

The evening workflow uses TrainingPeaks data to classify session outcomes. The following fallback chain defines the priority order:

Priority Source Description
1 TrainingPeaks MCP server Primary path. Installed at /Users/notgeoff/.openclaw-coachluca/trainingpeaks-mcp with a repo-local venv. Registered as the trainingpeaks MCP server in the OpenClaw profile coachluca. Provides structured activity data queries.
2 Legacy JS scripts Fallback. scripts/tp_check.js (headless Chrome check) and scripts/tp_last_activity.js (connects to running Chrome). These are screen-scraping tools with less structured output.
3 Direct athlete confirmation If automated paths fail, rely on athlete-reported session information from messages.
4 Unconfirmed If no evidence is available from any source.

MCP Server Usage

The TrainingPeaks MCP server is the preferred evidence source.

Authentication: Browser-based auth via /Users/notgeoff/.openclaw-coachluca/trainingpeaks-mcp/.venv/bin/tp-mcp auth --from-browser auto. If Chrome auth fails, manual cookie auth using the Production_tpAuth cookie from app.trainingpeaks.com.

Expected data: The MCP server should return structured activity data including:

  • Activity date and time
  • Activity type (ride, run, strength, etc.)
  • Duration
  • Distance (when applicable)
  • Power data summary (IF, NP, TSS, average power)
  • Heart rate summary
  • Athlete notes or descriptions

Validation check: Before relying on MCP data for evening review, confirm:

  1. The activity date matches today
  2. The activity type is consistent with the planned session
  3. The data is not a duplicate or stale cached result

Legacy Script Usage

If the MCP server is unavailable or returns no data:

scripts/tp_check.js — Launches headless Chrome, navigates to Sidney's TrainingPeaks calendar, and returns basic page content. Useful for verifying whether data is visible but not structured.

scripts/tp_last_activity.js — Connects to a running Chrome instance with the TP calendar open. Scrapes for activity-like text on the calendar page. Returns candidate activity entries with text snippets.

Limitations:

  • Output is unstructured text scraped from the UI
  • May not return precise metrics (TSS, IF, etc.)
  • Requires Chrome to be running with TP logged in (for tp_last_activity.js)
  • May fail silently if the page layout changes

Session-Outcome Certainty States

The evening workflow must classify today's session using exactly one of these states:

State Definition Evidence threshold
Confirmed completed Session was done as planned TP shows a matching activity with consistent type, duration, and effort; OR athlete explicitly reports completion
Confirmed modified — minor Session was done with small adjustments TP shows an activity that mostly matches but with minor duration or effort deviations; OR athlete reports small changes
Confirmed modified — significant Session was meaningfully different from planned TP shows an activity with major deviations (different type, much shorter, different intensity); OR athlete reports significant changes
Confirmed not completed Session was skipped or abandoned TP shows no activity for today; OR athlete confirms skip/abandonment; OR TP shows activity started but abandoned early
Unconfirmed Cannot determine outcome No TP data available, no athlete report, or evidence is ambiguous or contradictory

Evidence-to-State Mapping

TP MCP returns structured activity data

  1. Compare activity type to planned session type
  2. Compare duration to planned duration (± 15% is "minor" deviation; > 15% is "significant")
  3. Compare effort metrics (power, HR) to planned effort target if available
  4. If all match reasonably: Confirmed completed
  5. If minor deviations: Confirmed modified — minor
  6. If major deviations: Confirmed modified — significant

TP MCP returns no activity for today

  • If athlete has reported the session in messages: use athlete report to classify
  • If no athlete report: Unconfirmed (not Confirmed not completed — the data may simply be delayed)
  • Exception: if the athlete explicitly said they skipped: Confirmed not completed

Legacy scripts return data

  • Same mapping logic as MCP, but with lower confidence due to unstructured output
  • If the scraped text clearly shows a matching activity: classify normally
  • If the scraped text is ambiguous: Unconfirmed

No automated data available

  • Check for athlete messages reporting the session
  • If athlete explicitly reports: use their report to classify
  • If no athlete report: Unconfirmed

Handling Partial, Stale, or Missing Data

Scenario Classification Notes
TP data for today is not yet uploaded Unconfirmed Common if the athlete has not synced their device. Do not wait or retry.
TP data shows yesterday but not today Unconfirmed Data lag. Note this in the evening internal notes.
TP data shows an activity but it does not match the plan Classify the actual data The actual activity matters more than the plan.
TP MCP server returns an error or timeout Fall to legacy scripts Note the MCP failure in internal notes.
Both automated paths fail Fall to athlete confirmation If no confirmation available: Unconfirmed.
Athlete says "I did the session" with no detail Confirmed completed (low-detail) Note that confirmation is athlete-verbal only.
Athlete says "I modified the session" Confirmed modified — ask for detail if not provided Use athlete's description to determine minor vs. significant.

Critical Rules

  1. Missing TP evidence = Unconfirmed. Never assume a session was completed because it was planned.
  2. Do not retry or wait for TP data. The evening pass runs at 20:00. Whatever data is available at that time is what gets used.
  3. Do not infer effort quality from data alone without context. A shorter ride might be appropriate (Amber day) or might not.
  4. Always record the evidence source in the evening note's internal section: "Source: TP MCP", "Source: legacy script", "Source: athlete message", or "Source: none".
  5. TP auth may expire. If the MCP server fails with an authentication error, note this as an infrastructure issue for operator attention. Do not attempt to re-authenticate automatically during the evening pass.
  6. The plan is not evidence. The rolling 7-day file says what should have happened. TP data and athlete reports say what did happen. These are different things.