Heftig

Read a bounded summary of completed workouts in an inclusive calendar-date range (at most 366 days), newest first. Excludes active and abandoned workouts, photos, social data and notes. Narrow the date range if hasMore is true.

get_training_history

Read recorded meals and consumed nutrients for one exact local day in the user-supplied timezone. Incomplete totals are null; knownSubtotal is only the sum of known data. Never describe unknown nutrients as zero.

get_nutrition_day

Search Heftig canonical foods by exactly one query or barcode. Resolve ambiguous products with the user before previewing a meal. Nutrient null means unknown, never zero. Search results do not record a meal.

search_foods

Stateless preview of catalog foods or unlinked snapshots. Snapshot nutrients describe the whole entered quantity. Ask for missing or ambiguous quantity, date or timezone first. Catalog and mixed meals require this preview before log_meal; snapshot-only meals can be logged directly. Show unknown nutrients as unknown. The returned request_id and preview_hash belong together; no meal or draft is stored.

preview_meal

Record one meal the user asked to log. A meal containing only kind=snapshot items can be saved directly with a new request_id, without product search or preview_hash; nutrients describe each entire entered quantity. Catalog or mixed meals require the unchanged confirmed preview input and its request_id and preview_hash. Never invent missing amounts or nutrients: ask about ambiguous quantities and use null for unknown nutrients. Reuse exactly the same request_id and input after a timeout. A changed catalog meal requires a fresh preview. Creates a meal; cannot edit or delete existing meals.

log_meal

Make this owned plan the active plan, replacing the current active-plan choice. Call only when the user explicitly asks to activate or switch to this plan. Does not start or alter a workout. Supply a fresh UUID requestId; retries must reuse the same ID and planId. A completed retry returns its original result without reapplying a later superseded activation.

activate_training_plan

Create one complete inactive plan atomically in Heftig after the user requests saving it. Resolve exercises with search_exercises first and preserve their exact trackingMode. Supply a fresh UUID requestId for each intended creation; retry the identical requestId and plan after an uncertain result to avoid duplicates. Never reuse the ID for different content. Weights are combined kilograms even if weightPerHand is true; baseWeightKg is added once. At most 7 routines, 20 exercises per routine and 10 sets per exercise. Creates no workout and does not activate the plan; activation requires a separate explicit user request.

create_training_plan

Read the routines and planned sets of one plan owned by the connected user. Each routine includes a revision required for update_training_routine. For an existing exercise, its id is the saved routine entry ID; pass it as existingExerciseId to retain or adjust it without substituting its catalog reference. Weight is combined load in kilograms, including when weightPerHand is true; baseWeightKg is additive once. This does not read a running workout.

get_training_plan

List only the connected user’s plans, with the active plan first. Use offset pagination when hasMore is true.

list_training_plans

Edit one existing training day in place only after the user requests that change. Read get_training_plan first and pass that routine’s exact revision as expectedRevision. Supply its name and the complete ordered list of exercises for this day: omitted entries are removed. Retain an existing entry with existingExerciseId equal to its saved id; optionally change its plannedSets, restSeconds, baseWeightKg or weightPerHand. Omitted fields remain unchanged, including custom or older catalog exercise references. For new exercises use exact search_exercises results and trackingMode. Never invent or silently substitute unavailable exercises; explain the conflict and ask the user if a replacement is needed. Do not create a different plan as a fallback. Changes keep this plan, its active status and all other days; no live workout is modified. A server-recorded active workout using this day blocks the edit. A running device-local workout keeps its separate snapshot; this tool does not inspect or control it. On revision conflict reread and reconsider the requested edit instead of overwriting newer changes. Use a fresh UUID requestId for each intended edit; after an uncertain result retry identical arguments and requestId. At most 20 entries and 10 newly specified sets per entry. Weights are combined kilograms, including per-hand mode; baseWeightKg is additive once.

update_training_routine