Plan des parties enregistrées (1b)

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

docs/identite/charte/README.md

@@ -14,7 +14,6 @@ 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 = point % 2 === 1 ? "point-a" : "point-b"; // impairs en noyer, pairs en chêne
+      var pl = place(point), x = colX(pl.col), cls = (pl.col % 2 === 0) === pl.top ? "point-a" : "point-b";
       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 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.
+- 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.
 - **À é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

@@ -1,45 +0,0 @@
-# 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 impaires (1, 3, 5…), noyer clair."
+    "usage": "Flèches sombres (noyer clair), une sur deux."
    },
    {
     "name": "point-b",
@@ -203,7 +203,7 @@
      "light": "#C9AE88",
      "dark": "#7E6142"
     },
-    "usage": "Flèches paires (2, 4, 6…), chêne."
+    "usage": "Flèches claires (chêne), une sur deux."
    },
    {
     "name": "point-number",

docs/journal.md

@@ -136,30 +136,3 @@ 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

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