Dernier lot de la fonctionnalité (voir 449c36fd et a27d08c6) : les
sprites eux-mêmes, générés une fois par scripts/generate_animal_sprite_manifest.py
depuis les packs sources CraftPix (assets/characters/, non committés —
licence perso, voir .gitignore — gardés en local pour régénérer si besoin).
- static/characters/animals/manifest.json : catalogue déclaratif (14
familles, 15 variantes de couleur chacune, poses/animations
disponibles par famille) lu par screens/labels/animal_sprite_library.py
au démarrage pour construire ADMIN_SPRITE_LIBRARY.
- static/characters/animals/<famille>/<variante>/ : les frames PNG de
chaque pose, réencodées à une taille raisonnable pour le web (les
canevas sources CraftPix sont surdimensionnés, ~788×504 px).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Met en place les fondations du template Bulma décrit dans
regles/FORGE_ENGINE_TEMPLATE_BULMA.md : palette orange/ambre Forge
(--accent:#ff5f2e/--accent-2:#ffb020), typographie, rayons — appliqués
en recompilant Bulma lui-même plutôt qu'en le surchargeant après coup en
CSS, pour recolorer automatiquement ses composants internes (tags,
notifications, dropdowns...) sans avoir à les surcharger un par un.
- Bulma 0.9.4 vendoré en local (styles/bulma/, source Sass classique
$variable + @import) — PAS 1.0.2 (la version jusqu'ici en CDN) : 1.0.2
utilise le nouveau système de modules @use/@forward, que libsass (choisi
pour rester 100% Python, sans Node/npm) ne sait pas compiler (testé :
il ignore silencieusement le @use au lieu de le traiter). 0.9.4 est la
dernière version compatible avec libsass et couvre à l'identique tous
les composants utilisés ici (boutons, tableaux, onglets, modales,
formulaires, navbar).
- requirements.txt : +libsass (pip pur, aucun binaire/Node.js).
- styles/forge-theme.scss (nouveau, point d'entrée) : variables Sass
Bulma ($primary, $radius...) posées avant l'import, tokens Forge exposés
en :root (--forge-bg, --accent, --gradient, --status-*...) avec des
alias vers les noms de variables déjà utilisés par tout le CSS custom
existant (--bg/--panel/--border/--text/--danger...) — pas besoin de
renommer les ~600 lignes de règles déjà écrites, seules leurs VALEURS
changent.
- styles/forge-custom.scss : ancien static/style.css, structurellement
inchangé — seuls les hex/rgba en dur qui échappaient aux variables
(ancien accent bleu #5b8cff, danger #e2685f, couleurs de types de
nœuds du graphe de logique, fond du QR code recovery...) sont
remplacés par les tokens de la charte.
- build_css.py (nouveau) : compile styles/forge-theme.scss en
static/style.css via libsass — un seul fichier, un seul <link>
inchangé dans les templates, à relancer manuellement après toute
modification sous styles/.
- base.html/play.html : suppression du <link> CDN Bulma (auto-hébergé
désormais), ajout d'un favicon (absent jusqu'ici) et du vrai logo Forge
dans la navbar (assets/*.svg copiés dans static/branding/, seul dossier
réellement servi par Flask).
197 tests toujours verts (aucune assertion sur des valeurs CSS).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Première des deux grandes fonctionnalités demandées (authentification
d'abord, export HTML/CSS/JS autonome ensuite) :
- Inscription (nom, prénom, email UNIQUE, mot de passe) avec schéma
visuel du mot de passe (jauge + liste de critères qui passent au vert
en direct — auth/password_strength.py, mêmes règles vérifiées côté
serveur qu'affichées côté client).
- Double authentification (TOTP, compatible Google Authenticator/Authy)
OBLIGATOIRE dès l'inscription : QR code (SVG, sans dépendance Pillow)
à scanner puis code à confirmer avant que le compte soit utilisable —
voir auth/create_user.py (totp_confirmed) et routes/auth/register_2fa.py.
- Connexion en 2 temps (mot de passe puis code TOTP), déconnexion.
- Isolation par utilisateur : un compte "user" est limité à un SEUL
projet, dont le dossier est nommé d'après son adresse email (slugifiée)
et créé automatiquement dès la 2FA confirmée — aucune page de gestion
multi-jeux pour lui (redirigé directement vers son propre tableau de
bord). Le rôle "admin" reste illimité, comme le moteur l'a toujours été
(le TOUT PREMIER compte jamais créé sur une base de comptes vide devient
automatiquement admin — voir auth/is_first_user.py — pas de mot de
passe par défaut à faire circuler : s'inscrire en premier suffit).
Un compte "user" ne peut pas non plus supprimer son unique projet
(aucune façon d'en recréer un ensuite).
- Garde d'accès globale (core/auth_guard.py, un seul before_request) :
toute page exige une connexion, sans avoir touché individuellement aux
~80 routes déjà existantes du moteur.
tests/conftest.py isole complètement les tests de la vraie base de
comptes (FORGE_USERS_DB_PATH/FORGE_SECRET_KEY_PATH vers un dossier
temporaire propre à la session de tests) et authentifie automatiquement
la fixture `client` partagée en tant que compte admin de test — les 155
tests déjà existants continuent de passer SANS AUCUNE modification de
leur côté, exactement comme avant l'authentification. 10 nouveaux tests
dédiés (tests/test_auth.py) : inscription/mots de passe/2FA/connexion/
isolation par projet/blocage de suppression, vérifiés en conditions
réelles (vrai client de test Flask, vraie base SQLite, vrais codes TOTP
calculés avec pyotp). 165 tests au total, tous au vert.
Nouvelles dépendances : pyotp, qrcode (requirements.txt).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deux fonctionnalités demandées, développées et corrigées dans cet
échange :
1. "Donnée liée" (Texte/Titre) : le réglage à 2 filtres fixes (toujours
combinés en ET) devient une liste de conditions ILLIMITÉE, avec un
choix ET/OU pour les combiner (screens/widgets/controls/c_clause_list.py,
screens/clause_list_codec.py). Rétrocompatible avec les anciens
éléments (_data_filtre_champ/_data_filtre2_champ), convertis à la
volée à la lecture, sans migration. Après un premier essai à la
présentation trop compacte et technique (retour utilisateur : "pas de
champ technique, pas de notation bizarre {{ }}"), la présentation
finale reprend EXACTEMENT l'ancien style (labels "Champ"/"...est"/
"...cette valeur", même sélecteur de valeur fixe/dynamique/variable
déjà existant, jamais la syntaxe brute), simplement répétée par
condition (templates/partials/clause_row.html), avec un bouton
"+ Ajouter une condition" bien visible et une liste scrollable
(static/style.css, .clauseListWrap). Le même moteur (filter_repeater_
rows.py généralisé) profite aussi au Répéteur de données en interne.
2. Nœud Condition de la Logique de la scène : peut désormais tester une
VARIABLE GLOBALE en plus d'un champ d'objet (cond_source/cond_variable/
cond_variable_chemin — screens/flow/ensure_flow_schema.py), sur la
clause principale ET chaque clause supplémentaire (ET/OU). Évalué côté
CLIENT (templates/play.html, evaluateConditionClause), contre un
nouveau gameData.variables exposé par full_game_payload.py — tenu à
jour par refreshRuntimeData() après toute action qui modifie une
variable, sans changement supplémentaire nécessaire. Le panneau de
condition reste utilisable même sans aucun objet défini dans le jeu
(avant, il disparaissait entièrement).
Vérifié : 153 tests pytest (nouveaux : test_data_binding_clause_list.py,
test_condition_variable.py) + logique JS d'évaluation des conditions
vérifiée isolément avec Node (variable scalaire, objet avec chemin
chaîné, tableau par index, variable introuvable, booléen, rétrocompatibilité
legacy) + rendu des deux pages (éditeur/jeu) vérifié sur le vrai projet
"test" en plus des jeux de test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
