This user's training data for planning a workout (task next_workout), building a program (new_program), reviewing the week (weekly_review), checking for a deload (deload_check), a periodic check-in (checkin) or the intake (intake). Returns data only:

• task and requested_task: while the intake is incomplete a planning request is answered with the intake's data, so task is 'intake' and requested_task keeps the task asked for.

• intake: {complete, status, next_field, next_field_options, remaining}: the first profile topic with nothing stored yet in intake order, the values it accepts when it is enumerated, and how many topics are still empty. complete needs the seven core topics (motivation, experience, days per week, locations, equipment, health screening, goal); sex, age and body weight are optional. While it is false no training data is attached and intake_required is true for a planning task.

• safety: {screening_status, medical_clearance_advised, parq_flags, active_injury_areas, injuries, injury_map_basis}. screening_status is 'not_assessed' while the health questions were never answered, and medical_clearance_advised is then null, not false: no screening is not a clean screening. Each of injuries is {area, note, loads, catalog_exercises_loading_it}: loads is the body region the area names with the movement patterns and primary muscles that load it (null when the area cannot be placed), and the list names the user's own exercises with that pattern or muscle. injury_map_basis states that the map is a heuristic, not a diagnosis; an exercise it does not flag is not thereby cleared.

• goal_candidates (when the user has no active goal): unsaved goals computed from the profile and recent lifts in upsert_goal's shape, ratified=false, each with its basis; how many depends on what the profile holds.

• user_profile, goals (the featured goal carries a computed progress block), reply_language.

• planning_parameters: numeric ranges for the user's primary goal (weekly hard sets per muscle, reps per set, reps in reserve, rest, progression step); for a home or outdoor profile also without_added_load (the reps range and the order of progression levers when no weight can be added).

• first_session_load_estimates (next_workout / new_program): first working weights for an exercise with no logged history, from sex and body weight, for a calibration start, only for the kit the user has (all kits when equipment is unknown), with basis.

• training_data: sessions this week vs target, consistency_level (the 0-8 level the app shows as a flame, relative to the user's own rhythm), days since the last session, recent_sessions (logged_in_app=true means the app recorded it set by set and it is already stored), recent_lifts (last working sets per exercise: weight, reps, seconds or metres as logged), active_program (days and who last edited them), exercise_catalog (the user's exercise ids), weekly_sets_by_muscle (direct and assisted sets in the last 7 days against MEV/MAV landmarks; the landmarks are stated in direct sets; chest and traps are judged whole, their regions carry part_of and no band) and residual_load_by_muscle (pct_of_hard_session: how much of one hard session's work on that muscle has not yet faded, relative to this user's own hard sessions; fades_in_h: when it will have; a tally of work done, not a measure of recovery or readiness).

• todays_constraints: the constraints argument, echoed.

task defaults to 'next_workout'. 'check_in' is accepted as an alias of 'checkin'. constraints is for TODAY-ONLY circumstances ("only 30 minutes", "gym closed, training at home"); they are not saved to the profile, durable facts are stored with update_coach_profile. today is the current date in the user's timezone, YYYY-MM-DD, as for a session's date: everything here is anchored on which day it is for them, and the server's clock is UTC. When it is omitted the server uses the timezone stored from the web app, or UTC when none is stored, which can shift the weekly and muscle numbers by a day.