ADR 0013 amendé : une adresse pour chaque écran, de vrais liens

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

docs/adr/0013-position-dans-l-adresse.md

@@ -47,3 +47,41 @@ moteur sait les lire et les écrire (`engine.h`).
 - 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.
+
+## Amendements
+
+### 2026-11-03 — Une adresse pour chaque écran, des liens plutôt que des états
+
+Demandé par Pierre : « il faudra vraiment que chaque page (l'aide, etc.) ait
+une URL. Utilise des liens accessibles, pas des états. » Aucun lien de
+position n'a encore circulé : le format ci-dessus est remplacé par un schéma
+unique pour tous les écrans, avant sa première mise en œuvre.
+
+- Chaque écran a son adresse, dans le fragment (pour les mêmes raisons
+  qu'au-dessus : hors ligne, service worker, aucune configuration serveur) :
+
+  | Écran | Adresse |
+  | --- | --- |
+  | Partie en cours | `#/` |
+  | Accueil | `#/accueil` |
+  | Aide (onglet Jouer) | `#/aide`, une question : `#/aide/<identifiant>` |
+  | Les mots du jeu | `#/glossaire`, un terme : `#/glossaire/<fichier sans .md>` |
+  | À propos | `#/a-propos` |
+  | Tutoriel | `#/tutoriel`, une étape : `#/tutoriel/<n>` |
+  | Mes parties | `#/parties`, une partie : `#/parties/<id>` |
+  | Réglages / menu | `#/menu` |
+  | Une position | `#/position/<Position ID>/<Match ID>` (Match ID facultatif) |
+
+  Les identifiants de gnubg sont encodés avec `encodeURIComponent`. Les
+  écrans à venir (analyse, leçons, progression) suivront le même schéma.
+- On change d'écran par de vrais liens (`<a href="#/aide">`), pas par des
+  boutons qui modifient un état caché : le lien se partage, s'ouvre dans un
+  nouvel onglet, se lit aux lecteurs d'écran comme un lien, et le bouton
+  « retour » du téléphone ramène à l'écran précédent. Les actions de jeu
+  (lancer, jouer, doubler) restent des boutons : elles ne sont pas des écrans.
+- Les feuilles (menu, explication) et panneaux qui sont des écrans à part
+  entière ont aussi leur adresse ; une confirmation ou un bandeau éphémère
+  n'en a pas.
+- Une adresse inconnue mène à la partie en cours avec un message clair.
+- L'adresse de l'écran courant est la source de vérité de la navigation :
+  l'application l'écoute (`hashchange`) et dessine l'écran correspondant.

docs/feuille-de-route.md

@@ -24,7 +24,7 @@ Demandes de Pierre du 2026-11-03, traitées avant d'ouvrir l'étape 1.
 | Sous-étape | Contenu | État | Plan |
 | --- | --- | --- | --- |
 | 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 (ADR 0013) | ⏳ | `plans/2026-11-03-position-dans-l-adresse.md` |
+| 0e.4 | Une adresse par écran (aide, glossaire, menu, mes parties…) et par position, par de vrais liens (ADR 0013 amendé) | ⏳ | `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/plans/2026-11-03-accueil-tutoriel-aide.md

@@ -47,6 +47,8 @@ Traiter les points 2 et 3 du message de Pierre du 2026-11-03 et sa demande d'ins
    - `beforeinstallprompt` simulé dans Chromium ;
    - captures dans `build/browser-shots/accueil-tutoriel/` pour la recette design.
 
+Chaque écran (accueil, étapes du tutoriel, onglets et questions de l'aide) a son adresse et s'ouvre par un vrai lien, selon l'amendement de l'ADR 0013 ; le routeur vient de 0e.4.
+
 `make lint`, `make test` et `make test-browser` doivent passer. Aucune nouvelle dépendance.
 
 ## Critères de réussite

docs/plans/2026-11-03-conseil-du-maitre.md

@@ -0,0 +1,60 @@
+# Conseil du maître (1d)
+
+- **Date** : 2026-11-03
+- **Étape** : 1d (`docs/etape-1.md`)
+- **Statut** : prévu (après 1c)
+- **Exécutant** : sous-agent general-purpose, dans un worktree
+
+## Objectif
+
+Le coach bienveillant, « mis en avant mais discret » (Pierre, 2026-11-03) :
+après chaque coup et chaque décision de videau du joueur, jamais avant
+(ADR 0011), une appréciation et une phrase du maître fondées sur les chiffres
+du moteur.
+
+## Références
+
+- ADR 0011 ; maquette « conseil du maître après le coup » du canevas
+  https://claude.ai/artifact/CQw6vbDpi6XQqVWQa4sANe ; règles de la charte
+  (`docs/identite/charte/`, dont interaction.md) ; la ligne réservée de 44 px
+  de la révision UX.
+- Moteur : `analyseMove`, `analyseCube`, `luck`, seuils `SKILL_THRESHOLDS`
+  (gnubg : 0,03 / 0,06 / 0,12).
+
+## Consignes
+
+1. **Analyse en arrière-plan** : après la validation d'un coup (ou une
+   décision de videau), l'analyse à 2 plis part dans le Worker sans retarder le
+   tour de l'ordinateur ; son résultat est rattaché au coup dans le journal
+   (événement d'analyse rétrocompatible, ou cache séparé justifié) pour servir
+   au bilan (1e) sans recalcul.
+2. **Ligne du maître** : icône d'appréciation, mot en couleur (« Bon coup. »,
+   « Imprécision. », « Erreur. », « Gaffe. » : correspondance avec les seuils
+   de gnubg documentée), phrase courte en italique, chevron. Toucher ouvre la
+   feuille d'explication : coup joué et meilleur coup montrés sur le plateau
+   (pions animés, ADR 0011 « comparaison visuelle »), écart d'équité seulement
+   sur demande, lien vers la fiche du glossaire du concept en jeu si le moteur
+   permet de le déterminer, sinon rien.
+3. **Phrases du maître** : gabarits versionnés en français dans une source
+   unique sous `docs/` (CC BY-SA 4.0), ton encourageant, jamais culpabilisant ;
+   elles ne citent que des faits du moteur (coup recommandé, rang, pions
+   frappés, écart) : aucune explication inventée. Première version à faire
+   valider par Pierre (ton).
+4. **Discret** : rien n'apparaît pendant que le joueur réfléchit ; la ligne
+   s'efface à l'action suivante ; désactivable (réglage de 1c et menu).
+5. **Videau** : même traitement pour doubler, ne pas doubler, prendre, passer.
+6. Scénarios Gherkin (bon coup, erreur avec meilleur coup montré, conseil
+   désactivé, décision de videau commentée) avec positions et dés imposés ;
+   tests unitaires des gabarits (chaque gabarit rendu sur des analyses réelles
+   du moteur). `make lint`, `make test`, `make test-browser`, captures pour la
+   recette design.
+
+## Critères de réussite
+
+Après une erreur volontaire dans une position connue, la ligne du maître dit
+« Erreur. », nomme le coup recommandé par le moteur et le montre sur demande ;
+le tour de l'ordinateur n'est pas retardé ; les trois commandes passent.
+
+## Résultat
+
+À remplir à la clôture.

docs/plans/2026-11-03-match-et-reglages.md

@@ -0,0 +1,47 @@
+# Match, niveaux et réglages (1c)
+
+- **Date** : 2026-11-03
+- **Étape** : 1c (`docs/etape-1.md`)
+- **Statut** : prévu (après la révision UX et 1b)
+- **Exécutant** : sous-agent general-purpose, dans un worktree
+
+## Objectif
+
+Choisir sa partie : partie libre ou match en N points, avec les règles de
+Crawford et de Jacoby, contre l'ordinateur au niveau voulu.
+
+## Consignes
+
+ADR 0007, 0008. Le moteur expose depuis 1a les niveaux de gnubg
+(`levelMove`, `levelCubeDecision`) et accepte les matchs dans son API C.
+
+1. **Domaine** : longueur de match, score, règle de Crawford (partie Crawford
+   et suivantes, calculées par le moteur via le Match ID), règle de Jacoby en
+   partie libre ; enchaînement des manches d'un match jusqu'à sa fin ; le
+   journal d'événements reste rétrocompatible (les parties existantes se
+   rechargent).
+2. **Adaptateur** : `EngineCube` étendu au match (score, longueur, Crawford)
+   ou remplacé par le Match ID, sans casser les appels existants.
+3. **Niveau de l'ordinateur** : ses coups et ses décisions de videau au niveau
+   choisi. Reprendre de `ComputerTurn` (gnubg, `play.c`) les règles de
+   déroulement non reprises en 1a : pré-filtre « fenêtre de marché » et double
+   facultatif à 0 pli, avec citation des sources.
+4. **Écran de nouvelle partie** (maquettes de la session « identité » si
+   disponibles, sinon sobre et conforme à la charte) : type de partie, niveau
+   (noms montrés au joueur à proposer simplement : Débutant, Amateur,
+   Intermédiaire, Avancé, Expert, Champion — correspondance avec les niveaux
+   de gnubg documentée), conseil du maître activé ou non. Par défaut : partie
+   libre, Intermédiaire, conseil activé. Le réglage est mémorisé.
+5. Affichage du score de match et de la partie Crawford sur le plateau.
+6. Scénarios Gherkin (match en 3 points jusqu'au bout avec dés imposés,
+   Crawford, Jacoby) et fiches du glossaire (match, Crawford, Jacoby si
+   absentes). `make lint`, `make test`, `make test-browser` (un match court).
+
+## Critères de réussite
+
+Un match en 3 points se joue jusqu'au bout, au niveau choisi, avec Crawford
+appliqué ; les trois commandes passent.
+
+## Résultat
+
+À remplir à la clôture.

docs/plans/2026-11-03-position-dans-l-adresse.md

@@ -1,20 +1,29 @@
-# Position dans l'adresse (0e.4)
+# Une adresse pour chaque écran, et pour chaque position (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)
+- **Statut** : prévu (après la fusion de la révision UX et de 1b)
 - **Exécutant** : sous-agent general-purpose, dans un worktree
 
 ## Objectif
 
-Appliquer l'ADR 0013 : chaque position du plateau a un lien direct.
+Appliquer l'ADR 0013 et son amendement du 2026-11-03 : chaque écran (aide,
+glossaire, menu, mes parties…) a son adresse et s'ouvre par un vrai lien ;
+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.
+0. **Routeur** : un petit module pur (sans dépendance) qui traduit le
+   fragment en écran et inversement, testé unitairement ; l'app dessine
+   l'écran demandé par l'adresse, sur `hashchange`. Tous les écrans existants
+   (aide et ses questions, glossaire et ses termes, à propos, menu, mes
+   parties de 1b) passent par lui, avec de vrais liens `<a href>` ; le bouton
+   retour du navigateur ramène à l'écran précédent. Les actions de jeu restent
+   des boutons.
+1. Lecture de `#/position/<Position ID>/<Match ID>` ; 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 ».
@@ -26,8 +35,10 @@ ADR 0007, 0008 et 0013. Aucune nouvelle dépendance.
    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).
+6. `make lint`, `make test`, `make test-browser` : chaque adresse du tableau
+   de l'ADR ouverte directement dans un nouvel onglet montre le bon écran ;
+   « retour » du navigateur ; liens reconnus comme liens (rôle `link`) ;
+   position : ouvrir un lien, jouer à partir d'ici, revenir, lien invalide.
 
 ## Critères de réussite