Revue UX close et arbitrée ; plan de la révision UX (0e.3)

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

CLAUDE.md

@@ -1,7 +1,7 @@
 # CLAUDE.md — Règles du projet
 
 Ce fichier est lu par Claude Code au début de chaque session. Il fixe le cadre du projet.
-Le cadrage complet est dans `docs/cadrage.md`, l'étape en cours dans `docs/etape-0.md`.
+Le cadrage complet est dans `docs/cadrage.md`, le travail en cours dans `docs/feuille-de-route.md`.
 
 **En début de session**, lire `docs/organisation.md`, `docs/feuille-de-route.md`, la fin
 de `docs/journal.md`, l'index des ADR (`docs/adr/README.md`) et les plans en cours dans `docs/plans/`, puis reprendre là où en

docs/adr/0012-mode-immersif.md

@@ -53,3 +53,27 @@ des pions dans les deux cas.
   testée (`make test-browser`).
 - Le plein écran masque la barre d'état du téléphone, ce qui libère encore un
   peu de place.
+
+## Amendements
+
+### 2026-11-03 — Vue paysage dès la rotation, plateau = écran
+
+Décidé par Pierre après son premier essai sur le téléphone, où la vue paysage
+à deux colonnes (plateau limité à 70 % de la largeur, texte à droite) lui a
+paru « vraiment pas optimale ».
+
+- Dès que le téléphone est en paysage, même sans plein écran, l'app applique
+  la mise en page « plateau = écran » sur la hauteur réelle (`100dvh`, barre
+  d'adresse comprise). La mise en page à deux colonnes disparaît.
+- Dans cette vue, les contrôles sont dans le plateau : comptes de points sur la
+  barre, videau au milieu de la barre, dés et consigne dans la bande centrale,
+  pictogrammes (menu, annuler, plein écran) dans la colonne des sorties
+  (maquette « Immersif : plein écran, contrôles dans le plateau » du canevas
+  ci-dessus). La géométrie du plateau suit les proportions de l'écran ; les
+  numéros des flèches font au moins 12 px.
+- Le bouton « Plein écran » garde son rôle : plein écran, verrouillage en
+  paysage, repli par rotation CSS.
+
+La bascule automatique écartée plus haut était celle qui forçait
+l'orientation ; ici, seule la mise en page suit l'orientation choisie par le
+joueur.

docs/etape-0.md

@@ -1,73 +0,0 @@
-# Étape 0 — Prototype technique
-
-**But** : prouver que la chaîne technique fonctionne avant d'investir dans le design, et trancher entre deux socles : PWA (moteur en WebAssembly) ou Android natif.
-
-**Règle** : chaque sous-étape se termine par une démonstration que le développeur peut lancer lui-même avec une commande `make`.
-
----
-
-## 0a. Le moteur en ligne de commande
-
-**Objectif** : interroger le moteur GNU Backgammon sur une position, depuis le PC.
-
-À faire :
-1. Récupérer les sources du moteur (choisir entre gnubg, gnubg-nn ou le moteur extrait par CBG ; justifier le choix dans un ADR, `docs/adr/`).
-2. Définir une **interface C minimale** du moteur (`engine/include/engine.h`, identifiants en anglais : ADR 0007), indépendante de toute interface graphique :
-   - initialiser le moteur (charger réseaux, base de fin de partie, table d'équité de match) ;
-   - lister les coups légaux pour une position et des dés ;
-   - donner le meilleur coup et le classement des coups avec leur équité, pour un niveau d'évaluation donné ;
-   - donner la décision de videau (pas de double, double/prend, double/passe, avec équités) ;
-   - évaluer une position (probabilités de gain, gammon, backgammon).
-   Les positions entrent et sortent au format **GNU Position ID + Match ID**.
-3. Écrire `engine-cli`, un petit programme qui expose ces fonctions en ligne de commande, avec une sortie JSON.
-4. Générer un jeu de **positions de référence** (au moins 30 : ouvertures, contact, course, sortie, décisions de videau) avec le GNU Backgammon de bureau dans Docker, et stocker les résultats attendus dans `tests/reference/`.
-5. `make test` compare `engine-cli` aux références (même meilleur coup, équités à une tolérance près, à fixer).
-
-**Démo** : `make engine && ./build/engine-cli bestmove <position_id> <match_id> 31` affiche le meilleur coup en JSON ; `make test` passe.
-
----
-
-## 0b. Le test WebAssembly (décisif)
-
-**Objectif** : savoir si le moteur tourne assez vite et léger dans le navigateur du téléphone.
-
-À faire :
-1. Compiler le même moteur et la même interface C en WebAssembly avec Emscripten (dans Docker).
-2. Charger le moteur dans un **Web Worker** (jamais sur le fil d'affichage).
-3. Page HTML minimale : un champ Position ID, des dés, un bouton « meilleur coup », l'affichage du résultat et du temps de calcul.
-4. Rejouer les positions de référence dans le navigateur : les résultats doivent concorder avec 0a.
-5. `make deploy-web` sert la page sur le réseau local pour l'ouvrir depuis le Fairphone 4.
-6. `make bench` (ou une page de mesure) produit un petit rapport : temps par coup selon le niveau d'évaluation, taille téléchargée, mémoire utilisée.
-
-**Critères de réussite (à ajuster après mesure)** :
-
-| Mesure sur le Fairphone 4 | Seuil |
-| --- | --- |
-| Meilleur coup, niveau rapide (0-ply GNU) | moins de 0,3 s |
-| Meilleur coup, niveau fort (2-ply GNU) | moins de 3 s |
-| Décision de videau, niveau fort | moins de 3 s |
-| Taille totale à télécharger (wasm + données, compressé) | moins de 40 Mo |
-| Résultats identiques aux références de 0a | 100 % |
-
-**Démo** : la page ouverte sur le Fairphone donne le meilleur coup d'une position de référence, avec le temps de calcul affiché.
-
----
-
-## 0c. Android natif (seulement si 0b échoue)
-
-**Objectif** : la même démonstration en application Android.
-
-À faire :
-1. Compiler le moteur pour arm64 avec le NDK (dans Docker), en s'appuyant sur la configuration de CBG.
-2. Application Android minimale, construite en ligne de commande (Gradle sans Android Studio, `-j2`, démon Gradle limité en mémoire).
-3. Même écran de test et mêmes mesures qu'en 0b.
-4. `make deploy` installe l'APK sur le Fairphone via adb.
-
----
-
-## 0d. Plateau minimal et décision
-
-1. Sur le socle retenu, un **plateau minimal** : une partie complète jouable contre le moteur, coups et videau décidés par le moteur, dés tirés par l'app.
-2. Rédiger un ADR (`docs/adr/`) : socle retenu (PWA ou Android natif), mesures obtenues, raisons, risques restants.
-
-**Critère de fin de l'étape 0** : une partie complète jouée sur le Fairphone 4, moins de 2 s par coup de l'IA en niveau standard, tous les tests au vert.

docs/etape-1.md

@@ -0,0 +1,55 @@
+# Étape 1 — V1 « Jouer et comprendre »
+
+Document temporaire : il décrit l'étape en cours et sera supprimé à sa clôture,
+après report de ce qui est durable dans les ADR et le journal.
+
+**Critère de fin** (cadrage) : un débutant apprend et joue seul ; un joueur de
+club comprend ses erreurs. Livré avec un plan de test (`docs/guide-test-etape-1.md`)
+que Pierre déroule sur le Fairphone 4.
+
+**Préalable** : les sous-étapes 0e (retours du premier test) de la feuille de
+route, dont la revue UX validée par Pierre.
+
+## Périmètre
+
+Repris du cadrage (modules, écrans clés, IA générative en V1) et des ADR 0010,
+0011 et 0012. Ce qui n'y figure pas est hors de l'étape 1.
+
+| Sous-étape | Contenu | Dépend de |
+| --- | --- | --- |
+| 1a. Moteur pour l'analyse | Niveaux de jeu (plis et bruit de GNU Backgammon : débutant à expert), classement des coups d'un jet avec équités, analyse d'un coup joué et d'une décision de videau, chance d'un jet ; exposés par `engine.h`, `engine-cli` et le Worker, avec positions de référence comparées à gnubg de bureau | — |
+| 1b. Parties enregistrées | Stockage IndexedDB derrière l'interface de stockage existante : plusieurs parties, reprise automatique, branches (« Rejouer d'ici » crée une branche, l'originale reste intacte et rechargeable), export SGF avec variantes | — |
+| 1c. Match et réglages | Partie libre ou match en N points, règle Crawford, règle Jacoby, choix du niveau de l'ordinateur, conseil du maître activable ou non ; écran de nouvelle partie | 1a, 1b |
+| 1d. Conseil du maître | Après chaque coup du joueur, jamais avant (ADR 0011) : appréciation du moteur (bon coup, imprécision, erreur, gaffe) avec mot, icône et couleur, phrase du maître fondée sur les chiffres du moteur, coup recommandé montré sur demande ; aussi pour les décisions de videau ; calcul en arrière-plan sans retarder le jeu | 1a |
+| 1e. Fin de partie et analyse | Bilan (ADR 0011) : résultat, coups par appréciation, taux d'erreur comparé à la chance, « le coup à revoir » ; écran d'analyse : graphe d'équité (toucher un point ouvre la position), liste des erreurs filtrable, visualiseur pas à pas coup joué contre meilleur coup, « Rejouer d'ici » | 1a, 1b, 1d |
+| 1f. Prompts à copier | Gabarits versionnés et testés (`docs/prompts/` ou équivalent, source unique), bouton « Demander à une IA » sur le plateau, le conseil du maître, l'analyse et la fin de partie ; le moteur décide, l'IA explique | 1d, 1e |
+| 1g. Accueil, tutoriel et leçons | Accueil (reprendre, nouvelle partie, prochaine leçon, progression résumée), tutoriel des règles interactif et illustré (0e.5), cinq premières leçons numérotées (ADR 0011) avec positions et « à vous de jouer », progression locale ; contenus CC BY-SA 4.0 en brouillon, à relire par un joueur fort | 0e.5, 1a |
+| 1h. Progression | Historique des parties et courbe du taux d'erreur | 1b, 1e |
+| 1i. Plateau soigné | Dessin du plateau aligné sur la charte (`docs/identite/charte/board.js`), animations des pions, glisser-déposer en plus du toucher, double toucher pour le seul coup évident | 0e.3 |
+| 1j. Plan de test | `docs/guide-test-etape-1.md` : parcours du débutant et du joueur de club sur le téléphone, avec ce qu'il faut rapporter | toutes |
+
+## Orientation donnée par Pierre
+
+- **Un coach bienveillant, mis en avant mais discret** (2026-11-03) : le
+  conseil du maître et les conseils sont une signature de l'app, présents à
+  chaque partie, sans jamais interrompre le jeu ni culpabiliser le joueur. Le
+  ton des phrases du maître est encourageant ; l'espace qu'il occupe est
+  réservé dans la mise en page (revue UX 0e.2), pas en fenêtre surgissante.
+
+## Questions pour Pierre (ne bloquent pas le démarrage)
+
+- **Indice** : le cadrage le liste dans le module Jeu, l'ADR 0011 l'a laissé
+  « à concevoir séparément ». Il n'est pas dans l'étape 1 sans décision.
+- **Questionnaire de premier lancement** (choix du parcours) : le parcours 1
+  seul existe en V1 ; proposé : un simple choix « Je découvre » / « Je connais
+  les règles » qui oriente vers le tutoriel ou la partie.
+- **Seuils des appréciations** : proposés d'après ceux de GNU Backgammon
+  (douteux 0,04, mauvais 0,08, très mauvais 0,16 d'équité), à calibrer.
+- **Relecture des leçons** par un joueur fort de l'Atelier du Huit.
+
+## Ordre de réalisation
+
+1a et 1b d'abord (fondations, sans conflit avec l'interface), en parallèle des
+sous-étapes 0e. Puis 1c, 1d, 1e, 1f dans cet ordre ; 1g après la validation des
+maquettes d'accueil et de tutoriel par Pierre ; 1h et 1i ; 1j en dernier. Chaque
+sous-étape a son plan dans `docs/plans/` et sa merge request.

docs/feuille-de-route.md

@@ -3,38 +3,36 @@
 Le travail restant, dans l'ordre. Une ligne réalisée est retirée : ce qui a été
 fait se lit dans les merge requests et le journal, ce qui a été décidé dans les
 ADR (`docs/adr/`). Les versions et leur contenu sont définis dans
-`docs/cadrage.md` ; le détail de l'étape en cours est dans `docs/etape-0.md`.
+`docs/cadrage.md`.
 
 Légende : 🔄 en cours · ⏳ à venir · ⏸ conditionnel
 
-## Étape 0 — Prototype technique
+## Étape 0 — Prototype technique : terminée
 
-Acquis : socle du dépôt, organisation (ADR 0001, 0003, 0006), source du moteur
-(ADR 0005 : gnubg officiel, commit 14b6798), gnubg de référence et 32 positions
-de référence (0a.2), moteur embarqué et `engine-cli` (0a.3), comparaison
-automatique aux références, tolérance 0,002 (0a.4), moteur en WebAssembly avec
-page de test, page de mesure et guide de test (0b), mesures sur le Fairphone 4 et
-socle PWA en TypeScript (ADR 0009 ; 0c Android natif abandonnée), domaine
-« partie » en journal d'événements avec scénario exécuté sur le vrai moteur et
-garde-fous d'architecture (0d.1), déploiement sur https://ustagammon.sans.pub.
+Close le 2026-11-03 : partie complète jouée par Pierre sur le Fairphone 4, coups
+de l'ordinateur rapides, tous les tests au vert. Acquis : moteur gnubg officiel
+(ADR 0005) comparé à 32 positions de référence, moteur en WebAssembly, socle
+PWA en TypeScript (ADR 0009 ; Android natif abandonné), domaine « partie » en
+journal d'événements, plateau jouable hors ligne avec la charte graphique,
+publié sur https://ustagammon.sans.pub. Le détail est dans le journal et les
+merge requests.
+
+## Retours du premier test sur téléphone (avant l'étape 1)
+
+Demandes de Pierre du 2026-11-03, traitées avant d'ouvrir l'étape 1.
 
 | Sous-étape | Contenu | État | Plan |
 | --- | --- | --- | --- |
-| 0d.2 | Plateau minimal jouable (PWA hors ligne), publié ; reste la vérification avec Pierre sur le Fairphone 4 (`docs/guide-test-etape-0.md`, section « Étape 0d ») | 🔄 | |
 | 0e.1 | Saisie du coup : pion à destination unique joué en un toucher, coup à valider et annulable demi-coup par demi-coup, dés joués marqués, dés des deux côtés touchables, videau confirmé ; pages de test du moteur retirées | 🔄 | `plans/2026-11-03-saisie-du-coup.md` |
-| 0e.2 | Revue UX par un designer UI : compte de points, fluidité (bouton « Nouvelle partie », interruptions), paysage ; propositions à valider par Pierre | 🔄 | `plans/2026-11-03-revue-ux.md` |
-| 0e.3 | Paysage sur téléphone : plateau sur presque tout l'écran, contrôles en pictogrammes (ADR 0012 à amender), selon la revue validée | ⏳ | |
+| 0e.3 | Révision UX arbitrée (session « identité », sur délégation de Pierre) : portrait stable, bandeaux de compte de points, menu en feuille et nouvelle partie annulable, vibrations, écran allumé, paysage « plateau = écran » dès la rotation (ADR 0012 amendé) | ⏳ | `plans/2026-11-03-revision-ux.md` |
 | 0e.4 | Position dans l'adresse : chaque position du plateau a un lien direct (nouvel ADR pour le format) | ⏳ | |
 | 0e.5 | Page d'accueil, installation en un toucher (« Ajouter à l'écran d'accueil », proposée par l'app), tutoriel des règles très didactique avec plateaux illustrés, aide réécrite sur un ton plus humain ; textes à valider par Pierre | ⏳ | |
 
-**Critère de fin** : une partie complète jouée sur le Fairphone 4, moins de 2 s
-par coup de l'IA en niveau standard, tous les tests au vert.
-
 ## Étapes suivantes
 
 | Étape | Contenu | État |
 | --- | --- | --- |
-| 1. V1 Jouer et comprendre | Charte graphique appliquée à la PWA (ADR 0010, `docs/identite/charte/`), plateau soigné, niveaux, conseil du maître après le coup, bilan de fin de partie, premières leçons numérotées (ADR 0011), mode immersif en paysage (ADR 0012), analyse, branches, tutoriel, prompts, sauvegarde | ⏳ |
+| 1. V1 Jouer et comprendre | Détail et ordre dans `docs/etape-1.md` : moteur pour l'analyse, parties enregistrées et branches, match et réglages, conseil du maître, fin de partie et analyse, prompts, accueil, tutoriel et leçons, progression, plateau soigné, plan de test | 🔄 |
 | 2. V1.5 Apprendre | Parcours 2, exercices, progression | ⏳ |
 | 3. V2 Perfectionnement et IA | Parcours 3 et 4, rollouts, révision espacée | ⏳ |
 

docs/guide-test-etape-0.md

@@ -1,171 +0,0 @@
-# Guide de test : Ustagammon sur le Fairphone 4 (étape 0)
-
-Document temporaire de l'étape 0 : il sera supprimé avec `docs/etape-0.md`.
-
-Deux tests sur le téléphone :
-
-- **Étape 0d : jouer une partie** (section suivante), sur le site publié ;
-- **Étape 0b : mesurer le moteur** (fait le 2026-11-02), sur une page
-  servie par le PC.
-
-## Étape 0d : jouer une partie sur le téléphone
-
-Le but : installer l'application sur le Fairphone 4, jouer une partie
-complète contre l'ordinateur, vérifier qu'elle marche sans réseau, et
-rapporter ce que vous avez constaté. Comptez une demi-heure.
-
-### Ouvrir et installer l'application
-
-1. Sur le Fairphone, ouvrez Chrome et allez sur https://ustagammon.sans.pub.
-2. Attendez que le plateau s'affiche et que le message « Chargement du
-   moteur… » laisse place à une consigne (par exemple « À vous : lancez les
-   dés. » ou « L'ordinateur réfléchit… »). La première fois, le moteur se
-   télécharge (environ 7 Mo) : quelques secondes en Wi-Fi.
-3. Installez l'application : menu de Chrome (les trois points), puis
-   « Installer l'application » ou « Ajouter à l'écran d'accueil ». Une icône
-   (deux pions sur du bois) apparaît sur l'écran d'accueil.
-4. Fermez Chrome et ouvrez Ustagammon depuis cette icône : l'application
-   s'ouvre en plein écran, sans barre d'adresse.
-
-### Jouer une partie complète
-
-Suivez le scénario « Jouer une partie contre l'ordinateur »
-(`docs/scenarios/jouer-une-partie.feature`), qui est aussi l'aide de
-l'application : bouton « Aide », en haut.
-
-1. Une partie commence d'elle-même au premier lancement, par le jet
-   d'ouverture (un dé chacun) : le message dit qui commence. « Nouvelle
-   partie », en haut, en recommence une.
-2. Quand c'est à vous : touchez « Lancer les dés » (ou « Doubler », pour
-   proposer de doubler avant de lancer).
-3. Pour jouer : touchez un pion entouré de vert, puis l'une des cases
-   d'arrivée en surbrillance ; recommencez pour chaque dé. Pour sortir un
-   pion, touchez le bac à droite, en bas. « Annuler » remet les pions du coup
-   en cours à leur place.
-4. Le coup est envoyé dès qu'il est complet ; l'ordinateur joue ensuite, et
-   le message dit son coup et son temps de calcul, par exemple
-   « L'ordinateur a joué 6-4 : 24/18 13/9 (0,3 s) ». Les petits points
-   orange marquent ses cases de départ et d'arrivée (dans sa numérotation :
-   sa case 24 est votre case 1).
-5. Si l'ordinateur vous propose de doubler : « Prendre » ou « Passer ».
-   Essayez au moins une fois de doubler vous-même.
-6. En fin de partie, le message donne le gagnant, la sorte de victoire
-   (simple, gammon ou backgammon) et les points.
-
-En cours de partie, fermez l'application (balayez-la dans la liste des
-applications ouvertes), puis rouvrez-la : la partie doit reprendre là où vous
-en étiez.
-
-### Vérifier le hors ligne
-
-1. Après avoir ouvert l'application au moins une fois (attendez une
-   vingtaine de secondes après le premier chargement, le temps que tout soit
-   mis de côté), fermez-la.
-2. Passez le téléphone en mode avion.
-3. Rouvrez Ustagammon depuis son icône : le plateau, l'ordinateur et l'aide
-   doivent fonctionner comme avant.
-4. Repassez en mode normal.
-
-### Ce qu'il faut rapporter
-
-Dans la conversation avec Claude Code :
-
-- les **temps des coups de l'ordinateur** : ceux affichés dans les messages
-  (le plus long que vous avez vu), et votre ressenti (attente gênante ou
-  non) ;
-- si la partie est allée **jusqu'au bout**, et son résultat ;
-- si la **reprise** après fermeture et le **mode avion** ont marché ;
-- tout ce qui gêne : plateau trop petit, case difficile à toucher, texte
-  incompréhensible, bouton qui ne répond pas, couleurs peu lisibles (thème
-  clair ou sombre du téléphone) ;
-- une **capture d'écran** (bouton marche + volume bas) de tout problème.
-
-Si vous le pouvez, refaites l'essai dans Firefox sur le téléphone (sans
-l'installer) et dites si les temps de l'ordinateur sont nettement plus longs.
-
-## Étape 0b : mesurer le moteur
-
-Le but : ouvrir sur le téléphone une page web où le moteur de backgammon
-calcule, puis lancer une mesure et coller son rapport dans la conversation.
-Comptez un quart d'heure.
-
-### 1. Préparer le PC
-
-1. Ouvrez un terminal dans le dossier du projet (`~/Code/ustagammon`).
-2. Si ce n'est pas déjà fait, tapez `make setup` puis Entrée. Cela prépare les
-   outils. La première fois, c'est long ; ensuite, c'est immédiat.
-3. Le PC et le téléphone doivent être sur **le même Wi-Fi** (la même box).
-
-### 2. Lancer la page
-
-1. Tapez `make deploy` puis Entrée.
-2. La première fois, le moteur se compile : quelques minutes.
-3. Le terminal affiche deux adresses, par exemple :
-
-   ```
-   Application : http://192.168.1.21:8080/
-   Test du moteur : http://192.168.1.21:8080/moteur/
-   Page de mesure : http://192.168.1.21:8080/moteur/bench.html
-   ```
-
-   Vos chiffres peuvent être différents : notez ceux de votre écran.
-4. Laissez ce terminal ouvert pendant tout le test. Pour arrêter la page à la
-   fin : Ctrl+C dans le terminal.
-
-### 3. Essayer un meilleur coup
-
-1. Sur le Fairphone, ouvrez le navigateur (Chrome ou Firefox).
-2. Tapez l'adresse du **test du moteur** dans la barre d'adresse, exactement
-   comme affichée (avec `http://` et `:8080`). Les pages de test sont aussi
-   publiées : https://ustagammon.sans.pub/moteur/ et
-   https://ustagammon.sans.pub/moteur/bench.html.
-3. Attendez le message « Moteur prêt, chargé en … ms ».
-4. Dans « Exemple », choisissez une position, par exemple « middlegame-1 ».
-5. Dans « Niveau », choisissez « fort (2 plis) ».
-6. Touchez « Meilleur coup ».
-7. La page affiche le coup conseillé et le **temps de calcul**. Notez ce temps
-   si vous voulez, il sera aussi dans le rapport.
-
-### 4. Lancer la mesure
-
-1. En bas de la page, touchez « Page de mesure » (ou tapez l'adresse de la
-   page de mesure).
-2. Touchez « Lancer la mesure ».
-3. Attendez « Mesure terminée » : de une à quelques minutes. Pendant ce temps,
-   gardez l'écran allumé et la page ouverte, sans changer d'application.
-4. Un tableau résume les résultats : « OK » si le seuil est respecté,
-   « dépassé » sinon.
-
-### 5. Envoyer le rapport
-
-1. Touchez « Copier les résultats ».
-2. Si la page dit « Rapport copié », c'est bon.
-3. Sinon, le texte du rapport est sélectionné : faites un appui long dessus,
-   puis « Copier ».
-4. Collez le rapport dans la conversation avec Claude Code (sur le téléphone,
-   ou envoyez-le vous sur le PC).
-
-Si vous en avez le temps, refaites la mesure une deuxième fois (rechargez la
-page de mesure) et collez aussi ce second rapport : cela montre si les temps
-sont stables. Si les deux navigateurs sont installés, faites la mesure dans
-Chrome **et** dans Firefox : sur le PC, Firefox s'est montré nettement plus
-lent, et le rapport indique le navigateur utilisé.
-
-### Si la page ne s'ouvre pas
-
-- **Vérifiez l'adresse** : `http://` (et non `https://`), les chiffres exacts,
-  et `:8080` à la fin.
-- **Vérifiez le Wi-Fi** : le téléphone doit être sur le même réseau que le PC,
-  pas sur la 4G ni sur un Wi-Fi invité.
-- **Vérifiez que la page tourne** : sur le PC, ouvrez
-  `http://localhost:8080/` dans un navigateur. Si elle ne s'ouvre pas non
-  plus, relancez `make deploy` et lisez le message d'erreur.
-- **Le pare-feu du PC** peut bloquer le téléphone. S'il est actif
-  (`sudo ufw status` affiche « Status: active »), autorisez le port le temps
-  du test : `sudo ufw allow 8080/tcp`, puis à la fin `sudo ufw delete allow
-  8080/tcp`.
-- **« Le moteur n'a pas pu se charger »** : notez le message exact et
-  collez-le dans la conversation. Essayez aussi l'autre navigateur (Chrome ou
-  Firefox), à jour.
-- **Le port 8080 est déjà pris** : un autre programme l'utilise. Lancez
-  `make deploy WEB_PORT=8081` et utilisez `:8081` dans l'adresse.

docs/journal.md

@@ -110,3 +110,29 @@ Une entrée datée par session : ce qui a été fait, décidé, et la suite.
 - Les maquettes proposent des éléments de produit qui ne sont pas encore
   décidés (leçons, « Conseil du maître », bilan de fin de partie) : à valider
   par Pierre avant toute mise en œuvre.
+
+## 2026-11-03 (matin) : fin de l'étape 0, retours du test sur téléphone
+
+**Fait**
+- Pierre a joué une partie complète sur le Fairphone 4 : « très rapide de la
+  part de l'ordinateur ». Avec les tests au vert, le critère de fin de l'étape 0
+  est atteint. Le guide de test et `docs/etape-0.md`, temporaires, sont
+  supprimés ; leurs décisions sont dans les ADR 0005 et 0009.
+- Playwright validé par Pierre (amendement de l'ADR 0004, MR !20).
+- Douze retours de Pierre après l'essai, plus l'installation en un toucher et
+  les retours haptiques, rangés en sous-étapes 0e dans la feuille de route
+  (MR !20). Lancés : la saisie du coup (0e.1) et une revue UX par un designer
+  UI (0e.2).
+- Coordination avec la session « identité » : elle propose et maquette le
+  design (mode immersif, compte de points, accueil, tutoriel), Pierre tranche,
+  la session technique implémente. Numéros des flèches à 12 px minimum.
+- Décision de Pierre : la vue paysage « plateau = écran » s'applique dès la
+  rotation du téléphone, sans plein écran (amendement de l'ADR 0012).
+- Mode avion vérifié par Pierre sur le téléphone : l'application fonctionne
+  hors ligne.
+- Étape 1 découpée dans `docs/etape-1.md` (sous-étapes 1a à 1j).
+- Nouvel objectif fixé par Pierre : traiter les retours 0e (les siens et ceux
+  du designer), puis réaliser l'étape 1, livrée avec un plan de test.
+
+**Reste à faire**
+- Firefox sur le téléphone reste à mesurer.

docs/plans/2026-11-03-moteur-analyse.md

@@ -0,0 +1,60 @@
+# Moteur pour l'analyse et les niveaux (1a)
+
+- **Date** : 2026-11-03
+- **Étape** : 1a (`docs/etape-1.md`)
+- **Statut** : en cours
+- **Exécutant** : sous-agent general-purpose, dans un worktree
+
+## Objectif
+
+Donner au domaine tout ce dont l'étape 1 a besoin du moteur : niveaux de jeu de
+l'ordinateur, analyse d'un coup joué et d'une décision de videau, chance d'un
+jet. Tout vient de GNU Backgammon, comparé à gnubg de bureau.
+
+## Consignes
+
+ADR 0005, 0007 et la méthode de comparaison de `tests/reference/` (README).
+Ne pas modifier `engine/gnubg/` (copie fidèle). Pas de nouvelle dépendance.
+
+1. **Niveaux de jeu** : les niveaux de GNU Backgammon (débutant, amateur,
+   intermédiaire, avancé, expert, champion du monde…), avec leurs plis, filtres
+   et bruit, repris des réglages prédéfinis de gnubg (pas inventés). Le bruit
+   doit être déterministe (option « deterministic » de gnubg) pour que les
+   tests soient reproductibles. API C (`engine.h`), `engine-cli`, adaptateur
+   WebAssembly et interface `Engine` du domaine (ajout seulement : ne pas
+   toucher au reste de `app/src/domain/game/`, qu'un autre agent modifie).
+2. **Analyse d'un coup joué** : pour une position, un jet et un coup joué,
+   l'équité du coup joué, celle du meilleur coup, l'écart, et le rang du coup
+   joué, au niveau d'analyse demandé (comme l'analyse de partie de gnubg).
+3. **Analyse d'une décision de videau** : équités sans double, double/prend,
+   double/passe, et l'écart de la décision prise (double, pas de double,
+   prendre, passer), comme gnubg.
+4. **Chance d'un jet** : la chance (luck) d'un jet au sens de gnubg, et son
+   classement (très chanceux… très malchanceux) avec les seuils de gnubg.
+5. **Seuils d'appréciation** : exposer les seuils de gnubg (douteux, mauvais,
+   très mauvais) comme constantes documentées ; l'interface les traduira.
+6. **Références** : ajouter des positions de référence évaluées par gnubg de
+   bureau (Docker existant, `make reference`) pour l'analyse d'un coup, d'une
+   décision de videau et la chance, comparées par `make test` (natif et
+   WebAssembly) avec la tolérance existante. Les niveaux avec bruit : vérifier
+   au moins que le coup choisi est reproductible et identique à celui de gnubg
+   de bureau sur quelques positions.
+7. Glossaire : fiches pour les nouveaux termes (niveau, chance, appréciation,
+   équité si absente…), reliées au code.
+8. Mesurer sous Node (`make bench` ou équivalent) le temps d'une analyse de
+   coup au niveau prévu pour le conseil du maître (2 plis), pour vérifier
+   qu'elle tient en arrière-plan sur le téléphone (repère : ADR 0009).
+
+Machine ancienne : `-j2`, ne recompiler le moteur que si nécessaire.
+`make lint` et `make test` doivent passer. Commits fréquents ; `git add` avec
+chemins explicites ; ne pas pousser, pas de MR.
+
+## Critères de réussite
+
+- `engine-cli` répond aux nouvelles commandes en JSON.
+- Les nouvelles références concordent avec gnubg de bureau, natif et WebAssembly.
+- `make lint` et `make test` passent.
+
+## Résultat
+
+À remplir à la clôture.

docs/plans/2026-11-03-revision-ux.md

@@ -0,0 +1,63 @@
+# Révision UX : portrait stable, compte de points, menu, paysage « plateau = écran »
+
+- **Date** : 2026-11-03
+- **Étape** : 0e.3 (feuille de route)
+- **Statut** : prévu (après la fusion de 0e.1, qui touche les mêmes fichiers)
+- **Exécutant** : sous-agent general-purpose, dans un worktree
+
+## Objectif
+
+Appliquer la revue UX (0e.2) telle qu'arbitrée par la session « identité » sur
+délégation de Pierre le 2026-11-03, et l'amendement de l'ADR 0012.
+
+## Références
+
+- Maquettes : https://claude.ai/artifact/CQw6vbDpi6XQqVWQa4sANe, rangées
+  « Révision UX » en bas du canevas.
+- Règles : section « Interaction » du design system, copiée dans
+  `docs/identite/charte/interaction.md` (durées, courbes, motifs de vibration,
+  touches) et composant Icons (10 pictogrammes).
+- Rapport du designer UI : conservé dans la description de la MR qui clôt ce
+  plan.
+
+## Décisions à appliquer
+
+1. **Portrait stable** (maquette « Portrait révisé ») :
+   - une barre haute avec le symbole et trois pictogrammes, libellés de 13 px dessous : Aide, Plein écran, Menu ;
+   - le bandeau de l'ordinateur, puis le plateau, puis le bandeau du joueur ;
+   - une ligne réservée de 44 px : le dernier coup de l'ordinateur avec ↻, ou la ligne du maître ;
+   - la consigne ;
+   - une barre d'actions collée en bas, l'action secondaire à gauche et la principale à droite (« Jouer ce coup »). Toucher les dés valide aussi ;
+   - la durée de calcul affichée disparaît.
+2. **Compte de points** :
+   - en portrait, des bandeaux. Les chiffres sont en 20 px gras, alignés. Le bandeau de celui qui a la main est en accent-soft (« Vous · à vous de jouer »). L'écart s'écrit « mène de 8 », en muted, du côté de celui qui mène. Toucher le chiffre ouvre une bulle avec le texte de la fiche du glossaire (source unique, ADR 0008) ;
+   - en paysage, des pastilles aux bouts de la barre.
+3. **Menu en feuille** qui monte du bas :
+   - il contient Nouvelle partie, Plein écran, Aide et glossaire, Thème, et les interrupteurs Vibrations et « Écran allumé pendant la partie » ;
+   - « Nouvelle partie » agit sans confirmation. Un bandeau « Nouvelle partie commencée. Reprendre l'ancienne » reste 10 s avec une barre de temps, et l'ancienne partie se restaure depuis son journal ;
+   - plus de `window.confirm`.
+4. **Pas de passage automatique du tour** quand aucun coup n'est possible : les dés sont barrés avec le message, et le joueur passe en touchant les dés (ou Espace). Ajouter `overscroll-behavior: none` et `user-select: none`. L'écran reste allumé pendant une partie (Wake Lock), activé par défaut, avec un interrupteur.
+5. **Paysage, « le plateau est l'écran »** (ADR 0012 amendé) :
+   - la vue s'applique dès la rotation, sur `100dvh` ;
+   - la géométrie suit l'écran, par une fonction pure testée unitairement, d'après les formules du composant Board des maquettes ;
+   - une colonne de commandes à gauche dans le cadre : menu en haut, videau au milieu, ↶ en bas, remplacé par ↻ quand le coup de l'ordinateur est montré ;
+   - les sorties restent libres ;
+   - numéros des flèches à 12 px au moins ;
+   - la fin de partie s'affiche dans un panneau centré sur un voile ;
+   - le plein écran s'ouvre sur un geste (pictogramme ou menu), avec `requestFullscreen` puis `screen.orientation.lock` et un repli par rotation CSS. Ce n'est pas le réglage par défaut de l'app installée.
+6. **Vibrations** (`navigator.vibrate`, si disponible) aux quatre moments, avec les motifs d'`interaction.md` : pion posé, pion frappé, double proposé par l'ordinateur, fin de partie. Elles sont activées par défaut, rien au lancer des dés, et elles doublent toujours un signal visible.
+7. **Pictogrammes** du composant Icons, en SVG dans le site (CSP : pas de style en ligne).
+8. **Consigne** : forme longue pendant les trois premières parties, puis forme courte.
+9. **Mouvement** :
+   - durées de 90, 160 et 240 ms, avec la courbe cubic-bezier(0.2, 0, 0, 1) ;
+   - l'ordinateur joue pion par pion : 160 ms par pion, 120 ms de pause ;
+   - `prefers-reduced-motion` est respecté.
+10. **Clavier** (priorité basse) : prévoir dans l'architecture une table d'actions commune au toucher et au clavier. Les touches d'`interaction.md` peuvent venir dans une MR ultérieure.
+
+## Consignes
+
+ADR 0007 : ni le domaine ni le moteur ne changent pour la mise en page. ADR 0008 : scénarios Gherkin pour les comportements visibles nouveaux (nouvelle partie annulable, menu). Aucune nouvelle dépendance. `tests/browser/play.mjs` étendu aux deux orientations, avec des captures Playwright en 412×915, 915×412 et 844×320, en thème clair et sombre, rangées dans un dossier indiqué par la session principale pour la revue design. `make lint`, `make test` et `make test-browser` passent.
+
+## Résultat
+
+À remplir à la clôture.

docs/plans/2026-11-03-revue-ux.md

@@ -1,37 +0,0 @@
-# Revue UX : compte de points, fluidité, paysage
-
-- **Date** : 2026-11-03
-- **Étape** : 0e (retours du premier test de Pierre sur le téléphone)
-- **Statut** : en cours
-- **Exécutant** : sous-agent general-purpose, rôle de designer UI, en lecture
-  seule sur le code
-
-## Objectif
-
-Proposer à Pierre, avec maquettes, une meilleure présentation du compte de
-points et une revue de toute l'expérience de jeu (point 10 de son message du
-2026-11-03), en couvrant la fluidité (ligne 0d.2+ de la feuille de route) et le
-paysage sur téléphone (point 5).
-
-## Consignes
-
-- Partir de la charte (`docs/identite/`, ADR 0010), des ADR 0011 et 0012, et de
-  l'application publiée (https://ustagammon.sans.pub, ou `make site` puis les
-  captures de `make test-browser`).
-- Ne pas modifier le dépôt. Livrer un rapport en Markdown (chemin indiqué par
-  la session principale) et, si utile, une page de maquettes.
-- Pour chaque proposition : le problème observé, la solution, sa maquette, son
-  coût technique estimé, et ce qui relève d'un choix de Pierre.
-- Sujets imposés : compte de points ; bouton « Nouvelle partie » et tout ce qui
-  interrompt la partie ; paysage sur téléphone, plateau sur presque tout
-  l'écran, contrôles en pictogrammes.
-- Les changements de saisie du coup en cours (plan
-  `2026-11-03-saisie-du-coup.md`) sont acquis : ne pas les reproposer.
-
-## Critères de réussite
-
-Un rapport priorisé que Pierre peut valider point par point.
-
-## Résultat
-
-À remplir à la clôture.

web/moteur/benchmark.mjs

@@ -7,7 +7,7 @@
 // Sur les positions de référence (tests/reference/positions.json) : temps du
 // meilleur coup à 0 et 2 plis pour les positions avec dés, temps de la
 // décision de videau à 2 plis pour les autres. Le rapport compare aux seuils
-// de l'étape 0b (docs/etape-0.md).
+// de l'étape 0b (ADR 0009).
 
 // Seuils de l'étape 0b. Un temps respecte son seuil si son maximum, sur
 // toutes les positions, est en dessous (la médiane est donnée en plus).