diff --git a/Cargo.toml b/Cargo.toml index 6347dd7..0d325fa 100644 --- a/Cargo.toml +++ b/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" diff --git a/README.md b/README.md index a006910..2b41a09 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/deltas/0.3.0/0-pre.1.fix.2.md b/deltas/0.3.0/0-pre.1.fix.2.md new file mode 100644 index 0000000..0769be4 --- /dev/null +++ b/deltas/0.3.0/0-pre.1.fix.2.md @@ -0,0 +1,94 @@ + + + +# 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. diff --git a/docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md b/docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md index 4d58087..adc8245 100644 --- a/docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md +++ b/docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/docs/rules/RULES_PROJECT.md b/docs/rules/RULES_PROJECT.md index a11e88b..8af3512 100644 --- a/docs/rules/RULES_PROJECT.md +++ b/docs/rules/RULES_PROJECT.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/docs/rules/RULES_SESSION_PLANNING.md b/docs/rules/RULES_SESSION_PLANNING.md index 3d3ccc2..7535767 100644 --- a/docs/rules/RULES_SESSION_PLANNING.md +++ b/docs/rules/RULES_SESSION_PLANNING.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/prompts/002-V0_3_X_START_PROMPT.md b/prompts/002-V0_3_X_START_PROMPT.md index d639bb1..98d4548 100644 --- a/prompts/002-V0_3_X_START_PROMPT.md +++ b/prompts/002-V0_3_X_START_PROMPT.md @@ -1,5 +1,5 @@ - + # 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 ; -- éviter duplication bridge/frontend ; -- préparer input/resize/lifecycle/runtime provenance ; -- documenter les duplications provisoires. +- introduire la crate/adaptation WASM minimale de Snake ; +- générer les bindings avec `wasm-bindgen` ; +- conserver le gameplay dans `game-snake-poc` ; +- 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 -Tauri Android + Snake -``` +- un document HTML responsive piloté par Vite/TypeScript ; +- 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 -Web navigateur direct + Snake -``` +### `0-pre.5` — intégration plateforme complète -Le POC doit couvrir : +Fermer les besoins de bout en bout du POC : -- build avec outil natif ; -- lancement ; -- rendu ; -- contrôles ; -- resize/orientation selon host ; -- lifecycle ; -- logging ; +- resize/lifecycle ; - 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 - -À 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. +Sinon, omettre cette tranche. ### `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é.