Dev #5
Assignees
w-vandal (Vandal William)
Clear assignees
w-vandal (Vandal William)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Forge-Store/Forge-Engine#5
Reference in New Issue
Block a user
- index.html ("Mes jeux") : le <h1> nu est remplacé par l'en-tête de page compact du §5 (.dashPanelHeader, déjà utilisé ailleurs pour ce patron) — titre + badge du nombre de jeux (.forge-badge) sur une seule ligne. Pas de second CTA : le formulaire de création reste dans sa colonne dédiée, un bouton de plus ferait doublon. - game_dashboard.html : ajout du même en-tête, absent jusqu'ici (la page démarrait directement sur la barre d'onglets) — nom du jeu + chemin du dossier, pour savoir sur quel jeu on se trouve sans avoir à regarder l'URL. - styles/forge-custom.scss : .content-objectEdit > h1/.hint/form/ .warningBanner (règle qui fige la hauteur des enfants directs non extensibles dans la mise en page flex de l'accueil) étendue à .dashPanelHeader, qui remplace maintenant le <h1> direct. - profile.html : déjà conforme (rayons de boîte/bouton, danger tokenisé) depuis le passage global des tokens en Phase A — aucun changement supplémentaire nécessaire. 197 tests toujours verts ; vérification ciblée (fixture jetable, supprimée ensuite) confirmant l'en-tête et le JS du tableau de bord. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Fonctionnalité mise de côté depuis le tout début de ce chantier ("jouable en toute autonomie"). Nouveau bouton "📦 Publier" dans la barre de navigation du jeu (après "▶️ Jouer") : construit un zip contenant un Python portable + Flask embarqués, une copie figée du moteur de rendu (screens/db/filters + le strict minimum de core/) et des données du jeu (game.db + uploads/), lancé en double-cliquant sur run.bat — aucune installation requise, 100% hors-ligne (voir le commit précédent qui a auto-hébergé polices/animate.css, dernière dépendance CDN de l'app). Exploration préalable a confirmé que screens/ et db/ sont déjà totalement découplés de auth/routes/core (seul lien : un try/except optionnel dans db/connection.py) et que templates/play.html n'appelle que 4 endpoints "purs" (aucune logique d'auth mélangée dedans) — ce qui a permis de réutiliser ces routes quasiment telles quelles dans un mini-serveur Flask séparé plutôt que de les réécrire. - db/constants.py : PROJECTS_DIR devient surchargeable via FORGE_PROJECTS_DIR (même schéma que auth/connection.py) — le serveur joueur autonome pointe ainsi vers son propre dossier "projects/" embarqué. - publish/vendor_runtime.py : télécharge (une fois par poste, mis en cache sous data/publish_vendor/ — déjà ignoré par git) le ZIP Python embeddable officiel (python.org) et vendore Flask via pip --target ; fonctions séparées et mockables pour ne jamais déclencher de vrai téléchargement dans les tests. - publish/player_app_template.py : mini-Flask autonome, réutilise core/flask_app.py et core/jinja_filters.py tels quels (SLUG figé en dur au moment de la publication, csrf_token() factice puisqu'aucune session n'existe dans cet export). sys.path doit être complété manuellement au démarrage : le python311._pth de la distribution embeddable ne référence que le dossier de python.exe lui-même, jamais celui du script lancé. - publish/build_package.py : assemble le zip dans un dossier temporaire (jamais les vrais fichiers de l'app), copié/nettoyé après envoi de la réponse HTTP (routes/publish/publish_game.py, déjà protégée par la garde d'accès existante — aucune vérification supplémentaire). - templates/base.html : bouton + modale (avancement séquentiel, jamais de suivi serveur réel — le build est rapide) qui déclenche le téléchargement du zip via un blob, comme la modale des codes de récupération déjà en place (posée À L'INTÉRIEUR de <main> pour que pjax.js la remplace et rejoue son script à chaque navigation). Vérifié pour de vrai (pas seulement via les tests) : zip construit, extrait, lancé avec le Python embeddable réel — /, /game/test/play, /game/test/runtime-payload et /static/style.css répondent tous 200. tests/test_publish.py (nouveau, vendor mocké) : structure du zip, SLUG correctement substitué, route protégée par la même isolation par projet que le reste de l'app. 203 tests au total. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Signalé par l'utilisateur : quand "Modifier un élément" utilise la case "Utiliser l'élément transmis par l'événement en cours" (target_element_from_event), et que cet élément vit à l'intérieur d'un Répéteur, la résolution ne ciblait jamais que le PREMIER élément correspondant trouvé dans toute la page — jamais forcément la bonne ligne. Vérifié directement sur un rendu réel : chaque ligne d'un Répéteur rejoue le MÊME modèle (voir render_repeater.py), donc le MÊME data-element-id se répète à l'identique sur CHAQUE .repeaterItem — seul data-row-id (posé sur l'enveloppe .repeaterItem) distingue réellement une ligne d'une autre. Un simple document.querySelector('[data-element-id]') global tombe donc toujours sur la première ligne rencontrée dans le DOM, sans rapport avec la ligne réellement transmise par l'événement (window.lastEventParams.row_id). Corrigé : quand l'événement transmet aussi une ligne, la recherche est désormais scopée à l'intérieur du .repeaterItem[data-row-id=...] correspondant avant d'y chercher l'élément — sinon (élément fixe, ou événement sans paramètre de ligne), le comportement global d'avant reste inchangé. 210 tests toujours verts (ce correctif est purement côté client, jamais couvert par les tests automatisés — vérifié manuellement via un rendu réel confirmant la structure .repeaterItem/data-row-id décrite ci-dessus). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Diagnostic effectué directement sur projects/test/game.db de l'utilisateur (suite à son signalement "je ne parviens pas à mettre fin à la surbrillance") : deux nœuds Déclencheur distincts ("Au clic", id=4 et id=42) référençaient le même trigger_element_id=65. La fonction findTriggerNode() utilisait Array.find(), qui ne retourne que la PREMIÈRE correspondance — le second nœud (celui qui devait couper la surbrillance) n'était donc jamais exécuté, silencieusement, quel que soit le graphe construit dans l'éditeur. Ce n'est pas un bug lié aux événements personnalisés ni aux conditions par variable (deux pistes explorées avant ce diagnostic) : c'est une limitation générale du moteur, qui n'a jamais géré plus d'un déclencheur "Au clic"/"Au survol"/"À la fin du survol" par élément. Renomme findTriggerNode() en findTriggerNodes() (pluriel) : retourne désormais TOUS les nœuds correspondants (élément + type d'événement), et bindClicks()/bindHoverTriggers() exécutent chaque flow trouvé au lieu de s'arrêter au premier. Vérifié : 208 tests passent, syntaxe JS validée (script de play.html rendu via le client de test puis node --check). Comme pour le reste du graphe de logique côté client, ce changement n'est pas couvert par les tests automatisés (pas de harnais navigateur/DOM) — vérification manuelle recommandée sur le scénario réel de l'utilisateur. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>