--- issueRef: "#166" version: 12 updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"} updatedAt: 1785311597894 --- ## #166/#167/#169 — Cadrage UX coordonné : slot "donnée dominante sans chrono" (UX, 2026-07-28) Statut : **cadrage exploitable, à traiter comme une seule mini-refonte**, pas trois patchs indépendants (voir point 4). Détail complet ici sur #166, #167 et #169 pointent vers ce carnet + leur delta propre. Base : écran `Séance active` déjà révisé par #161 (fermé) — un chrono/donnée dominante + un bouton d'action unique sur la même ligne, un seul libellé, FC en icône en pied d'écran. Ce lot traite les **cas où il n'y a pas de chrono actif**, laissés de côté par #161. ### Constat commun Quand il n'y a pas de chrono actif, l'écran retombe aujourd'hui sur des solutions par défaut peu utiles : le compteur `SÉRIE X/Y` se répète en donnée dominante alors qu'il est déjà affiché en en-tête (#167), aucune action rapide n'est proposée pour une étape à répétitions alors que c'est justement l'action la plus probable à cet instant (#166), et un sous-titre `Prêt pour la série suivante` occupe une ligne entière pour une information déjà déductible du reste de l'écran (#169). ### 1. Comportement attendu par ticket **#166** : sur une étape à répétitions (sans chrono), un bouton de validation/passage à l'étape suivante est visible directement sur l'écran principal — pas besoin de swiper vers `Actions`. Ce bouton déclenche la même commande que `Étape suivante` (valide l'étape, avance), pas un `Passer l'étape` (qui reste une action de contournement, toujours dans `Actions`). **#167** : sur une étape à répétitions (sans chrono), la donnée dominante centrale devient le nombre de répétitions à faire pour cette étape, et non plus le nombre de séries de l'exercice (déjà visible en en-tête `SÉRIE X/Y`, donc redondant). **#169** : le sous-titre `Prêt pour la série suivante` est supprimé, sans remplacement — l'écran (nom d'exercice + bouton `Démarrer l'exercice`) reste compréhensible sans lui. ### 2. Disposition recommandée — écran principal, cas étape reps-only Réutilise **exactement** le template ligne chrono+bouton posé par #161, appliqué à la donnée reps au lieu du chrono : ```text SÉRIE 2 / 5 Pompes tempo Passage 1 / 3 · Étape 2 / 4 Répétitions 10 [✓] ♥ 132 ``` - Légende `Répétitions` une seule fois, au-dessus de la valeur — même règle que le libellé de chrono (#161). - Bouton icône `[✓]` (valider/étape suivante) à droite de la valeur, même ligne, même cible tactile ≥48dp que le bouton pause/play (#128/#161) — pas un nouveau composant, le même gabarit rejoue avec une icône différente. - Un seul bouton d'action visible à la fois sur cette ligne : jamais `[✓]` et `[⏸]` en même temps. Si l'étape a aussi un chrono (score chrono d'étape, cas #140), ce cas reste géré par le layout dédié `_ManualScoreContent` existant, non touché par ce lot. - Cœur FC inchangé, en pied d'écran (#161). ### 3. Disposition recommandée — écran `Prêt pour la série suivante` ```text SÉRIE 3 / 5 Pompes tempo [Démarrer l'exercice] ``` Le sous-titre disparaît, l'espace libéré n'est **pas** réutilisé pour un nouvel élément (contrainte explicite : ne pas ajouter de bruit) — juste un espacement plus respirant entre le nom d'exercice et le bouton. ### 4. Garde-fous de lisibilité / priorité visuelle - Un seul élément "action" par écran, toujours à droite de la donnée dominante quand il y en a une (chrono → `[⏸]`, reps → `[✓]`) — jamais empilé en dessous, jamais dupliqué ailleurs. C'est la même règle que #161, appliquée maintenant au cas reps. - Ne jamais afficher deux fois la même information sous deux formes (le principe qui motive #167) : si une donnée est déjà visible ailleurs sur l'écran (ex. `SÉRIE X/Y` en en-tête), elle n'a pas sa place une seconde fois dans le slot dominant. - Suppression de texte (#169) : ne jamais compenser par un ajout ailleurs sauf besoin explicite ; le vide contrôlé est préférable au bruit, conformément à la contrainte utilisateur de ce lot. - Icône `[✓]` distincte visuellement de `[⏸]`/`[▶]` pour éviter toute ambiguïté entre "valider l'étape" et "mettre en pause la séance" — même style (or sur fond `#141824`, anneau crimson au tap, cf. #128) mais pictogramme différent. ### 5. Coordination des 3 tickets **Oui, à traiter comme une seule mini-refonte cohérente**, pas trois patchs séparés : - #166 et #167 modifient la **même zone d'écran** (slot donnée dominante + bouton d'action pour une étape reps-only) — les livrer séparément risquerait qu'un commit écrase la mise en page de l'autre, ou que le bouton `[✓]` soit ajouté sans que la redondance `SÉRIE X/Y` soit corrigée en même temps (ou l'inverse). - #169 touche un état adjacent du même écran (`Séance active` sans chrono actif) et applique le même principe (pas de texte qui ne porte pas d'action ni de donnée nécessaire) — le traiter isolément ferait revivre exactement la dérive de densité déjà diagnostiquée et corrigée par #161 (accumulation de correctifs isolés qui perdent la cohérence d'ensemble). - Recommandation : un seul lot Architect/DevFrontend pour les trois, avec cette section comme spec unique de référence. --- ## Cadrage Architect (2026-07-28) Statut : **ticket déjà implémenté dans le code actuel, conforme au cadrage UX ci-dessus**. Vérifié en lecture directe sur `watch_app/lib/presentation/watch_session_screen.dart` : - `_ActiveContent.build()` (~L704-788) calcule `repsTarget` et bascule déjà sur `_DominantRepsLine` quand `repsTarget != null` (L753-758), au lieu de la donnée `SÉRIE` — #167 déjà appliqué. - `_DominantRepsLine` (~L790-815) affiche la valeur reps + `_CompleteStepButton` sur la même ligne, gabarit `SizedBox(height: 52)` + `Row` — conforme au template ligne unique posé par #161. - `_CompleteStepButton` (~L817-844) : `SizedBox.square(dimension: 48)` (cible tactile 48dp respectée), icône `Icons.check`, couleur or `#C9A24A` sur fond `#141824` avec liseré crimson `#D72638` — conforme au style #128/#161, visuellement distinct de pause/play. - Câblage commande : le bouton appelle `onCompleteStep` → `WatchSessionViewModel.completeCurrentStep()` (`watch_session_view_model.dart:190-191`) → `WatchCommandType.completeCurrentStep`, une commande **distincte** de `WatchCommandType.skipCurrentStep` (utilisée par `Passer l'étape` dans `Actions`) — la séparation validation/contournement exigée par le cadrage UX est bien respectée, pas de confusion de commande. - Libellé `Répétitions` déjà affiché une seule fois au-dessus de la valeur (L751, `_SmallLabel(repsTarget == null ? dominantLabel : 'Répétitions')`) — #167 confirmé. - Recherche du texte `Prêt pour la série suivante` dans tout le repo Dart : **aucune occurrence** — le sous-titre visé par #169 n'existe déjà plus. - Aucun double bouton `[✓]`/`[⏸]` possible : `_ActiveContent.build()` structure les branches `repsTarget != null` / `timer == null` / chrono en `if/else if/else` mutuellement exclusifs (L753-767). ### Conclusion **Aucun développement restant.** #166 (et vraisemblablement #167/#169 associés dans ce même carnet) sont fonctionnellement livrés dans le code présent sur la branche. Il n'y a ni contrat, ni port, ni frontière hexagonale à faire évoluer ici — pure présentation Flutter déjà en place. ### Recommandation - Ne pas relancer de lot DevFrontend sur ce ticket : le repasser directement en validation **QA** sur device/émulateur Wear OS réel, avec ces points de contrôle précis : 1. Étape reps-only sans chrono → bouton `[✓]` visible et fonctionnel sur l'écran principal (pas besoin de swiper vers `Actions`). 2. Étape avec score chrono manuel (`_ManualScoreContent`) → bouton `[✓]` absent de ce layout dédié, pas de régression croisée. 3. Écran `Prêt pour la série suivante` → absence confirmée du sous-titre, pas de nouvel élément parasite. 4. Cible tactile et absence d'ambiguïté visuelle avec le bouton pause/play sur écran chrono. - Si le ticket reste "open" c'est vraisemblablement un oubli de requalification après une implémentation antérieure (probablement dans le même lot que #161/#159, cf. commit bc533d6c "lot #165-169 validé QA") plutôt qu'un travail réellement en attente. À confirmer avec Main avant clôture pure, mais aucune architecture nouvelle n'est à cadrer.