Acta Fit

Status of proposals sent via create_training_plan or create_workout_template (`format` tells them apart: track.plan.v1 = plan, track.workout.v1 = single workout): pending (awaiting the user's in-app review), imported (accepted — a plan is then readable via get_plan, a workout via get_workout_templates, after the next sync), failed/dismissed (status_detail says why), superseded, expired. List mode returns metadata only; pass proposal_id with include_payload for one full proposal.

get_plan_inbox

Propose a multi-day training plan for the user. This only files a proposal: it lands in the user's inbox in the Acta Fit app, where they review it and accept or dismiss it; nothing in their data changes until they accept. Strength training only: a template is exercises × sets × reps × load, so plans cannot schedule cardio (bike, run, swim, row or intervals) yet. Leave each cardio weekday a rest day and put the session in the plan notes, never as a weight exercise; then tell the user plainly, in your own words, that plans can't hold cardio days yet, that you left those days as rest days and that the sessions are in the plan notes. Before proposing: (1) if the plan builds on the user's routine, call get_workout_templates and copy their templates faithfully, accessories included; (2) use exercise names exactly as get_workout_templates / get_exercise_history / get_training_maxes return them (unknown names are rejected with close-match suggestions; register a genuinely new movement with create_exercise first); (3) give working sets a load via `weight` (in weights_unit, the user's own unit) or `percentageOfMax` (resolved against the user's training max at review time), never both; (4) pick progressionAlgorithmRaw deliberately: linear5x5 for 5×5-style linear progression, gzclp for GZCLP, none for a manual plan. When a template re-uses the name of one the user already has, include every exercise, every warm-up set (setTypeRaw: 'warmup') and every superset grouping (supersetGroup) from the saved version: the server compares the two and rejects a proposal that leaves any out, listing what is missing; only when the user explicitly asked for a slimmer version, resubmit with confirm_omissions: true. Days reference templates by exact name from this proposal's templates array; a day without templateName is a rest day (weekday 1 = Sunday). An identical resubmit returns the existing pending proposal; pass replaces_id to revise one of your own pending proposals. The user's inbox holds at most 5 pending proposals. When it is full the call files nothing and returns error pending_limit_reached with the pending proposals (id, title, oldest first): don't stop at telling the user the inbox is full; offer to replace the pending proposal most like this one (or else the oldest), naming it by title, and only if they agree, call again with the same arguments plus replaces_id set to its id. The replaced proposal stays in the inbox history. Hard safety limits are enforced server-side and cannot be overridden: a proposal that exceeds them (sets per exercise or week, training days, load above the user's recent best or training max, back-to-back heavy leg days, and the like) is rejected with error hard_limit_violation and a list of violations, each with the field path, the limit and a suggested fix; apply every fix and resubmit.

create_training_plan

Propose ONE standalone workout (a template: exercises × sets × reps × load) for the user's library, with no plan or weekly schedule. Use it when the user asks for a single workout ('make me a push day'); use create_training_plan for a multi-day program. This only files a proposal: it lands in the user's inbox in the Acta Fit app, where they review it and tap Save to Library; nothing in their data changes until then, and saving adds a new template beside any existing one with the same name, which stays as it is. Afterwards it can be started from the library and read back via get_workout_templates. The rules of create_training_plan's templates apply: strength only (a workout cannot hold cardio or intervals yet, and they never go in as weight exercises; put them in the notes and tell the user so); exercise names exactly as the read tools return them (unknown names are rejected with close-match suggestions; register a genuinely new movement with create_exercise first); a load per working set via `weight` (in weights_unit, the user's unit) or `percentageOfMax`, never both; and when the name matches a template the user already has, include every exercise, warm-up set (setTypeRaw: 'warmup') and superset grouping (supersetGroup) from the saved version, because the server rejects a proposal that leaves any out and lists what is missing; confirm_omissions: true only when the user explicitly asked for a slimmer version. An identical resubmit returns the existing pending proposal; pass replaces_id to revise one of your own pending proposals. The user's inbox holds at most 5 pending proposals. When it is full the call files nothing and returns error pending_limit_reached with the pending proposals (id, title, oldest first): don't stop at telling the user the inbox is full; offer to replace the pending proposal most like this one (or else the oldest), naming it by title, and only if they agree, call again with the same arguments plus replaces_id set to its id. The replaced proposal stays in the inbox history. Poll get_plan_inbox for the outcome. Hard safety limits are enforced server-side and cannot be overridden: a proposal that exceeds them (sets per exercise or week, training days, load above the user's recent best or training max, back-to-back heavy leg days, and the like) is rejected with error hard_limit_violation and a list of violations, each with the field path, the limit and a suggested fix; apply every fix and resubmit.

create_workout_template

Register ONE new exercise name for use in future create_training_plan / create_workout_template proposals. Rare and deliberate: plans should be built from the user's existing exercises. Two-step check: the first call returns the user's complete exercise vocabulary — READ IT and check whether any entry is the SAME MOVEMENT under a different name (e.g. 'Stationary Bike' duplicates 'Cycling'; 'OHP' duplicates 'Overhead Press') — and only when nothing matches, call again with confirm: true. Nothing is created immediately: the name becomes usable in proposals, and the exercise is created in the user's library (badged as new on the review screen) only when they accept a plan that uses it. Strength movements only — plans cannot schedule cardio yet.

create_exercise