Plan des parties enregistrées (1b)

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

docs/adr/0012-mode-immersif.md

@@ -77,3 +77,23 @@ paru « vraiment pas optimale ».
 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-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

@@ -24,8 +24,7 @@ Demandes de Pierre du 2026-11-03, traitées avant d'ouvrir l'étape 1.
 | Sous-étape | Contenu | État | Plan |
 | --- | --- | --- | --- |
 | 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 | ⏳ | |
 
@@ -33,7 +32,7 @@ Demandes de Pierre du 2026-11-03, traitées avant d'ouvrir l'étape 1.
 
 | É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/identite/charte/README.md

@@ -14,6 +14,7 @@ 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 |
+| `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/guide-de-marque.md

@@ -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/tokens.json

@@ -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

@@ -128,10 +128,11 @@ Une entrée datée par session : ce qui a été fait, décidé, et la suite.
   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**
-- Le test en mode avion sur le téléphone n'a pas été rapporté ; le hors ligne
-  est vérifié dans Chromium par `make test-browser`.
 - 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-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.

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.