---
issueRef: "#123"
version: 3
updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
updatedAt: 1785137390347
---

## #123 — Cadrage transparent des statistiques issues de la montre (UX, 2026-07-26)

Statut : **CADRAGE UNIQUEMENT, ne pas ouvrir l'implémentation.** Comme décidé dans le carnet #106 (Main), ce ticket doit se combiner avec le cadrage Architect #124 (permissions capteurs, disponibilité partielle, modèle de persistance) avant tout lot d'implémentation. Ce document fixe le **quoi côté UX**, pas le **quand/comment technique**.

### Cadre produit
Demande utilisateur explicite : si la donnée n'est pas disponible (pas de montre, capteur non supporté, capteur refusé), **aucune notification, aucun message, aucun vide visible** — silence total. C'est la contrainte structurante de tout le cadrage.

### Métriques MVP proposées (à valider par Architect côté faisabilité capteur Wear OS)
Périmètre volontairement réduit à ce qui a une valeur de lecture immédiate pour un utilisateur de musculation/sport, sans dupliquer un tracker cardio dédié :
1. **Fréquence cardiaque moyenne de la séance** (bpm) — métrique la plus universellement disponible sur Wear OS, et la plus lisible pour l'utilisateur.
2. **Fréquence cardiaque max de la séance** (bpm) — complète la moyenne à peu de coût de lecture supplémentaire.
3. *(optionnel, second temps, pas bloquant pour le MVP)* Calories estimées si le capteur/API le fournit nativement sans calcul maison — GameTime n'est pas une app de fitness tracking, ne pas construire de modèle de calcul propre.

Explicitement **hors MVP** pour ce cadrage : VO2 max, zones d'intensité cardio, SpO2, ECG, tout ce qui relève d'un tracker santé complet — hors du produit GameTime (app de séances de sport, pas app santé).

### Surface de restitution
- **Écran de fin de séance / résumé** (le même écran qui affiche déjà la durée totale et le récap des séries) : nouveau bloc optionnel "Fréquence cardiaque" avec deux valeurs (moyenne / max), même traitement visuel que les autres stats du résumé (Anton pour les chiffres, cf. [[gametime-visual-identity]]).
- **Historique de séance** (détail d'une séance passée) : même bloc, affiché dans le détail si la donnée existe pour cette séance.
- **Pas d'affichage temps réel pendant la séance** dans ce périmètre MVP — pas de graphique cardio live sur l'écran d'exécution téléphone, ni sur la montre. Justification : ajouterait une surface supplémentaire à concevoir et à tester pour une valeur d'usage secondaire (l'utilisateur suit son exercice, pas son cardio, pendant l'effort) ; peut être réévalué plus tard si demande explicite.

### Silence UX si donnée absente
- Montre non appairée, capteur cardio absent, permission refusée, ou données insuffisantes pour un calcul fiable → le bloc "Fréquence cardiaque" **n'apparaît simplement pas** dans le résumé ni l'historique. Pas de placeholder grisé "Non disponible", pas d'icône barrée, pas de bouton "Connecter une montre" inséré au milieu du résumé de séance.
- Aucun état d'erreur dédié à concevoir : l'absence de la donnée n'est pas un état de l'écran, c'est une variation normale de contenu (comme une séance sans note, ou sans photo) — cohérent avec [[gametime-online-layer-philosophy]] (silence sur l'indisponibilité, jamais de message intrusif).
- Un seul endroit où la fonctionnalité peut être rendue *découvrable* sans être intrusive : dans les réglages de compte/appareils (là où l'utilisateur configure déjà l'appairage montre, hors scope de ce ticket) — pas sur l'écran de séance lui-même.

### Hiérarchie des métriques (si plusieurs disponibles un jour)
Ordre de priorité de lecture déjà anticipé pour ne pas re-arbitrer plus tard si le périmètre s'étend : Fréquence cardiaque (moyenne, max) > Calories > toute métrique additionnelle. La fréquence cardiaque reste toujours la première ligne du bloc, jamais noyée sous des métriques secondaires.

### Ce qui reste à trancher par Architect (#124) avant ouverture de l'implémentation
- Faisabilité et API Wear OS Health Services pour lire bpm moyenne/max sur la durée d'une séance.
- Modèle de permission (demande à quel moment du parcours, cohérent avec le principe "jamais de blocage du parcours principal").
- Modèle de persistance (nouveau champ sur l'entité séance, ou table séparée) et comportement en cas de séance déjà terminée sans cette donnée (pas de migration rétroactive à inventer).

### Definition of done de ce ticket UX
Ce cadrage est **terminé pour la partie UX** : personne ne doit revenir vers l'utilisateur pour une question de restitution ou de silence UX. La suite (ouverture des lots d'implémentation) dépend uniquement du retour d'Architect sur #124, pas d'un nouvel arbitrage UX.