0.3.4-alpha.1

docs/rules/VERSION_WORKFLOW.md

@@ -1,32 +1,31 @@
 <!-- file: docs/rules/VERSION_WORKFLOW.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Versionnement, maturité et livraisons
 
 ## SemVer canonique
 
-Le projet utilise SemVer et les labels de maturité normalisés suivants :
+À partir de `0.3.4`, le projet utilise SemVer et les labels de maturité normalisés suivants :
 
 ```text
-X.Y.Z-0-pre.N
-X.Y.Z-0-pre.N.fix.M
-X.Y.Z-1-alpha.N
-X.Y.Z-1-alpha.N.fix.M
-X.Y.Z-2-beta.N
-X.Y.Z-2-beta.N.fix.M
-X.Y.Z-3-rc.N
-X.Y.Z-3-rc.N.fix.M
+X.Y.Z-alpha.N
+X.Y.Z-alpha.N.fix.M
+X.Y.Z-beta.N
+X.Y.Z-beta.N.fix.M
+X.Y.Z-rc.N
+X.Y.Z-rc.N.fix.M
 X.Y.Z
 ```
 
 `N` et `M` sont des entiers positifs sans zéro initial.
 
+Les anciens labels `0-pre.N`, `1-alpha.N`, `2-beta.N` et `3-rc.N` appartiennent uniquement aux jalons livrés avant cette migration. Les fichiers historiques concernés restent immuables et leurs identifiants ne sont jamais normalisés rétroactivement.
+
 ## Sens des niveaux
 
-- `0-pre.N` : construction initiale, architecture et fonctionnalités encore très mouvantes ;
-- `1-alpha.N` : périmètre fonctionnel principal établi mais encore incomplet ou instable ;
-- `2-beta.N` : fonctionnalités attendues largement présentes, priorité à la stabilisation et aux tests ;
-- `3-rc.N` : candidat de publication, aucune évolution non indispensable ;
+- `alpha.N` : construction, architecture et fonctionnalités encore susceptibles d'évoluer ; `alpha.1` porte obligatoirement le cadrage de la version ;
+- `beta.N` : fonctionnalités attendues largement présentes, priorité à la stabilisation et aux tests ;
+- `rc.N` : candidat de publication, aucune évolution non indispensable ;
 - `X.Y.Z` : version stable.
 
 ## Correctifs
@@ -34,13 +33,13 @@ X.Y.Z
 Un suffixe `.fix.M` corrige la prerelease immédiatement précédente sans changer son objectif fonctionnel. Exemple :
 
 ```text
-0.1.0-0-pre.4
-0.1.0-0-pre.4.fix.1
-0.1.0-0-pre.4.fix.2
-0.1.0-0-pre.5
+0.3.4-alpha.2
+0.3.4-alpha.2.fix.1
+0.3.4-alpha.2.fix.2
+0.3.4-alpha.3
 ```
 
-Après une version stable, un correctif produit normalement un nouveau patch SemVer, par exemple `0.1.1`, et non `0.1.0.fix.1`.
+Après une version stable, un correctif produit normalement un nouveau patch SemVer, par exemple `0.3.5`, et non `0.3.4.fix.1`.
 
 ## Version workspace et versions autonomes
 
@@ -64,19 +63,21 @@ Les documents sont rangés sous :
 deltas/X.Y.Z/<prerelease-or-rel>.md
 ```
 
-Exemples :
+Exemples canoniques pour les nouvelles versions :
 
 ```text
-deltas/0.1.0/0-pre.1.md
-deltas/0.1.0/0-pre.1.fix.1.md
-deltas/0.1.0/1-alpha.1.md
-deltas/0.1.0/3-rc.2.md
-deltas/0.1.0/rel.md
+deltas/0.3.4/alpha.1.md
+deltas/0.3.4/alpha.1.fix.1.md
+deltas/0.3.4/beta.1.md
+deltas/0.3.4/rc.1.md
+deltas/0.3.4/rel.001.md
 ```
 
+Les anciens chemins déjà livrés, par exemple `deltas/0.3.3/0-pre.1.md` ou `deltas/0.3.3/3-rc.1.md`, restent des preuves historiques valides et immuables.
+
 ## Versions principalement documentaires
 
-Une version de conception suit le même SemVer que les autres versions et peut utiliser plusieurs `0-pre.N` pour permettre une revue humaine progressive.
+Une version de conception suit le même SemVer que les autres versions et peut utiliser plusieurs `alpha.N` pour permettre une revue humaine progressive.
 
 Les audits Markdown et de règles valident la cohérence mécanique mais ne valent jamais acceptation du fond documentaire. Une prerelease documentaire reste candidate jusqu'à revue explicite de son contenu.
 
@@ -93,7 +94,7 @@ La promotion `rc` puis stable d'une version de conception exige une validation h
 
 - **VER-RC-001** — Une RC est fonctionnellement gelée. Les nouvelles fonctionnalités, nouvelles capabilities, refactors architecturaux non indispensables et changements volontaires de comportement sont interdits.
 - **VER-RC-002** — Les modifications de code restent autorisées en RC lorsqu'elles corrigent un bug, un test erroné, un défaut de packaging, un problème de sécurité, une incompatibilité de release ou un défaut strictement nécessaire à la publication.
-- **VER-RC-003** — Un correctif conforme à `VER-RC-002` produit `3-rc.N.fix.M` et n'impose pas un retour automatique en beta.
+- **VER-RC-003** — Un correctif conforme à `VER-RC-002` produit `rc.N.fix.M` et n'impose pas un retour automatique en beta.
 - **VER-RC-004** — Si le périmètre fonctionnel est rouvert pendant une RC, la candidate est abandonnée et le développement revient à une phase adaptée, normalement beta, avant une nouvelle RC.
 
 ## Prompt de la version suivante
@@ -106,7 +107,7 @@ La promotion `rc` puis stable d'une version de conception exige une validation h
 ## Correctifs strictement documentaires
 
 - **VER-DOCFIX-001** — Un `.fix.N` limité à la documentation, aux prompts, aux deltas, à `history/` ou aux règles non consommées par le build/runtime ne modifie aucune version technique : ni `workspace.package.version`/`Cargo.toml`, ni `package.json`, ni Gradle/Android, ni `tauri.conf.json`, ni autre métadonnée de version consommée par un build ou une distribution. L'identité du correctif est portée uniquement par le delta et son archive.
-- **VER-DOCFIX-002** — Une prerelease non-fix (`pre.N`, `alpha.N`, `beta.N`, `rc.N`) synchronise sa version technique selon le workflow de phase même lorsque son contenu est principalement documentaire.
+- **VER-DOCFIX-002** — Une prerelease non-fix (`alpha.N`, `beta.N`, `rc.N`) synchronise sa version technique selon le workflow de phase même lorsque son contenu est principalement documentaire.
 - **VER-DOCFIX-003** — Dès qu'un correctif touche du code, une configuration exécutable, un manifeste consommé par le build/runtime ou un artefact distribué, la version technique suit l'identifiant `.fix.N`.
 
 ## Phases de développement
@@ -118,11 +119,11 @@ 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 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-002** — `alpha.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** — `alpha.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. 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-005** — Le plan établi en `alpha.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 `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.
 - **VER-PHASE-009** — Alpha, beta et RC sont utilisées proportionnellement au risque et à la maturité ; elles ne sont pas créées uniquement pour satisfaire une séquence cérémonielle.
@@ -133,7 +134,7 @@ PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
 
 - **VER-TAURI-001** — Pour une app Tauri Rust du workspace, la version produit canonique est la version Cargo.
 - **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-003** — La `version` de `package.json` décrit le package frontend local et n'est pas synchronisée à chaque prerelease 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