116 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	4111081e1a	Implemente le mini-jeu Memory (retournement de cartes, mode paire/single) ... document_engine/labels/memory_config.py (nouveau) : modele de donnees, meme convention resolve_X/sanitize_X que quiz_config.py/ association_config.py - DEFAULT_MEMORY_CONFIG, sanitize_memory_config. Chaque carte a un recto ET un verso, chacun avec image/texte independants et tous deux optionnels ; seul le verso doit avoir au moins l'un des deux non vide (rien a reveler/apparier sinon) - le recto peut rester entierement vide (dos de carte generique "?" par defaut). Liste tronquee a MAX_CARDS=8. Cote serveur, routes/document/document_element_update.py revalide desormais aussi memory avant persistance. Le rendu (_render_memory) affiche un resume reel (nombre de cartes, mode) et, des qu'au moins une carte existe, un plateau de retournement REELEMENT interactif en Mode Apercu (_render_memory_player) : en mode "paire", chaque carte definie est DUPLIQUEE en deux instances partageant le meme card_index (appariement classique) ; en mode "single", une seule instance par carte (simple retournement, sans appariement - "c'est donc un retourner de carte classique plus un jeu memory"). Les instances sont melangees (random.shuffle, documente dans CODE_QUALITY.md) puis embarquees en JSON dans data-memory-config. Cote editeur, le panneau Proprietes propose un bascule segmentee Paire/Simple et une liste de cartes repetable, chaque carte avec ses deux faces (recto/verso) editables independamment (image + texte). Extrait au passage forgeDocEscapeHtml (ex-forgeDocEscapeForTextarea, generalise pour couvrir aussi les attributs) reutilise pour les deux mini-jeux. Le plateau jouable (static/document/js/document-editor.js) est une vraie carte-retournement CSS 3D (perspective/rotateY), contenu de chaque face construit via DOM (textContent/img.src, jamais innerHTML avec le texte du createur - meme precaution que le plateau Association) : bon appariement verrouille en vert, mauvais reinitialise apres un delai, ecran de resultat une fois le jeu termine (les deux modes), et un "Recommencer" qui remelange reellement les cartes (Fisher-Yates cote client). Tests : 11 tests purs (tests/document/test_memory_config.py, sans Flask, dont un qui verifie explicitement la duplication en mode paire vs son absence en mode single) + 1 test de route verifiant la sanitization a l'ecriture. SKIP=djlint : backlog H021 pre-existant, aucun template touche ici. ruff/mypy --strict/vulture/bandit/import-linter/eslint/stylelint tous verts ; 62 tests document verifies frais. Verification manuelle live complete : ajout, sanitization sur carte invalide, rendu du plateau, et simulation DOM du gameplay reel dans les DEUX modes (mode paire : mauvais appariement puis bon appariement puis jeu complet ; mode single : retournement puis jeu complet) - script de diagnostic non conserve dans le depot. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 14:13:28 +02:00
williamandClaude Sonnet 5	ce750ec697	Implemente le mini-jeu Association (glisser-deposer par paires) ... document_engine/labels/association_config.py (nouveau) : modele de donnees, meme convention resolve_X/sanitize_X que quiz_config.py - DEFAULT_ASSOCIATION_CONFIG, sanitize_association_config (chaque paire doit avoir ses deux cotes non vides, sinon supprimee silencieusement ; liste tronquee a MAX_PAIRS=8). Cote serveur, routes/document/document_element_update.py revalide desormais aussi l'association avant persistance (meme raisonnement que pour le quiz). Le rendu (_render_association) affiche un resume reel (nombre de paires) et, des qu'au moins une paire existe, un plateau de glisser-deposer REELEMENT interactif en Mode Apercu (_render_association_player) : les deux colonnes (termes/ correspondances) sont melangees independamment (random.shuffle, melange d'affichage documente dans CODE_QUALITY.md) puis embarquees en JSON dans un attribut data-assoc-config. Cote editeur, le panneau Proprietes d'une association ("relier visuellement deux champs qui vont ensemble") est une liste de paires repetable, chaque ligne reliant visuellement un champ "Element" et un champ "Correspondance" par un glyphe ↔. Le plateau jouable en Apercu (static/document/js/document-editor.js) supporte deux facons de jouer, toutes deux reelles : glisser-deposer HTML5 natif, ou cliquer une carte puis son emplacement (repli pour les appareils sans support fiable du drag) - bonne association verrouillee en vert, mauvaise signalee puis reinitialisee, ecran de resultat une fois toutes les paires associees. Bug reel trouve ET corrige via simulation DOM complete (glisser- deposer + clic simules, pas juste un chargement de page) : le feedback visuel reutilisait la classe CSS du quiz via une reaffectation de className qui supprimait au passage la classe d'identite docAssocFeedback, rendant l'element introuvable des le premier essai de match (aurait plante en usage reel des la premiere tentative). Corrige en gardant toujours les deux classes ensemble. Tests : 8 tests purs (tests/document/test_association_config.py, sans Flask) + 1 test de route verifiant la sanitization a l'ecriture. SKIP=djlint : backlog H021 pre-existant, aucun template touche ici. ruff/mypy --strict/vulture/bandit/import-linter/eslint/stylelint tous verts ; 50 tests document verifies frais. Verification manuelle live complete : ajout, sanitization sur paire invalide, rendu du plateau, et simulation DOM du gameplay reel (glisser-deposer correct/incorrect, clic-selection, progression, ecran de resultat) - script de diagnostic non conserve dans le depot. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 13:01:21 +02:00
williamandClaude Sonnet 5	9fb22be1ae	Quiz reellement interactif en Mode Apercu (voir maquette document-formation-web.html) ... Le quiz affichait jusqu'ici la meme carte resume en edition comme en Apercu. Ajoute un vrai questionnaire jouable, visible UNIQUEMENT en Mode Apercu (masque en edition via CSS, jamais les deux a la fois) : options de reponse cliquables, marquage correct/incorrect immediat, score qui accumule les points de chaque question repondue correctement, progression "Question suivante", et un ecran de resultat final (score obtenu / total des points possibles) avec "Recommencer le quiz" - structure et identite visuelle calquees sur docs/plan/maquettes/document-formation-web.html (cartes en degrade, options A/B/C/D, feedback vert/orange), adaptees aux tokens --doc-* deja en place (theme clair/sombre inclus, nouvelles variables --doc-quiz-success-*/--doc-quiz-danger-*). Cote rendu (document_engine/rendering/render_document_element.py), _render_quiz ajoute desormais le questionnaire (fonction privee _render_quiz_player) des qu'au moins une question existe : les questions sont embarquees en JSON dans un attribut data-quiz-config (jamais un <script> par element), echappees pour l'HTML - aucun aller-retour serveur pendant qu'on joue, tout le deroulé (reponse/ score/suivant/resultat) est gere par static/document/js/document-editor.js. pointer-events, desactive sur tout element en Apercu pour empecher la selection/le glisser-deposer pendant le test, est reactive specifiquement dans le questionnaire pour qu'il reste reellement cliquable. Tests : 3 nouveaux tests de rendu purs (sans Flask, dont un qui verifie l'echappement HTML du texte d'une question contre une injection). Verifie en live via une simulation DOM complete (basculer Apercu, repondre correctement puis incorrectement, verifier score/feedback/etat des options, passer a la question suivante, voir l'ecran de resultat) - le script de diagnostic n'a pas ete conserve dans le depot. SKIP=djlint : backlog H021 pre-existant, aucun template touche ici. ruff/mypy --strict/vulture/bandit/import-linter/eslint/stylelint tous verts ; 48 tests cibles (document + onboarding) verifies frais. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 12:08:03 +02:00
williamandClaude Sonnet 5	9d87a4bfef	Implemente le mini-jeu Quiz (questions/choix/points/timer) ... document_engine/labels/quiz_config.py (nouveau) : modele de donnees complet, meme convention resolve_X/sanitize_X que game_engine/rendering/quiz_box_config.py cote jeu (aucun import croise) - DEFAULT_QUIZ_CONFIG, sanitize_quiz_config (valide/nettoie chaque question independamment, jamais ne leve, tronque a 2-4 choix, remet correct_index a 0 si hors bornes/non-entier, clampe points >= 0 et timer_seconds dans [5,300]), quiz_total_points. Cote serveur, routes/document/document_element_update.py revalide desormais un quiz avant persistance (seul kind qui en a besoin - les autres n'ont que des attributs scalaires sans structure a garantir) et renvoie les attributs REELLEMENT persistes dans sa reponse, pour que le client ne derive jamais de la verite serveur apres un nettoyage serveur (ex. choix en trop tronque). Cote editeur (static/document/js/document-editor.js), le panneau Proprietes d'un quiz est desormais reel : chronometre optionnel, couleur de theme, liste de questions repetable (ajout/suppression), chacune avec son texte, un nombre de choix ajustable (2-4, les inputs texte suivent), le choix correct via un radio par question, et les points gagnes. Le rendu canevas (render_document_element.py) affiche un resume reel (nombre de questions, total des points, minuteur) au lieu du placeholder generique. Tests : document_engine/labels/quiz_config.py couvert par 13 tests purs (tests/document/test_quiz_config.py, sans Flask - defauts, troncature, validation, cas limites dont bool comme correct_index) + 1 test de route verifiant la sanitization a l'ecriture et le rendu. SKIP=djlint : backlog H021 pre-existant, aucun template touche ici. ruff/mypy --strict/vulture/bandit/import-linter/eslint/stylelint tous verts ; 63 tests cibles (document + onboarding + auth) verifies fraichement + verification manuelle live via le serveur de dev (ajout, sanitization sur choix invalides/en trop, rendu du resume avec minuteur). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 11:40:48 +02:00
williamandClaude Sonnet 5	7ca03380b7	Retire l'action Publier du support de formation ... Un apprenant n'a jamais acces a l'editeur : un etat "publie" persiste en base (published_at) ne servait donc a rien tant qu'aucune vue apprenant/export ne le consomme (retour utilisateur direct). Retrait complet : route /document/<slug>/publish, db.mark_support_published, la colonne logique published_at dans support_meta, le bouton et son CSS/JS. "Aperçu" devient l'action primaire du bandeau (repond au vrai besoin : voir le rendu avant un futur export). Un export reel (SCORM ou equivalent) reste a specifier separement le jour venu. SKIP=djlint : meme backlog H021 pre-existant que le commit precedent, aucun fichier touche ici n'y figure. ruff/mypy --strict/vulture/ bandit/import-linter/eslint/stylelint tous verts ; 615 tests Python (617 - 2 tests du Publier retire) + verification manuelle live du retrait (route 404, bouton absent du HTML, Apercu confirme fonctionnel par simulation DOM). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 09:58:53 +02:00
williamandClaude Sonnet 5	bab581737a	Ajoute le support de formation : entite racine separee du jeu 2D ... Nouveau moteur document_engine/ (elements CRUD + rendering + labels), db/supports/ (stockage independant de db/games), routes/document/ (CRUD AJAX + publication), et l'editeur frontend complet (templates/document/, static/document/) avec moteur de layout reel (glisser-deposer -> fusion en rangee ou insertion avant/apres), vrai Undo/Redo par pile de commandes, grille d'accroche pour les formes libres, apercu responsive a largeurs fixes, mode Apercu, et publication persistee. "Mes formations" (templates/index.html) liste desormais les environnements 2D et les supports de formation cote a cote ; l'onboarding et core/auth_guard.py sont generalises pour qu'un compte restreint puisse posseder un projet de chaque type independamment. SKIP=djlint : le hook ne signale que le backlog H021 (styles en ligne) deja documente dans CODE_QUALITY.md sur des fichiers pre-existants non touches ici (base.html, game/play.html, scene_edit.html, game_dashboard_simple.html, clause_row.html) plus une ligne de index.html deja presente avant cette session — aucun nouveau fichier (document_edit.html compris) n'y figure. Tous les autres outils (ruff, mypy --strict, vulture, bandit, import-linter, eslint, stylelint) passent sans erreur ; 617 tests Python + 276 tests JS verts, plus une verification manuelle complete du cycle de vie via le serveur de developpement. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 09:20:33 +02:00
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	7db4803b93	Ajoute la fonctionnalite quiz autonome/plein ecran a la boite a quiz ... Introduit la double categorie de modeles (boite de dialogue / page de quiz plein ecran) avec plein ecran, minuteur, score integre et ecran de resultat pour les modeles page ; ajoute les modeles "Manga" (boite et page) et "Classique" (page), pilotables aussi par l'assistant IA Ruby. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-13 15:07:23 +02:00
williamandClaude Sonnet 5	559331f9cf	Enrichit les declencheurs/actions de scene (clic/survol/affichage, surbrillance/video/son/visibilite/indication/attendre) et fiabilise la pose d'un fond/decor importe ... - Ajoute clic/survol/affichage-ecran comme declencheurs, et surbrillance, video, son, visibilite, indication, attendre comme actions, utilisables aussi bien par l'editeur manuel (menu lateral Objets/Ecran) que par Ruby (IA), avec blocs deplacables/supprimables dans une chaine. - Corrige plusieurs variantes du bug "impossible de poser un objet hors du champ de la camera" (troncature du chainage d'actions a 4 maillons, fond importe pose a 128x128 au lieu de sa taille reelle, decalage du fond au vrai glisser-depose, redimensionnement manuel jamais propage au monde). - Ajoute un vrai glisser-depose depuis la galerie vers la scene, la gestion complete de "Mes assets" (sous-sections Fonds/Decors/Sons/ Videos, suppression, reclassement fond<->decor sans re-upload). - Ajoute l'upload de son (limite 3 min) et de video (MP4 uniquement, limite 5 min), avec validation de la duree reelle du fichier, et une replique audio optionnelle dans une bulle de dialogue. - Fixe la taille de pose d'un objet/decor importe a 200x200 avec une boite de collision de 150x150. - Filtre le selecteur de fichier des actions son/video par type reel. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:28:46 +02:00
williamandClaude Sonnet 5	b07b231a61	Ajoute l'assistant IA "Ruby" (Claude + Scenario) et corrige plusieurs bugs de la scène ... Intègre un chat IA capable de manipuler la scène via les mêmes fonctions que l'éditeur manuel (objets, variables, déclencheurs, images générées), avec conversations multiples par écran façon Claude. Corrige au passage le rafraîchissement pjax hors-ordre, l'onglet IA/déclencheurs vide après sélection d'un objet, la comparaison de booléens dans les conditions, et le blocage du glisser-déposer hors du cadre caméra après un redimensionnement de fond par l'IA. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-09 19:40:31 +02:00
williamandClaude Sonnet 5	ab6635eee0	Corrige l'action "Modifier une variable" sans effet en aperçu créateur ... compute-operation.js/apply-actions.js n'étaient chargés que dans le paquet SCORM exporté (offline_mode) ; en aperçu créateur (/game/<slug>/play), forgeApplyVariableActionOffline était donc absente et l'action ne modifiait rien. Charge les deux scripts inconditionnellement dans play.html. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 22:24:47 +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
william	7ebc9b143f	Corrige une faille d'isolation entre comptes et retire l'email des chemins de projet ... Le rôle "admin" contournait entièrement l'isolation par projet (core/auth_guard.py) : il pouvait ouvrir/modifier/supprimer le jeu de n'importe quel autre compte en connaissant son slug, et la page d'accueil listait sans filtrage tous les projets de tous les comptes. - La propriété d'un projet se vérifie désormais sur le segment "propriétaire" du slug (id du compte), pour tous les rôles y compris admin — un slug "à plat" (sans compte associé) reste réservé à l'admin, comportement historique conservé pour ce cas précis. - routes/games/index.py ne liste plus que les projets du compte connecté. - Le dossier propriétaire d'un projet est maintenant l'id numérique du compte, plus jamais son email slugifié (visible en clair dans chaque URL auparavant) — script de migration fourni et déjà exécuté sur les données existantes. - Changer d'email ne renomme plus aucun dossier (n'en dépend plus). - Deux nouveaux tests de régression, fixtures corrigées en conséquence. - README réécrit pour refléter l'état actuel du produit (jeu 2D uniquement, plus de traces de l'ancien éditeur "document").	2026-09-04 22:52:05 +02:00
william	50835a18e2	Supprime le type d'écran "document" et recentre le produit sur le jeu 2D ... Le document de cadrage produit cible des formateurs non techniques créant des serious games/quiz gamifiés — l'éditeur générique "document" (blocs de logique en nœuds, timeline d'animation, définitions d'objets/relations, templates réutilisables) est une complexité hors cible que l'effort d'ingénierie récent avait déjà abandonnée au profit du jeu_2d. - Onboarding : ne garde que le parcours "RPG" (jeu_2d), retire Quiz/Embranchement/Créer mon jeu de A à Z (tous document-only) - Suppression en bloc des modules exclusifs au document : routes/elements, routes/element_types, routes/objects, routes/legacy_actions, screens/elements, screens/element_types, screens/widgets, screens/legacy_actions, le rendu render_element_html.py et son cluster, templates/screen_edit.html, templates/game_dashboard.html, flow-editor.js/tabs-and-blocks.js/animation-timeline.js - Dashboard toujours simplifié (un seul mode possible désormais) - Tests document-only supprimés, tests de logique partagée (flow, événements personnalisés, animations) retargetés sur des écrans jeu_2d - Aucune régression jeu_2d : 299 tests passent Carte d'onboarding retravaillée : argumentaire RH non technique (liste à coche, badge "Compatible LMS"), taille et interaction de retournement ajustées.	2026-09-04 20:56:32 +02:00
williamandClaude Sonnet 5	55c6bb330b	Contrôle direct de la taille de la caméra (Largeur × Hauteur, toujours modifiable) ... Remplace le bouton conditionnel "Agrandir la caméra à la zone visible" (n'apparaissait que si un fond dépassait déjà la scène) par deux champs "Caméra (px)" TOUJOURS visibles, pré-remplis avec scene_width/ scene_height actuels — demande explicite : "l'écran de l'éditeur a une taille fixe, la caméra a la même taille, c'est tout", un réglage direct plutôt qu'une suggestion automatique liée à la taille d'un fond. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 17:28:03 +02:00
williamandClaude Sonnet 5	b9d3c46087	Bouton "📐 Agrandir la caméra à la zone visible" ... Fait de tout le "monde" affiché par l'éditeur (la taille réelle d'un "fond" plus grand que la scène nominale, voir routes/scenes/ scene_edit_view.py::world_width/world_height) la scène/caméra ELLE-MÊME — jusqu'ici scene_width/scene_height n'étaient fixées qu'à la création de l'écran, jamais modifiables ensuite. Le bouton n'apparaît que quand un fond dépasse encore la scène nominale (même condition que le repère "🎥 Champ de la caméra"), affiche la taille cible, recharge la page une fois appliqué. La caméra ne recadre alors plus rien en jeu (monde == scène == viewport, voir personnage-controller.js::forgeUpdateSceneCamera). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 17:07:24 +02:00
williamandClaude Sonnet 5	14ec76dddd	Éditeur : le canevas affiche tout le monde (fond agrandi), pas que la scène ... Suite au fix du glisser figé à (0,0) : le canevas de l'éditeur restait malgré tout limité à la scène nominale (960×540 par ex.) — la partie d'un "fond" plus grand qui dépasse restait invisible/injoignable à la souris. Le canevas affiche désormais tout le "monde" (max de la scène et de l'étendue de chaque "fond", voir routes/scenes/scene_edit_view.py), comme la caméra en jeu le fait déjà (personnage-controller.js). Nouveau repère visuel "🎥 Champ de la caméra" : un cadre en pointillés marquant où s'arrête la scène nominale à l'intérieur de ce monde agrandi (le reste est assombri), pour que l'auteur voie clairement ce que le joueur verra réellement à l'écran une fois le monde plus grand que le viewport. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 16:55:09 +02:00
williamandClaude Sonnet 5	d705f58c4a	Fix accès au canevas masqué + quiz : header quête, réponse fausse n'avance jamais bloquée, animé ... - Bug corrigé : les panneaux flottants "🧩 Objets"/"⚙️ Propriétés" sont en position:fixed (hors du flux flex de .builder3) — ils flottaient PAR-DESSUS le canevas sans jamais réduire sa largeur, rendant sa partie droite/gauche inaccessible au clic/glisser tant qu'un panneau restait ouvert. .builderCanvasArea réserve maintenant leur largeur (marge) dès qu'un panneau est ouvert (:has()). - Boîte à quiz : header = "Quête : <titre>" (au lieu du texte de la question), corps = la question ET ses choix ensemble. - Mauvaise réponse : ne bloque plus JAMAIS la progression (bug signalé : "je suis obligé de bien répondre sinon j'avance pas") — surligne la bonne réponse en vert (le choix cliqué en rouge s'il était faux) puis avance automatiquement après un court délai, sans jamais octroyer de points. Un second clic pendant la révélation est ignoré. - Animations : la boîte à quiz rejoue une entrée (pop-in) à CHAQUE nouvelle question, la bonne réponse pulse en vert, une mauvaise réponse "secoue" en rouge. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 16:08:59 +02:00
williamandClaude Sonnet 5	b5546df044	Quiz jouable : budget de récompense, boîte à quiz, widget score ... - Récompense d'une quête = budget MAXIMUM pour ses questions : la somme des points des "❓ Question" ne peut plus dépasser recompense_score (routes/quests/quest_dialogues.py à l'enregistrement des dialogues, quest_update.py si on abaisse la récompense sous ce qui est déjà réparti) — message d'erreur explicite (400) dans les deux sens, affiché via alert() côté éditeur (quest-editor.js), jamais enregistré silencieusement dans un état incohérent. - Nombre de choix par question plafonné à 4 (au lieu de 8). - Deux nouveaux widgets "🖥️ Interface" (mêmes fondations que "💬 Boîte de dialogue" — screens/rendering/dialogue_box_style.py, même panneau "🎨 Style") : - "❓ Boîte à quiz" : affiche la question et ses choix, sans pied (une question se résout au clic sur un choix, pas de "Suivant"). - "🏆 Score" : affiche en continu les points gagnés, TOUJOURS visible une fois posé (contrairement aux boîtes de dialogue/quiz, masquées par défaut). - Moteur d'exécution (static/js/play/dialogue-box-controller.js, refonte) : une conversation de quête alterne maintenant répliques (boîte de dialogue) et questions (boîte à quiz) selon le type de chaque ligne. Bonne réponse -> crédite le score (compteur runtime dédié, jamais lié au score du moteur document) et avance ; mauvaise réponse -> rien, la question reste affichée pour réessayer ; aucune boîte à quiz posée -> la question est ignorée plutôt que de bloquer la conversation. Le dialogue "en_cours" épuisé (donc, s'il contenait des questions, toutes répondues) fait passer la quête "terminee" (en mémoire seulement, comme le reste de ce système — voir accepter/ refuser une offre de quête) : le joueur peut alors quitter la scène normalement, ces widgets n'étant jamais des obstacles. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 15:42:42 +02:00
williamandClaude Sonnet 5	e972acf9e6	Quêtes : bulle "❓ Question" à choix multiples, à côté de "+ Réplique" ... Nouveau type de ligne dans un dialogue de quête (voir db/quests/sanitize_quest_dialogues.py) : une bulle JAUNE, dans la même chaîne verticale que les répliques (même alignement, reliée par un trait) — header : nombre de choix (2 à 8) + récompense (score, montant en points) ; body : la question, ses choix et un bouton radio pour désigner la bonne réponse. Aucune limite au nombre de questions par colonne, comme pour une réplique. Les lignes de dialogue portent maintenant explicitement {"type": "dialogue", ...} (au lieu d'un objet sans type) pour distinguer les deux formes — migration de forme, tests mis à jour. Portée de ce commit : l'ÉDITEUR (créer/modifier une question). Le jeu lui-même (afficher la question au joueur, vérifier la réponse, attribuer la récompense) reste à construire — le widget "💬 Boîte de dialogue" ne sait aujourd'hui afficher qu'une réplique. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 14:48:14 +02:00
williamandClaude Sonnet 5	f2ed602459	Fix boutons Accepter/Refuser absents de l'écran d'offre de quête ... Le footer de la boîte de dialogue n'avait pas data-dialogue-role="footer" (seul son bouton interne "Suivant" l'avait, sous "next-btn") — le JS (forgeShowQuestOffer, dialogue-box-controller.js) le cherche par ce sélecteur pour y injecter les boutons Accepter/Refuser en fin de dialogue d'une quête "nouvelle". querySelector ne trouvait donc jamais le footer, et l'écran d'offre gardait silencieusement le bouton "Suivant" au lieu des deux nouveaux boutons — exactement le bug signalé. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 14:04:26 +02:00
williamandClaude Sonnet 5	521792fe00	Dialogues de quête : bulles illimitées, n'importe quel objet, timeline reliée ... - "qui parle" n'est plus réservé au personnage : N'IMPORTE QUEL objet de scène nommé (personnage, décor, fond — voir "ℹ️ Informations", screens/rendering/scene_object_names.py, ex-personnage_names.py) peut parler dans un dialogue. - Confirmé/documenté : aucune limite au nombre de répliques par colonne (bouton "+ Réplique" reste toujours disponible). - Bulle = header (menu déroulant du "qui parle") + body (le texte), centrée dans sa colonne à 70% de largeur, alignée verticalement et reliée à la suivante par un trait — remplace l'ancien alignement gauche/droite façon chat. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 11:54:06 +02:00
williamandClaude Sonnet 5	2347a70c45	Quêtes/collision : personnages nommés, dialogues qui parlent, boîte de dialogue en jeu ... - "ℹ️ Informations" (propriétés d'un personnage) : nom éditable, réutilisé comme "qui parle" dans l'éditeur de dialogue de quête (menu déroulant, plus "Joueur" toujours disponible) — remplace l'ancien choix binaire joueur/pnj. db.sanitize_quest_dialogues accepte maintenant un nom libre. - Nouveau menu "🖥️ Interface" (palette d'objets) avec le premier widget : "💬 Boîte de dialogue" (kind="dialogue_box", screens/rendering/ dialogue_box_style.py) — position/taille comme tout objet de scène, panneau "🎨 Style" dédié (police, taille, épaisseur, couleur du texte, couleur header/body/footer). Rendu en <div> à 3 zones, jamais soumis à la collision ni à l'éditeur de collision (exclu partout : obstacles, liste des règles, payload). Rendu côté jeu dans .sceneUI, une couche FIXE au viewport (jamais .sceneWorld, qui défile avec la caméra). - static/js/play/dialogue-box-controller.js : fait le lien moteur entre l'action "quete" de l'éditeur de collision et ce widget — affiche la réplique en cours du dialogue correspondant au STATUT ACTUEL de la quête (gameData.quests, désormais exposé game-wide par full_game_payload.py), avance au clic sur "Suivant" (header = qui parle, body = texte, footer = bouton), se masque à la dernière réplique. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 11:20:58 +02:00
williamandClaude Sonnet 5	78c1aba8a0	Éditeur de quêtes : onglet à côté de Collision, pas une page à part ... Corrige la mauvaise interprétation de la demande initiale : la page dédiée "🗺️ Quêtes" (nav du jeu) est retirée au profit d'un nouvel onglet "🗺️ Quêtes" DANS l'éditeur de scène 2D, juste à côté de "🧩 Collision" — même liste tabulaire que l'onglet "📣 Événements" (titre/objectif/récompense/statut/résultat par ligne, pas des cartes), un clic sur une ligne ouvrant la modale d'arbre de dialogue déjà construite. L'assistant "+ Action" de l'éditeur de collision ouvre toujours cette même modale pour "Déclencher une quête". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 20:46:27 +02:00
williamandClaude Sonnet 5	51427b5297	Éditeur de quêtes : titre/objectif/récompense/statut/résultat + dialogue à 3 colonnes ... Nouvel espace "🗺️ Quêtes" (game-wide, comme les événements personnalisés) : liste de cartes + "+ Nouvelle quête", chaque carte ouvrant une modale d'arbre de dialogue en bulles de théâtre ("speaker: texte"), une colonne par statut de quête (nouvelle/en cours/terminée) puisque le dialogue joué dépend de l'état de la quête au moment où le joueur parle au PNJ. Bulles alternées joueur/PNJ, couleur différente selon qui parle. L'action "Déclencher une quête" de l'éditeur de collision n'est plus un champ texte libre : elle ouvre directement CETTE MÊME modale (picker de quêtes existantes + création à la volée), et finalise la règle avec l'id numérique de la quête choisie — collision_rules.py migré en conséquence (quete_id devient un entier, comme evenement_id). Corrige aussi la miniature d'objet de la carte "🧩 Collision", 3× plus grande (120px) comme demandé. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 20:24:57 +02:00
williamandClaude Sonnet 5	ee270d0286	Éditeur de collision (jeu 2D) : règles trigger -> action par objet ... Nouvel onglet "🧩 Collision" dans l'éditeur de scène 2D : chaque objet (hors joueur et fond) peut porter des règles "à la collision" ou "dans un périmètre (px)" déclenchant une action (quête, attaque, événement, ou interagir - qui affiche "Appuie sur [touche]" puis exécute une sous-action à l'appui, un seul niveau d'imbrication). Backend (sanitisation, route de persistance, exposition dans full_game_payload) + assistant modal en cartes empilées côté client. Ajoute le moteur d'exécution runtime (collision-rules-controller.js) : détecte l'entrée en collision/périmètre avec le joueur à chaque tick, déclenche l'action une seule fois par entrée, pur JS client sans appel serveur (fonctionne à l'identique en ligne et en export SCORM). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 17:11:42 +02:00
williamandClaude Sonnet 5	a231bcf2fa	Aperçu de la boîte de collision dans l'éditeur + blocage physique au jeu ... Deux retours utilisateur sur la boîte de collision (ajoutée précédemment) : - Visible et réglable directement dans l'éditeur de scène : pour l'objet sélectionné, un contour pointillé (rectangle/cercle) se superpose sur le canevas — glisser son corps ajuste le décalage, glisser sa poignée (coin bas-droit) ajuste la taille, les deux se répercutent dans le panneau "🧱 Collision" et inversement (édition des champs -> aperçu à jour). static/js/scenes/scene-editor.js::onCollisionBoxMouseDown/ onCollisionBoxResizeMouseDown, mirror des poignées de position/taille déjà existantes pour l'objet lui-même. - Bloque désormais RÉELLEMENT le déplacement au clavier : avant chaque pas, personnage-controller.js teste si la position candidate chevaucherait la boîte de collision d'un autre objet solide (jamais un "fond", jamais un objet à collision désactivée) et annule ce pas — par AXE séparément, pour permettre de glisser le long d'un mur en diagonale plutôt qu'un blocage total au moindre contact. Réutilise forgeShapesOverlap (conditions.js, factorisé depuis elementsOverlap pour ne jamais dupliquer la règle "qu'est-ce qui se touche"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 15:48:08 +02:00
williamandClaude Sonnet 5	bc3feb5080	Panneau scène simplifié + boîte de collision + rôle joueur/ennemi/pnj ... Trois retours utilisateur sur l'éditeur de scène 2D : - Retire l'arborescence "Objets de cette scène" (un objet reste sélectionnable en cliquant dessus sur le canevas) et le bouton "+ Ajouter un décor" (le type "decor" reste supporté côté serveur, juste plus accessible depuis ce menu). - Chaque objet de scène a désormais une boîte de collision AUTOMATIQUE (= sa propre boîte, comportement inchangé pour une condition de collision déjà posée) réglable dans un nouveau panneau "🧱 Collision" : activée/désactivée, forme (rectangle/cercle), taille et décalage — utile pour un sprite très paddé (CraftPix) dont la silhouette réelle est bien plus petite que son canevas. elementsOverlap() (conditions.js) applique ces réglages en restant identique par défaut. - Nouveau champ "🏷️ Rôle" (Joueur/Ennemi/PNJ) sur un personnage : SEUL un personnage "Joueur" est désormais déplacé/animé au clavier et suivi par la caméra (personnage-controller.js) — "Ennemi"/"PNJ" restent immobiles tant qu'aucune logique de flow ne les pilote (déplacement ennemi automatique/apparition, dialogue de PNJ... hors scope de ce réglage, qui ne fait qu'identifier "quel objet est le joueur"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 15:30:34 +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	5891c82c62	Commandes personnage : détection de touche au clavier + touches d'animation supplémentaires ... Deux retours utilisateur sur le panneau "Commandes" (déplacement/ animation automatiques, voir précédent commit) : - Les champs de touche (haut/bas/gauche/droite/interagir) capturent maintenant la touche au clavier (clic puis appui — event.key, même valeur que heldKeys/triggers.js) au lieu d'être tapés à la main, source d'erreurs ("Espace" vs " ", "flèche haut" vs "ArrowUp"...). - Nouvelle section "Animations supplémentaires" : un nombre illimité de touches, chacune liée à UNE pose au choix parmi celles réellement disponibles pour ce personnage (sauter, attaquer, courir...) — pas seulement les 4 touches de déplacement + interagir. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 11:50:29 +02:00
williamandClaude Sonnet 5	74f7ca396f	Déplacement/animation automatiques d'un personnage (scène 2D) ... Simplification demandée pour l'éditeur de jeu RPG : un personnage posé sur une scène 2D se déplace et s'anime TOUT SEUL avec ZQSD (+ E pour interagir) dès qu'il est posé — plus besoin de poser le moindre nœud de flow pour un mouvement de base. Le panneau "🕹️ Commandes" du personnage permet de remapper les 4 touches de déplacement et la touche d'interaction, et de bloquer un axe (horizontal/vertical seulement). Entièrement client (static/js/play/personnage-controller.js), réutilise heldKeys (triggers.js) et applyObjectProperty/clampSceneObjectPosition/ runSpriteAnimation (actions.js) — aucune logique dupliquée, et ça fonctionne aussi bien en ligne que dans l'export Web/SCORM (aucune requête serveur). "walk"/"idle"/"interact" (poses déjà présentes pour tout personnage Forge/CraftPix) sont utilisées telles quelles ; une pose absente dégrade silencieusement (déplacement sans animation) plutôt que de planter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 11:26:37 +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	e08c53e042	Export Web/SCORM : corrige la résolution des champs "relation" hors ligne ... Bug signalé : une Donnée liée/un filtre référençant un champ "relation" affichait "{{champ}}" tel quel une fois exporté, alors qu'il fonctionnait en ligne. Deux causes cumulées : - full_game_payload.py lisait la colonne SQL "<champ>" au lieu de "<champ>_id" (seule vraie colonne d'un champ relation, voir _field_column dans filter_repeater_rows.py) en construisant gameData.data — une valeur toujours None. Invisible en ligne (les filtres y requêtent la base fraîche, jamais cette snapshot), mais fatal hors ligne (aucune base à requêter). - Une fois ce None corrigé, le port JS (forgeFieldColumn) relisait cette même valeur sous une clé slugifiée+suffixée ("boss_id") alors que gameData.data est déjà indexé par le nom D'AFFICHAGE du champ ("boss") — mismatch qui ne se voyait que sur un champ relation (le seul cas où slugify(nom)+suffixe diverge du nom original). Supprime ce port erroné, lit directement row[fieldName] partout. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 10:02:26 +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	9776fbc057	Score/Progression (Phase 1.1 de la feuille de route produit) ... Concept de premier ordre, distinct du système de variables globales — préalable identifié aux futurs exports SCORM/xAPI (note de cadrage .claude/Forge_Engine_Cadrage.pdf) : ces standards ont besoin d'un signal "score"/"terminé" propre, pas d'une convention sur une variable choisie par le créateur. - db/scoring/ (même patron que db/global_vars/) : table _scoring, un score numérique + un statut (non_commence/en_cours/termine/reussi/ echoue) par joueur (voir db.PLAYER_SHARED pour l'aperçu créateur). - Deux nouvelles actions de flux, dans les deux éditeurs (document et scène) : "Modifier le score" (réutilise le vocabulaire d'opérations déjà là pour "Modifier une variable" — incrémenter/définir/etc., aucune nouvelle colonne de nœud) et "Définir le statut de la partie". - Routes créateur (routes/flow/flow_node_run_score.py, flow_node_run_status.py) + miroirs publics par joueur (routes/public_play/) — même principe que flow_node_run_variable.py. - GET /game/<slug>/scoring/<player_id> : lecture interne, pas exposée au joueur, préparée pour être consommée par le futur export Web/SCORM. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:23:37 +02:00
williamandClaude Sonnet 5	76a50fa87a	Onboarding guidé systématique + tableau de bord simplifié ... Comportement SYSTÉMATIQUE à chaque création de jeu (admin compris), pas une formalité réservée à l'inscription : /onboarding (routes/onboarding/) devient le point d'entrée unique — 4 cartes retournables (survol = explication au dos), défilement horizontal animé vers le nom du jeu. Un admin y repasse à volonté (pas de project_slug dédié, jamais bloqué/ redirigé vers un projet précédent) ; un compte "user" n'en a plus qu'un créé d'office (routes/auth/register_2fa.py), guidé ici à la place. - db/games/game_type_catalog.py : catalogue des 4 types (Quiz/ Embranchement-escape game/RPG/Créer mon jeu de A à Z), _meta['onboarding_type'] décide du "kind" du premier écran créé et si le tableau de bord complet reste accessible. - routes/games/game_dashboard.py, templates/game_dashboard_simple.html : un type restreint (quiz/embranchement/rpg) voit désormais SON tableau de bord (même route que "custom"), rendu en version simplifiée — juste ses écrans en cartes avec un aperçu RÉEL du contenu (scène mise à l'échelle par container query CSS, adaptée à la largeur réelle de la carte). "+ Ajouter un écran" n'y propose pas de choix de type : imposé par le projet (routes/screens/screens_new.py), verrouillé aussi côté serveur. - core/auth_guard.py : plus de blocage de game_dashboard par type — la restriction se fait au rendu, pas à l'accès à la route. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:22:45 +02:00
williamandClaude Sonnet 5	0f23024882	Structure de dossiers par utilisateur : projects/<propriétaire>/<projet>/ ... Remplace le rangement plat projects/<slug>/ par une vraie arborescence par compte créateur, sans toucher aux routes existantes (aucune ne déclare de "/" dans son <slug> : le chemin composé "propriétaire_projet" reste un détail interne à db/, décodé par db/games/project_slug.py, seul fichier à modifier si la convention change un jour). - db/game_dir.py, create_game.py, delete_game.py, list_games.py, move_game.py : résolvent/construisent ce chemin composé. Bénéfice direct : deux comptes différents peuvent chacun avoir un projet nommé pareil sans collision (l'unicité ne se vérifie plus que par dossier propriétaire). move_game.py renomme désormais le dossier PROPRIÉTAIRE entier (changement d'email), prêt pour un futur multi-projet. - scripts/migrate_flat_project_slugs.py : migration des projets déjà créés sous l'ancien rangement plat (simulation par défaut, --apply pour exécuter). - routes/auth/profile.py, tests/conftest.py : suppression de compte/jeu de test via db.delete_game (nettoie aussi le dossier propriétaire devenu vide) plutôt qu'un shutil.rmtree direct du seul dossier projet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:22:03 +02:00
williamandClaude Sonnet 5	d5a59bdbd8	Fusion des deux moteurs : type d'écran par écran, plus par projet ... "document" (écrans %) et "jeu_2d" (scène pixels) devient une propriété PAR ÉCRAN (_screens.kind, migration automatique idempotente dans ensure_schema.py, source = l'ancien game_type au niveau projet) plutôt qu'un choix figé pour tout le jeu — un même projet peut désormais mélanger écrans classiques et scènes 2D librement. - routes/screens/screen_edit.py : dispatch vers l'éditeur de scène selon screen["kind"] (l'écran demandé), plus game["game_type"]. - screens/payload/full_game_payload.py, templates/play.html, static/js/play/screens.js : le rendu jouable (payload, markup, bascule du mode plein-écran #playFrame) décide écran par écran, y compris en cours de partie (changer d'écran ne recharge pas la page). - screens/screens_repo/create_screen.py : nouveau paramètre kind. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:21:13 +02:00
williamandClaude Sonnet 5	727af55a5e	Mouvement continu, limites de scène et priorité d'animation (jeu 2D) ... Répond au manque signalé par l'utilisateur : le déclencheur "clavier" existant (keydown) ne se déclenche qu'UNE FOIS par appui, insuffisant pour "maintenir une touche fait avancer/sauter le personnage en continu". - Deux nouveaux déclencheurs (screens/flow/constants.py, screens/scenes/flow_palette.py) : "Tant qu'une touche est maintenue" (se répète ~20 fois/seconde tant que la touche reste enfoncée, runScreenHeldKeyTriggers() dans triggers.js — même patron PAR ÉCRAN que "minuteur", arrêté au changement d'écran) et "Au relâchement d'une touche" (un seul déclenchement, scan global comme "clavier"). Combinés à l'action existante "Modifier un objet de scène → Déplacer de... px (relatif)", ça permet un vrai déplacement continu. - preventDefault() sur toute touche que le jeu écoute réellement (isGameKey(), triggers.js) : Espace/Flèches font défiler la page par défaut, et Espace réactive en plus le bouton actuellement focus (souvent le bouton "Jouer" qui garde le focus après l'ouverture de l'aperçu) — ça pouvait donner l'impression qu'une touche du jeu ne faisait rien. - Le personnage pouvait sortir du cadre de la scène en se déplaçant : applyObjectProperty()/clampSceneObjectPosition() (static/js/play/actions.js) bornent maintenant toute position (absolue ou relative) à [0, scene_width/height − la taille de l'objet]. - Vitesse d'animation par défaut adaptée au nombre d'images : la valeur fixe (8 i/s) venait d'un formulaire pensé pour les cycles Kenney (8 images) — un cycle CraftPix (walk=30 images) au même 8 i/s prenait ~4 secondes, "très lent". Le choix d'une animation dans la galerie calcule maintenant une vitesse par défaut proportionnelle à son nombre d'images (flow-editor.js, animation-timeline.js). - Priorité d'animation (bug : "je ne peux pas me déplacer et sauter") : un déclencheur de déplacement (touche maintenue) redemande "marche" à chaque tick, écrasant aussitôt une animation ponctuelle ("sauter") démarrée entre-temps avant qu'elle ait pu s'afficher. runSpriteAnimation() (actions.js) laisse maintenant une animation NON BOUCLÉE en cours (même à une seule frame, ex. une pose Kenney figée) aller jusqu'au bout avant qu'une autre demande puisse l'interrompre. Nouveaux tests : static/js/play/__tests__/{actions,triggers}.test.js (idempotence + priorité d'animation, bornage aux limites de la scène, isGameKey) ; tests/test_scene_edit_view.py (persistance d'un nœud "touche_maintenue"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 21:53:49 +02:00
williamandClaude Sonnet 5	449c36fd5d	Bibliothèque de sprites animaux CraftPix (1/3) : catalogue, galerie, accès admin ... Premier commit d'une fonctionnalité découpée en plusieurs lots (voir le plan "Bibliothèque de sprites animaux CraftPix") : intègre 14 familles d'animaux (15 variantes de couleur chacune) comme personnages Forge sélectionnables, à côté des 6 Kenney existants — réservé au rôle admin, licence CraftPix oblige (interdiction contractuelle de rendre ces sprites utilisables par un compte "user" via l'application). - screens/labels/animal_sprite_library.py (nouveau) : charge un manifest JSON généré une fois (voir scripts/generate_animal_sprite_manifest.py, commit suivant) et construit ADMIN_SPRITE_LIBRARY, dans le même format que l'existant PUBLIC_SPRITE_LIBRARY (screens/labels/sprite_library.py, ex-SPRITE_LIBRARY, renommé pour distinguer les deux). screens.SPRITE_LIBRARY reste le catalogue FUSIONNÉ (utilisé par resolve_personnage_animations pour la résolution runtime, sans filtrage par rôle — voir le constat d'exploration : le payload de jeu et /jouer/<slug> ne vérifient déjà aucun rôle nulle part). - screens/labels/sprite_gallery.py (nouveau) : sprite_gallery_families() groupe la galerie par famille — un animal n'apparaît qu'une fois (sa variante "de base"), ses 15 couleurs se choisissent depuis le panneau de propriétés (render_variant_gallery, templates/screen_edit.html), répondant à la suggestion de l'utilisateur plutôt que d'encombrer la galerie d'ajout de 210 tuiles quasi identiques. - routes/screens/screen_edit.py, routes/scenes/scene_edit_view.py : la galerie passée au template est filtrée par rôle (PUBLIC_SPRITE_LIBRARY pour un compte "user", SPRITE_LIBRARY complet pour un admin) — même idiome que core/auth_guard.py. - core/sprite_gate.py (nouveau) + 4 routes d'écriture (element_add, element_set_personnage_data, scene_object_add, scene_object_personnage_data) : ferme la brèche d'un POST direct qui contournerait la galerie filtrée (403 si un compte non-admin tente d'assigner un personnage animal). - tests/conftest.py : nouvelles fixtures user_client/user_game (compte "user" non-admin avec un projet assigné) pour tester le filtrage par rôle de bout en bout. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 21:49:05 +02:00
williamandClaude Sonnet 5	43abfc9b93	Fix éditeur de scène 2D : décalage visuel des objets + crash Timeline ... Deux bugs remontés en test manuel sur l'éditeur de scène (Phase A, commit f0070fa) : 1. Décalage visuel à l'ajout d'un objet de scène (personnage/décor) : render_scene_object.py positionne son <img> en absolu (left/top/ width/height en px), pensé pour être un enfant DIRECT de .playScreen.playScene en mode jouable. Dans scene_edit.html, la même balise est nichée dans .canvasElementInner, lui-même déjà positionné par .canvasElement — l'image se repositionnait donc EN PLUS depuis #canvas (son ancêtre positionné le plus proche), en double du décalage déjà appliqué par le conteneur. Corrigé par une règle CSS scoped à l'éditeur (.canvasElementInner > img) qui neutralise le positionnement propre de l'image et la fait simplement remplir son conteneur. 2. "FOREIGN KEY constraint failed" à l'ajout d'un clip de Timeline sur un objet de scène : _animation_clips.element_id portait une VRAIE contrainte FK vers _screen_elements depuis la création de la table. animation-timeline.js est réutilisé TEL QUEL entre les deux éditeurs (voir le plan "Fondations d'une plateforme multi-éditeurs") et n'opère aucune distinction — pour un jeu jeu_2d, element_id désigne en réalité un id de _scene_objects, absent de _screen_elements, d'où l'échec de l'INSERT sous PRAGMA foreign_keys=ON. ensure_animation_schema reconstruit maintenant la table (une fois, migration automatique à la volée comme le reste du schéma) sans cette contrainte FK — même patron que trigger_element_id/cond_element_a dans ensure_flow_schema.py. Comme la suppression en cascade reposait jusqu'ici sur cette FK, un nettoyage manuel des clips a été ajouté à la suppression d'un élément (delete_element.py) et d'un objet de scène (delete_scene_object.py). Nouveaux tests (tests/test_scene_edit_view.py, +4 cas) : ajout d'un clip de Timeline sur un objet de scène via la route, nettoyage des clips à la suppression d'un objet de scène et d'un élément DOM. Suite complète : 312 tests passent (aucune régression). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 10:22:58 +02:00
williamandClaude Sonnet 5	f0070faced	Phase A (2/2) : éditeur de scène 2D — route, template, runtime jouable ... Deuxième et dernier commit de la Phase A du plan "Fondations d'une plateforme multi-éditeurs" (le premier, efa7d1d, posait le schéma et le CRUD des objets de scène). Ce commit branche l'éditeur et le mode jouable sur ces fondations, en réutilisant TEL QUEL tout ce qui est déjà générique côté moteur de logique. Éditeur (routes/scenes/, templates/scene_edit.html, static/js/scenes/scene-editor.js) : - routes/screens/screen_edit.py délègue à render_scene_edit() dès que game_type == "jeu_2d" — même endpoint Flask "screen_edit" pour les deux éditeurs, aucune route dupliquée. - Nouveau template scene_edit.html : canevas à taille FIXE en pixels (scene_width/scene_height) avec glisser-déposer/redimensionnement en pixels (scene-editor.js, mirror pixel de tree-panels.js), galerie personnages/décors. Les onglets "Blocs de logique"/"Timeline d'animation"/"Événements" réutilisent tels quels flow-editor.js, tabs-and-blocks.js et animation-timeline.js. - flow-editor.js : nouveau flag FLOW_TARGETS_OBJECTS (false par défaut, true dans scene_edit.html) qui fait écrire submitNodeForm() vers trigger_object_id/target_object_id au lieu de trigger_element_id/ target_element_id, plus une branche "Modifier un objet de scène" (position px, visibilité, orientation) et des gardes null partout (le DOM de scene_edit.html n'a pas tous les champs de l'éditeur document). - blocks_view.py étend l'ensemble d'ids d'éléments concernés par un bloc pour inclure aussi trigger_object_id/target_object_id. Runtime jouable (templates/play.html, static/js/play/actions.js, screens/payload/full_game_payload.py) : - full_game_payload() construit les écrans d'un jeu jeu_2d à partir de _scene_objects (render_scene_object) au lieu de _screen_elements, et récupère les animations de personnage sur les objets de scène. - play.html : #playFrame occupe tout le viewport pour une scène jeu_2d (pas de ratio fluide) ; la scène se centre via .playScreen.playScene, qui réutilise tel quel showScreen() (déjà indexé par id d'écran, pas par forme DOM) — aucun fichier "scenes.js" séparé n'a été nécessaire. - actions.js : jouer_animation_sprite retombe sur target_object_id si target_element_id est absent ; nouvelle action modifier_objet_scene avec applyObjectProperty() (positions en px, contrairement aux % de applyElementProperty()). Un bug de gabarit a été découvert et corrigé pendant la vérification : le commentaire CSS de play.html contenait littéralement "{% for %}" comme texte français, que Jinja interprétait comme une vraie balise et faisait planter le rendu — reformulé. render_scene_object() n'était en outre jamais appelé par la vue de l'éditeur (les objets de scène s'affichaient sans image) — scene_edit_view.py attache maintenant rendered_html à chaque objet avant de les passer au template. Nouveaux tests (tests/test_scene_edit_view.py, 10 cas) : dispatch document vs jeu_2d, rendu d'un personnage sélectionné, CRUD géométrie/ suppression d'objet, nœuds de flow ciblant un objet de scène (action et condition de collision), payload et page /play pour un jeu jeu_2d, présence des nouveaux helpers JS. Suite complète : 309 tests passent (299 existants + 10 nouveaux, aucune régression). node --check et node --test (13 tests JS) passent également. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 10:05:40 +02:00
williamandClaude Sonnet 5	efa7d1d9b0	Fondations multi-éditeurs (1/3) : game_type + schéma/CRUD des objets de scène ... Première brique du plan "Fondations d'une plateforme multi-éditeurs" — l'utilisateur veut un éditeur dédié aux jeux 2D/serious games (scène à coordonnées pixel fixes, objets en couches, collision, personnages animés), distinct de l'éditeur générique actuel, sans dupliquer ce qui peut être partagé (comptes, objets de données, moteur de logique de flow, hébergement/publication). - db/games/get_game_type.py (nouveau) : "document" (défaut, éditeur actuel) ou "jeu_2d" (nouveau), stocké dans _meta comme is_public_played — aucune migration pour les jeux déjà créés (retombent sur "document"). Choisi obligatoirement à la création (templates/index.html), jamais modifiable ensuite. - screens/scenes/ (nouveau sous-module) : table _scene_objects (une scène = des objets en pixels fixes, pas les % fluides de _screen_elements — indispensable pour la collision/l'animation), CRUD complet, rendu HTML. kind="personnage" réutilise TELLE QUELLE la structure _personnage_data et les fonctions resolve_personnage_* déjà écrites pour le widget "personnage" de l'éditeur document (Phase 8) — même bibliothèque Forge, même moteur d'animation, juste une autre table de stockage. - screens/flow/ensure_flow_schema.py : += trigger_object_id/ target_object_id (ALTER TABLE sans contrainte FK, même patron que cond_element_a) — le moteur de logique de flow (_flow_nodes/_flow_edges, flow-engine.js) reste EXACTEMENT le même pour les deux éditeurs, seule la palette de nœuds change (screens/scenes/flow_palette.py, nouveau : sous-ensemble direct des triggers/actions existants, déjà génériques). - screens/screens_repo/ensure_schema.py : += scene_width/scene_height sur _screens (taille de scène fixe en pixels, sans effet sur un écran "document"). Reste à faire (prochains commits) : route + template de l'éditeur de scène, puis le rendu en mode jouable. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 09:42:38 +02:00
williamandClaude Sonnet 5	70c2b8df05	Corrige : une animation déjà posée dans la logique ignorait le changement de personnage ... Bug réel identifié grâce à la vidéo fournie + inspection directe de la base de jeu de test : quand un nœud de flow "Jouer une animation" (ou un clip de Timeline "sprite") était configuré pour un personnage, ses frames étaient résolues et FIGÉES dans data_value/custom_keyframes au moment de la configuration — changer ensuite le personnage Forge de l'élément (galerie des propriétés) n'avait donc aucun effet sur les animations déjà posées, qui continuaient à jouer indéfiniment les frames de l'ANCIEN personnage. Le nœud/clip ne stocke désormais que le NOM de l'animation ({"animation": "walk", "fps": 8, "loop": true}) — ses frames sont résolues à l'EXÉCUTION, à partir du personnage ACTUELLEMENT assigné à l'élément cible : - screens/payload/full_game_payload.py expose un nouveau gameData.personnage_animations (élément → animations), reconstruit à chaque chargement de la page de jeu depuis _personnage_data — donc toujours à jour, y compris après un changement de personnage. - static/js/play/actions.js (resolveSpriteFrames) et static/js/play/screens.js (applyAnimationClip) résolvent le nom d'animation en frames à ce moment précis, plutôt que d'utiliser des frames figées — repli sur l'ancien format {frames,...} pour les nœuds/clips déjà créés avant ce correctif. - Éditeur (flow-editor.js/animation-timeline.js) : simplifié en conséquence — plus besoin de deviner rétroactivement quelle animation correspond à une liste de frames stockées (l'ancien hack de comparaison), le nom est maintenant stocké directement. Nouveau test de régression (test_swapping_forge_character_updates_ already_configured_flow_action) qui reproduit exactement le scénario filmé : configure l'action pour "male-adventurer", change le personnage en "zombie", vérifie que gameData.personnage_animations reflète bien zombie sans avoir à retoucher le nœud de flow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 08:56:20 +02:00