0.3.0-0-pre.1-fix.1

Cargo.toml

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

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 26 -->
+<!-- version: 27 -->
 
 # 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`.
+Version de développement : `0.3.0-0-pre.1.fix.1`.
 
 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.1.md

@@ -0,0 +1,85 @@
+<!-- file: deltas/0.3.0/0-pre.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.3.0-0-pre.1.fix.1
+
+## Base
+
+Base requise : `0.3.0-0-pre.1`.
+
+Ce correctif reste dans la responsabilité de cadrage de `0-pre.1`. Il ne modifie aucun gameplay, runtime, frontend ou packaging.
+
+## Objet
+
+Corriger deux omissions du cadrage initial :
+
+- créer le plan vivant de `0.3.0` sous `docs/plans/`, avec le découpage prévisionnel souple de toute la progression de la version ;
+- formaliser les règles associées, notamment la relation plan/ROADMAP/deltas, la cible d'au moins une version complète par session et le traitement des archives fournies depuis un tag.
+
+## Version
+
+La version workspace passe de `0.3.0-0-pre.1` à `0.3.0-0-pre.1.fix.1`.
+
+## Plan de version
+
+Ajout de :
+
+- `docs/plans/000-README.md` ;
+- `docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md`.
+
+Le plan conserve le scope et les décisions du cadrage, puis suit une trajectoire souple : baseline Snake portable, adaptation WASM, frontend Web/Vite, intégration E2E, correction/extraction conditionnelle, beta, RC et stable.
+
+La numérotation est prévisionnelle. Les tranches peuvent être scindées, fusionnées ou décalées en fonction des résultats réels sans forcer une fermeture artificielle.
+
+## Règles ajoutées ou précisées
+
+- `0-pre.1` crée ou révise obligatoirement le plan actif de la version sous `docs/plans/` ;
+- le plan porte le découpage prévisionnel fin, `ROADMAP.md` reste macroscopique et les deltas enregistrent le livré réel ;
+- une session de développement est planifiée pour livrer au minimum une version concrète complète ; une prerelease est une tranche interne, pas une cible normale de fin de session ;
+- lorsqu'une archive est fournie comme téléchargement d'un tag du dépôt, elle est la baseline autoritaire de ce tag ; l'absence de `.git` est normale et n'est ni une anomalie ni une validation manquante ;
+- les contrôles Git nécessitant `.git` ne s'appliquent qu'à un checkout local effectivement fourni.
+
+Le prompt `002-V0_3_X_START_PROMPT.md` est aligné sur ces règles : il ne demande plus de vérifier un état Git inexistant dans une archive taggée et exige le plan actif dans le résultat de `pre.1`.
+
+## Fichiers ajoutés
+
+- `docs/plans/000-README.md` ;
+- `docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md` ;
+- `deltas/0.3.0/0-pre.1.fix.1.md`.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `README.md` ;
+- `docs/000-README.md` ;
+- `docs/rules/FILE_CONTRACTS.md` ;
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/rules/RULES_SESSION_PLANNING.md` ;
+- `docs/rules/VERSION_WORKFLOW.md` ;
+- `docs/rules/RULES_COMMANDS.md` ;
+- `prompts/002-V0_3_X_START_PROMPT.md`.
+
+## Suppressions
+
+Aucune.
+
+## Validations applicables
+
+Ce fix modifie uniquement le manifest de version et la documentation/règles. 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
+```
+
+Clippy/tests ne sont pas rendus nécessaires par ce fix documentaire lui-même ; ils restent ceux prévus par la progression de `0.3.0`.
+
+## Suite
+
+Après validation de ce fix, poursuivre `0.3.0` selon `docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md`, en commençant par `0-pre.2` et en visant la fermeture complète de `0.3.0` dans la session plutôt qu'un arrêt planifié sur une prerelease.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 21 -->
+<!-- version: 22 -->
 
 # Documentation games.sasedev
 
@@ -12,6 +12,11 @@
 - [`ideas/000-README.md`](ideas/000-README.md) — rôle des idées non engagées et règles de maturation.
 - [`studies/000-README.md`](studies/000-README.md) — rôle des études comparatives non normatives.
 
+## Plans
+
+- [`plans/000-README.md`](plans/000-README.md) — plans vivants des versions ; le plan actif porte notamment le découpage prévisionnel souple des prereleases.
+- [`plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md`](plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md) — plan actif de `0.3.0`, premier POC Snake Web direct.
+
 ## Architecture
 
 - [`architecture/001-WORKSPACE_ARCHITECTURE.md`](architecture/001-WORKSPACE_ARCHITECTURE.md) — workspace, générations de moteur, jeux, runners, assets et Android.

docs/plans/000-README.md

@@ -0,0 +1,14 @@
+<!-- file: docs/plans/000-README.md -->
+<!-- version: 1 -->
+
+# Plans de versions games.sasedev
+
+Ce répertoire contient les plans vivants des versions concrètes.
+
+Un plan est créé ou révisé pendant `0-pre.1`. Il conserve le scope, les décisions utiles, les validations et surtout le découpage prévisionnel souple des tranches jusqu'à la release. Il peut évoluer lorsque les audits ou validations imposent de scinder, fusionner, reporter ou corriger une tranche.
+
+Le `ROADMAP.md` reste la trajectoire macroscopique du projet ; les deltas décrivent ce qui a réellement été livré. Le plan se situe entre les deux et sert au suivi de la version en cours.
+
+## Plans
+
+- [`001-V0_3_0_WEB_SNAKE_POC_PLAN.md`](001-V0_3_0_WEB_SNAKE_POC_PLAN.md) — plan actif de `0.3.0`, baseline Snake et premier POC Web direct.

docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md

@@ -0,0 +1,99 @@
+<!-- file: docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md -->
+<!-- version: 1 -->
+
+# Plan v0.3.0 — baseline Snake et premier POC Web direct
+
+## But de la version
+
+`0.3.0` ouvre la série de POC `0.3.x`. La version doit rendre Snake suffisamment portable pour servir de jeu-sonde et valider un premier host de bout en bout : le navigateur Web direct.
+
+La version doit rester assez petite pour être fermée dans la session qui l'ouvre. Si une tranche devient trop lourde, elle est scindée ; si le scope global ne tient plus, la partie non indispensable est reportée à une version suivante.
+
+## Base et décisions acquises
+
+Base stable : `0.2.0`.
+
+Décisions issues du cadrage `0-pre.1` :
+
+- Snake reste le jeu-sonde principal ;
+- le premier host de `0.3.0` est Web navigateur direct ;
+- 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 ;
+- aucune abstraction n'est extraite avant qu'un besoin partagé réel soit observé.
+
+## Scope
+
+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 ;
+- 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 ;
+- documentation des duplications observées et des extractions réellement justifiées.
+
+Hors périmètre : Tauri Android/Desktop Snake, Android natif multi-ABI, réseau realtime, WebTransport/QUIC, Uroburas, ads, billing, auth, leaderboard et nouveau moteur.
+
+## Prévision souple
+
+Les numéros ci-dessous sont des repères de progression, pas un contrat rigide. Une découverte peut insérer un fix, scinder une tranche ou décaler les numéros suivants sans forcer la fermeture.
+
+### `0-pre.1` — cadrage
+
+Audit de la baseline, requirements, choix du host Web, sizing et validations prévues. Le présent plan manquant à la livraison initiale est ajouté par `0-pre.1.fix.1`.
+
+### `0-pre.1.fix.1` — plan et règles de suivi
+
+Créer `docs/plans/`, formaliser le caractère vivant du plan, corriger le contrat des archives taggées et rendre explicite qu'une session est planifiée pour fermer au minimum la version concrète ouverte.
+
+### `0-pre.2` — baseline Snake portable
+
+Nettoyer les dépendances inutiles/spécifiques au launcher, stabiliser la frontière gameplay/input et confirmer les tests Snake ainsi que le runner Desktop SDL3.
+
+Gate : audits statiques, tests ciblés des crates touchées et smoke Desktop si le runtime SDL est modifié.
+
+### `0-pre.3` — adaptation Snake WASM
+
+Introduire la crate/adaptation WASM minimale de Snake et le chemin de génération `wasm-bindgen`, sans frontend riche ni généralisation prématurée.
+
+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
+
+Créer le frontend Vite/TypeScript minimal, brancher clavier et boutons directionnels tactiles, puis afficher et piloter Snake dans le navigateur.
+
+Gate : build Web par le chemin natif prévu et smoke navigateur.
+
+### `0-pre.5` — intégration plateforme complète
+
+Fermer resize/lifecycle, assets, logging et provenance runtime du POC ; vérifier que Desktop SDL reste intact.
+
+Gate : tests ciblés, build Web et smoke navigateur couvrant les requirements de `0.3.0`.
+
+### `0-pre.6` — correction/extraction seulement si prouvée
+
+Tranche conditionnelle. Elle n'existe que si les POC précédents révèlent une duplication réelle, une frontière mal placée ou un défaut nécessitant une correction structurante avant stabilisation. Sinon elle est omise.
+
+### `2-beta.1` — validation large
+
+Scope feature-complete. Exécuter les gates workspace applicables, les tests ciblés et les validations Web/Desktop prévues. Aucun nouveau scope.
+
+### `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.
+
+### `0.3.0` — release stable
+
+Publication mécanique de l'état RC validé.
+
+## Suivi et ajustements
+
+Le plan est révisé lorsqu'un résultat réel modifie la trajectoire. Un changement de numérotation n'est pas un problème ; une responsabilité importante ne doit en revanche pas être comprimée artificiellement pour respecter le forecast initial.
+
+La session ne doit pas être planifiée pour s'arrêter à `pre.2`, `pre.4` ou beta : ces identifiants sont des tranches de la même version. Si `0.3.0` devient trop grande, le scope non indispensable est déplacé vers `0.3.1+` afin de préserver une version complète par session.
+
+## Version suivante envisagée
+
+`0.3.1` reste le candidat pour le second host Snake, Tauri Android, en réutilisant la baseline Web/WASM réellement validée par `0.3.0`.

docs/rules/FILE_CONTRACTS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/FILE_CONTRACTS.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Contrats des fichiers principaux
 
@@ -11,6 +11,7 @@
 - `docs/rules/` contient les règles durables.
 - `docs/ideas/000-README.md` est le point d'entrée des idées et variantes non engagées.
 - `docs/studies/000-README.md` est le point d'entrée des analyses comparatives non normatives préparant une décision.
+- `docs/plans/000-README.md` est le point d'entrée des plans de versions ; chaque plan actif porte le découpage prévisionnel souple et les gates de sa version.
 - `docs/architecture/` contient les décisions et descriptions d'architecture retenues.
 - `docs/objectives/` décrit les objectifs et la stratégie produit/technique.
 - `docs/games/` classe les familles de jeux, leurs contrôles et leurs évolutions.

docs/rules/RULES_COMMANDS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_COMMANDS.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Règles d'exécution des commandes
 
@@ -63,6 +63,8 @@
 
 - **CMD-GIT-001** — Les commandes Git destructives (`reset --hard`, nettoyage forcé, réécriture non demandée) ne sont jamais utilisées pour remettre artificiellement le workspace en état.
 - **CMD-GIT-002** — Les fichiers générés ne sont pas commités sauf contrat explicite du dépôt ou exigence de distribution.
+- **CMD-GIT-003** — Lorsqu'une archive fournie par l'utilisateur est déclarée comme téléchargement d'un tag du dépôt, cette archive est la baseline autoritaire de ce tag. L'absence de `.git` dans l'archive est normale et ne constitue ni une anomalie ni une validation manquante.
+- **CMD-GIT-004** — Les contrôles nécessitant le répertoire `.git` s'appliquent uniquement à un checkout Git local lorsqu'il est effectivement fourni ; sur une archive taggée, on contrôle la cohérence interne des versions et fichiers sans inventer un état Git inaccessible.
 
 - **CMD-WEB-005** — `npm run dev` et `npm run build` du frontend Tauri sont pilotés par les hooks Tauri ; ils ne constituent pas des gates manuelles indépendantes.
 

docs/rules/RULES_DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_DOCUMENTATION.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Règles de documentation
 
@@ -28,6 +28,7 @@
 - **DOC-CAT-006** — Les documents spécialisés existants (`games/`, `engine/`, `monetization/`, `services/`, `development/`, `testing/`, `validation/`) conservent leur rôle fonctionnel et ne servent pas de dépôt générique d'idées.
 - **DOC-CAT-007** — Une information peut mûrir de `idea` vers `study`, puis vers une décision d'architecture ou une réservation de capability ; ce passage est explicite et n'est jamais déduit de la seule présence d'un texte.
 - **DOC-CAT-008** — Une étude peut conclure à `retained`, `deferred`, `rejected` ou `needs-poc` sans créer automatiquement une capability, une crate ou une entrée de roadmap.
+- **DOC-CAT-009** — `docs/plans/` contient les plans vivants des versions concrètes. Un plan détaille le scope, les décisions, les validations et surtout le découpage prévisionnel souple des prereleases ; il ne remplace ni `ROADMAP.md` ni les deltas.
 
 ## Nomenclature documentaire
 

docs/rules/RULES_SESSION_PLANNING.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Règles de cadrage des versions, sessions et prompts
 
@@ -13,6 +13,10 @@ Ces règles imposent un découpage suffisamment petit pour qu'une version puisse
 - **SESSION-002** — Cette tranche couvre au minimum l'audit de la base, le brainstorming/recherche de requirements, le sizing, les dépendances, les validations prévues et le découpage prévisionnel.
 - **SESSION-003** — Une première implémentation peut être incluse dans `0-pre.1` uniquement si elle est petite, cohérente et n'empêche pas le cadrage d'être terminé.
 - **SESSION-004** — Si le sizing montre que l'objectif global ne peut raisonnablement pas être terminé dans la session, il est scindé en plusieurs versions avant le développement lourd.
+- **SESSION-005** — `0-pre.1` crée ou révise obligatoirement le plan de la version sous `docs/plans/`. Ce plan est un livrable du cadrage, pas une note optionnelle.
+- **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é.
 
 ## Taille des tranches
 
@@ -24,9 +28,10 @@ Ces règles imposent un découpage suffisamment petit pour qu'une version puisse
 
 ## Une version par session
 
-- **SESSION-020** — Une session de développement vise une version complète, de son cadrage jusqu'à sa release ou à sa candidate de publication selon le scope décidé.
-- **SESSION-021** — Une session ne doit pas être planifiée de façon à s'arrêter normalement au milieu d'une version.
-- **SESSION-022** — Si de nouvelles informations rendent la version trop grande, le scope restant est replanifié explicitement vers une version suivante au lieu de prolonger indéfiniment la session.
+- **SESSION-020** — Une session de développement est dimensionnée pour livrer au minimum une version concrète complète, de son cadrage jusqu'à sa release stable.
+- **SESSION-021** — Une prerelease est une tranche interne de progression et ne constitue pas une cible normale de fin de session ; la session ne doit pas être planifiée pour s'arrêter au milieu de la version ouverte.
+- **SESSION-022** — Si de nouvelles informations rendent la version trop grande, le scope restant est replanifié explicitement vers une ou plusieurs versions suivantes au lieu de prolonger indéfiniment la version courante.
+- **SESSION-023** — Le découpage prévisionnel doit donc permettre de suivre toute la progression de la version dans la même session, tout en restant assez souple pour insérer des fixes ou déplacer du scope sans forcer artificiellement la fermeture.
 
 ## Dernières tranches
 

docs/rules/VERSION_WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/VERSION_WORKFLOW.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Versionnement, maturité et livraisons
 
@@ -111,10 +111,10 @@ PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
 ```
 
 - **VER-PHASE-001** — Ces phases structurent le travail mais n'imposent pas une prerelease distincte pour chacune.
-- **VER-PHASE-002** — `0-pre.1` est obligatoirement la tranche de cadrage de la version : audit de la base, brainstorming/recherche de requirements, sizing, planification, dépendances, validations attendues et découpage prévisionnel.
+- **VER-PHASE-002** — `0-pre.1` est obligatoirement la tranche de cadrage de la version : audit de la base, brainstorming/recherche de requirements, sizing, planification, dépendances, validations attendues et création/révision du plan actif sous `docs/plans/` avec son découpage prévisionnel souple.
 - **VER-PHASE-003** — `0-pre.1` peut aussi contenir une première implémentation strictement bornée si le cadrage montre qu'elle tient naturellement dans la même tranche, mais le cadrage ne doit jamais être sauté.
 - **VER-PHASE-004** — Une version doit être dimensionnée pour que l'ensemble de son développement puisse être terminé dans une seule session de travail. Si ce n'est pas réaliste, son objectif est découpé en plusieurs versions/sessions avant le développement lourd.
-- **VER-PHASE-005** — Le plan établi en `0-pre.1` est vivant : il peut regrouper, scinder, reporter ou reclasser des tranches lorsque l'information réelle le justifie, sans réécrire les deltas déjà livrés.
+- **VER-PHASE-005** — Le plan établi en `0-pre.1` est vivant : il peut regrouper, scinder, reporter ou reclasser des tranches lorsque l'information réelle le justifie, sans réécrire les deltas déjà livrés. Il reste la référence de suivi prévisionnel de la version jusqu'à sa clôture.
 - **VER-PHASE-006** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou leur fix vise normalement un delta réalisable en environ 15 à 30 minutes. Une tranche sensiblement plus lourde est découpée avant exécution ; une tranche trop petite peut être regroupée avec une tranche adjacente cohérente.
 - **VER-PHASE-007** — Le découpage privilégie des unités fonctionnelles complètes et validables, pas des coupures arbitraires au milieu d'une fonctionnalité.
 - **VER-PHASE-008** — Chaque tranche ferme son propre scope, produit son delta et ses validations proportionnelles avant l'ouverture de la tranche suivante.

prompts/002-V0_3_X_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/002-V0_3_X_START_PROMPT.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Prompt de démarrage — `0.3.0` / série `0.3.x` POC plateforme et réseau
 
@@ -12,7 +12,7 @@ Avant toute modification :
 1. lire `RULES.md`, `ROADMAP.md`, `CHANGELOG.md` et `docs/000-README.md` ;
 2. lire les règles de session, commandes et validation ;
 3. lire les architectures consolidées `012` à `016` ;
-4. vérifier l'état Git/workspace ;
+4. lorsque la base est une archive téléchargée depuis le tag fourni, la traiter comme snapshot autoritaire sans exiger `.git` ; vérifier sa cohérence workspace/version ;
 5. exécuter les audits applicables à la base ;
 6. confirmer la version workspace avant `0.3.0-0-pre.1`.
 
@@ -128,7 +128,7 @@ Objectif :
 - requirements ;
 - graphe de dépendances ;
 - choix du premier POC ;
-- forecast corrigé ;
+- plan actif sous `docs/plans/` avec forecast corrigé ;
 - commandes prévues ;
 - critères de sortie.