chore(ideai): met a jour carnets et issues des tickets #164 #174 #179 #180 #182 #183 #184

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.ideai/tickets/183/carnet.md

@@ -1,10 +1,30 @@
 ---
 issueRef: "#183"
-version: 4
+version: 9
 updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
-updatedAt: 1785412142205
+updatedAt: 1785421036326
 ---
 ## 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.
+- 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.

.ideai/tickets/183/issue.md

@@ -2,7 +2,7 @@
 id: "6bbb4a4d-7c42-4658-9212-e86f3ff65684"
 number: 183
 title: "[Produit][UX] Permettre le choix de types d'exercice métier mappés vers les types Health Services"
-status: "inProgress"
+status: "qa"
 priority: "medium"
 sprint: "d5c18b44-0eec-46db-b8ab-506cfee0bfea"
 links: [{"target":"#179","kind":"relatesTo"}]
@@ -11,8 +11,8 @@ attachments: []
 createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
 updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
 createdAt: 1785407800593
-updatedAt: 1785412142205
-version: 4
+updatedAt: 1785421036326
+version: 9
 ---
 Contexte au 30 juillet 2026 : sur certaines montres Wear OS, les métriques `distance` et `calories` ne semblent pas remonter selon le type d'exercice Health Services utilisé. Aujourd'hui, GameTime choisit en interne parmi `RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT` sans que ce choix soit exposé à l'utilisateur métier. Or ce choix influence les métriques réellement fournies par la montre.