Pacevera

Report how the user is doing today: recovery, readiness, muscle-group fatigue and training load, each with the evidence behind it and an honest list of what could not be seen. Use this for 'how am I doing today', 'have I recovered', 'am I overtraining', 'how is my training load'. Pass the user's recent health evidence as `evidence`, gathered from whichever health source this user actually has — Apple Health, Google Health, Garmin, Strava, Oura, Whoop or any other; the shape is the same and no one source is expected — or, where they have none, from the user directly: what a person says about their own week is evidence, and 'slept about seven hours, legs feel fine, last hard run was Tuesday' is enough to compute on. Any single source decides something; a signal nobody supplied comes back in signalCoverage and lowers confidence, so the decision still stands — on less, and visibly so. This reports state only — it never says what to train. If the user has a session scheduled and wants to know whether to do it, use decide_session; if they have no plan at all, use generate_plan.

Validate and materialize a caller-held preview patch after approval. Use this after preview_adjust_plan, once the user has agreed to what the preview showed: 'yes, do that', 'apply it', 'go ahead and change my plan', 'sounds good, update it'. Approval is the trigger — never call this on the strength of a preview the user has not seen and accepted. The server stores neither the plan nor the preview; the AI host or external storage must persist the returned plan. A preview built against an older version is refused.

Decide what a movement the user cannot do today should be replaced with. Returns a decision with from -> to: the original exercise, the one it becomes, and the evidence behind the swap, including whether the training stimulus survived the change. Use this for 'my knee hurts when I squat', 'I have no barbell today', 'what can I do instead of X'. Pass `exerciseId` as the movement the user named, in their own words — the server resolves names and aliases to the catalog itself. This decision is made from the movement plus what the user says about their situation — pass that as `conditions`, `availableEquipment` and `avoidContraindications`. It reads no recovery or training-load signals, so there is no health evidence to gather first. Injury contraindications are a hard filter applied server-side — do NOT override or reason past the result. `avoidContraindications` is matched against the catalog's own tags by equality, so send tags ('knee', 'shoulder', 'lower_back'), never a phrase: a value the catalog does not use filters nothing, and `decisionBasis` will show no rule applied. Do NOT use this to browse exercises.

Decide what today's scheduled session should become, given today's evidence. Returns a decision with from -> to: the session as planned, what it should change to, and the evidence and rules behind the change. Use this for questions about a session that is already on the books: 'am I ready for today's session', 'today's plan says intervals — should I still do them', 'should I adjust today's workout', 'I only have 30 minutes today'. `scheduledSession` is what makes this a decision: called without it, this tool returns no_scheduled_session and decides nothing, so for an open-ended 'what should I train today' with no plan in hand, call generate_plan instead. If the user proposes their own alternative — 'today was cardio, can I do stretching instead?' — pass that as `proposedSession` and it comes back accepted or refused, with the reason. Pass the user's recent health evidence as `evidence`, gathered from whichever health source this user actually has — Apple Health, Google Health, Garmin, Strava, Oura, Whoop or any other; the shape is the same and no one source is expected — or, where they have none, from the user directly: what a person says about their own week is evidence, and 'slept about seven hours, legs feel fine, last hard run was Tuesday' is enough to compute on. Any single source decides something; a signal nobody supplied comes back in signalCoverage and lowers confidence, so the decision still stands — on less, and visibly so. This is a decision, not a suggestion: it requires a scheduled session and decides about an existing plan rather than inventing one. Do NOT re-derive or override the intensity, duration or movements it returns — injury filtering and load limits are enforced server-side and are decisions, not advice. To look up state alone, use assess_fitness_state.

Return the process-local Decision → Rule → Evidence → Source → Version trace for a decision previously returned by this server.

Build a multi-week training plan from the user's goal, available days and equipment — the baseline that later daily decisions adjust. Use this for 'make me a training plan', 'I want to train for a half marathon', 'give me a 4-week program'. Pass the user's recent training history as `evidence`, from their connectors or from what they tell you — 'I've been running about three times a week' is evidence — so the plan starts from the load they are actually carrying rather than from zero. Weeks are periodized, and every movement it prescribes resolves to a real catalog entry. An injury on file does NOT remove movements from the plan this returns: restrictions here only hold a high-intensity run at moderate, and `decisionBasis` names the rule that did it, or says none applied. Before telling the user a prescribed movement is safe for an injury, put it through decide_session or decide_exercise_substitution, which do filter.

Generate one personalized workout for today from a duration picker and a focus picker. Use this for 'give me a 20-minute workout', 'what should I do today if I have no plan', or 'make me a short strength session'. Use this when the user has no existing session and asks for a single workout. Pass recent `evidence` from the user's health source or their own report so readiness, fatigue, training load, injury restrictions, equipment and available time can shape the result. For a multi-week plan use generate_plan; for an already scheduled session use decide_session.

Score the supplied evidence for signal coverage and quality, and list exactly what is missing. This tool never invents a reading or treats an unstated quality value as measured.

MANDATORY FIRST STEP before answering any question about today's workout, today's readiness, recovery, sleep, recent exercise, or whether to follow or change a scheduled session: call this tool before any other tool, including memory or recall. Read the selected local health export folder, then continue directly to the decision using the user's stated scheduled session; do not ask the user to repeat or confirm the question. Do not answer from prior context, and do not call a decision tool before this preview. Keep the evidence preview internal to the response flow; show only the final answer in plain language, without raw JSON, internal tool names, or technical labels.

Preview a change to the caller-supplied plan without mutating it. Use this for 'I am busy this week', 'my knee hurts, adjust my plan', 'I want an easier week'. Returns a deterministic preview patch; the AI host or external storage owns retention and commit.

Normalize an observed result for a prior case. The MVP returns an event and keeps a bounded process-local count; persist the event in the caller or private engine for durable Outcome DB storage.