--- issueRef: "#183" version: 12 updatedBy: {"kind":"user"} updatedAt: 1785497678018 --- ## Clarification transverse — 30 juillet 2026 - Cette évolution doit être pensée sur **toutes les couches de l'application**, **serveur inclus**, pour que la **sauvegarde** et la **synchronisation** fonctionnent correctement. - Si un nouveau champ métier ou un nouveau mapping de type d'exercice est introduit, il ne devra pas rester cantonné au téléphone ou à la montre : il devra être propagé proprement dans les modèles, contrats et mécanismes de sync concernés. ## Clarification produit — 30 juillet 2026 Intention produit confirmée : - Quel que soit le type d'exercice métier choisi par l'utilisateur, la stratégie Health Services retenue doit toujours **préserver au minimum la remontée de `distance` et `calories`** quand ces métriques sont calculables/fournies par la montre. - Le choix des types Health Services ne doit donc pas sacrifier inutilement ces métriques de base. - En revanche, le mapping doit rester **cohérent avec la nature de l'exercice** : on ne choisit pas un type Health Services aberrant par rapport à l'intention métier juste pour forcer des métriques. Conséquence attendue : - Chaque type d'exercice métier doit se résoudre vers une **stratégie ordonnée** de types Health Services compatibles. - Cette stratégie doit chercher le **meilleur type cohérent** avec l'exercice, tout en garantissant qu'on retient de préférence une configuration capable de produire `distance` et `calories`. - Exemple explicite : un type métier assimilable à de la `marche` ne doit pas être mappé vers `HIGH_INTENSITY_INTERVAL_TRAINING`. Règle de sélection attendue : 1. respecter d'abord la cohérence métier du type d'exercice ; 2. parmi les types Health Services cohérents, préférer ceux qui permettent `distance` et `calories` ; 3. éviter les types génériques ou incohérents tant qu'un type plus approprié existe ; 4. ne tomber sur un mode plus pauvre qu'en vrai dernier recours technique. Cette clarification remplace implicitement toute lecture trop simpliste du ticket qui consisterait à laisser les types métier purement décoratifs ou à accepter un fallback FC-only trop tôt.