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/0004-outils-de-developpement-dans-docker.md

@@ -52,3 +52,9 @@ construire ou tester ; rien n'est embarqué dans l'application.
 Validés par Pierre avec l'ADR 0009, dans Docker, jamais embarqués :
 TypeScript (`tsc`, Apache-2.0), Biome (MIT ou Apache-2.0),
 `@cucumber/cucumber` (MIT), `dependency-cruiser` (MIT).
+
+### 2026-11-03 — Playwright pour les tests dans le navigateur
+
+Validé par Pierre : Playwright 1.48.2 (Apache-2.0), image
+`mcr.microsoft.com/playwright:v1.48.2-noble`, utilisé seulement par
+`make test-browser` (Chromium et Firefox sans écran). Rien n'est embarqué.

docs/adr/0012-mode-immersif.md

@@ -53,3 +53,47 @@ 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.
+
+### 2026-11-03 — Placement des contrôles en paysage, après la revue UX
+
+La revue UX de l'étape 0e.2 a montré deux conflits dans le placement décrit
+par l'amendement précédent : la moitié basse de la colonne des sorties est une
+cible de jeu (toucher fait sortir un pion), et les pions frappés s'empilent
+depuis le milieu de la barre. Arbitrage de la session design, sur délégation
+de Pierre :
+
+- une colonne de commandes à gauche, dans le cadre : menu en haut, videau au
+  milieu (il monte ou descend selon son propriétaire), « Annuler le
+  demi-coup » en bas, remplacé par « Revoir » quand le coup de l'ordinateur
+  est montré ; « Quitter le plein écran » passe dans le menu ;
+- la colonne des sorties reste réservée aux pions sortis ;
+- les comptes de points sont des pastilles aux deux bouts de la barre, aux
+  couleurs du camp, en 13 px.
+
+Maquettes : rangée « Révision UX (étape 0e) : paysage » du canevas
+(variantes thème sombre, barre d'adresse visible et fin de partie). Règles de
+comportement : `docs/identite/charte/interaction.md`.

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,34 +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 ») | 🔄 | |
-| 0d.2+ | Fluidité de la partie : supprimer ce qui interrompt le jeu sans nécessité (bouton « Nouvelle partie » toujours visible, confirmations, étapes inutiles) : demande de 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.
+| 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.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 | ⏳ | |
 
 ## É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/identite/charte/README.md

@@ -14,6 +14,8 @@ Décisions : ADR 0010. Fichiers du logo et des icônes : `../logo/`.
 | Fichier | Contenu |
 | --- | --- |
 | `guide-de-marque.md` | Règles d'usage : ton, couleurs, typographie, formes, mouvement, icônes, composants |
+| `recette-ux.md` | Critères de recette design de l'écran de jeu, à cocher sur les captures et sur le téléphone |
+| `interaction.md` | Comportement : réponse immédiate, annuler plutôt que confirmer, mouvement, vibrations, clavier, mises en page de l'écran de jeu (portrait, paysage, ordinateur), pictogrammes |
 | `tokens.json` | Toutes les valeurs, thèmes clair et sombre, avec une note d'usage par couleur |
 | `bundle.css` | Styles des composants ; mêmes noms de classes que `web/app.css` |
 | `board.js` | Dessin de référence du plateau (repère 640 × 520), pour comparaison |

docs/identite/charte/board.js

@@ -34,7 +34,7 @@ window.UstaBoard = (function () {
     o += '<rect class="board-tray" x="' + TRAY_X + '" y="' + TB + '" width="' + TRAY_W + '" height="' + (H / 2 - TB - 4) + '" rx="4"/>';
     o += '<rect class="board-tray" x="' + TRAY_X + '" y="' + (H / 2 + 4) + '" width="' + TRAY_W + '" height="' + (H / 2 - TB - 4) + '" rx="4"/>';
     for (var point = 1; point <= 24; point++) {
-      var pl = place(point), x = colX(pl.col), cls = (pl.col % 2 === 0) === pl.top ? "point-a" : "point-b";
+      var pl = place(point), x = colX(pl.col), cls = point % 2 === 1 ? "point-a" : "point-b"; // impairs en noyer, pairs en chêne
       var base = pl.top ? TB : H - TB, apex = pl.top ? TB + PH : H - TB - PH;
       o += '<polygon class="' + cls + '" points="' + x + ',' + base + ' ' + (x + PW) + ',' + base + ' ' + (x + PW / 2) + ',' + apex + '"/>';
       if ((state.targets || []).indexOf(point) >= 0)

docs/identite/charte/guide-de-marque.md

@@ -22,7 +22,7 @@ La palette, c'est le bois, les pions et le café, avec **un seul accent : le rou
 - `accent-soft` : fond léger pour signaler « c'est à vous », avec du texte `text` dessus.
 - Les appréciations de coups ont leurs propres couleurs, distinctes de la brique : `verdict-good` (vert), `verdict-doubtful` (ocre), `verdict-bad` (lie-de-vin). **Toujours avec le mot et l'icône**, jamais la couleur seule.
 - `brand-laiton` (via `last-move`) marque le dernier coup joué, comme les charnières en laiton d'un plateau de tavla. Rien d'autre.
-- Le plateau : cadre `frame` en noyer, fond `bed`, flèches alternées `point-a` (noyer clair) et `point-b` (chêne), barre `bar`, sorties `tray`. Le joueur a les pions ivoire (`checker-player`, l'apprenti), l'ordinateur les pions noyer (`checker-computer`, le maître), comme dans le logo.
+- Le plateau : cadre `frame` en noyer, fond `bed`, flèches impaires en `point-a` (noyer clair) et paires en `point-b` (chêne), barre `bar`, sorties `tray`. Le joueur a les pions ivoire (`checker-player`, l'apprenti), l'ordinateur les pions noyer (`checker-computer`, le maître), comme dans le logo.
 - **À éviter** : le vert feutre de casino, le noir et or, les dégradés, les néons.
 
 Les deux thèmes, clair et sombre, sont complets. Tous les textes atteignent 4,5:1 sur leurs fonds dans les deux thèmes ; les contours et marques porteuses de sens, 3:1.
@@ -56,6 +56,10 @@ Sobre et utile : un pion glisse vers sa flèche (150 à 250 ms, sans rebond), le
 - Icônes d'interface : traits simples de 2px à bouts ronds, dessinés en SVG dans le code (pas de police d'icônes, pas d'émoji). Les seules icônes du système pour l'instant : les trois appréciations de coups (coche, point d'interrogation, croix) et la copie (deux feuillets).
 - Dés, pions et videau sont dessinés en SVG avec les couleurs du plateau, jamais en images.
 
+## Interaction
+
+Règles de comportement (réponse immédiate, annuler plutôt que confirmer, mouvement, vibrations, clavier, mises en page de l’écran de jeu) : section « Interaction ».
+
 ## Composants
 
-Plateau (`Board`) et ses pièces (`Checker`, `Die`, `DoublingCube`), boutons (`Button`), barre haute (`TopBar`), zone de consigne (`GamePrompt`), appréciation d'un coup (`MoveVerdict`), fiche de glossaire (`GlossaryCard`), carte de leçon (`LessonCard`) et « Demander à une IA » (`AskAI`). Chacun a sa fiche avec ses règles d'usage et un aperçu dans les deux thèmes.
+Plateau (`Board`) et ses pièces (`Checker`, `Die`, `DoublingCube`), boutons (`Button`), barre haute (`TopBar`), zone de consigne (`GamePrompt`), appréciation d’un coup (`MoveVerdict`), pictogrammes (`Icons`), fiche de glossaire (`GlossaryCard`), carte de leçon (`LessonCard`) et « Demander à une IA » (`AskAI`). Chacun a sa fiche avec ses règles d'usage et un aperçu dans les deux thèmes.

docs/identite/charte/interaction.md

@@ -0,0 +1,72 @@
+# Interaction
+
+Ustagammon doit se sentir **net et rapide**, comme un outil bien réglé : chaque toucher répond tout de suite, rien ne saute, rien n'interrompt la partie sans raison. La chaleur vient de la matière et du ton ; la précision vient du comportement.
+
+## Principes
+
+1. **Réponse immédiate.** Un toucher produit un effet visible en moins de 100 ms : le pion part, le bouton s'enfonce. Le moteur calcule ensuite, en arrière-plan ; l'interface ne l'attend jamais pour réagir.
+2. **Rien ne bouge sous le doigt.** Les zones de l'écran de jeu ont une hauteur fixe : seuls leurs contenus changent. Une ligne vide garde sa place.
+3. **Annuler plutôt que confirmer.** Une action se fait tout de suite et se rattrape pendant 10 s par un bandeau « Reprendre » (nouvelle partie, abandon). Une boîte de confirmation n'est permise que pour une décision de jeu irréversible qui engage la partie : prendre ou passer un double, doubler.
+4. **Une seule action principale par moment**, en brique, à droite, sous le pouce.
+5. **Le joueur garde la main.** L'app ne joue jamais à sa place : quand aucun coup n'est possible, les dés se barrent et le joueur passe en les touchant (demande explicite de Pierre).
+6. **Le maître parle après le coup, discrètement** (ADR 0011) : une ligne réservée sous le plateau, qui s'ouvre sur l'explication si on la touche. Jamais de fenêtre qui s'impose.
+7. **Le sens passe toujours par deux canaux** : couleur et mot, vibration et marque visible, raccourci et bouton.
+
+## Mouvement
+
+| Jeton | Valeur | Usage |
+| --- | --- | --- |
+| `duration-instant` | 90ms | Retour d'appui d'un bouton, apparition du contour d'un pion jouable. |
+| `duration-fast` | 160ms | Pion qui glisse d'une flèche à l'autre, dés qui se posent, bandeaux. |
+| `duration-moderate` | 240ms | Feuille du menu qui monte, panneau de fin de partie, bascule de mise en page. |
+| `easing-standard` | cubic-bezier(0.2, 0, 0, 1) | Tout ce qui se déplace : départ franc, arrivée douce. |
+| `easing-exit` | cubic-bezier(0.4, 0, 1, 1) | Ce qui disparaît. |
+
+- Pas de rebond, pas d'élastique, pas de fondu de plus de 240 ms.
+- Les coups de l'ordinateur se jouent demi-coup par demi-coup, 160 ms par pion, 120 ms de pause entre deux : on suit le coup sans l'attendre.
+- Le bouton enfoncé descend de 1 px et s'assombrit de 6 %, sans ombre.
+- `prefers-reduced-motion` : les déplacements deviennent des apparitions instantanées ; les dés ne roulent pas.
+
+## Vibrations
+
+Activées par défaut, désactivables dans le menu (« Vibrations »). Elles doublent un événement visible, jamais seules. Rien ne vibre pour un toucher de bouton ni pour le lancer des dés.
+
+| Moment | Motif (ms) |
+| --- | --- |
+| Votre pion se pose | `12` |
+| Un pion est frappé | `25, 40, 25` |
+| L'ordinateur propose de doubler | `40, 60, 40` |
+| Fin de partie gagnée | `30, 50, 30, 50, 60` |
+| Fin de partie perdue | `60` |
+
+Les durées se règlent en main sur le Fairphone 4. Une seule vibration à la fois : la dernière annule la précédente.
+
+## Clavier (ordinateur)
+
+Chaque action a son raccourci, affiché sur le bouton en petite touche (`kbd`) quand un clavier est détecté. `?` ouvre la liste.
+
+| Touche | Action |
+| --- | --- |
+| `Espace` | Lancer les dés ; jouer le coup quand il est complet ; passer quand aucun coup n'est possible |
+| `←` `→` | Choisir un pion jouable (le focus se voit : anneau `focus`) |
+| `↑` `↓` | Choisir sa case d'arrivée |
+| `Entrée` | Poser le pion |
+| `Z` | Annuler le demi-coup (aussi `Ctrl+Z`) |
+| `D` | Doubler |
+| `P` / `N` | Prendre / passer, quand l'ordinateur double |
+| `F` | Plein écran |
+| `M` | Menu |
+| `?` | Aide et raccourcis |
+| `Échap` | Fermer le menu, l'aide ou la bulle ouverte ; ne touche jamais à la partie |
+
+Le plateau entier se joue au clavier : c'est aussi ce qui le rend accessible aux lecteurs d'écran.
+
+## Pictogrammes
+
+Trait de 2 px à bouts ronds, sur une grille de 20 × 20, `currentColor`, dessinés en SVG dans le code. Le jeu complet : menu, aide, plein écran, quitter le plein écran, annuler (flèche de retour), revoir (flèche circulaire), fermer, chevron, copier, et les trois appréciations (coche, point d'interrogation, croix dans un cercle). En portrait, la barre haute affiche un libellé de 13 px sous chaque pictogramme ; en paysage et sur ordinateur, le pictogramme seul avec son `aria-label`.
+
+## Mises en page de l'écran de jeu
+
+- **Portrait** : barre haute, bandeau de l'ordinateur, plateau, bandeau du joueur (teinté `accent-soft` quand c'est à lui), ligne du maître ou du dernier coup, consigne, et barre d'actions collée en bas. Hauteurs fixes.
+- **Paysage** (dès que le téléphone est tourné ; ADR 0012) : le plateau est l'écran. Colonne de commandes à gauche dans le cadre (menu, videau, annuler ou revoir), sorties à droite, comptes de points en pastilles aux deux bouts de la barre, consigne et dés dans la bande centrale. Numéros des flèches à 12 px au moins.
+- **Ordinateur** : plateau à gauche, colonne à droite avec les bandeaux des joueurs, la liste des coups, la consigne, les actions et leurs raccourcis.

docs/identite/charte/recette-ux.md

@@ -0,0 +1,45 @@
+# Recette design de l'écran de jeu
+
+Critères vérifiables sur les captures de `make test-browser` (412×915,
+915×412, 844×320, thèmes clair et sombre) et à la main sur le Fairphone 4.
+Chaque ligne se coche ou se refuse ; une ligne refusée dit pourquoi.
+Référence : `interaction.md`, maquettes « Révision UX » du canevas.
+
+## Toutes tailles
+
+- [ ] Flèches impaires en `point-a`, paires en `point-b` ; 12 et 13 de couleurs différentes.
+- [ ] Une seule action principale (brique) visible à la fois.
+- [ ] Aucun `window.confirm` ni `alert` dans le code de l'app (`grep -rn "confirm(\|alert(" app/src` vide).
+- [ ] Aucune cible tactile sous 44 × 44 px (boutons, pictogrammes, dés, videau).
+- [ ] Textes à lire : 13 px au moins ; numéros des flèches : 12 px au moins.
+- [ ] Thème sombre : aucune couleur codée en dur hors `tokens` ; le cadre se distingue du fond.
+- [ ] Anneau de focus `focus` visible au clavier sur chaque élément interactif.
+- [ ] `overscroll-behavior: none` : tirer vers le bas ne recharge pas la page.
+
+## Portrait (412 × 915)
+
+- [ ] Ordre de haut en bas : barre haute, bandeau ordinateur, plateau, bandeau joueur, ligne du maître ou du dernier coup, consigne, barre d'actions collée en bas.
+- [ ] Stabilité : sur une partie complète, la position verticale du plateau et de la barre d'actions ne varie pas d'un pixel (comparer les boîtes entre deux captures successives).
+- [ ] Barre haute : pictogrammes avec libellé de 13 px (Aide, Plein écran, Menu) ; pas de bouton « Nouvelle partie ».
+- [ ] Comptes de points en 20 px gras, chiffres alignés ; le bandeau du joueur qui a la main est teinté `accent-soft` ; l'écart s'écrit « mène de N ».
+- [ ] Plus de durée de calcul « (0,5 s) » dans les messages.
+- [ ] Aucun coup possible : dés barrés et message ; le tour ne passe qu'au toucher des dés.
+- [ ] Conseil du maître : une ligne, après le coup du joueur seulement ; toucher l'ouvre.
+
+## Paysage (915 × 412 et 844 × 320)
+
+- [ ] Le cadre noyer touche les quatre bords ; aucune marge de page, aucune colonne de texte.
+- [ ] Flèches d'au moins 44 px de large ; pions d'au moins 22 px de diamètre à 844 × 320.
+- [ ] Colonne de commandes à gauche : menu en haut, videau au milieu, annuler (ou revoir) en bas ; colonne des sorties libre.
+- [ ] Comptes en pastilles aux deux bouts de la barre, 13 px, couleur du camp ; ils ne chevauchent pas les pions sur la barre.
+- [ ] Consigne et dés dans la bande centrale, sans chevaucher un pion.
+- [ ] Rotation portrait ↔ paysage en cours de partie : la position, la sélection et les dés sont conservés.
+- [ ] Fin de partie : panneau centré sur un voile, « Revoir la partie » et « Nouvelle partie ».
+
+## Comportement
+
+- [ ] Un toucher sur un pion produit un effet visible en moins de 100 ms (trace de performance de Playwright).
+- [ ] Déplacements à 160 ms en `easing-standard`, sans rebond ; coups de l'ordinateur pion par pion ; tout est instantané avec `prefers-reduced-motion`.
+- [ ] « Nouvelle partie » depuis le menu : effet immédiat, bandeau « Reprendre l'ancienne » 10 s, et la reprise restaure la partie exacte.
+- [ ] Vibrations aux quatre moments, coupées par l'interrupteur du menu (test unitaire sur `haptic()` ; ressenti à la main).
+- [ ] Écran maintenu allumé pendant une partie, interrupteur dans le menu.

docs/identite/charte/tokens.json

@@ -195,7 +195,7 @@
      "light": "#6B4430",
      "dark": "#3A2519"
     },
-    "usage": "Flèches sombres (noyer clair), une sur deux."
+    "usage": "Flèches impaires (1, 3, 5…), noyer clair."
    },
    {
     "name": "point-b",
@@ -203,7 +203,7 @@
      "light": "#C9AE88",
      "dark": "#7E6142"
     },
-    "usage": "Flèches claires (chêne), une sur deux."
+    "usage": "Flèches paires (2, 4, 6…), chêne."
    },
    {
     "name": "point-number",
@@ -526,5 +526,38 @@
  },
  "meta": {
   "source": "Brief créatif + ADR 0010 + web/app.css (noms des variables du plateau)"
+ },
+ "duration": {
+  "tokens": [
+   {
+    "name": "duration-instant",
+    "value": "90ms",
+    "usage": "Retour d'appui d'un bouton, contour d'un pion jouable."
+   },
+   {
+    "name": "duration-fast",
+    "value": "160ms",
+    "usage": "Pion qui glisse, dés qui se posent, bandeaux."
+   },
+   {
+    "name": "duration-moderate",
+    "value": "240ms",
+    "usage": "Feuille du menu, panneau de fin de partie, bascule de mise en page. Jamais plus long."
+   }
+  ]
+ },
+ "easing": {
+  "tokens": [
+   {
+    "name": "easing-standard",
+    "value": "cubic-bezier(0.2, 0, 0, 1)",
+    "usage": "Tout ce qui se déplace : départ franc, arrivée douce."
+   },
+   {
+    "name": "easing-exit",
+    "value": "cubic-bezier(0.4, 0, 1, 1)",
+    "usage": "Ce qui disparaît."
+   }
+  ]
  }
 }

docs/journal.md

@@ -110,3 +110,56 @@ 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.
+
+## 2026-11-03 (jour) : coordination design et développement
+
+**Fait**
+- Leçons numérotées, conseil du maître après le coup et bilan de fin de partie
+  retenus par Pierre (ADR 0011) ; mode immersif en paysage (ADR 0012), puis
+  vue paysage dès la rotation, avec le plateau qui occupe tout l'écran.
+- Revue UX du designer de la session de développement (étape 0e.2), arbitrée
+  par la session design sur délégation de Pierre : portrait à zones fixes,
+  compte de points en bandeaux (pastilles en paysage), menu en feuille,
+  « annuler plutôt que confirmer », pas de passage automatique du tour,
+  vibrations, pictogrammes, clavier sur ordinateur. Règles dans
+  `docs/identite/charte/interaction.md` (MR !23), second amendement de
+  l'ADR 0012 (placement des contrôles en paysage).
+- Maquettes des variantes sur le canevas (paysage clair, sombre, avec barre
+  d'adresse, fin de partie ; portrait révisé, conseil, nouvelle partie
+  annulable ; menu ; ordinateur avec raccourcis).
+- Couleur des flèches corrigée dans la charte (impaires en noyer clair, paires
+  en chêne ; MR !25). La correction dans l'app est faite par la session de
+  développement, dans la MR de saisie du coup.
+
+**Reste à faire**
+- Implémentation par la session de développement (plan
+  `docs/plans/2026-11-03-revision-ux.md`), puis revue design sur ses captures
+  Playwright (412×915, 915×412, 844×320, clair et sombre) avant l'essai de
+  Pierre sur le téléphone.
+- Réglage en main des vibrations sur le Fairphone 4.

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-parties-enregistrees.md

@@ -0,0 +1,57 @@
+# Parties enregistrées, branches et export SGF (1b)
+
+- **Date** : 2026-11-03
+- **Étape** : 1b (`docs/etape-1.md`)
+- **Statut** : prévu (lancé après la fusion de 0e.1)
+- **Exécutant** : sous-agent general-purpose, dans un worktree
+
+## Objectif
+
+Garder toutes les parties du joueur sur le téléphone, avec leurs branches, et
+les exporter au format SGF de GNU Backgammon.
+
+## Consignes
+
+ADR 0007 (domaine pur, stockage derrière une interface), ADR 0008 (scénarios
+et glossaire). Aucune nouvelle dépendance : l'API IndexedDB du navigateur
+directement.
+
+1. **Stockage IndexedDB** derrière l'interface de `app/src/storage/` : une
+   liste de parties (identifiant, date de début et de dernière action,
+   adversaire et niveau, score, état en cours ou finie, résultat) et le
+   journal d'événements de chacune. Migration transparente de la partie
+   en cours enregistrée aujourd'hui dans `localStorage`. Si IndexedDB est
+   indisponible (navigation privée), repli sur le comportement actuel.
+2. **Branches** : le journal est déjà un arbre (événements avec parent,
+   `goBackTo`). Exposer dans le domaine la liste des branches d'une partie
+   (feuilles de l'arbre, avec le coup d'origine) et le passage de l'une à
+   l'autre. « Rejouer d'ici » depuis un coup passé crée une branche ; la
+   branche d'origine reste intacte et rechargeable. Pas d'écran d'analyse ici
+   (1e) : un accès minimal suffit pour le test (menu « Mes parties » :
+   reprendre une partie, voir ses branches).
+3. **Nouvelle partie annulable** : l'arbitrage UX (plan
+   `2026-11-03-revision-ux.md`, point 3) prévoit « Reprendre l'ancienne »
+   pendant 10 s. Fournir l'API de stockage qui le permet (reprendre une partie
+   par son identifiant) ; l'interface viendra avec la révision UX.
+4. **Export SGF** : une partie (et ses branches en variantes) au format SGF
+   de GNU Backgammon, téléchargeable depuis « Mes parties ». Vérification par
+   le gnubg de bureau de référence (Docker existant) : le fichier exporté se
+   charge sans erreur et ses positions successives sont les mêmes que celles
+   du journal, sur des parties générées par les tests.
+5. Scénarios Gherkin : reprendre une partie parmi plusieurs, rejouer d'ici
+   sans perdre l'original, exporter une partie. Fiches du glossaire pour les
+   nouveaux termes (branche, SGF…).
+
+`make lint`, `make test` et `make test-browser` passent (ajouter au test
+navigateur : deux parties enregistrées, reprise de la première après
+rechargement). Commits fréquents ; pas de push ni de MR.
+
+## Critères de réussite
+
+- Après rechargement, la liste des parties et chaque branche sont intactes.
+- Un SGF exporté se charge dans gnubg de bureau avec les mêmes positions.
+- Les trois commandes de 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.

engine-wasm/benchmark.mjs

@@ -9,7 +9,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).