0.2.0-0-pre.1-fix.2

docs/rules/FILE_CONTRACTS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/FILE_CONTRACTS.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Contrats des fichiers principaux
 
@@ -41,3 +41,11 @@
 - Un README propre à une crate, un package ou un répertoire technique peut conserver `README.md` lorsque cet usage est naturel à son écosystème.
 - Un répertoire documentaire conçu pour accumuler plusieurs fichiers Markdown utilise `000-README.md` comme point d'entrée.
 - `history/000-README.md` est le point d'entrée de l'historique validé.
+
+## Immutabilité et suppressions dans les deltas
+
+- Les fichiers `deltas/**/*.md` livrés sont immuables sur le fond.
+- Une correction de forme sans changement de sens peut modifier un delta existant uniquement en incrémentant son en-tête `version`.
+- Toute correction sémantique ou tout ajout produit un nouveau delta ou `.fix.N`.
+- Les fichiers `deltas/**/*.delete.txt` sont des manifests de suppression contractuels.
+- Chaque manifest contient un chemin relatif par ligne et est expliqué dans le fichier Markdown du delta qui l'introduit.

docs/rules/RULES_DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_DOCUMENTATION.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Règles de documentation
 
@@ -92,3 +92,20 @@
 - **DOC-MAT-004** — `Planned` signifie qu'une implémentation est affectée à une version ou un jalon de roadmap.
 - **DOC-MAT-005** — `Experimental` signifie qu'un POC ou une implémentation d'évaluation existe ou est explicitement planifié ; ce statut ne remplace pas `Reserved` pour une simple possibilité.
 - **DOC-MAT-006** — Une idée purement spéculative ne devient pas une capability réservée uniquement pour préserver une possibilité future.
+
+## Immutabilité des deltas
+
+- **DOC-DELTA-002** — Un fichier `deltas/**/*.md` livré est immuable sur le fond. Il ne reçoit jamais ultérieurement de nouveau scope, de nouvelle règle, de nouvelle validation, de nouveau résultat ou de nouvelle justification.
+- **DOC-DELTA-003** — Une correction strictement non sémantique d'un delta livré est autorisée uniquement pour la forme : orthographe, typographie, alignement de tableau ou correction mécanique équivalente.
+- **DOC-DELTA-004** — Toute correction autorisée par `DOC-DELTA-003` incrémente le numéro `version` d'en-tête du fichier corrigé.
+- **DOC-DELTA-005** — Toute correction sémantique ou tout ajout produit un nouveau delta ou un nouveau `.fix.N` ; l'ancien delta reste inchangé.
+- **DOC-DELTA-006** — Un fichier `deltas/**/*.delete.txt` fait partie du contrat de livraison et doit être documenté explicitement par le fichier Markdown du même delta.
+- **DOC-DELTA-007** — Un manifest `*.delete.txt` contient uniquement des chemins relatifs à la racine, un par ligne. Le delta associé documente la raison des suppressions et la commande d'application.
+
+## Versions d'en-tête
+
+- **DOC-HEAD-001** — Tout fichier géré par le projet qui possède un en-tête `version` incrémente ce numéro lors de toute modification réelle de contenu.
+- **DOC-HEAD-002** — Une modification réelle inclut ajout, suppression, déplacement, reformulation, changement de valeur de configuration, changement de contrat ou changement de chemin dans l'en-tête `file:`.
+- **DOC-HEAD-003** — Une transformation purement mécanique par un formatter officiel du projet, telle que `cargo fmt`, ne déclenche pas à elle seule d'incrément de version.
+- **DOC-HEAD-004** — Si un formatter est exécuté après une modification réelle du fichier, l'incrément reste requis à cause de la modification réelle.
+- **DOC-HEAD-005** — Un nouveau fichier versionné commence normalement à `version: 1`.

docs/rules/RULES_PROJECT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_PROJECT.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Règles spécifiques games.sasedev
 
@@ -82,3 +82,9 @@
 - **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.
+
+## Version d'en-tête des fichiers
+
+- **GAME-FILE-001** — Toute modification réelle d'un fichier qui possède un en-tête `version` incrémente ce numéro.
+- **GAME-FILE-002** — Les transformations purement mécaniques réalisées par les formatters officiels n'incrémentent pas à elles seules cet en-tête.
+- **GAME-FILE-003** — Un changement du champ d'en-tête `file:` dû à un renommage est une modification réelle et incrémente la version.

docs/rules/RULES_VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_VALIDATION_MATRIX.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Matrice normative des commandes et validations
 
@@ -63,3 +63,15 @@ La politique est donc double :
 Le nettoyage complet est normalement positionné au début d'un nouveau cycle de développement lorsque l'on souhaite évacuer les artefacts de la version précédente, ou avant une validation finale RC/stable lorsqu'un rebuild propre est recherché et que l'espace disque le justifie.
 
 Le delta ou le plan de version indique quel jalon de nettoyage est retenu. Il n'est pas nécessaire d'exécuter `cargo clean` à chaque prerelease.
+
+## Vérification des versions d'en-tête
+
+Avant livraison d'un delta :
+
+1. fichier modifié réellement et déjà versionné → en-tête incrémenté ;
+2. fichier uniquement reformaté mécaniquement → en-tête inchangé ;
+3. nouveau fichier versionné → `version: 1` sauf règle spécialisée ;
+4. renommage modifiant `file:` → en-tête incrémenté ;
+5. delta antérieur → aucun ajout sémantique rétroactif.
+
+Cette vérification fait partie de la revue de livraison même lorsqu'aucun audit automatisé ne dispose encore de la version précédente pour comparer.

docs/rules/VERSION_WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/VERSION_WORKFLOW.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Versionnement, maturité et livraisons
 
@@ -122,3 +122,10 @@ PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
 - **VER-TAURI-002** — `tauri.conf.json` omet `version` lorsque Tauri peut hériter de la version `Cargo.toml`.
 - **VER-TAURI-003** — La `version` de `package.json` décrit le package frontend local et n'est pas synchronisée à chaque `pre.N` ou `.fix.N`.
 - **VER-TAURI-004** — Tant que le frontend n'est pas publié comme package npm, sa version est mise à jour uniquement aux jalons significatifs retenus par le projet, au minimum lorsque cela est nécessaire pour alpha, beta, RC ou stable.
+
+## Corrections des deltas déjà livrés
+
+- **VER-DELTA-001** — Un delta livré n'est jamais enrichi après coup.
+- **VER-DELTA-002** — Une correction purement orthographique, typographique, d'alignement ou de forme sans changement de sens peut être appliquée au fichier delta existant si son en-tête `version` est incrémenté.
+- **VER-DELTA-003** — Une correction qui change le sens, le scope, les validations, les suppressions ou les décisions produit un nouveau `.fix.N`.
+- **VER-DELTA-004** — Les manifests `*.delete.txt` sont toujours décrits dans le delta Markdown qui les introduit.