3 Commits

Include renames

Author	SHA1	Message	Date
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	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	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