hybridlog

Delete a symptom log entry by id when the user corrects or retracts it. Ids come from the log-symptom-tool response or from get-health-summary (last 3 days). Log the corrected entry afterwards when there is one.

Describe the Garmin mirror schema: every table with its commented CREATE statement, how well it is filled (row count, date range, missing days, columns this device never records), plus open fetch errors and semantic notes (units, enums, quirks). Call this once per conversation before writing SQL. Never build a query on a column listed under never_filled: it returns nulls, not a finding.

One session in depth: the summary, its heart-rate zones as seconds, minutes and shares next to the zone floors the athlete's profile carried on that date (hard_minutes is zones 4 and 5 together), the laps, the strength sets per exercise category, the heart-rate curve in a few dozen buckets, and how the session compares with the earlier ones of the same type: medians, the deviation from them, the rank by training load. Without an activity_id it reads the most recent session. Use this rather than rebuilding zones from hr_zones_json or the curve from intraday in SQL.

Curated snapshot of the athlete's current state: readiness, HRV, sleep, recent activities with training load. Fastest way to ground a coaching conversation; use query-health-data for anything deeper.

The app's own reading of the body systems: cardiovascular, sleep, breathing, autonomic recovery and metabolism, each with a status (good / warning / serious / critical), the facts behind it and a concrete recommendation. Carries the early illness pattern across resting heart rate, nightly breathing and HRV. These are the rules the dashboard and the morning briefing run on, so call this instead of inventing thresholds in SQL: a verdict derived ad hoc will contradict what the athlete was told this morning.

The muscle map as the dashboard computes it: per-zone freshness (0 = just hammered, 100 = fully fresh) with exponential per-zone decay, what each zone saw in the last 7 and 28 days (volume, fractional sets, measured share, the sessions behind it), and a recovery forecast. Call this instead of re-deriving muscle load in SQL: the model self-calibrates against the athlete's own history, and an ad-hoc SQL version will disagree with what the athlete sees on their map.

Lap-by-lap breakdown of one race-style session: every lap classified as running or station work, pace per running lap, how far the pace drifted from the first lap to the last, and the time the clock ran while nobody moved. Built for sessions that alternate between the two, which is what a HYROX race or simulation is (8 x 1 km with a station between each), but it reads any activity carrying laps: an interval session, a multi-sport day, a road race with manual splits. Without an activity_id it takes the most recent session that has enough laps to be worth splitting.

Week by week strength progression per exercise category as the dashboard computes it: reps, tonnage where the sets really carry a weight, the weekly top weight, the bests inside the window and a "holds at X kg for N weeks" reading. Answers "am I getting stronger". Call this instead of summing strength_sets in SQL: weights are grams, most categories come back UNKNOWN, and a naive sum mixes weightless reps into a tonnage that was never lifted.

The fitness/fatigue/form model as the dashboard computes it: CTL (42-day EWMA), ATL (7-day), TSB, today's acute:chronic workload ratio with its corridor verdict, plus the weekly load split by stimulus (run / strength / other). Call this instead of re-deriving CTL, ATL or the ratio in SQL: the EWMAs start where the athlete's history starts, and an ad-hoc SQL version will disagree with the dashboard's numbers.

Store feedback the user just gave about how this connector should behave (tone, format, defaults), so it sticks. The guideline (English, imperative, one or two sentences) becomes part of the server instructions from the next conversation on; pass retire_guideline_id instead of a guideline to withdraw a rule the user takes back (ids are the [gN] markers in the instructions). Use only for feedback the user explicitly voiced, never on your own initiative.

Log a symptom or complaint ("kratziger Hals", "Kopfschmerzen"), but ONLY when the user mentions it unprompted. Capture it in passing with a one-sentence confirmation and move on; NEVER ask the user how they feel or whether they have symptoms. severity is optional: 1 mild, 2 moderate, 3 severe. Pass body_zone whenever the user named a place ("knee hurts", "sore hamstrings") so the report lands on the body map next to that zone's training load; omit it for anything without a place ("scratchy throat"). Entries surface on the dashboard as context on the illness early-warning banner and, with a body_zone, as a marker on the body map. To correct an entry, delete it (delete-symptom-tool) and log the corrected one.

Run a single read-only SELECT (or WITH ... SELECT) against the Garmin mirror and get the rows back (max 500). PostgreSQL dialect. Use describe-schema first for table and column names.

Trigger a fresh Garmin Connect sync of today and yesterday and wait for it to finish (the same job as the dashboard's refresh button, narrowed to two days: the scheduled runs cover the week, this one exists for "now"). Use when the user asks about today and last_fetch is stale (e.g. after a workout). The call blocks until the run is over, up to about half a minute per call; a still_running answer means the run needs longer, so call this tool again to keep waiting, that never starts a second sync. completed means the whole run is done, activities included, so re-query and answer with the fresh numbers instead of asking the user to come back. A not_started answer means the previous run only just finished and the start window has not reopened: use the data as it is, or wait retry_in_seconds and call again if something the user expects is still missing. Refuses while there is no working Garmin session (data_status not_connected or auth_broken): fetching cannot succeed then, and the answer carries the URL where the user signs in.