Blomios
917777e18b
Regroupe l'état de travail en cours réalisé dans un même worktree sur plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164), mélangeant des tickets QA et inProgress. Ne constitue pas une feature terminée : commit de sauvegarde avant triage/split par ticket en branches feature/* dédiées. Exclut les dossiers d'environnement de build locaux et le heap dump parasite (.gitignore mis à jour). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
43 lines
4.8 KiB
Markdown
43 lines
4.8 KiB
Markdown
---
|
|
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.
|