Forge-Engine

185 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	a445b72a6e	Corrige "Ouvrir"/"Modifier" inertes dans l'onglet Blocs de logique Deux bugs distincts, signalés par capture d'écran (bouton "Ouvrir" sans effet, ligne d'édition affichée en permanence au lieu d'être cachée) : 1. onclick="openLogicBlockPanel({{ b.id }}, {{ b.name\|tojson }})" cassait l'attribut HTML : tojson produit des guillemets DOUBLES (valides en JSON), qui terminaient prématurément l'attribut onclick="..." lui-même entre guillemets doubles — le gestionnaire de clic généré était donc tronqué et invalide, provoquant une erreur JS non interceptée qui arrêtait aussi tout le script restant dans la même balise <script> (dont l'IIFE qui devait poser window.openLogicBlockPanel). Corrigé en ne passant que l'id dans l'attribut et en retrouvant le nom du bloc côté client depuis FLOW_BLOCKS (déjà chargé) — plus aucune chaîne utilisateur à échapper dans un attribut HTML. 2. <tr class="hidden" id="blockEditRow..."> ne se cachait jamais : le CSS ne définissait .hidden que scopé (.floatPanel.hidden, .columnFilterMenu.hidden), jamais en règle générique — ajoutée dans styles/forge-custom.css. Vérifié : 215 tests passent, syntaxe JS validée sur un scénario avec un vrai bloc existant (reproduisant exactement la situation signalée), onclick généré inspecté directement dans le HTML rendu. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 11:48:25 +02:00
williamandClaude Sonnet 5	1b7706b357	Ajoute les blocs de logique : organise le graphe de flow en sous-graphes nommés Le graphe de logique d'une scène s'affichait jusqu'ici sur un seul canevas plat (toutes les scènes accumulant leurs nœuds sur la même grille), ce qui ne tient pas à l'échelle dès qu'une scène évolue au fil de l'avancée du joueur et accumule des centaines/milliers de nœuds. Ajoute les "Blocs de logique" : un bloc regroupe un sous-ensemble de nœuds/arêtes d'un écran sous un nom et une description (comme une fonction). L'onglet "Logique de la scène" devient une liste de blocs (nom, description tronquée à 3 phrases, éléments concernés, nombre de nœuds, bouton "Ouvrir"). Ouvrir un bloc affiche SON graphe dans une modale plein écran, redimensionnable et déplaçable (patron déjà mûr dans game_dashboard.html, porté tel quel : makeFloatPanelDraggable/ Resizable/Fullscreenable). Décision d'architecture : un bloc est un automate FERMÉ — impossible de relier un nœud d'un bloc à un nœud d'un autre bloc (rejeté côté serveur dans flow_edge_add.py). Toute communication entre deux blocs passe par le système d'événements personnalisés déjà en place (declencher_evenement / trigger_event="evenement"). Détails techniques : - Nouvelle colonne _flow_nodes.block_id (nullable, sans FK — même rationale que trigger_element_id/target_element_id, voir screens/elements/delete_element.py) et nouvelle table _flow_blocks (screens/flow/ensure_flow_schema.py, screens/flow/blocks/ensure_flow_blocks_schema.py). - Migration douce et automatique : les nœuds posés avant l'existence des blocs (block_id NULL) sont rattachés, à la première ouverture de l'onglet, à un "Bloc principal" auto-créé (screens/flow/blocks/ list_flow_blocks.py) — aucun script de migration séparé, aucune donnée perdue. - Suppression d'un bloc = cascade complète (bloc + tous ses nœuds/ arêtes), patron identique à screens/custom_events/delete_custom_event.py mais scopé à un seul bloc plutôt que game-wide. - Routes CRUD sous routes/flow_blocks/, montées comme routes/custom_events/. - templates/screen_edit.html : FLOW (global unique) renommé en ALL_FLOW (toutes les données de l'écran) ; un seul bloc ouvert à la fois (modale unique, à la Unity) — currentBlockNodes()/currentBlockEdges() filtrent ALL_FLOW par CURRENT_BLOCK_ID à chaque rendu, sans tenir de seconde copie à synchroniser manuellement. Vérifié : 215 tests passent (7 nouveaux dans tests/test_flow_blocks.py, dont un qui verrouille l'ordre d'appel list_flow_blocks()/ list_flow_nodes() dans screen_edit.py — la migration douce doit tourner AVANT le chargement des nœuds, sinon le compte de nœuds affiché juste après une migration est périmé), syntaxe JS validée (script de screen_edit.html rendu via le client de test puis node --check). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 11:30:49 +02:00
williamandClaude Sonnet 5	c60884ec46	Corrige une régression fonctionnelle : revient à Bulma 1.0.2 (plus de Sass) L'utilisateur a signalé des bugs réels en jeu après la refonte design system : jauges qui ne se remplissent plus, conditions de visibilité cassées sur une carte (enveloppe ouverte/fermée affichées en même temps). Racine du problème : Phase A avait basculé Bulma de 1.0.2 (CDN d'origine) vers 0.9.4, seule version compatible avec libsass (1.0.2 utilise le système de modules @use/@forward que libsass ne sait pas compiler). Or screens/rendering/render_jauge.py pilote le remplissage d'une jauge en fixant en ligne --bulma-progress-value-background-color — une variable CSS qui n'existe QUE dans le nouveau système de theming de Bulma 1.x, absente de 0.9.4. Aucune perte de données : les champs d'objet étaient toujours intacts en base (vérifié directement sur projects/test/game.db) — uniquement un problème de rendu/comportement en jeu. Correction : revient à Bulma 1.0.2, vendoré tel quel et non modifié (static/vendor/bulma.min.css, ~677 Ko, auto-hébergé — toujours aucune dépendance CDN). Bulma 1.x expose déjà tout son thème via de vraies variables CSS (--bulma-primary-h/-s/-l, --bulma-radius...), justement conçues pour être surchargées après coup SANS recompilation Sass — styles/bulma-override.css les redéfinit avec la palette Forge (teintes HSL calculées à partir des couleurs de la charte). build_css.py devient un simple concaténage de 4 fichiers (bulma.min.css + bulma-override.css + forge-tokens.css + forge-custom.css), plus besoin de libsass ni d'aucun compilateur — supprimé de requirements.txt. styles/bulma/ (source Sass 0.9.4 vendorée en Phase A) et styles/forge-theme.scss supprimés. Nouvelle règle ajoutée en commentaire dans bulma-override.css : ne plus jamais changer de version de Bulma sans `grep -rn "\-\-bulma-" screens/ templates/` d'abord — cette dépendance n'est pas que visuelle. 197 tests toujours verts (ils ne couvrent que le HTML généré, jamais le rendu réel — c'est pour ça que cette régression n'avait pas été détectée avant que l'utilisateur ne la signale en jouant pour de vrai). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 08:40:16 +02:00

Author

SHA1

Message

Date

williamandClaude Sonnet 5

a445b72a6e

Corrige "Ouvrir"/"Modifier" inertes dans l'onglet Blocs de logique

Deux bugs distincts, signalés par capture d'écran (bouton "Ouvrir" sans
effet, ligne d'édition affichée en permanence au lieu d'être cachée) :

1. onclick="openLogicBlockPanel({{ b.id }}, {{ b.name|tojson }})" cassait
   l'attribut HTML : tojson produit des guillemets DOUBLES (valides en
   JSON), qui terminaient prématurément l'attribut onclick="..." lui-même
   entre guillemets doubles — le gestionnaire de clic généré était donc
   tronqué et invalide, provoquant une erreur JS non interceptée qui
   arrêtait aussi tout le script restant dans la même balise <script>
   (dont l'IIFE qui devait poser window.openLogicBlockPanel). Corrigé en
   ne passant que l'id dans l'attribut et en retrouvant le nom du bloc
   côté client depuis FLOW_BLOCKS (déjà chargé) — plus aucune chaîne
   utilisateur à échapper dans un attribut HTML.

2. <tr class="hidden" id="blockEditRow..."> ne se cachait jamais : le
   CSS ne définissait .hidden que scopé (.floatPanel.hidden,
   .columnFilterMenu.hidden), jamais en règle générique — ajoutée dans
   styles/forge-custom.css.

Vérifié : 215 tests passent, syntaxe JS validée sur un scénario avec un
vrai bloc existant (reproduisant exactement la situation signalée),
onclick généré inspecté directement dans le HTML rendu.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-30 11:48:25 +02:00

williamandClaude Sonnet 5

1b7706b357

Ajoute les blocs de logique : organise le graphe de flow en sous-graphes nommés

Le graphe de logique d'une scène s'affichait jusqu'ici sur un seul
canevas plat (toutes les scènes accumulant leurs nœuds sur la même
grille), ce qui ne tient pas à l'échelle dès qu'une scène évolue au fil
de l'avancée du joueur et accumule des centaines/milliers de nœuds.

Ajoute les "Blocs de logique" : un bloc regroupe un sous-ensemble de
nœuds/arêtes d'un écran sous un nom et une description (comme une
fonction). L'onglet "Logique de la scène" devient une liste de blocs
(nom, description tronquée à 3 phrases, éléments concernés, nombre de
nœuds, bouton "Ouvrir"). Ouvrir un bloc affiche SON graphe dans une
modale plein écran, redimensionnable et déplaçable (patron déjà mûr
dans game_dashboard.html, porté tel quel : makeFloatPanelDraggable/
Resizable/Fullscreenable).

Décision d'architecture : un bloc est un automate FERMÉ — impossible de
relier un nœud d'un bloc à un nœud d'un autre bloc (rejeté côté serveur
dans flow_edge_add.py). Toute communication entre deux blocs passe par
le système d'événements personnalisés déjà en place
(declencher_evenement / trigger_event="evenement").

Détails techniques :
- Nouvelle colonne _flow_nodes.block_id (nullable, sans FK — même
  rationale que trigger_element_id/target_element_id, voir
  screens/elements/delete_element.py) et nouvelle table _flow_blocks
  (screens/flow/ensure_flow_schema.py,
  screens/flow/blocks/ensure_flow_blocks_schema.py).
- Migration douce et automatique : les nœuds posés avant l'existence
  des blocs (block_id NULL) sont rattachés, à la première ouverture de
  l'onglet, à un "Bloc principal" auto-créé (screens/flow/blocks/
  list_flow_blocks.py) — aucun script de migration séparé, aucune
  donnée perdue.
- Suppression d'un bloc = cascade complète (bloc + tous ses nœuds/
  arêtes), patron identique à screens/custom_events/delete_custom_event.py
  mais scopé à un seul bloc plutôt que game-wide.
- Routes CRUD sous routes/flow_blocks/, montées comme routes/custom_events/.
- templates/screen_edit.html : FLOW (global unique) renommé en ALL_FLOW
  (toutes les données de l'écran) ; un seul bloc ouvert à la fois
  (modale unique, à la Unity) — currentBlockNodes()/currentBlockEdges()
  filtrent ALL_FLOW par CURRENT_BLOCK_ID à chaque rendu, sans tenir de
  seconde copie à synchroniser manuellement.

Vérifié : 215 tests passent (7 nouveaux dans tests/test_flow_blocks.py,
dont un qui verrouille l'ordre d'appel list_flow_blocks()/
list_flow_nodes() dans screen_edit.py — la migration douce doit tourner
AVANT le chargement des nœuds, sinon le compte de nœuds affiché juste
après une migration est périmé), syntaxe JS validée (script de
screen_edit.html rendu via le client de test puis node --check).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-30 11:30:49 +02:00

williamandClaude Sonnet 5

c60884ec46

Corrige une régression fonctionnelle : revient à Bulma 1.0.2 (plus de Sass)

L'utilisateur a signalé des bugs réels en jeu après la refonte design
system : jauges qui ne se remplissent plus, conditions de visibilité
cassées sur une carte (enveloppe ouverte/fermée affichées en même temps).
Racine du problème : Phase A avait basculé Bulma de 1.0.2 (CDN d'origine)
vers 0.9.4, seule version compatible avec libsass (1.0.2 utilise le
système de modules @use/@forward que libsass ne sait pas compiler). Or
screens/rendering/render_jauge.py pilote le remplissage d'une jauge en
fixant en ligne --bulma-progress-value-background-color — une variable
CSS qui n'existe QUE dans le nouveau système de theming de Bulma 1.x,
absente de 0.9.4. Aucune perte de données : les champs d'objet étaient
toujours intacts en base (vérifié directement sur projects/test/game.db)
— uniquement un problème de rendu/comportement en jeu.

Correction : revient à Bulma 1.0.2, vendoré tel quel et non modifié
(static/vendor/bulma.min.css, ~677 Ko, auto-hébergé — toujours aucune
dépendance CDN). Bulma 1.x expose déjà tout son thème via de vraies
variables CSS (--bulma-primary-h/-s/-l, --bulma-radius...), justement
conçues pour être surchargées après coup SANS recompilation Sass —
styles/bulma-override.css les redéfinit avec la palette Forge (teintes
HSL calculées à partir des couleurs de la charte). build_css.py devient
un simple concaténage de 4 fichiers (bulma.min.css + bulma-override.css
+ forge-tokens.css + forge-custom.css), plus besoin de libsass ni
d'aucun compilateur — supprimé de requirements.txt. styles/bulma/ (source
Sass 0.9.4 vendorée en Phase A) et styles/forge-theme.scss supprimés.

Nouvelle règle ajoutée en commentaire dans bulma-override.css : ne plus
jamais changer de version de Bulma sans `grep -rn "\-\-bulma-" screens/
templates/` d'abord — cette dépendance n'est pas que visuelle.

197 tests toujours verts (ils ne couvrent que le HTML généré, jamais le
rendu réel — c'est pour ça que cette régression n'avait pas été détectée
avant que l'utilisateur ne la signale en jouant pour de vrai).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-29 08:40:16 +02:00