Scénarios en Gherkin standard validés par l'analyseur officiel ; ADR amendables

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

docs/adr/0001-consigner-les-decisions-dans-des-adr.md

@@ -40,3 +40,15 @@ dans un ADR, dans la description de la merge request ou dans le journal.
 - `make test` vérifie la forme des ADR (numérotation, statut, sections, index).
 - Les ADR 0002 à 0006 reprennent des décisions antérieures à celui-ci, avec
   leur date d'origine.
+
+## Amendements
+
+### 2026-11-02 — Amender plutôt que multiplier les ADR
+
+Décidé par Pierre, pour ne pas créer un ADR à chaque précision. Un ADR accepté
+peut recevoir un amendement : une section « Amendements » en fin de fichier,
+une sous-section datée par amendement, qui dit qui l'a décidé, ce qu'il change
+et pourquoi. Le texte d'origine n'est pas réécrit ; s'il le faut, une courte
+mention renvoie à l'amendement. Un nouvel ADR (qui fait passer l'ancien au
+statut « remplacé par NNNN ») reste nécessaire quand la décision elle-même est
+abandonnée au profit d'une autre.

docs/adr/0008-glossaire-et-scenarios-source-unique.md

@@ -67,7 +67,8 @@ documentation affichée est donc toujours celle de la version installée.
 - **Documentation utilisateur rédigée à part des tests** : deux textes qui
   divergent tôt ou tard.
 - **Gherkin classique (`.feature`)** : exécutable, mais austère comme page
-  d'aide. Le Markdown avec Gherkin donne les deux.
+  d'aide. Le Markdown avec Gherkin donne les deux. (Choix inversé par
+  l'amendement du 2026-11-02, ci-dessous.)
 - **Aide intégrée en dur dans l'application** : une seconde source à
   maintenir.
 
@@ -80,3 +81,30 @@ documentation affichée est donc toujours celle de la version installée.
   de glossaire dans la même merge request.
 - Toute fonction visible par l'utilisateur demande son scénario dans la même
   merge request.
+
+## Amendements
+
+### 2026-11-02 — Gherkin standard, exécution sur le domaine et le moteur
+
+Décidé par Pierre. Remplace, dans la décision ci-dessus, le format Markdown
+avec Gherkin et l'exécution de bout en bout par l'interface.
+
+- **Format** : Gherkin standard, fichiers `.feature` commençant par
+  `# language: fr`. Le Markdown avec Gherkin est la variante la moins outillée
+  de Cucumber, et sa prise en charge des mots-clés français n'est pas assurée ;
+  le Gherkin standard est compris par tous les outils. Le paragraphe libre sous
+  `Fonctionnalité:` porte l'introduction destinée au joueur ; l'application met
+  le fichier en forme comme page d'aide.
+- **Validation dès maintenant** : `make test` passe chaque scénario dans
+  l'analyseur officiel de Cucumber (`@cucumber/gherkin`, MIT, image
+  `docker/gherkin/`), et refuse une étape égarée dans une description, signe
+  d'un mot-clé mal orthographié que Gherkin accepterait comme texte libre.
+- **Exécution** : piloter une application native de bout en bout serait
+  compliqué. Les scénarios sont donc exécutés comme tests d'intégration :
+  leurs étapes appellent directement le domaine, branché sur le vrai moteur.
+  Ils s'écrivent en conséquence avec des intentions (« vous commencez une
+  nouvelle partie ») et non des gestes d'interface (« vous touchez le bouton
+  … ») : le même scénario reste vrai quelle que soit l'interface.
+- **Perspective** : si les scénarios peuvent un jour être joués dans une
+  instance réelle de l'application, la même exécution produira les captures
+  d'écran de l'aide, toujours à jour avec la version installée.

docs/adr/README.md

@@ -1,8 +1,9 @@
 # Décisions d'architecture (ADR)
 
 Un fichier par décision structurante, au format de `modele.md`. Un ADR accepté
-n'est plus réécrit : une décision qui change donne un nouvel ADR, et l'ancien
-passe au statut « remplacé par NNNN ». Voir l'ADR 0001.
+n'est pas réécrit : une précision s'ajoute en amendement daté à la fin du
+fichier ; une décision abandonnée au profit d'une autre donne un nouvel ADR, et
+l'ancien passe au statut « remplacé par NNNN ». Voir l'ADR 0001.
 
 | N° | Décision | Statut |
 | --- | --- | --- |