chore(ideai): synchronise etat tickets/agents/skills pour vague #179 #180 #182 #183 #184

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

.ideai/tickets/183/issue.md

@@ -0,0 +1,42 @@
+---
+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: "open"
+priority: "medium"
+sprint: "d5c18b44-0eec-46db-b8ab-506cfee0bfea"
+links: [{"target":"#179","kind":"relatesTo"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+createdAt: 1785407800593
+updatedAt: 1785408937216
+version: 3
+---
+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.
+
+Idée produit à étudier : lors de la création/configuration d'un exercice dans GameTime, permettre à l'utilisateur de choisir un ou plusieurs types d'exercice métier (exemples évoqués : `shoot`, `haute intensité`, `dribble`, etc.). Ces types métier seraient ensuite mappés en interne vers un ou plusieurs types `Health Services` (`RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT`, ...).
+
+Objectifs :
+- ne plus laisser ce choix uniquement implicite côté technique ;
+- mieux refléter l'intention réelle de l'exercice côté utilisateur ;
+- améliorer les chances d'obtenir les bonnes métriques montre (`distance`, `calories`, `FC`) selon le contexte ;
+- préparer une architecture extensible si plusieurs types métier doivent se combiner.
+
+Questions de cadrage attendues dans ce ticket :
+- UX : comment exposer ce choix dans la création/édition d'exercice sans alourdir le flux ?
+- Produit : faut-il autoriser un seul type métier ou plusieurs tags combinables ?
+- Architecture : comment modéliser un mapping stable `type(s) métier -> stratégie Health Services` ?
+- Technique : faut-il choisir un seul type Health Services final, ou une stratégie de fallback ordonnée selon les capacités de la montre ?
+- Compatibilité : comment gérer les exercices existants qui n'ont encore aucun type métier explicite ?
+
+Hors périmètre immédiat :
+- ce ticket ne corrige pas directement le bug courant de distance/calories indisponibles ;
+- il sert à cadrer une évolution produit/UX/architecture qui pourrait améliorer durablement la sélection du type d'exercice côté montre.
+
+Proposition de premier périmètre :
+- cadrage UX + architecture ;
+- définition d'un premier vocabulaire métier ;
+- définition du mapping initial vers Health Services ;
+- stratégie par défaut pour les exercices existants.