0.3.0-0-pre.1-fix.1

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.