Cadrage des vues d'entraînement au choix, et point d'étape du 21/08

Le chantier « écrans configurables façon WorkOutDoors » est cadré, rien n'est
codé. docs/watch-training-screens.md fixe l'analyse pour qu'une session
ultérieure n'ait pas à la refaire.

Ce qui a été établi :

- LiveWorkoutView a cinq métriques ÉCRITES EN DUR ; il n'existe aucune notion
  de champ, de page ni de configuration. Tout est à créer.
- Neuf champs sont disponibles sans aucune collecte nouvelle (dont allure, D+,
  précision GPS, étape du fractionné) ; FC moyenne, temps en zone, cadence,
  puissance et laps demandent du travail.
- Décision : la configuration s'édite côté WEB (TileManager existe déjà) et
  voyage par WCSession — donc changer ses écrans ne demandera aucun rebuild
  Xcode, comme pour la routine.
- Le modèle et le catalogue sont du Foundation pur : écrits et testés sur
  Linux, seul le rendu TabView exige le Mac. Ne pas commencer par le rendu.
- Deux contraintes tenues dès la conception : 1 Hz maximum et page visible
  seule (le CPU suspend l'app et arrête le GPS sans erreur), et espacement des
  mises à jour en luminance réduite.

COWORK gagne le point d'étape du 21/08 : build passé, correctif finishRoute, et
surtout le fait que les 4 vérifications au poignet ne sont PAS encore faites —
les logs du jour ne montrent que l'app iPhone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/watch-training-screens.md

@@ -0,0 +1,107 @@
+# Vues d'entraînement au choix sur la montre — cadrage du 2026-08-21
+
+Chantier **non commencé**. Ce document fixe ce qui a été établi le 21/08 pour
+qu'une session ultérieure reprenne sans refaire l'analyse.
+
+Objectif : des écrans de séance configurables façon **WorkOutDoors** — plusieurs
+pages, des champs au choix, un profil par sport.
+
+## Point de départ réel (vérifié, pas supposé)
+
+`LiveWorkoutView` (`ios/App/CoachWatch/ContentView.swift`, ~l.392-441) est un
+`ScrollView` avec **cinq métriques écrites en dur** : FC + zone, calories,
+distance, vitesse km/h, durée — puis l'état iPhone et les boutons
+Pause / Terminer.
+
+**Il n'existe aujourd'hui aucune notion de champ, de page, ni de configuration.**
+Tout est à créer.
+
+## Les quatre briques manquantes
+
+### 1. Un catalogue de champs
+
+Chaque métrique doit devenir une valeur identifiable (`id` stable, libellé,
+unité, couleur, formatage) et non une ligne de vue. C'est ce qui permet à une
+page de déclarer `["hr", "pace", "distance"]` sans que la vue connaisse les
+champs à l'avance.
+
+**Disponibles immédiatement, aucune collecte nouvelle :**
+
+| Champ | Source |
+|---|---|
+| FC + zone | `WorkoutManager.heartRate` + `ConnectivityManager.zones` |
+| Calories | `WorkoutManager.activeEnergyKcal` |
+| Distance | `WorkoutManager.distanceMeters` |
+| Vitesse km/h | `WorkoutManager.speedKmh` |
+| Durée | `WorkoutManager.elapsedSec` |
+| **Allure min/km** | dérivée de `speedKmh` (rien à collecter) |
+| **D+ / D−** | `LocationTracker.ascentMeters` / `descentMeters` |
+| **Précision GPS** | `LocationTracker.horizontalAccuracy` |
+| **Étape du fractionné** | `IntervalEngine`, dès qu'il est câblé (cf. COWORK) |
+
+**Demandent du travail :**
+
+- **FC moyenne** et **temps passé par zone** : rien ne les accumule aujourd'hui.
+- **Cadence** : non collectée sur la montre.
+- **Puissance de course** (`runningPower`, watchOS 9+).
+- **Tours / laps** : aucun `HKWorkoutEvent` posé aujourd'hui.
+
+### 2. Un modèle de page
+
+```
+WorkoutScreenConfig { sport: String, pages: [WorkoutPage] }
+WorkoutPage        { id: String, fields: [String] }
+```
+
+Rendu par un `TabView` paginé (défilement vertical + Digital Crown, watchOS 10+).
+1 à 4 champs par page selon la taille d'écran — l'Ultra en tient davantage.
+
+💡 **Ce modèle est du Foundation pur** : il s'écrit et se teste **sur Linux**
+(`./tests-linux/run.sh`), comme `IntervalEngine` et ses 17 tests. Seul le rendu
+SwiftUI exigera Xcode.
+
+### 3. Où l'utilisateur choisit — décision prise le 21/08
+
+**La configuration s'édite côté web et se pousse à la montre.** Pas d'écran de
+réglages sur la montre.
+
+- `TileManager` (long-press, drag, toggle) existe déjà côté web : le paradigme
+  est là, éprouvé sur les tuiles.
+- Même chemin de transport que la routine et les zones : `WCSession` →
+  `ConnectivityManager`.
+- **Conséquence décisive** : changer ses écrans ne demanderait **aucun rebuild
+  Xcode**. C'est exactement ce qui rend la routine agréable aujourd'hui — « les
+  blocs voyagent avec l'état, rien n'est codé en dur côté watchOS ».
+- Un **profil par sport** (course ≠ vélo ≠ renfo), comme WorkOutDoors.
+
+⚠️ **Repli obligatoire** : sans configuration reçue, la montre affiche les cinq
+champs actuels. Jamais d'écran vide — la config peut ne pas être arrivée, et une
+séance ne s'interrompt pas pour ça.
+
+### 4. Deux contraintes watchOS, à tenir dès la conception
+
+- **Le CPU tue le GPS** (piège n°4 documenté dans `LocationTracker.swift`) :
+  watchOS suspend une app trop gourmande et les positions s'arrêtent **sans
+  aucune erreur**. ⇒ rafraîchissement **1 Hz maximum**, et ne recalculer **que
+  la page visible**, jamais les quatre. Ne pas utiliser un `Timer` de vue.
+- **Écran always-on** : en luminance réduite (`@Environment(\.isLuminanceReduced)`),
+  espacer les mises à jour, sinon la batterie fond sur une sortie longue.
+
+## Effort estimé
+
+| Lot | Estimation |
+|---|---|
+| Châssis (catalogue + modèle + config web + push + `TabView`) | ~1 jour |
+| Chaque métrique dérivée supplémentaire | 30 min à 2 h |
+| Always-on propre | ½ jour |
+
+## Ordre proposé
+
+1. **Modèle + catalogue en Foundation pur**, testés sur Linux — sans Mac.
+2. **Endpoint serveur + éditeur web** (réutiliser `TileManager`).
+3. **Push `WCSession`** et publication dans `ConnectivityManager`.
+4. **Rendu `TabView`** dans `LiveWorkoutView`, avec le repli en dur.
+5. Métriques accumulées (FC moyenne, temps en zone) — chacune isolément.
+
+⚠️ Ne pas commencer par le rendu : c'est la seule partie qui exige le Mac, et
+elle ne se juge qu'une fois les données au bon format.