---
issueRef: "#140"
version: 5
updatedBy: {"kind":"user"}
updatedAt: 1785160464016
---
## Cadrage UX (agent UX, 2026-07-27)

**Nature** : gap fonctionnel réel côté montre (vérifié dans le code), prêt à implémenter avec une décision de layout.

**Constat technique** : `watch_session_view_model.dart`/`watch_session_screen.dart` — quand `projection.hasManualScore` est vrai, `_ActiveContent` bascule exclusivement sur `_ManualScoreContent` (score +/-) et n'affiche plus jamais le chrono ni le bouton pause/play, même si l'étape en a un. C'est le bug exact décrit par le ticket.

**Décision UX** : le score reste la donnée dominante de l'écran (l'action principale sur la montre est +/-). Le chrono devient une **donnée secondaire compacte**, affichée sous le nom d'exercice — même emplacement/style que `secondaryTimers` déjà utilisé côté purement-chrono (réutiliser `_compactTimerText`), aujourd'hui invisible dans `_ManualScoreContent`.

**Layout `_ManualScoreContent`** :
```
[objectif score, si présent]
SCORE
[-]   12   [+]
ÉTAPE · 00:07        ← nouvelle ligne compacte
Nom exercice
[status]
```

**Contrôle du chrono** : uniquement si ce chrono est piloté manuellement par l'utilisateur (cas "chrono score d'étape" sur étape à répétitions, cf. [[gametime-ux-score-chrono]]) — ajouter un petit bouton pause/play à côté de la ligne, en réutilisant `_TimerToggleButton` réduit (≈32 au lieu de 48, peu de place sur la montre), pas un nouveau composant. Si le chrono est un simple compte à rebours automatique d'étape "Temps" (avance seule, cf. enchaînement [[gametime-ux-step-chaining-override]]), ne pas ajouter de bouton — afficher la valeur seule, cohérent avec l'avancement automatique.

**Bridge** : vérifier avec Architect si `dominantTimer`/`secondaryTimers` projettent déjà cette donnée quand `hasManualScore` est vrai ; si non, ajouter la projection manquante — pas de nouveau concept de commande nécessaire.