blomios/GameTime
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Blomios
2026-07-30 16:17:31 +02:00
parent 2ae716206a
commit c43b93ef99
15 changed files with 78 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
.ideai/tickets/183/carnet.md
View File

@ -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.