7 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	ecd483f352	Implemente un systeme de pages pour le support de formation ... Retour utilisateur : "il faut implementer un systeme de page". Un support est desormais compose de PLUSIEURS pages (_document_pages), chacune un document independant affiche seul sur le canevas -- chaque element appartient a exactement une page via page_id (document_engine/ elements/*, routes/document/document_element_add.py/document_render.py revalident desormais un page_id explicite). Migration automatique et silencieuse pour les supports crees avant cette fonctionnalite (db/supports/ensure_document_pages_schema.py, meme convention que les ensure_X_schema.py existants) : leurs elements deviennent tous les enfants d'une "Page 1" creee a la volee, aucune perte de contenu. Nouveau paquet document_engine/pages/ (add/list/get/rename/move/delete) et 4 routes dediees (routes/document/document_page_*.py) -- supprimer la DERNIERE page restante est refuse (garde-fou pose a la route, meme decoupage que routes/game/screens/screen_delete.py cote jeu, jamais dans la fonction bas niveau). Cote editeur : une bande d'ONGLETS au-dessus du canevas (jamais un panneau lateral, choix explicite de l'utilisateur) -- clic pour changer de page, double-clic pour renommer (contenteditable), glisser pour reordonner, "+" pour ajouter, "x" pour supprimer. Changer de page vide la pile Annuler/Retablir (une commande empilee sur une autre page n'a plus de sens). Mode Apercu : navigation Page precedente/suivante avec indicateur "Page X / N" (choix explicite : page par page, pas de defilement continu), jamais affichee s'il n'y a qu'une seule page. Verifie : suite pytest complete (702 tests, dont 14 nouveaux pour les routes de pages), simulation DOM reelle (jsdom, 25 assertions couvrant tout le cycle de vie cote client -- creation/bascule/renommage/ reordonnancement/suppression de page, portee correcte des elements par page, pile Annuler/Retablir videe au changement de page, pilule de navigation en Apercu), et un test de fumee HTTP reel contre le serveur de dev en marche (creation/ajout d'element/rendu/renommage/suppression d'une page, refus de supprimer la derniere page, page inconnue -> 404). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-21 13:24:23 +02:00
williamandClaude Sonnet 5	7e504b7865	Sanitize les attributs en LECTURE aussi, pas seulement a l'ecriture ... Bug reel constate le 21/09/2026 : un element Scenario cree avant la refonte en arbre de decision (ancien schema plat "situation"/"choices"/ "correct_index") faisait planter silencieusement le panneau Proprietes cote client des la selection - scenario.nodes etait inexistant sur l'ancienne forme, aucune erreur visible, juste "il ne se passe rien". Cause : document_edit.py et document_render.py renvoyaient les attributs BRUTS de la base au client, jamais revalides - contrairement a la route d'ecriture qui, elle, sanitize deja avant de persister. Ajoute document_engine.sanitize_element_attributes(kind, attributes), point d'entree unique de dispatch kind -> sanitize_X_config, utilise desormais a la fois en ecriture (document_element_update.py, qui reutilise ce nouveau dispatch au lieu de son if/elif duplique) ET en lecture (document_edit.py/document_render.py). Elimine toute la classe de bug "schema devenu obsolete apres une evolution du modele de donnees d'un mini-jeu, donnee jamais retouchee depuis" - present et futur, pas seulement pour Scenario. Migre les donnees reelles deja affectees (support de test, element 46) vers le nouveau schema en arbre, en preservant integralement le contenu deja redige par l'utilisateur (situation + 3 choix/consequences du scenario "chat sur la route"). Ajoute un test de non-regression qui ecrit delibirement l'ancien schema en base (en contournant le sanitize de la route d'ecriture, pour simuler une donnee reellement ancienne jamais nettoyee) puis verifie que /edit et /render renvoient une structure saine au client. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-21 08:07:06 +02:00
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	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