0.3.0-0-pre.1-fix.2

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