1.8 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||
|---|---|---|---|---|---|
| #136 | 11 |
|
1785318540643 |
#136 — Cadrage UX (2026-07-28)
Comportement attendu : tap sur Passer le repos → bouton passe en état pending bref (Envoi..., pattern déjà spécifié gametime-ux-watch-companion) → commande envoyée au téléphone → téléphone applique le skip (repos terminé, phase avance) → c'est la projection confirmée qui fait changer l'écran montre, jamais un tap local. Le repos réel côté téléphone doit changer ; l'écran montre ne doit refléter ce changement qu'une fois l'ack/la nouvelle projection reçus.
Contraintes UI/feedback :
- Ne jamais quitter l'écran
Reposavant réception d'un ackaccepted/acceptedNoOp+ nouvelle projection. Si rejet (rejectedStaleRevision,rejectedNotApplicable…), rester surReposavec son état confirmé actuel, sans transition fantôme. - Si latence perceptible, réutiliser les seuils déjà cadrés (état
Envoi...court, puisEn attente du téléphone) plutôt qu'un basculement d'écran optimiste.
À ne pas faire :
- Naviguer localement vers l'écran séance active sur simple tap, avant confirmation — c'est exactement le bug actuel (l'écran change sans que le repos ait réellement sauté côté téléphone).
- Ajouter une confirmation (
Passer le repos ?) : cette action reste dans la liste des actions immédiates, pas dans celles à confirmer (gametime-ux-watch-companion).
Libellé/navigation : aucune évolution nécessaire. Le libellé Passer le repos et le modèle « écran piloté par la projection confirmée » sont déjà correctement spécifiés — c'est un bug d'implémentation (navigation locale avant état confirmé, ou commande mal routée côté téléphone), pas un manque de conception.