0.3.0-0-pre.1-fix.2

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 59
+# version: 60
 
 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.3.0-0-pre.1.fix.1"
+version = "0.3.0-0-pre.1.fix.2"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # games.sasedev
 
@@ -25,7 +25,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
 
 Version stable de référence : `0.2.0`.
 
-Version de développement : `0.3.0-0-pre.1.fix.1`.
+Version de développement : `0.3.0-0-pre.1.fix.2`.
 
 Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
 

deltas/0.3.0/0-pre.1.fix.2.md

@@ -0,0 +1,94 @@
+<!-- file: deltas/0.3.0/0-pre.1.fix.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.3.0-0-pre.1.fix.2
+
+## Base
+
+Base requise : `0.3.0-0-pre.1.fix.1`.
+
+Ce correctif reste dans la responsabilité de cadrage de `0-pre.1`. Il ne modifie aucun gameplay, runtime, frontend ou packaging.
+
+## Objet
+
+Compléter le plan `0.3.0` sur deux responsabilités qui doivent être visibles dès le cadrage :
+
+- le POC navigateur doit posséder un véritable shell Web HTML/Vite/TypeScript autour du Canvas/WASM, avec Bootstrap 5 comme baseline de présentation du premier POC Snake ;
+- la prévision de version doit montrer explicitement la tranche finale de consolidation documentaire et de transmission avant RC/stable, au lieu de laisser cette responsabilité seulement implicite dans les règles générales.
+
+## Version
+
+La version workspace passe de `0.3.0-0-pre.1.fix.1` à `0.3.0-0-pre.1.fix.2`.
+
+## Frontend Web
+
+Le plan retient désormais explicitement pour `0-pre.4` :
+
+- Vite/TypeScript comme host frontend ;
+- un document HTML responsive ;
+- Bootstrap 5 pour le layout, les états UI et les contrôles tactiles ;
+- un Canvas dédié au rendu du jeu ;
+- clavier et contrôles directionnels tactiles ;
+- séparation stricte : Bootstrap/DOM restent côté frontend, le gameplay et l'état du jeu restent dans Rust/WASM.
+
+La règle durable ne rend pas Bootstrap obligatoire pour tous les futurs hosts Web : elle impose la séparation shell Web / Canvas-WASM / gameplay. Bootstrap 5 est la décision concrète du POC `0.3.0`.
+
+## Consolidation de fin de version
+
+Le forecast `0.3.0` ajoute `2-beta.2` comme repère prévisionnel de consolidation :
+
+- réconciliation de la documentation durable et du plan actif ;
+- mise à jour de `CHANGELOG.md` ;
+- mise à jour de `ROADMAP.md` ;
+- mise à jour de l'historique applicable ;
+- vérification des deltas réellement livrés ;
+- préparation et vérification du prompt de la version/session suivante.
+
+Le numéro reste souple : des fixes ou une beta supplémentaire peuvent le décaler. La responsabilité, elle, ne doit pas disparaître du plan.
+
+La documentation fonctionnelle reste mise à jour au fil des tranches concernées ; cette consolidation finale sert à fermer la cohérence transversale et la transmission de session.
+
+## Règles précisées
+
+- `SESSION-009` exige que le forecast créé en `0-pre.1` rende explicitement visible une tranche de consolidation avant la candidate finale ;
+- `GAME-PLATFORM-020` fixe la séparation durable du host Web : shell HTML/CSS/TypeScript autour du Canvas/WASM, sans fuite du framework de présentation dans gameplay/WASM ; Bootstrap 5 est la baseline du premier POC Snake.
+
+Le prompt `002-V0_3_X_START_PROMPT.md` est aligné sur les décisions déjà prises par `pre.1` : Web direct en premier host, adaptation WASM dédiée, shell Bootstrap 5 et tranche `2-beta.2` de consolidation/transmission.
+
+## Fichiers ajoutés
+
+- `deltas/0.3.0/0-pre.1.fix.2.md`.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `README.md` ;
+- `docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md` ;
+- `docs/rules/RULES_PROJECT.md` ;
+- `docs/rules/RULES_SESSION_PLANNING.md` ;
+- `prompts/002-V0_3_X_START_PROMPT.md`.
+
+## Suppressions
+
+Aucune.
+
+## Validations applicables
+
+Ce fix modifie uniquement la version workspace et le cadrage documentaire/normatif. Les audits statiques sont exécutés lors de la préparation du delta.
+
+Validation utilisateur demandée :
+
+```bash
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android deltas history
+python3 scripts/audit_distribution_layout.py
+
+cargo fmt --all -- --check
+cargo check --workspace
+```
+
+Aucun build Web n'est demandé par ce fix : Bootstrap 5 et le frontend Snake seront introduits seulement dans leur tranche d'implémentation.
+
+## Suite
+
+Après validation de ce fix, poursuivre `0.3.0` avec `0-pre.2` selon le plan actif. La session reste planifiée jusqu'à la stable `0.3.0`, avec consolidation documentaire/transmission explicitement réservée avant RC.

docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan v0.3.0 — baseline Snake et premier POC Web direct
 
@@ -20,6 +20,7 @@ Décisions issues du cadrage `0-pre.1` :
 - Tauri Android est reporté à `0.3.1` ;
 - le gameplay reste dans `game-snake-poc` ;
 - le chemin Web utilise Cargo, `wasm-bindgen` et Vite/TypeScript, sans orchestrateur Python ;
+- le host navigateur possède un shell HTML piloté par Vite/TypeScript, avec Bootstrap 5 pour le layout/les contrôles et un Canvas dédié au rendu du jeu ; Bootstrap ne porte aucune règle de gameplay ;
 - aucune abstraction n'est extraite avant qu'un besoin partagé réel soit observé.
 
 ## Scope
@@ -28,7 +29,7 @@ La version couvre :
 
 - nettoyage de la baseline Snake et de ses dépendances de plateforme ;
 - adaptation WASM dédiée à Snake ;
-- frontend Web minimal avec clavier et contrôles directionnels tactiles ;
+- frontend Web avec shell HTML responsive, Bootstrap 5, Canvas, clavier et contrôles directionnels tactiles ;
 - resize/lifecycle adaptés au navigateur ;
 - branchement des assets, du logging et de la provenance runtime nécessaires au POC ;
 - maintien du runner Desktop SDL3 comme témoin de non-régression ;
@@ -60,11 +61,11 @@ Introduire la crate/adaptation WASM minimale de Snake et le chemin de générati
 
 Gate : compilation ciblée WASM et tests Rust applicables. Si cette tranche dépasse le budget normal, séparer bridge et build en deux prereleases.
 
-### `0-pre.4` — frontend Web/Vite et contrôles
+### `0-pre.4` — frontend Web/Vite, shell Bootstrap 5 et contrôles
 
-Créer le frontend Vite/TypeScript minimal, brancher clavier et boutons directionnels tactiles, puis afficher et piloter Snake dans le navigateur.
+Créer le frontend Vite/TypeScript avec un document HTML responsive servant de shell au jeu. Utiliser Bootstrap 5 côté frontend pour la mise en page, les états UI et les contrôles tactiles ; conserver le rendu du jeu dans un Canvas et les règles de gameplay dans Rust/WASM. Brancher clavier, boutons directionnels tactiles, chargement/erreur et affichage d'état nécessaires au POC.
 
-Gate : build Web par le chemin natif prévu et smoke navigateur.
+Gate : build Web par le chemin natif prévu et smoke navigateur couvrant Canvas, clavier, contrôles tactiles et comportement responsive du shell.
 
 ### `0-pre.5` — intégration plateforme complète
 
@@ -80,9 +81,17 @@ Tranche conditionnelle. Elle n'existe que si les POC précédents révèlent une
 
 Scope feature-complete. Exécuter les gates workspace applicables, les tests ciblés et les validations Web/Desktop prévues. Aucun nouveau scope.
 
+### `2-beta.2` — consolidation documentaire et transmission
+
+Réconcilier l'état réellement validé avec la documentation durable et le plan actif, puis mettre à jour `CHANGELOG.md`, `ROADMAP.md` et l'historique applicable. Préparer et vérifier le prompt de la version/session suivante à partir de cet état, sans prétendre à des validations non exécutées.
+
+Cette tranche est une responsabilité obligatoire du cycle même si son numéro doit être décalé par des fixes ou une beta supplémentaire. La documentation spécifique à une fonctionnalité reste mise à jour dans la tranche qui introduit cette fonctionnalité ; `2-beta.2` réalise la consolidation transversale, elle ne sert pas à reporter toute la documentation en fin de version.
+
+Gate : cohérence docs/plan/deltas/`CHANGELOG.md`/`ROADMAP.md`/history/prompt, puis audits documentaires applicables.
+
 ### `3-rc.1` — candidate gelée
 
-Reproductibilité, documentation de livraison et derniers défauts strictement nécessaires à la publication. Aucun nouveau POC ni nouvelle capability.
+Reproductibilité, validation finale de la candidate et derniers défauts strictement nécessaires à la publication. Le prompt suivant préparé pendant la consolidation est vérifié/complété si l'état RC apporte une information nouvelle. Aucun nouveau POC ni nouvelle capability.
 
 ### `0.3.0` — release stable
 

docs/rules/RULES_PROJECT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_PROJECT.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 
 # Règles spécifiques games.sasedev
 
@@ -82,6 +82,7 @@
 - **GAME-PLATFORM-017** — Téléphone, tablette et futures classes de device sont des dimensions distinctes de l'OS et du backend technique.
 - **GAME-PLATFORM-018** — SDL3 reste le backend natif de référence du POC, mais l'architecture de jeu ne doit pas assimiler une plateforme à SDL ni empêcher un adapter différent lorsque la plateforme l'exige.
 - **GAME-PLATFORM-019** — Une plateforme réservée n'est ni implémentée ni planifiée tant qu'une ligne ROADMAP ou un delta ne l'engage explicitement.
+- **GAME-PLATFORM-020** — Un host Web navigateur possède un shell HTML/CSS/TypeScript explicite autour du Canvas/WASM. Le framework de présentation éventuel reste une dépendance frontend et ne fuit ni dans la crate de gameplay ni dans le bridge WASM ; pour le premier POC Snake `0.3.0`, Bootstrap 5 est la baseline de présentation retenue.
 
 ## Version d'en-tête des fichiers
 

docs/rules/RULES_SESSION_PLANNING.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Règles de cadrage des versions, sessions et prompts
 
@@ -17,6 +17,7 @@ Ces règles imposent un découpage suffisamment petit pour qu'une version puisse
 - **SESSION-006** — Le plan de version contient au minimum l'objectif et le scope, les décisions acquises, les dépendances/risques utiles, les validations attendues, les hors-périmètre et une prévision souple des tranches jusqu'à la release stable.
 - **SESSION-007** — La prévision du plan n'est pas un calendrier figé : une tranche peut être scindée, fusionnée, déplacée ou complétée par un fix lorsque les résultats réels le justifient. Le plan actif est alors réconcilié et le delta explique le changement.
 - **SESSION-008** — `ROADMAP.md` reste macroscopique, le plan porte le découpage prévisionnel fin de la version et les deltas enregistrent ce qui a réellement été livré.
+- **SESSION-009** — Le forecast créé en `0-pre.1` rend explicitement visible une tranche de consolidation avant la candidate finale ; cette tranche couvre au minimum la réconciliation de la documentation durable, `CHANGELOG.md`, `ROADMAP.md`, l'historique applicable et le prompt de la version/session suivante, même si son numéro exact reste prévisionnel.
 
 ## Taille des tranches
 

prompts/002-V0_3_X_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/002-V0_3_X_START_PROMPT.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Prompt de démarrage — `0.3.0` / série `0.3.x` POC plateforme et réseau
 
@@ -150,65 +150,51 @@ Validation candidate :
 - Desktop SDL toujours fonctionnel ;
 - dependency audit ciblé.
 
-### `0-pre.3` — adapters/capabilities minimaux
+### `0-pre.3` — adaptation Snake WASM
 
-Objectif candidat :
+Décision issue de `pre.1` :
 
-- extraire uniquement ce que le premier POC prouve nécessaire ;
+- introduire la crate/adaptation WASM minimale de Snake ;
-- éviter duplication bridge/frontend ;
+- générer les bindings avec `wasm-bindgen` ;
-- préparer input/resize/lifecycle/runtime provenance ;
+- conserver le gameplay dans `game-snake-poc` ;
-- documenter les duplications provisoires.
+- ne pas généraliser avant qu'un second consommateur ne le justifie.
 
-Cette tranche peut être fusionnée avec `pre.2`.
+### `0-pre.4` — frontend Web/Vite + shell Bootstrap 5
 
-### `0-pre.4` — premier POC de bout en bout
+Décision issue de `pre.1` : le premier host est Web navigateur direct + Snake.
 
-Préférence initiale :
+Le frontend doit fournir :
 
-```text
+- un document HTML responsive piloté par Vite/TypeScript ;
-Tauri Android + Snake
+- Bootstrap 5 comme baseline de présentation/layout et pour les contrôles UI ;
-```
+- un Canvas dédié au rendu du jeu ;
+- clavier et boutons directionnels tactiles ;
+- états de chargement/erreur utiles au POC.
 
-Alternative si `pre.1` la juge plus rationnelle :
+Le framework HTML/CSS reste strictement côté frontend : Rust/WASM conserve le gameplay et l'état du jeu.
 
-```text
+### `0-pre.5` — intégration plateforme complète
-Web navigateur direct + Snake
-```
 
-Le POC doit couvrir :
+Fermer les besoins de bout en bout du POC :
 
-- build avec outil natif ;
+- resize/lifecycle ;
-- lancement ;
-- rendu ;
-- contrôles ;
-- resize/orientation selon host ;
-- lifecycle ;
-- logging ;
 - assets ;
-- runtime provenance.
+- logging ;
+- runtime provenance ;
+- non-régression du runner Desktop SDL3.
 
-Compiler seul ne suffit pas.
+Compiler seul ne suffit pas : le smoke navigateur fait partie de la validation.
 
-### `0-pre.5` — corrections/généralisation issues du POC
+### `0-pre.6` — correction/extraction conditionnelle
 
-Créer seulement si le POC révèle un besoin réel :
+Créer seulement si les tranches précédentes révèlent un besoin réel :
 
 - supprimer duplication avérée ;
 - corriger frontières mal placées ;
 - ajouter tests nécessaires ;
 - documenter ce qui reste spécifique.
 
-### `1-alpha.1` — intégration éventuelle
+Sinon, omettre cette tranche.
-
-À utiliser seulement si le volume de code nouveau justifie une phase distincte.
-
-Objectif :
-
-- stabiliser interfaces Snake/capabilities/host ;
-- fermer les défauts structurels ;
-- aucun nouveau scope.
-
-Sinon, ne pas créer cette tranche artificiellement.
 
 ### `2-beta.1` — validation large
 
@@ -220,6 +206,18 @@ Objectif :
 - documentation des commandes ;
 - vérification qu'aucune abstraction spéculative n'a été ajoutée.
 
+### `2-beta.2` — consolidation documentaire et transmission
+
+Responsabilité obligatoire, même si sa numérotation finale glisse :
+
+- réconcilier la documentation durable avec l'état validé ;
+- mettre à jour `CHANGELOG.md` et `ROADMAP.md` ;
+- mettre à jour l'historique applicable ;
+- réconcilier le plan avec les deltas réellement livrés ;
+- préparer et vérifier le prompt de la version/session suivante.
+
+Cette tranche consolide la documentation ; elle ne reporte pas à la fin la documentation spécifique qui devait accompagner les tranches fonctionnelles.
+
 ### `3-rc.1` — candidate
 
 Scope gelé.