chore(wip): lot #165-169 validé QA + rework foreground #163 (KO - preuve device/toolchain insuffisante)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.ideai/tickets/166/carnet.md

@@ -0,0 +1,67 @@
+---
+issueRef: "#166"
+version: 8
+updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
+updatedAt: 1785254327361
+---
+
+## #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.