Ustagammon/docs/journal.md

Journal

Une entrée datée par session : ce qui a été fait, décidé, et la suite.

2026-11-02

Fait

• Dépôt initialisé (branche main) avec le kit de démarrage : CLAUDE.md, docs/cadrage.md, docs/etape-0.md, PROMPTS.md.
• Nom de l'application reporté partout : Ustagammon (lien vers le brief créatif dans CLAUDE.md et docs/cadrage.md).
• Squelette : Makefile (help, setup, build, test, lint, deploy, clean), LICENSE (GPLv3), CREDITS.md, README.md, .gitignore, ce journal, docs/decisions.md.
• Premiers tests : contrat du Makefile (tests/test_makefile.sh) ; lint du dépôt (tests/lint.sh, avec ShellCheck dans Docker).
• main poussé sur Gitea (git@git.sans.pub:pierre/Ustagammon.git), après fusion avec le commit initial créé par Gitea (LICENSE et README). Incident : le premier envoi contenait un README.md avec des marqueurs de conflit ; corrigé, et make lint les détecte désormais.
• PROMPTS.md supprimé ; ajout de docs/organisation.md, docs/feuille-de-route.md et docs/plans/.
• Étape 0a.1 lancée : étude des trois sources du moteur confiée à un sous-agent (docs/plans/2026-11-02-choix-source-moteur.md), puis clôturée avec vérification des points clés par la session principale.

Décidé

• Les outils de lint tournent dans Docker, comme les autres chaînes d'outils.
• Claude Code pilote le projet par sous-agents ; tout le suivi est dans docs/.
• Moteur : gnubg officiel, commit 14b6798 (validé par Pierre).
• Toute modification passe par une merge request Gitea décrite en détail, fusionnée par Claude Code une fois make lint et make test au vert (demande de Pierre).
• Les décisions passent dans des ADR (docs/adr/) ; docs/decisions.md est remplacé par les ADR 0001 à 0006. Plans et feuille de route deviennent temporaires : le plan du choix du moteur est supprimé, son contenu durable est dans l'ADR 0005 (demande de Pierre).
• Les hash de commit s'écrivent sans backticks, pour les liens automatiques de Gitea (demande de Pierre).

Incident (clos)

• Les MR fusionnées restaient « open » dans Gitea : les hooks git du serveur ne s'exécutaient plus, sur toute l'instance (diagnostic par un sous-agent, en lecture seule ; brief transmis à Pierre). Pierre a réparé les hooks et marqué les MR !1 à !8 comme fusionnées. Les branches fusionnées ont été supprimées du serveur.

Suite de la session (après-midi)

• ADR 0007 (architecture et conventions de code) et ADR 0008 (glossaire et scénarios, source unique), puis amendements : scénarios en Gherkin standard validés par l'analyseur officiel, ADR amendables (0001).
• Étape 0a terminée, par sous-agents : gnubg de référence et 32 positions (0a.2, MR !6) ; moteur embarqué, engine.h et engine-cli (0a.3, MR !7) ; comparaison automatique aux références, tolérance 0,002, deux défauts du moteur corrigés (0a.4, MR !8).
• Outils de compilation et de test validés par Pierre (amendement de l'ADR 0004).
• Étape 0b : moteur en WebAssembly, même suite de contrat (écart maximal 9,5e-4), 7,3 Mo compressés, page de test et de mesure, make deploy-web, guide de test docs/guide-test-etape-0.md.

Reste à faire

• Mesures sur le Fairphone 4 avec Pierre, puis décision du socle (ADR).
• Étape 0d : plateau minimal jouable sur le socle retenu.
• adb n'est pas installé sur le PC : sudo apt install adb avant les tests sur le téléphone.

2026-11-02 (soir) et 2026-11-03

Fait

• Mesures sur le Fairphone 4 (Chrome 156) : 2 plis en 348 ms au pire, seuil 3 s ; ADR 0009 accepté (socle PWA en TypeScript), 0c abandonnée.
• Déploiement CapRover (MR !10) : app ustagammon créée, site publié sur https://ustagammon.sans.pub (HTTPS forcé).
• Étape 0d.1 (MR !11) : domaine « partie » en journal d'événements, scénario exécuté par Cucumber sur le vrai moteur, garde-fous d'architecture.
• Étape 0d.2 : plateau jouable au toucher en PWA hors ligne, aide intégrée (glossaire et scénarios lus depuis leurs sources), CSP, make test-browser (parties complètes dans Chromium et Firefox). Deux bugs trouvés et corrigés : la pile du moteur WebAssembly débordait après quelques centaines de commandes (plantage en cours de partie), et le service worker échouait dans Chromium en téléchargeant les données en même temps que le moteur.
• Interruptions de quota : reprise programmée à 23h50 ; l'agent de 0d.2 arrêté a été remplacé par un agent de reprise sur le même espace de travail.

Reste à faire

• Vérification finale de l'étape 0 avec Pierre : une partie complète sur le Fairphone 4, en suivant le guide de test (section « Étape 0d »).
• Sous Firefox sur PC, un tour de l'ordinateur a pris jusqu'à 5,1 s (Chromium : 0,4 s) ; Firefox sur le téléphone reste à mesurer.
• Validation par Pierre de Playwright (Apache-2.0), outil de make test-browser.

2026-11-03 (nuit) : identité visuelle

Fait

• Identité choisie par Pierre en trois tours sur une planche de travail : accent brique, symbole « P3d » (deux pions sur une flèche, le 8 caché), logotype « L3 » (les « mm » en flèches), icône sur fond ivoire. ADR 0010, fichiers du logo et des icônes dans docs/identite/logo/ (MR !12).
• Design system publié (https://claude.ai/artifact/K2Z7MPE58XXJzv19n5r11M) : couleurs des deux thèmes reprenant les noms de variables de web/app.css, Alegreya Sans, onze composants, contrastes vérifiés par calcul. Copie dans docs/identite/charte/.
• Maquettes des quatre écrans et du thème sombre (https://claude.ai/artifact/CQw6vbDpi6XQqVWQa4sANe).

Reste à faire

• Appliquer la charte à la PWA (couleurs, police embarquée, icônes, logo) : à planifier pour l'agent développeur, voir docs/identite/charte/README.md.
• Les maquettes proposent des éléments de produit qui ne sont pas encore décidés (leçons, « Conseil du maître », bilan de fin de partie) : à valider par Pierre avant toute mise en œuvre.

2026-11-03 (matin) : fin de l'étape 0, retours du test sur téléphone

Fait

• Pierre a joué une partie complète sur le Fairphone 4 : « très rapide de la part de l'ordinateur ». Avec les tests au vert, le critère de fin de l'étape 0 est atteint. Le guide de test et docs/etape-0.md, temporaires, sont supprimés ; leurs décisions sont dans les ADR 0005 et 0009.
• Playwright validé par Pierre (amendement de l'ADR 0004, MR !20).
• Douze retours de Pierre après l'essai, plus l'installation en un toucher et les retours haptiques, rangés en sous-étapes 0e dans la feuille de route (MR !20). Lancés : la saisie du coup (0e.1) et une revue UX par un designer UI (0e.2).
• Coordination avec la session « identité » : elle propose et maquette le design (mode immersif, compte de points, accueil, tutoriel), Pierre tranche, la session technique implémente. Numéros des flèches à 12 px minimum.
• Décision de Pierre : la vue paysage « plateau = écran » s'applique dès la rotation du téléphone, sans plein écran (amendement de l'ADR 0012).
• Mode avion vérifié par Pierre sur le téléphone : l'application fonctionne hors ligne.
• Étape 1 découpée dans docs/etape-1.md (sous-étapes 1a à 1j).
• Nouvel objectif fixé par Pierre : traiter les retours 0e (les siens et ceux du designer), puis réaliser l'étape 1, livrée avec un plan de test.

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.