Fusion de la MR !27 : recette design

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

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 |
+| `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` |

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.

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",

docs/journal.md

@@ -136,3 +136,30 @@ Une entrée datée par session : ce qui a été fait, décidé, et la suite.
 
 **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-parties-enregistrees.md

@@ -1,57 +0,0 @@
-# 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.