pierre/Ustagammon
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Activity

Fusion de main dans moteur-analyse ; plan 1a clos

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Pierre MARTIN
2026-11-03 15:06:09 +01:00
co-authored by Claude Opus 5.5
parent fa558667f7 cbef27ae9c
commit 091cb4a8b0
44 changed files with 1264 additions and 740 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/adr/0009-socle-pwa-typescript.md
+21
View File
@@ -68,3 +68,24 @@ vérification des dépendances.
standard ») est tenu même au niveau fort (2 plis) : c'est le niveau standard
de l'ordinateur à l'étape 0d.
- Firefox sur le téléphone reste à vérifier, sans bloquer.
## Amendements
### 2026-11-03 — Pages de test du moteur retirées du site
Décidé par Pierre après son premier test sur le téléphone : « supprimer la
partie test du moteur totalement ».
- Les pages de test et de mesure de l'étape 0b (`web/moteur/` : `index.html`,
`bench.html` et leurs scripts) sont supprimées. Le site publié n'a plus rien
sous `/moteur/`, ni dans le cache du service worker ; `make deploy`
n'annonce plus que l'application, et l'aide ne renvoie plus vers le test du
moteur.
- Les mesures du Fairphone 4 ci-dessus, faites avec `bench.html`, restent la
référence. Pour les refaire, la mesure se lance sous Node sur le PC
(`make bench`) : son code partagé est déplacé de `web/moteur/benchmark.mjs`
vers `engine-wasm/benchmark.mjs`. Une mesure sur le téléphone demanderait de
remettre une page de mesure, à décider le moment venu.
- Le moteur reste vérifié par la suite de contrat sur WebAssembly
(`make test`) et, dans l'application, par la partie jouée dans un navigateur
(`make test-browser`).
docs/adr/0013-position-dans-l-adresse.md
+49
View File
@@ -0,0 +1,49 @@
# 0013. Une position du plateau dans l'adresse de la page
- **Statut** : accepté
- **Date** : 2026-11-03
- **Décideurs** : Pierre (besoin), Claude Code (format)
## Contexte
Pierre a demandé, au premier test sur le téléphone (2026-11-03), qu'avec la
seule adresse on arrive à une position du plateau : chaque position devient un
lien direct, à partager, à mettre dans une leçon ou dans un prompt pour une IA.
GNU Backgammon décrit déjà toute position par deux identifiants publics et
documentés : le Position ID (14 caractères, les pions) et le Match ID
(12 caractères : videau, score, longueur du match, joueur au trait, dés). Le
moteur sait les lire et les écrire (`engine.h`).
## Décision
- L'adresse porte la position dans le fragment (après `#`) :
`https://ustagammon.sans.pub/#position=<Position ID>&match=<Match ID>`,
chaque identifiant encodé avec `encodeURIComponent` (le base64 de gnubg
contient `+` et `/`). `match` est facultatif : sans lui, partie libre, videau
au centre, joueur du bas au trait, sans dés.
- Ouvrir un tel lien affiche la position, non jouable, avec deux actions :
« Jouer à partir d'ici » (nouvelle partie contre l'ordinateur depuis cette
position, sans toucher à la partie en cours) et « Retour à ma partie ».
- Toute position affichée (partie, coup de l'ordinateur, analyse, leçon) peut
être copiée en lien (« Copier le lien de la position »).
- Un identifiant illisible pour le moteur donne un message clair et le retour
à la partie, jamais une page cassée.
## Alternatives écartées
- **Paramètres de requête (`?position=`)** : ils changent l'adresse demandée
au serveur et au service worker ; hors ligne, la page en cache ne
correspondrait plus. Le fragment ne quitte jamais le navigateur.
- **XGID (format d'eXtreme Gammon)** : répandu, mais un seul identifiant de
plus à décoder ; gnubg l'importe, son import pourra s'ajouter plus tard
(outil « import d'un identifiant GNU ou XGID » du cadrage).
- **Format maison plus lisible** : il faudrait le décoder sans le moteur, donc
réimplémenter une règle de représentation (ADR 0007).
## Conséquences
- Le fragment est lu au chargement et à chaque changement (`hashchange`) ; le
domaine reçoit une position et un Match ID, le moteur les valide.
- Les liens restent valables tant que GNU Backgammon garde ces formats, stables
depuis des années.
- Les liens contiennent la position, rien d'autre : pas de donnée personnelle.
docs/adr/README.md
+1
View File
@@ -19,3 +19,4 @@ l'ancien passe au statut « remplacé par NNNN ». Voir l'ADR 0001.
| [0010](0010-identite-visuelle.md) | Identité visuelle : symbole, logotype, palette | accepté |
| [0011](0011-lecons-conseil-et-bilan.md) | Leçons numérotées, conseil du maître après le coup, bilan de fin de partie | accepté |
| [0012](0012-mode-immersif.md) | Mode immersif : le plateau en paysage, sur demande | accepté |
| [0013](0013-position-dans-l-adresse.md) | Une position du plateau dans l'adresse de la page | accepté |
docs/deploiement.md
+3 -4
View File
@@ -2,8 +2,8 @@
Ustagammon est un site statique (PWA, ADR 0009) : des fichiers HTML,
JavaScript, le moteur en WebAssembly et ses données. L'application est à la
racine ; les pages de test du moteur de l'étape 0b restent publiées sous
`/moteur/` (test du moteur) et `/moteur/bench.html` (mesure). Il est publié sur
racine ; les pages de test du moteur de l'étape 0b ont été retirées (ADR
0009, amendement du 2026-11-03). Il est publié sur
CapRover, machine `sans-pub` (https://captain.cloud.sans.pub), app
`ustagammon`, sur https://ustagammon.sans.pub.
@@ -112,8 +112,7 @@ ssh sans.pub 'sudo docker service ps srv-captain--ustagammon --format "{{.Image}
```
Puis ouvrir le site sur le téléphone : le plateau s'affiche et une consigne
remplace « Chargement du moteur… ». La page de test du moteur
(https://ustagammon.sans.pub/moteur/) doit afficher « Moteur prêt ».
remplace « Chargement du moteur… ».
## Retour arrière
docs/etape-1.md
+4 -3
View File
@@ -17,7 +17,7 @@ Repris du cadrage (modules, écrans clés, IA générative en V1) et des ADR 001
| 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 | — |
| 1a. Moteur pour l'analyse (fait) | 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 |
@@ -43,8 +43,9 @@ Repris du cadrage (modules, écrans clés, IA générative en V1) et des ADR 001
- **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.
- **Seuils des appréciations** : ceux de GNU Backgammon (douteux 0,03,
mauvais 0,06, très mauvais 0,12 d'équité, `arSkillLevel`), exposés par le
moteur depuis 1a ; à calibrer sur de vraies parties.
- **Relecture des leçons** par un joueur fort de l'Atelier du Huit.
## Ordre de réalisation
docs/feuille-de-route.md
+2 -3
View File
@@ -23,10 +23,9 @@ 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.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 | ⏳ | |
| 0e.4 | Position dans l'adresse : chaque position du plateau a un lien direct (ADR 0013) | ⏳ | `plans/2026-11-03-position-dans-l-adresse.md` |
| 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 | ⏳ | `plans/2026-11-03-accueil-tutoriel-aide.md` |
## Étapes suivantes
docs/identite/charte/README.md
+2
View File
@@ -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 |
| `accueil-tutoriel-aide.md` | Accueil, installation sans intrusion, tutoriel des règles (forme et première version du texte), aide en questions |
| `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/accueil-tutoriel-aide.md
+153
View File
@@ -0,0 +1,153 @@
# Accueil, installation, tutoriel et aide
Règles de l'étape 0e.5 (et 1g pour le tutoriel). Maquettes : rangée « Étape
0e.5 » du canevas https://claude.ai/artifact/CQw6vbDpi6XQqVWQa4sANe et
l'artboard « Accueil ». Les textes sont une **première version, à valider par
Pierre**. Comportement général : `interaction.md`.
## Accueil
**Premier lancement** (aucune partie ni leçon enregistrée) : le logo, le
plateau en position de départ, « Bienvenue à la table », une phrase, puis deux
grands choix :
- **« Je découvre »** (action principale) → le tutoriel, étape 1 ;
- **« Je connais les règles »** → une partie tout de suite.
Le choix ne revient plus. Le tutoriel reste dans le menu.
**Ensuite**, de haut en bas :
1. **La partie en cours** : miniature du plateau, comptes de points,
« Reprendre la partie » (seule action principale de l'écran) et
« Nouvelle partie ». Sans partie en cours : « Nouvelle partie » devient
l'action principale.
2. **L'invitation à installer**, si elle doit apparaître (voir plus bas).
3. **La prochaine leçon** : une seule carte (titre, état, progression,
« Continuer » en secondaire), avec le lien « Toutes les leçons ».
4. **La progression résumée**, en une ligne `caption` : « 1 leçon terminée
sur 8 · 12 parties jouées · 4 gagnées ».
5. En pied de page, la phrase de l'Atelier du Huit.
Pas de chiffres d'erreur ou d'équité sur l'accueil : ils viennent avec
l'analyse.
## Installation
Le but : proposer l'installation au bon moment, une fois, sans jamais
interrompre.
- **Jamais** au premier lancement, jamais pendant une partie, jamais en
fenêtre qui s'impose.
- **Quand** : à partir de la fin de la **première partie terminée**, quand le
joueur a vu ce que vaut l'app.
- **Où** : une carte compacte sur l'accueil (symbole, « Installer
Ustagammon », « Sur l'écran d'accueil, en plein écran, sans réseau. »,
bouton « Installer » et croix « Plus tard »), et une ligne « Installer
l'application » dans le menu, toujours présente tant que l'app n'est pas
installée.
- **« Plus tard »** masque la carte ; elle revient une seule fois, après
trois parties de plus. Ensuite, seul le menu la propose.
- **Chrome Android** : le bouton déclenche l'invite du système, gardée depuis
l'événement `beforeinstallprompt`. Sans cet événement (navigateur qui ne
propose pas l'installation), le même bouton ouvre la marche à suivre.
- **Firefox Android** : une feuille en trois étapes numérotées (menu ⋮,
« Installer » ou « Ajouter à l'écran d'accueil », confirmer), qui se ferme
par « J'ai compris ».
- **iPhone (Safari)** : même feuille, avec ces étapes : bouton de partage,
« Sur l'écran d'accueil », « Ajouter ».
- **Une fois installée** (`display-mode: standalone`, ou événement
`appinstalled`) : plus aucune proposition, la ligne du menu disparaît.
## Tutoriel des règles
### Forme
- Huit étapes, chacune en **écrans courts** : un titre, un plateau illustré,
deux ou trois phrases. Une étape sur deux finit par un écran **« à vous »**
où le joueur fait le geste sur le vrai plateau, contrôlé par le moteur.
- En haut : une barre de progression en huit segments (`accent` pour les
étapes faites) et « Passer » à droite. En bas : « Retour » et
« Continuer ».
- Les positions sont données par leurs identifiants gnubg (ADR 0013) ; le
plateau est le composant de l'app, non jouable sauf sur les écrans
« à vous ». Aucune règle n'est codée hors du moteur : un écran « à vous »
demande au moteur si le coup du joueur fait partie des coups permis attendus.
- **Les pions bougent** : sur un écran d'explication, le coup illustré se joue
tout seul après une seconde, pion par pion (`duration-fast`), puis reste
affiché ; « Revoir » le rejoue. Sur les écrans à flèches (sens du jeu), un
tracé en pointillés `text` sur un liseré ivoire, jamais en brique (la brique
veut dire « à faire »).
- Un geste juste : coche `verdict-good`, vibration « pion posé », phrase
courte, « Continuer » devient l'action principale. Un geste faux : le pion
revient, et une phrase dit pourquoi, sans le mot « erreur ».
- Chaque terme nouveau est un lien vers sa fiche du glossaire, à sa première
apparition.
### Texte, première version
1. **Le but du jeu.** « Vous avez quinze pions ivoire, l'ordinateur quinze
pions noyer. Chacun fait faire le tour du plateau à ses pions, puis les
sort. Le premier qui a sorti tous les siens gagne la partie. »
2. **Dans quel sens avancer.** « Vos pions ivoire font le tour du plateau dans
le sens des pointillés : ils partent d'en haut à droite, passent à gauche,
puis reviennent en bas jusqu'aux six dernières flèches, en bas à droite.
C'est là que vous les rassemblerez avant de les sortir. Les pions noyer de
l'ordinateur font le même chemin, en sens inverse. »
3. **Les dés et les doubles.** « Chaque dé déplace un pion d'autant de
flèches. Avec 5 et 2, vous jouez un pion de 5 et un pion de 2, ou le même
pion de 5 puis de 2. Un double se joue quatre fois : avec 4-4, vous avancez
quatre fois de 4. » *À vous* : jouer 3-1 en faisant le point 5 (8/5 6/5).
4. **Frapper un pion seul.** « Un pion seul sur une flèche s'appelle un blot.
Si vous vous posez dessus, vous le frappez : il part sur la barre et devra
refaire tout le chemin. Une flèche où l'adversaire a deux pions ou plus est
fermée : vous ne pouvez pas vous y poser. » *À vous* : frapper le blot du
point 7 avec 6-1.
5. **Rentrer depuis la barre.** « Votre pion frappé attend sur la barre, au
milieu. Avant de jouer quoi que ce soit d'autre, il doit rentrer dans le
camp adverse, en haut à droite. Chaque dé indique une flèche d'entrée :
avec 3 et 4, la 22 ou la 21. Si les deux flèches sont fermées, votre tour
passe. »
6. **Sortir ses pions.** « Quand vos quinze pions sont dans les six dernières
flèches, vous pouvez commencer à les sortir : un 6 sort un pion de la
flèche 6, un 1 un pion de la flèche 1. Touchez le pion, puis la sortie à
droite. » *À vous* : sortir deux pions avec 6-3.
7. **Gammon et backgammon.** « Une partie gagnée vaut 1 point. Si
l'adversaire n'a sorti aucun pion quand vous finissez, c'est un gammon :
2 points. S'il lui reste en plus un pion sur la barre ou dans votre camp,
c'est un backgammon : 3 points. »
8. **Le videau.** « Le cube aux faces 2, 4, 8, 16, 32 et 64 sert à miser.
Avant de lancer vos dés, vous pouvez proposer de doubler la valeur de la
partie. L'ordinateur prend, et la partie continue en valant le double, ou il
passe, et vous gagnez tout de suite. Celui qui a pris garde le cube : lui
seul pourra redoubler. » *À vous* : décider de prendre ou passer, avec une
phrase du maître ensuite.
Fin du tutoriel : « Vous connaissez les règles. Le reste s'apprend en jouant,
et le maître vous accompagne. » → « Jouer ma première partie ».
## Aide
L'aide n'est plus une copie brute des fichiers : c'est une page organisée en
questions, avec un ton. **La source reste unique** (ADR 0008) : les mêmes
fichiers servent d'aide et de tests.
- **Trois onglets** : « Jouer » (les scénarios), « Les mots du jeu » (le
glossaire), « À propos ». Le tutoriel est proposé en tête de page.
- **« Jouer »** : un scénario = une question repliable (`details`), fermée par
défaut sauf celle qui correspond à l'écran d'où l'on vient.
- Le **titre du scénario** est la question, formulée comme le joueur se la
pose : « Comment jouer un coup ? », « Je me suis trompé de pion », « Je ne
peux rien jouer avec mes dés ». C'est un changement de titre dans les
`.feature` : les tests n'en dépendent pas.
- La **description du scénario** (le paragraphe sous le titre) est la
réponse affichée. Elle se lit seule, au présent, au « vous ».
- Les **étapes Gherkin** ne s'affichent pas dans l'aide : elles restent la
preuve que l'app fait ce que dit la réponse. « Voir sur le plateau » ouvre
la position de l'exemple quand le scénario en donne une (lien ADR 0013).
- La **description de la fonctionnalité** sert d'introduction à l'onglet.
- **« Les mots du jeu »** : une fiche du glossaire = une carte (le mot, son nom
anglais en `caption` italique, « En bref », les renvois), triées par ordre
alphabétique, avec un champ de recherche en tête.
- **Ton** : celui du maître de café, patient et concret. Pas de « Étant
donné que », pas de vocabulaire technique (moteur, scénario, événement).
docs/identite/charte/board.js
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+45
View File
@@ -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
+2 -2
View File
@@ -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
+27
View File
@@ -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-accueil-tutoriel-aide.md
+59
View File
@@ -0,0 +1,59 @@
# Accueil, installation, tutoriel des règles, aide (0e.5)
- **Date** : 2026-11-03
- **Étape** : 0e.5 (feuille de route), qui couvre aussi le tutoriel de 1g
- **Statut** : prévu (après la fusion de 0e.4)
- **Exécutant** : sous-agent general-purpose, dans un worktree
## Objectif
Traiter les points 2 et 3 du message de Pierre du 2026-11-03 et sa demande d'installation en un toucher :
- une page d'accueil ;
- l'installation proposée par l'app ;
- un tutoriel des règles très didactique, illustré par le plateau ;
- une aide plus humaine.
## Références
- Règles : `docs/identite/charte/accueil-tutoriel-aide.md`. Le texte du tutoriel y figure en première version, à faire valider par Pierre.
- Maquettes : https://claude.ai/artifact/CQw6vbDpi6XQqVWQa4sANe, rangée « Étape 0e.5 » et artboard « Accueil ».
- ADR 0008 (source unique), ADR 0013 (positions par identifiants gnubg).
## Consignes
1. **Accueil**, selon la charte :
- au premier lancement, et une seule fois, le choix entre « Je découvre » et « Je connais les règles » ;
- ensuite : la partie en cours, la carte d'installation, la prochaine leçon et la progression résumée. La leçon et la progression restent en attente tant que 1g et 1h n'existent pas : n'afficher que ce qui existe.
2. **Installation** :
- sous Chrome, garder l'invite reçue avec `beforeinstallprompt` ;
- sous Firefox et sur iPhone, une feuille en 3 étapes ;
- la carte n'apparaît qu'à partir de la première partie terminée. « Plus tard » la masque, et elle ne revient qu'une fois, après 3 parties. Le menu garde une ligne tant que l'app n'est pas installée ;
- plus rien en `display-mode: standalone` ni après l'événement `appinstalled`.
3. **Tutoriel**, en 8 étapes :
- le texte vit dans un fichier source unique sous `docs/` (par exemple `docs/tutoriel/`), copié dans le site par `make site` comme le glossaire, sous licence CC BY-SA 4.0 ;
- positions données par leurs identifiants gnubg ;
- sur les écrans « à vous », le moteur vérifie le coup joué en le comparant aux coups attendus de l'étape ;
- le coup illustré se joue seul après 1 s, avec « Revoir » ;
- un test vérifie que chaque position du tutoriel est valide pour le moteur et que chaque coup attendu est légal ;
- ajouter la fiche du glossaire « camp ».
4. **Aide**, en trois onglets :
- « Jouer » : les scénarios deviennent des questions repliables. Le titre est la question et la description la réponse ; les étapes Gherkin sont cachées. Reformuler les titres des `.feature` sans casser les tests ;
- « Les mots du jeu » : les cartes du glossaire, avec une recherche ;
- « À propos » : licence, crédits, version ;
- le tutoriel est proposé en tête de l'aide.
5. **Scénarios Gherkin** : premier lancement, installation, suivre le tutoriel.
6. **`make test-browser`** :
- premier lancement, tutoriel complet avec ses écrans « à vous », aide ;
- `beforeinstallprompt` simulé dans Chromium ;
- captures dans `build/browser-shots/accueil-tutoriel/` pour la recette design.
`make lint`, `make test` et `make test-browser` doivent passer. Aucune nouvelle dépendance.
## Critères de réussite
- Un débutant suit le tutoriel jusqu'au bout sur le téléphone, et chaque écran « à vous » accepte le bon coup et refuse les autres.
- Les trois commandes passent, et les captures sont livrées pour la recette.
## Résultat
À remplir à la clôture.
docs/plans/2026-11-03-moteur-analyse.md
-96
View File
@@ -1,96 +0,0 @@
# 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
Réalisé le 2026-11-03, branche `moteur-analyse`. Critères tenus : nouvelles
commandes d'`engine-cli` en JSON, références concordantes en natif et en
WebAssembly, `make lint` et `make test` au vert.
- **Niveaux** : les neuf réglages prédéfinis de gnubg 1.08 (`aecSettings`) :
`beginner`, `casual`, `intermediate`, `advanced` (0 pli, bruit 0,06 / 0,05 /
0,04 / 0,015, déterministe), puis `0ply` à `4ply` sans bruit (anciens noms
gnubg : « expert » = 0 pli, « world class » = 2 plis). Coup choisi comme
l'ordinateur de gnubg (`ComputerTurn` : sans analyse, puis
`RefreshMoveList`). `engine.h` (`engine_level_*`), `engine-cli --level` et
`levels`, `Engine.levelMove` et `levelCubeDecision`.
- **Analyses** : `engine_analyse_move` (comme `AnalyzeMove` : coup joué
évalué au niveau le plus profond, rang, perte, appréciation),
`engine_analyse_cube` (pas de double, double, prendre, passer ; pertes de
`AnalyzeMove`), `engine_luck_of` (portage de `LuckNormal` et `LuckFirst`
d'`analysis.c`, fichier non repris dans `engine/gnubg/`). Commandes
`analysemove`, `analysecube`, `luck` ; `Engine.analyseMove`, `analyseCube`,
`luck`.
- **Seuils** : ceux de gnubg, `gnubg.c` : appréciation 0,03 / 0,06 / 0,12
(et non 0,04 / 0,08 / 0,16 comme proposé dans `docs/etape-1.md`) ; chance
0,3 / 0,6. Constantes dans `engine.h` et `SKILL_THRESHOLDS`,
`LUCK_THRESHOLDS` dans `engine.ts`, vérifiées égales par un test.
- **Références** : `tests/reference/analyses.json` (16 coups joués, 14
décisions de videau, 7 cas de niveaux), résultats dans `analysis/`, produits
par l'analyse de partie de gnubg de bureau (« analyse game ») ; comparés par
`compare.py`. Écart maximal 1,64e-3 (`move-jacoby`, 2 plis), tolérance
inchangée (0,002).
- **Écart au plan, décision à valider** : le moteur vide le cache
d'évaluation de gnubg à chaque calcul. Une recherche à 2 plis avec élagage
y laisse des évaluations à 0 pli des réseaux d'élagage, que les calculs à
0 pli suivants reprennent (même défaut dans gnubg de bureau : jusqu'à
2,5e-2 d'écart sur la chance). Coût : environ 3 ms par appel sur le PC.
- **Mesure** (`make bench`, Node 18, i5-2450M) : analyse du coup joué à
2 plis, médiane 76 ms, maximum 451 ms (`opening-21`) ; seuil 3 s. Aussi
dans `bench.html` pour le téléphone.
- **Glossaire** : Niveau de jeu (`Level`), Appréciation (`Skill`), Chance
(`Luck`).
docs/plans/2026-11-03-parties-enregistrees.md
+57
View File
@@ -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-position-dans-l-adresse.md
+39
View File
@@ -0,0 +1,39 @@
# Position dans l'adresse (0e.4)
- **Date** : 2026-11-03
- **Étape** : 0e.4 (feuille de route)
- **Statut** : prévu (après la fusion de la révision UX, qui touche les mêmes fichiers)
- **Exécutant** : sous-agent general-purpose, dans un worktree
## Objectif
Appliquer l'ADR 0013 : chaque position du plateau a un lien direct.
## Consignes
ADR 0007, 0008 et 0013. Aucune nouvelle dépendance.
1. Lecture du fragment `#position=…&match=…` au chargement et sur
`hashchange` ; validation par le moteur ; message clair si illisible.
2. Vue de la position, non jouable, avec « Jouer à partir d'ici » (nouvelle
partie depuis la position, la partie en cours restant reprenable) et
« Retour à ma partie ».
3. Domaine : démarrer une partie depuis une position et un Match ID donnés
(événement GameStarted étendu de façon rétrocompatible, ou équivalent
justifié), sans règle réimplémentée.
4. « Copier le lien de la position » depuis le menu de la partie et depuis la
vue du coup de l'ordinateur ; le lien copié rouvre exactement la même
position (test aller-retour).
5. Scénarios Gherkin (« Ouvrir un lien vers une position », « Partager la
position »), fiches du glossaire (Position ID, Match ID si absentes).
6. `make lint`, `make test`, `make test-browser` (ouvrir un lien, jouer à
partir d'ici, revenir, lien invalide).
## Critères de réussite
Un lien copié depuis l'app, ouvert dans un nouvel onglet, montre la même
position ; les trois commandes passent.
## Résultat
À remplir à la clôture.
docs/plans/2026-11-03-revision-ux.md
+1 -1
View File
@@ -2,7 +2,7 @@
- **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)
- **Statut** : prévu
- **Exécutant** : sous-agent general-purpose, dans un worktree
## Objectif
docs/plans/2026-11-03-saisie-du-coup.md
-65
View File
@@ -1,65 +0,0 @@
# Saisie du coup, videau confirmé, pages de test du moteur retirées
- **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, dans un worktree
## Objectif
Rendre la saisie du coup aussi confortable que dans CBG, d'après les retours de
Pierre du 2026-11-03 (points 1, 6, 7, 8, 9 et 11 de son message), et retirer du
site les pages de test du moteur.
## Consignes
Règles de code : ADR 0007 (domaine pur, aucune règle de backgammon
réimplémentée : tout vient du moteur via le domaine). Glossaire et scénarios :
ADR 0008 (chaque comportement visible a son scénario Gherkin dans
`docs/scenarios/`, chaque nouveau terme sa fiche). Aucune nouvelle dépendance.
1. **Pages de test du moteur retirées** (« supprimer la partie test du moteur
totalement ») : plus de `/moteur/` sur le site ni dans `make deploy`.
`make bench` (mesure sous Node) reste : déplacer ce dont il a besoin hors de
`web/`. Mettre à jour `tests/test_site.sh`, le Makefile, `deploy/`, le
service worker, `docs/guide-test-etape-0.md` et ajouter un amendement daté à
l'ADR 0009.
2. **Un seul coup possible, le pion avance** : quand le joueur touche un pion
(ou une case) et qu'une seule case d'arrivée est possible pour ce pion, le
demi-coup est joué aussitôt, sans second toucher. S'il y en a plusieurs, la
sélection actuelle reste.
3. **Coup à valider, annulable** : quand tous les demi-coups sont joués (ou
qu'aucun autre n'est possible), le coup n'est pas envoyé tout de suite. Le
joueur le valide en touchant ses dés (ou un bouton « Valider »). Tant qu'il
ne l'a pas validé, « Annuler » défait le dernier demi-coup, un par un. Le
journal d'événements ne reçoit `MovePlayed` qu'à la validation.
4. **Dés joués marqués** : chaque dé déjà utilisé par un demi-coup est
visiblement estompé. Pour un double, quatre dés, marqués un par un.
5. **Dés de l'adversaire touchables** : toucher la zone des dés de l'un ou
l'autre côté du plateau lance les dés quand le joueur peut lancer (et valide
le coup en attente de validation).
6. **Confirmation du videau** : toucher le videau ou « Doubler » ouvre une
confirmation courte (« Doubler à 2 ? L'ordinateur pourra prendre ou
passer. » : Doubler / Annuler) avant d'envoyer le double.
Tests : scénarios Gherkin mis à jour ou ajoutés (validation du coup, annulation
demi-coup par demi-coup, confirmation du videau), tests unitaires, et
`tests/browser/play.mjs` adapté (Playwright est validé par Pierre). Lancer
`make lint`, `make test` et `make test-browser`.
Rapporter : ce qui a été fait, les écarts, les résultats des trois commandes,
et un brouillon de description de MR (7 sections, voir `docs/organisation.md`).
Commits fréquents sur la branche du worktree ; ne pas pousser, ne pas ouvrir de
MR : la session principale s'en charge.
## Critères de réussite
- `make lint`, `make test` et `make test-browser` passent.
- Dans le navigateur : un pion à destination unique avance en un toucher ; un
coup complet attend la validation ; « Annuler » défait un demi-coup à la
fois ; les dés joués sont estompés ; le videau demande confirmation.
- `https://…/moteur/` n'existe plus dans le site construit (`make site`).
## Résultat
À remplir à la clôture.
docs/scenarios/jouer-une-partie.feature
+42
View File
@@ -11,11 +11,40 @@ Fonctionnalité: Jouer une partie contre l'ordinateur
Et le premier jet de dés désigne qui commence
Scénario: Jouer un coup permis
Touchez un pion, puis sa case d'arrivée ; s'il n'en a qu'une, il y va dès
que vous le touchez. Chaque dé joué s'estompe. Une fois tous vos dés
joués, votre coup attend que vous le validiez : touchez vos dés, d'un côté
ou de l'autre du plateau, ou « Valider ».
Étant donné que c'est à vous de jouer avec le jet 3-1
Quand vous jouez 8/5 6/5
Alors votre coup attend votre validation
Et vos dés sont tous marqués comme joués
Quand vous validez votre coup
Alors votre coup est accepté
Et c'est ensuite au tour de l'ordinateur
Scénario: Un pion qui n'a qu'une case d'arrivée
Après 8/5, il ne vous reste que le 1 : chaque pion jouable n'a plus
qu'une case d'arrivée, et il y va dès que vous le touchez.
Étant donné que c'est à vous de jouer avec le jet 3-1
Quand vous jouez 8/5
Alors seul votre 3 est marqué comme joué
Et chacun de vos pions jouables n'a plus qu'une case d'arrivée
Scénario: Reprendre un pion avant de valider
Tant que vous n'avez pas validé votre coup, « Annuler » reprend le
dernier pion déplacé ; touchez-le encore pour reprendre le précédent.
Étant donné que c'est à vous de jouer avec le jet 3-1
Quand vous jouez 8/5 6/5
Et que vous annulez le dernier demi-coup
Alors il ne reste de joué que 8/5
Quand vous annulez le dernier demi-coup
Alors la position n'a pas changé
Et aucun de vos dés n'est marqué comme joué
Scénario: Un coup interdit est refusé
La case 12 est tenue par l'ordinateur, qui y a cinq pions : vous ne
pouvez pas vous y poser.
@@ -54,6 +83,19 @@ Fonctionnalité: Jouer une partie contre l'ordinateur
Et votre pion frappé part sur la barre
Et vous pouvez revoir son coup
Scénario: Doubler, après confirmation
Avant de lancer les dés, vous pouvez doubler en touchant le videau ou
« Doubler ». L'application vous demande de confirmer : une fois proposé,
un double ne se reprend pas.
Étant donné que vous pouvez doubler
Quand vous demandez à doubler
Mais que vous changez d'avis
Alors rien n'est proposé à l'ordinateur
Quand vous demandez à doubler
Et que vous confirmez
Alors l'ordinateur prend ou passe, comme le recommande le moteur
Scénario: Prendre le double de l'ordinateur
Étant donné que l'ordinateur vous propose de doubler
Quand vous prenez