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