---
issueRef: "#132"
version: 8
updatedBy: {"kind":"user"}
updatedAt: 1785141275322
---

## #132 — Avis UX bref (2026-07-27)

Décision simple : rendre le geste symétrique. Si swipe gauche (séance → actions) existe déjà comme pager horizontal, activer le swipe droit (actions → séance) sur ce même pager plutôt que d'exiger le tap. Garder le bouton existant en complément (pas de régression pour qui ne découvre pas le geste) — pas un remplacement, une addition. Aucun nouveau libellé ni état à concevoir. Prêt pour implémentation directe.

---

## Cadrage technique Architect (2026-07-27)

**Root cause probable identifiée** — conflit avec le geste système Wear OS, pas un bug applicatif Flutter classique.

`watch_session_screen.dart` utilise déjà un `PageView` standard (`_pageController`, ligne 18-24, `PageView` ligne 52) avec deux pages : session (index 0) et actions (index 1). Un `PageView` Flutter standard est **nativement bidirectionnel** — rien dans `_ActionsView` (`lib/presentation/watch_session_screen.dart:638` et suivants) ne bloque le swipe : ce sont des `OutlinedButton` en pleine largeur dans un `Column`/`Stack`, aucun `GestureDetector`/scrollable horizontal imbriqué qui capturerait le drag avant le `PageView`.

Donc l'asymétrie observée (swipe gauche marche, swipe droit ne marche pas) ne vient probablement pas du code Flutter, mais du **geste système Wear OS "swipe to dismiss"** : par défaut, Android Wear réserve la zone de bord gauche de l'écran pour un swipe-vers-la-droite (glisser le doigt de gauche à droite en partant du bord) interprété comme "retour/dismiss" au niveau de la fenêtre native, **avant** que Flutter ne reçoive le geste. Aucune configuration n'a été trouvée dans `watch_app/android/app/src/main/res/values*/styles.xml` (`windowSwipeToDismiss` absent, donc comportement par défaut du thème actif). C'est cohérent avec le symptôme précis : seul le swipe *partant du bord gauche vers la droite* est absorbé par le système, pas le swipe gauche (séance→actions) qui part du centre/droite de l'écran vers la gauche.

### Contrat technique (à valider on-device par DevFrontend, deux pistes par ordre de préférence)
1. **Désactiver le swipe-to-dismiss système sur cet écran** pour laisser le geste au `PageView` applicatif : `android:windowSwipeToDismiss="false"` sur le thème de `MainActivity` (`styles.xml`), ou gestion explicite via `OnBackInvokedCallback`/`BackHandler` si l'app cible l'API de predictive-back. Cohérent avec le fait que GameTime n'a pas besoin du dismiss système ici : le bouton retour physique/couronne reste la sortie d'app standard, le swipe droit devient un geste de navigation interne au pager.
2. Si la contrainte OS empêche de désactiver complètement le dismiss (à vérifier on-device), alterative : ne pas ancrer `_ActionsView` sur le bord gauche de l'écran (ex. léger padding gauche pour que le point de départ du swipe utilisateur naturel soit hors de la zone système réservée) — solution de repli, moins propre, seulement si l'option 1 s'avère impossible.
- Garder le bouton `IconButton`/`chevron_left` existant (ligne 673-681) en complément, conformément à l'avis UX ci-dessus — c'est déjà le cas, aucun changement requis sur ce point.

### Tests
Non testable en sandbox (comportement de geste système natif Wear OS, cohérent avec les autres limites déjà connues, cf. [[gametime-watch-companion-implementation]]) — validation manuelle on-device requise : swipe droit depuis l'écran actions doit revenir sur l'écran session, sans déclencher de dismiss/sortie d'app.

**Prêt pour implémentation directe. Un point à vérifier on-device par DevFrontend avant de considérer le correctif complet** : confirmer que la piste 1 (`windowSwipeToDismiss=false`) ne réintroduit pas de régression sur la sortie d'app via bouton retour physique — pas un arbitrage produit, une vérification technique de mise en œuvre.
