Files
GameTime/.ideai/tickets/183/carnet.md
2026-07-30 17:12:03 +02:00

30 lines
2.2 KiB
Markdown

---
issueRef: "#183"
version: 11
updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
updatedAt: 1785424283717
---
## 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.