- 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>
"no tests ran ... file or directory not found: tests/" : .dockerignore
(à la racine, pensé pour l'image de PROD buildée par build-and-push)
exclut tests/ du contexte de build — COPY . . dans le Dockerfile jetable
de test-python ne l'incluait donc jamais, quel que soit le Dockerfile
utilisé (.dockerignore s'applique au contexte entier envoyé au démon,
pas à un -f en particulier).
Renomme .dockerignore avant ce build précis (le checkout de ce job est
jetable, propre à lui, jamais repoussé vers le dépôt réel) — test-js n'a
pas besoin du même correctif, il ne copie que static/js/play/, jamais
exclu.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"container: image: python:3.13-slim" (tentative précédente) casse
actions/checkout@v4 : c'est une action Node.js, qui a besoin de Node
dans l'environnement d'exécution des steps — "container:" remplace CET
environnement en entier par l'image donnée, qui n'a pas Node
("command not found", nektos/act#107), pas seulement l'environnement
des commandes qu'on y lance soi-même.
Nouvelle approche : le job tourne sur le runner par défaut (checkout
fonctionne normalement, Node y est déjà disponible), et les tests
s'exécutent PENDANT un `docker build` (Dockerfile jetable passé par
stdin, jamais commité, un par langage) plutôt que dans un conteneur
lancé après coup — le transfert du contexte de build vers le démon
Docker passe par le protocole API (tar), jamais par un chemin hôte à
monter, donc insensible au problème Docker-outside-of-Docker qui avait
fait échouer le tout premier essai (docker run -v "$PWD":/app).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le job "test" échouait ("Could not open requirements file:
requirements-dev.txt") : docker run -v "$PWD":/app lancé DEPUIS un
runner qui exécute déjà le job dans son propre conteneur (Docker-
outside-of-Docker) ne peut pas monter "$PWD" — ce chemin vit dans le
conteneur du job, pas sur l'hôte où tourne le vrai démon Docker sollicité
par ce docker run imbriqué ; /app se retrouvait donc vide dans le
conteneur imbriqué.
Corrigé en utilisant la clé "container" (standard Gitea/GitHub Actions) :
le job tourne DIRECTEMENT dans l'image voulue, le checkout dépose les
fichiers dans son propre système de fichiers, aucun montage de volume à
faire. Un seul job "test" ne peut avoir qu'UNE image : scindé en
test-python (python:3.13-slim) et test-js (node:20-slim, pour les tests
node:test de static/js/play/__tests__/), build-and-push dépend des deux.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1. Duplication éliminée avant que la Phase 2 (hasard/opérations
mathématiques) n'en ajoute 6 de plus aux DEUX fichiers : la chaîne
d'opérations quasi identique entre screens/data_actions/
apply_data_action.py (champ d'objet) et apply_variable_action.py
(variable globale) est factorisée dans un nouveau
compute_operation.py::compute_new_value(operation, current, raw_value,
is_decimal), réutilisé par les deux. Nouveau tests/test_compute_operation.py
verrouille le comportement des 7 opérations existantes (dont les cas
limites : valeur invalide, type décimal vs entier, opération inconnue)
avant d'en ajouter d'autres.
2. .gitea/workflows/deploy.yml déployait en prod à chaque push sur main
sans jamais exécuter la suite de tests — rien ne bloquait
techniquement un commit cassé. Nouveau job "test" (pytest + node:test
sur la logique pure de static/js/play/, via des conteneurs officiels
plutôt que des actions du marketplace, cohérent avec le choix déjà
fait dans ce fichier) tourne sur CHAQUE push (main ET dev, utile pour
ce dépôt qui travaille sur dev) ; "build-and-push"/"deploy" gagnent un
"needs: test" et restent réservés à main (filtre sur gitea.ref) — un
push sur dev ne redéploie jamais la prod, seulement les tests.
Vérifié : 223 tests passent (8 nouveaux), YAML validé.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
