Cloture le ticket #183 (QA), ajoute les tickets #186 et #187, re-attribue les permissions MCP entre agents. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
30 lines
2.2 KiB
Markdown
30 lines
2.2 KiB
Markdown
---
|
|
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. |