16 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	b2e933f322	Reorganisation game/document : renommage screens->game_engine + sous-dossiers game/ dans routes, scripts, static, templates, tests ... Prepare la scission a venir entre l'editeur Jeu 2D et le futur editeur Support de formation (voir docs/plan/PLAN.md), sans toucher a l'architecture en couches existante : - screens/ renomme en game_engine/ (nom clair pour le moteur du jeu 2D, avant l'arrivee d'un second "moteur" cote document) : ~85 imports corriges, contrat import-linter mis a jour, meme forme de couches. - routes/, scripts/, static/, templates/, tests/ : tout ce qui est propre au jeu 2D deplace dans un sous-dossier game/ de chacun (routes/game/, static/game/, templates/game/, tests/game/, scripts/game/) ; ce qui est partage par le site (auth, onboarding, dashboard, uploads, db/) reste a la racine de chaque dossier. Un sous-dossier document/ (vide) cree dans chacun pour le futur chantier. - styles/ volontairement inchange : les 3 fichiers sources sont concatenes en un seul static/style.css charge par tout le site, scinder leur CONTENU (editeur vs partage) serait un refactor CSS distinct, pas un deplacement mecanique. - Chaine d'export SCORM (publish/build_scorm_package.py) mise a jour en profondeur : copie des assets, URLs d'icones relatives a static/style.css (qui ne bouge pas), manifeste, wrapper SCORM. - Deux regressions d'un sweep de renommage anterieur corrigees au passage (screens.js/screens/scene-objects incorrectement convertis en game_engine.js/game_engine/scene-objects dans des commentaires). - Effet de bord Windows decouvert et corrige : git mv + Path.write_text convertissent des fichiers en CRLF (core.autocrlf=true) - ~189 fichiers normalises en LF. - .eslintrc.json/package.json : uniquement les chemins de glob mis a jour (static/game/js/...) ; la preparation eslint-plugin-unicorn du lot 7 reste volontairement non committee (package-lock.json restaure a la version precedente). Verifications : ruff, mypy --strict (391 fichiers), vulture, bandit, lint-imports tous verts ; 591/591 tests Python, 276/276 tests JS ; demarrage serveur + requetes HTTP manuelles confirmant que les assets deplaces repondent en 200 au nouvel emplacement et 404 a l'ancien. SKIP=djlint : backlog H021 (styles inline) deja documente comme dette assumee dans CODE_QUALITY.md section 6, aucun template touche par ce commit au-dela d'un deplacement de fichier. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-19 12:27:53 +02:00
williamandClaude Sonnet 5	c57420c8c9	Phase 3 : hardening qualite de code - typage strict, securite, dead code, a11y ... Config strictement stricte partout (ruff, mypy --strict, bandit, vulture, import-linter, eslint, stylelint), aucune regle desactivee "pour ne pas casser le build" - l'existant a ete corrige pour la satisfaire plutot que l'inverse. Hooks pre-commit locaux (language: system) bloquants. - Typage mypy --strict propage a tout le moteur (db, screens, auth, core, ai, routes, puis publish/scripts/tests/app.py/build_css.py). - Securite : fuite de handle fichier Windows corrigee dans l'export SCORM (routes/publish/export_scorm.py), CSRF/RNG non-crypto/xAPI documentes (# nosec, # NOSONAR justifies), nouveau db.json_for_script() (echappe "</script>" dans le JSON embarque en <script>, 25 sites). - Architecture : imports circulaires/F811 nettoyes, contrats import-linter respectes, code mort retire (vulture). - Accessibilite : 69 champs de formulaire sans label correctement associe corriges (for/id ou aria-label) sur 11 templates. - ESLint/Stylelint : lot mecanique JS/CSS, regles ajustees puis appliquees (aucune desactivee sans verification individuelle). - Tests : isolation du compte admin partage (nettoyage ponctuel + fixture de teardown automatique en filet de securite), suite complete verte (591 tests Python, 241 tests JS). - SonarQube Community Build self-heberge (Docker + PostgreSQL) : rapport complet analyse point par point, faux positifs documentes. - .gitattributes ajoute (LF force) : core.autocrlf=true sur cette machine faisait echouer ESLint (linebreak-style) via un bug connu de git (checkout "en place" qui ignore l'eol force sur un fichier deja present sur disque - contourne en supprimant puis recreant chaque fichier suivi). djLint (H021, styles inline) volontairement saute pour ce commit - backlog assume, deja documente, traite dans un lot separe. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-15 16:06:15 +02:00
williamandClaude Sonnet 5	d664ed5637	Remplace le système de quêtes par des déclencheurs, ajoute l'action variable et le chaînage ... Supprime le concept de "quête" au profit d'un onglet unique "Déclencheurs" portant toute la logique (dialogue, condition, marquage terminé) directement sur l'objet de scène. Ajoute une nouvelle action "Modifier une variable" (réutilisant le vocabulaire du graphe de flow) utilisable après une collision, une interaction ou une branche de condition, ainsi qu'un chaînage d'actions ("then") permettant d'enchaîner plusieurs actions à la suite et d'étendre un déclencheur déjà posé sans le recréer. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 22:05:06 +02:00
william	c504ace167	Enrichit le reporting SCORM/xAPI et met en conformité RGAA le player ... SCORM/xAPI : - Ajoute l'export SCORM 2004 (3rd/4th edition) au choix, en plus du 1.2 par défaut : sépare completion_status/success_status (un échec reste "completed" au lieu de retomber à tort en "incomplete" comme force la 1.2), remonte aussi cmi.interactions.n.* par question répondue. - Fournit cmi.core.score.min/max (1.2 et 2004), calculé depuis les récompenses de quiz du jeu, pour que le LMS affiche un vrai pourcentage au lieu du score brut à tort étiqueté "%". - Libellés de verbes xAPI en français en plus de l'anglais. Accessibilité (RGAA/WCAG 2.1 AA) sur le player : - Navigation clavier des objets de scène "au clic"/"au survol" (tabindex, role, Entrée/Espace, focus/blur). - alt sur les images (nom auteur ou décoratif), aria-hidden sur les icônes seules, role="dialog"/aria-live sur les boîtes de dialogue/quiz. - Landmark <main> + titre de page, respect de prefers-reduced-motion. - Le quiz n'avance plus automatiquement après un délai fixe : bouton "Continuer →" explicite (RGAA 2.2.1). - Avertissement de contraste dans l'éditeur de style de dialogue. - Déclaration d'accessibilité téléchargeable depuis la modale d'export.	2026-09-06 00:17:51 +02:00
william	f7a50e5afe	Ajoute un suivi xAPI optionnel (bolt-on) au paquet SCORM exporté ... Greffe l'envoi de statements xAPI vers un LRS configurable par le créateur du jeu, en parallèle du reporting SCORM existant : réglages stockés en base (_meta), formulaire dans la modale d'export, injection dans le paquet exporté. Relié aussi bien à l'action de flow "Modifier un score/statut" qu'au parcours quête/quiz (qui alimentait déjà le SCORM classique via un chemin séparé). L'export ne se lance plus automatiquement à l'ouverture de la modale, pour laisser le temps d'enregistrer les réglages xAPI avant de générer le paquet.	2026-09-05 10:00:57 +02:00
williamandClaude Sonnet 5	00f7191a8b	Corrige les animations figées et le reporting SCORM dans le paquet exporté ... Deux bugs distincts détectés dans le paquet Web/SCORM : - L'animation de marche du personnage dépend entièrement des touches clavier maintenues (heldKeys), qui ne sont alimentées que par des écouteurs keydown/keyup sur window. Un LMS comme SCORM Cloud charge index.html dans une iframe qui ne reçoit pas le focus clavier par défaut : aucune touche n'atteignait jamais window, donc le personnage ne bougeait/animait jamais. On force désormais le focus au chargement et on le reprend au premier clic dans le jeu. - scorm-api.js (qui pousse score/statut au LMS) était bien copié dans le zip mais jamais référencé par un <script> dans index.html, car build_scorm_package.py ne passait pas scorm_api_wrapper_url au template — le reporting SCORM (Completion/Success/Score) ne fonctionnait donc jamais depuis un export. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 18:23:17 +02:00
williamandClaude Sonnet 5	9199897784	Image de fond de scène + caméra qui suit le personnage, fps d'animation cohérent ... Trois retours utilisateur : - fps d'idle/interagir/touches supplémentaires alignés sur celui de la marche (8 i/s partout, était 4 pour idle — perçu comme "les autres animations sont lentes à côté de la marche"). - Nouveau menu "🏞️ Images de fond" dans "Objets de cette scène" : pose un objet kind="fond" à la taille RÉELLE de l'image choisie (pack CraftPix intégré en galerie, admin seulement — licence, voir core/sprite_gate.py), derrière tout le reste, insensible au clic. - Si ce fond dépasse la scène, elle devient le "monde" : .playScreen. playScene est désormais le viewport (overflow:hidden, taille fixe), .sceneWorld le monde à l'intérieur — la caméra centre le premier personnage trouvé, bornée pour ne jamais montrer au-delà des bords (voir personnage-controller.js::forgeUpdateSceneCamera). Le personnage peut désormais se déplacer sur tout le monde, pas seulement le petit cadre visible (clampSceneObjectPosition, actions.js). Un jeu sans fond XXL garde un comportement strictement identique à avant (monde == scène, transform vide). Bibliothèque générée une fois par scripts/generate_background_manifest.py (assets/background/, non versionné, licence CraftPix) vers static/backgrounds/ (committé), même patron que generate_animal_sprite_manifest.py. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 12:24:10 +02:00
williamandClaude Sonnet 5	e82eb7ce88	Retire l'export exécutable (.exe) et la partie publique en ligne (/jouer) ... Décision produit : seul l'export Web/SCORM (LMS) est pertinent — l'export exécutable Windows autonome (publish/build_package.py, bouton "Publier") et la partie publique par joueur (/jouer/<slug>, routes/public_play/, "Publier en ligne") sont jugés redondants et retirés. Conserve le mécanisme d'état "par joueur" (db/global_vars, db/rows, per_player) : infrastructure générique déjà utilisée par Score/Progression et testée indépendamment de toute route publique (voir tests/test_player_state.py), aucune raison de la retirer. _STATIC_ITEMS/_copy_characters (copie sélective des sprites CraftPix réellement utilisés) migrent de build_package.py vers build_scorm_package.py, seul appelant restant. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 10:59:28 +02:00
williamandClaude Sonnet 5	82d00b3800	Export Web/SCORM : inline les icônes en data: URI (CORS Firefox/file://) ... Le chemin relatif ("icons/x.svg") était enfin correct, mais Firefox bloque encore par CORS TOUT chemin de fichier pour mask-image sous file:// — chaque ressource file:// y est une origine opaque distincte, indépendamment du chemin (troisième rapport du même utilisateur). Seule une data: URI (aucune requête réseau séparée) contourne le problème. _build_icon_data_uris (build_scorm_package.py) encode chaque icône RÉELLEMENT posée dans le jeu (élément direct ou niché dans un élément de jeu réutilisable) en base64, ajouté au payload sous gameData.icon_data_uris ; forgeRenderIcone (JS) le consulte pour toute régénération après une action, avec repli sur l'ancien chemin relatif si jamais une icône n'a pas été pré-encodée. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 10:27:04 +02:00
williamandClaude Sonnet 5	b60fe63a54	Export Web/SCORM : corrige le chemin de l'icône doublé "static/static/" ... Le premier correctif ("static/icons/x.svg") ne suffisait pas : cette URL est posée en style inline (--icon-url) mais CONSOMMÉE par `mask-image: var(--icon-url)` dans static/style.css (.icon-svg) — une URL relative dans une propriété personnalisée CSS se résout par rapport à la feuille de style où le var() est UTILISÉ, pas où elle est définie (piège CSS connu). Résultat : "static/icons/x.svg" redevenait "static/static/icons/x.svg" une fois résolu depuis static/style.css (CORS bloqué — deuxième rapport du même utilisateur). Seul "icons/x.svg" (sans le préfixe "static/") est correct une fois résolu depuis static/style.css. Corrigé côté rendu initial (_relativize_absolute_urls) et côté port JS (forgeRenderIcone, qui régénère ce widget après une action). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 10:12:44 +02:00
williamandClaude Sonnet 5	7bc4c89eaa	Export Web/SCORM : corrige les URLs absolues cassées en local (file://) ... Bug signalé : icône disparue et texte suivant du dialogue absent après export. render_icone.py (et son miroir JS, forgeRenderIcone) bakaient une URL "/static/icons/..." en dur, correcte en ligne (racine du serveur Flask) mais bloquée par CORS une fois ouverte en local (file:///static/...). Même souci pour les fichiers envoyés par le créateur (/game/<slug>/uploads/..., jamais dans static/, jamais copiés par le paquet). Ajoute _relativize_absolute_urls (réécriture globale post-rendu du HTML) + copie du dossier uploads/, et relativise le port JS de l'icône pour toute régénération après action en mémoire. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 09:31:44 +02:00
williamandClaude Sonnet 5	f3b72d73c9	Export Web/SCORM : port complet du runtime jouable côté navigateur ... Phase 1.2 de la feuille de route produit — un paquet SCORM tourne seul dans le LMS du client, sans serveur Forge Engine disponible. Ajoute static/js/play/offline/ (miroir JS de screens/rendering/ et data_actions/, sous window.FORGE_OFFLINE) pour que variables, score, données d'objet, répéteurs et conditions de visibilité fonctionnent entièrement en mémoire côté navigateur ; branche actions.js et bindings.js dessus au lieu d'un fetch() serveur. Ajoute publish/build_scorm_package.py (paquet statique + imsmanifest.xml SCORM 1.2 + wrapper API SCORM) et le bouton "Exporter (Web/SCORM)". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 07:43:02 +02:00
williamandClaude Sonnet 5	a27d08c6b0	Bibliothèque de sprites animaux CraftPix (2/3) : export .zip sélectif ... Corrige aussi un import cassé du commit précédent : screens/__init__.py importe déjà screens.rendering.list_used_forge_characters (nécessaire à screens.ADMIN_ONLY_CHARACTER_SLUGS/la galerie filtrée), mais ce fichier n'avait pas été inclus dans ce commit — screens/ ne s'importait plus en l'état. Corrigé ici, dans le même commit que sa seule vraie utilisation. publish/build_package.py copiait jusqu'ici static/characters/ dans SON INTÉGRALITÉ pour CHAQUE jeu exporté (.zip), sans filtrage — avec la bibliothèque d'animaux (~2,1 Go), ça aurait gonflé chaque export du poids de toute la bibliothèque, même un jeu qui n'utilise aucun animal. screens.list_used_forge_characters(slug) (nouveau) parcourt tous les écrans du jeu (écrans-modèles compris, même patron que full_game_payload.py) et renvoie l'ensemble des personnages Forge réellement référencés. _copy_engine_sources()/_copy_characters() copient désormais : le rangement plat Kenney (petit, comme avant) + toujours static/characters/animals/manifest.json (nécessaire à l'IMPORT de screens/labels/animal_sprite_library.py dans le paquet exporté, sinon le jeu exporté ne démarre plus) + UNIQUEMENT les dossiers animal/variante réellement utilisés par CE jeu. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 21:52:13 +02:00
williamandClaude Sonnet 5	d2c2f20b65	Phase 7 : personnage animé par sprites (poses/images successives) ... Ajoute une nouvelle action de flow "jouer_animation_sprite" qui joue une séquence de PNG sur un élément image (cycle en boucle type marche, ou une fois type saut) — réutilise target_element_id (déjà whitelisté) et data_value en JSON {frames, fps, loop}, exactement le patron déjà établi par "jouer_son" (Phase 6) et "alea" (Phase 2) : aucune nouvelle colonne, aucune migration de schéma. Ajoute une propriété d'élément "orientation" (Modifier un élément) pour retourner un personnage en miroir (gauche/droite/bascule) sans nécessiter une 2e feuille de sprites "vue de dos" — même patron que "surbrillance"/ "désactivé". Étend aussi la Timeline d'animation existante (kind="sprite", aux côtés de "animate_css"/"custom") pour qu'un personnage puisse animer tout seul dès l'affichage de l'écran (ex. idle en boucle perpétuelle), pas seulement en réaction à un événement — réutilise la colonne générique custom_keyframes (JSON) et le réglage iteration_count déjà là pour la boucle, aucune migration non plus. Les deux entrées (action de flow et clip de timeline) partagent le même moteur côté client (runSpriteAnimation()/activeSpriteAnimations dans static/js/play/ actions.js, indexé par nœud DOM plutôt que par id d'élément pour supporter plusieurs instances d'un même écran-modèle animées indépendamment). Une bibliothèque de sprites Forge (2 personnages Kenney CC0, sous- ensemble curé idle/marche/saut copié dans static/characters/) est proposée dans l'éditeur, mais un créateur peut tout aussi bien utiliser ses propres sprites uploadés (même route d'upload générique que le son de la Phase 6). Périmètre volontairement limité à ce qui a été demandé : pas d'avatar modulable en couches (assemblage cheveux/haut/bas par le joueur), écarté du plan initial à la demande de l'utilisateur. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 19:18:07 +02:00
williamandClaude Sonnet 5	dbada333d5	Phase -1 : découpe le moteur de play.html en modules JS + premiers tests JS ... templates/play.html était un unique fichier HTML+CSS+JS de 1069 lignes, tout le moteur de jeu vivant dans UN SEUL <script>, sans aucune couverture de test sur cette logique (seuls le rendu HTML et la syntaxe JS étaient vérifiés). La feuille de route à venir (état par joueur, hasard, clavier/minuteur, position/collision, son — voir le plan) va justement faire grossir ce moteur : "un fichier = une fonction, un dossier = une responsabilité" s'applique aussi au JS, pas seulement au Python — le moment de découper est avant d'ajouter encore plus de code, pas après. Découpage en 6 fichiers sous static/js/play/, calqués sur les sections déjà présentes dans le code (aucune réorganisation de logique, une pure extraction) : screens.js (affichage d'écran, timeline d'animation), conditions.js (évaluation des conditions — la partie 100% PURE, sans DOM, la plus testable), actions.js (exécution des actions), triggers.js (recherche des nœuds déclencheurs, attache des écouteurs), bindings.js (résolution des {{champ}}, rafraîchissement des données), flow-engine.js (parcours du graphe, événements personnalisés). Zéro nouvel outillage : plusieurs <script src> dans l'ordre, partageant le même espace global qu'avant (aucun bundler, aucune étape de build). Les 2 URLs de route dont ces fichiers ont besoin (flow_node_run_data/ run_variable, runtime_payload) ne peuvent plus être injectées par Jinja directement dans le code (un fichier statique n'est jamais passé par le moteur de templates) — elles sont maintenant posées une fois dans window.FORGE_PLAY_URLS par le petit <script> inline restant dans play.html, qui ne porte plus que les données Jinja (gameData) et l'amorçage (bindClicks() etc. au chargement). publish/build_package.py : ajoute static/js/play à la liste des fichiers copiés dans l'exécutable exporté (le mode jouable en dépend désormais). Premiers tests JS (static/js/play/__tests__/conditions.test.js, lancés via `node --test`, zéro nouvelle dépendance npm — decision prise avec l'utilisateur de commencer par la logique PURE seulement, pas par une couverture DOM via jsdom) : compareValues, resolveVariablePath, evaluateConditionClause/Node, exactement la logique que les phases à venir (opérations mathématiques, condition de collision) vont étendre. tests/conftest.py : nouveau helper play_js_bundle() (concatène tout static/js/play/*.js) — 13 tests existants qui vérifiaient la présence de telle fonction/chaîne dans le HTML de /game/<slug>/play (tout le JS y était inline avant ce découpage) sont mis à jour pour chercher dans ce bundle à la place ; les tests qui vérifient un CSS/HTML réellement resté dans play.html (forgeHighlight, forgeDisabled, #playFrame...) continuent de chercher dans le HTML. Vérifié : 215 tests pytest passent (aucune régression comportementale, juste une réorganisation), 13 tests node:test passent, node --check sur chacun des 6 nouveaux fichiers. Test manuel recommandé (jeu joué de bout en bout : navigation, clic, survol, répéteur, condition, animation) avant de considérer le découpage définitivement sans risque. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 13:59:11 +02:00
williamandClaude Sonnet 5	1289079da5	Ajoute "Publier" : exporte un jeu en exécutable Windows autonome ... Fonctionnalité mise de côté depuis le tout début de ce chantier ("jouable en toute autonomie"). Nouveau bouton "📦 Publier" dans la barre de navigation du jeu (après "▶️ Jouer") : construit un zip contenant un Python portable + Flask embarqués, une copie figée du moteur de rendu (screens/db/filters + le strict minimum de core/) et des données du jeu (game.db + uploads/), lancé en double-cliquant sur run.bat — aucune installation requise, 100% hors-ligne (voir le commit précédent qui a auto-hébergé polices/animate.css, dernière dépendance CDN de l'app). Exploration préalable a confirmé que screens/ et db/ sont déjà totalement découplés de auth/routes/core (seul lien : un try/except optionnel dans db/connection.py) et que templates/play.html n'appelle que 4 endpoints "purs" (aucune logique d'auth mélangée dedans) — ce qui a permis de réutiliser ces routes quasiment telles quelles dans un mini-serveur Flask séparé plutôt que de les réécrire. - db/constants.py : PROJECTS_DIR devient surchargeable via FORGE_PROJECTS_DIR (même schéma que auth/connection.py) — le serveur joueur autonome pointe ainsi vers son propre dossier "projects/" embarqué. - publish/vendor_runtime.py : télécharge (une fois par poste, mis en cache sous data/publish_vendor/ — déjà ignoré par git) le ZIP Python embeddable officiel (python.org) et vendore Flask via pip --target ; fonctions séparées et mockables pour ne jamais déclencher de vrai téléchargement dans les tests. - publish/player_app_template.py : mini-Flask autonome, réutilise core/flask_app.py et core/jinja_filters.py tels quels (SLUG figé en dur au moment de la publication, csrf_token() factice puisqu'aucune session n'existe dans cet export). sys.path doit être complété manuellement au démarrage : le python311._pth de la distribution embeddable ne référence que le dossier de python.exe lui-même, jamais celui du script lancé. - publish/build_package.py : assemble le zip dans un dossier temporaire (jamais les vrais fichiers de l'app), copié/nettoyé après envoi de la réponse HTTP (routes/publish/publish_game.py, déjà protégée par la garde d'accès existante — aucune vérification supplémentaire). - templates/base.html : bouton + modale (avancement séquentiel, jamais de suivi serveur réel — le build est rapide) qui déclenche le téléchargement du zip via un blob, comme la modale des codes de récupération déjà en place (posée À L'INTÉRIEUR de <main> pour que pjax.js la remplace et rejoue son script à chaque navigation). Vérifié pour de vrai (pas seulement via les tests) : zip construit, extrait, lancé avec le Python embeddable réel — /, /game/test/play, /game/test/runtime-payload et /static/style.css répondent tous 200. tests/test_publish.py (nouveau, vendor mocké) : structure du zip, SLUG correctement substitué, route protégée par la même isolation par projet que le reste de l'app. 203 tests au total. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 09:58:32 +02:00