Sasedev/games
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.3.4-alpha.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-21 17:14:34 +02:00
parent 0ad980a06b
commit 27978c3782
14 changed files with 831 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/rules/PROMPT_STRUCTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/PROMPT_STRUCTURE.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Structure des prompts de reprise
@@ -15,7 +15,7 @@ Le prompt rappelle les invariants qui évitent les erreurs de workflow et renvoi
- **PROMPT-STR-002** — Le prompt fournit un ordre de lecture court des sources de vérité : `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/000-README.md`, règles directement pertinentes, plan/historique de la version précédente et documents d'architecture concernés.
- **PROMPT-STR-003** — Le prompt distingue explicitement l'état déjà validé hérité de la baseline des validations qui devront être exécutées dans la nouvelle version.
- **PROMPT-STR-004** — Le prompt décrit la mission, le résultat attendu, le scope inclus, le hors-périmètre et les invariants architecturaux gelés.
- **PROMPT-STR-005** — Le prompt rappelle que `0-pre.1` est le gate de cadrage : audit, requirements, sizing, risques, validations prévues et création/révision du plan sous `docs/plans/` avant développement lourd.
- **PROMPT-STR-005** — Le prompt rappelle que `alpha.1` est le gate de cadrage : audit, requirements, sizing, risques, validations prévues et création/révision du plan sous `docs/plans/` avant développement lourd.
- **PROMPT-STR-006** — Le prompt contient un forecast souple jusqu'à la stable. Il réserve les responsabilités de développement, validation large, consolidation documentaire, préparation de publication/RC et release mécanique sans rendre les numéros immuables.
- **PROMPT-STR-007** — Le prompt rappelle où se trouve la définition des commandes : `docs/rules/RULES_COMMANDS.md` pour la politique d'exécution et `docs/rules/RULES_VALIDATION_MATRIX.md` pour les IDs, dépendances et déclencheurs. Il ne recopie que les commandes indispensables à la reprise ou au premier gate.
- **PROMPT-STR-008** — Le prompt rappelle la séparation utilisateur/générateur : les audits statiques peuvent être exécutés par le générateur, mais les builds, tests et smokes finaux restent côté utilisateur conformément à `CMD-BUILD-005` et ne sont jamais déclarés réussis sans sortie réelle.
@@ -30,7 +30,7 @@ Le prompt rappelle les invariants qui évitent les erreurs de workflow et renvoi
- **PROMPT-STR-010** — Le prompt rappelle que `deltas/` décrit la livraison candidate et ses validations attendues, alors que `history/` enregistre uniquement le résultat d'un jalon effectivement accepté.
- **PROMPT-STR-011** — Le prompt rappelle qu'une entrée `history/<X.Y.Z>/<jalon>.md` est créée par le delta suivant ou le fix suivant après validation, jamais avant la validation qu'elle décrit.
- **PROMPT-STR-012** — Le prompt rappelle que `CHANGELOG.md` n'est normalement mis à jour qu'à partir de la RC puis à la stable ; les détails `pre`/`beta` restent dans `deltas/` et `history/`.
- **PROMPT-STR-012** — Le prompt rappelle que `CHANGELOG.md` n'est normalement mis à jour qu'à partir de la RC puis à la stable ; les détails `alpha`/`beta` restent dans `deltas/` et `history/`.
- **PROMPT-STR-013** — Le prompt rappelle que `ROADMAP.md` reste macroscopique et n'est modifié que lorsque le scope, son ordre ou son statut évolue réellement ; le plan de version porte le découpage fin.
- **PROMPT-STR-014** — Le prompt rappelle que la documentation propre à une fonctionnalité évolue avec la tranche qui l'introduit ; la consolidation finale réconcilie l'ensemble mais ne sert pas à repousser toute documentation à la fin.
- **PROMPT-STR-015** — Le prompt mentionne explicitement la politique `README.md`/`USAGE.md` lorsque la version crée ou finalise une crate, une application ou un package : appliquer `DOC-CRATE-*` et décider dans le plan quels fichiers ont une valeur durable réelle.

6
docs/rules/RULES_DOCUMENTATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_DOCUMENTATION.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Règles de documentation
@@ -74,7 +74,7 @@
## CHANGELOG
- **DOC-CHG-001** — `CHANGELOG.md` est une synthèse de publication, pas un journal de développement.
- **DOC-CHG-002** — Les `pre.*`, `alpha.*`, `beta.*` et leurs `.fix.*` ne créent normalement aucune entrée de changelog.
- **DOC-CHG-002** — Les `alpha.*`, `beta.*` et leurs `.fix.*` ne créent normalement aucune entrée de changelog.
- **DOC-CHG-003** — Le changelog est mis à jour à partir des jalons `rc.*` et pour chaque release stable.
- **DOC-CHG-004** — Une entrée RC résume l'état candidat à publication ; l'entrée stable résume le résultat effectivement publié.
- **DOC-CHG-005** — Les détails intermédiaires de construction, corrections et validations restent dans `deltas/` et `history/`.
@@ -92,7 +92,7 @@
- **DOC-VAL-001** — Une gate Markdown ou un audit syntaxique valide la forme des documents, jamais leur exactitude fonctionnelle, leur exhaustivité ni leur acceptation.
- **DOC-VAL-002** — Une prerelease principalement documentaire reste candidate tant que son contenu n'a pas été relu et accepté humainement.
- **DOC-VAL-003** — Une version de conception peut utiliser plusieurs `pre.N` successives uniquement pour permettre revue, correction, complément et maturation documentaire.
- **DOC-VAL-003** — Une version de conception peut utiliser plusieurs `alpha.N` successives uniquement pour permettre revue, correction, complément et maturation documentaire.
- **DOC-VAL-004** — Cargo, Gradle, packaging et smoke tests ne sont requis pour une prerelease documentaire que si le delta modifie du code, une configuration de build/runtime ou un contrat susceptible de les affecter.
- **DOC-VAL-005** — Le document de delta énumère les validations applicables ; l'absence volontaire d'une gate technique doit découler du scope réel, pas d'un raccourci.
- **DOC-VAL-006** — Une version documentaire n'est promue en `rc` ou stable qu'après validation explicite de son contenu, même si tous les audits automatisés sont propres.

18
docs/rules/RULES_SESSION_PLANNING.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Règles de cadrage des versions, sessions et prompts
@@ -7,26 +7,26 @@
Ces règles imposent un découpage suffisamment petit pour qu'une version puisse être développée complètement dans une seule session et reprise sans ambiguïté.
## `pre.1` — cadrage obligatoire
## `alpha.1` — cadrage obligatoire
- **SESSION-001** — Toute nouvelle version commence par une `0-pre.1` de cadrage.
- **SESSION-001** — Toute nouvelle version commence par une `alpha.1` de cadrage.
- **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-003** — Une première implémentation peut être incluse dans `alpha.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-005** — `alpha.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é.
- **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.
- **SESSION-009** — Le forecast créé en `alpha.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
- **SESSION-010** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou `fix.N` vise normalement un delta correspondant à environ 15 à 30 minutes de travail effectif.
- **SESSION-010** — Une tranche `alpha.N`, `beta.N`, `rc.N` ou `fix.N` vise normalement un delta correspondant à environ 15 à 30 minutes de travail effectif.
- **SESSION-011** — Une tranche clairement plus lourde est scindée avant exécution.
- **SESSION-012** — Plusieurs micro-tranches sans valeur de validation indépendante peuvent être regroupées.
- **SESSION-013** — Le découpage suit des unités fonctionnelles complètes et validables ; une fonctionnalité ne doit pas être volontairement coupée au milieu uniquement pour respecter un numéro de prerelease.
- **SESSION-014** — Chaque tranche livre son delta et ses validations proportionnelles avant la tranche suivante.
- **SESSION-015** — Le plan créé en `0-pre.1` identifie explicitement le ou les rares jalons où `cargo test --workspace --all-targets --all-features` apporte une valeur globale (initial si nécessaire, préfinal/final ou changement transverse). Les autres tranches privilégient les tests `cargo test -p ...` ciblés.
- **SESSION-015** — Le plan créé en `alpha.1` identifie explicitement le ou les rares jalons où `cargo test --workspace --all-targets --all-features` apporte une valeur globale (initial si nécessaire, préfinal/final ou changement transverse). Les autres tranches privilégient les tests `cargo test -p ...` ciblés.
## Une version par session
@@ -49,7 +49,7 @@ Ces règles imposent un découpage suffisamment petit pour qu'une version puisse
- **PROMPT-005** — Le prompt rappelle les invariants essentiels mais renvoie aux RULES pour les détails normatifs au lieu de les recopier intégralement.
- **PROMPT-006** — Le prompt contient suffisamment de contexte pour reprendre la version sans dépendre de la mémoire conversationnelle ni relire toute l'histoire du dépôt.
- **PROMPT-007** — Le prompt précise la condition de fin de session et les livrables attendus.
- **PROMPT-008** — Si `pre.1` invalide le sizing prévu par le prompt, le nouveau découpage est documenté immédiatement avant le développement lourd.
- **PROMPT-008** — Si `alpha.1` invalide le sizing prévu par le prompt, le nouveau découpage est documenté immédiatement avant le développement lourd.
- **PROMPT-009** — Tout nouveau prompt de version applique `docs/rules/PROMPT_STRUCTURE.md`; le présent document fixe le cycle de session tandis que `PROMPT_STRUCTURE.md` fixe le contenu opératoire à rappeler.
## Relation avec VERSION_WORKFLOW

38
docs/rules/RULES_VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_VALIDATION_MATRIX.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Matrice normative des commandes et validations
@@ -15,30 +15,30 @@ Les commandes ciblées restent la norme pendant l'implémentation ; les gates wo
| ID | Commande / action | Dépend de | Déclencheur principal | Phase minimale typique |
|-----------|------------------------------------------------------------------------------------|---------------------------------|----------------------------------------------------|------------------------|
| `CMD-001` | `cargo fmt --all` | — | Rust ou dépendance Cargo modifiée | `pre` |
| `CMD-002` | `cargo fmt --all -- --check` | `CMD-001` | Rust ou dépendance Cargo modifiée | `pre` |
| `CMD-010` | `python3 scripts/audit_rust_workspace_rules.py` | — | Rust/Cargo/workspace/règles Rust concernés | `pre` |
| `CMD-011` | `python3 scripts/audit_markdown_tables.py ...` | — | Markdown concerné | `pre` |
| `CMD-012` | `python3 scripts/audit_distribution_layout.py` | — | layout/build/distribution concerné | `pre` |
| `CMD-020` | `cargo check -p <crate>` | audits applicables | diagnostic ciblé facultatif | `pre` |
| `CMD-021` | `cargo test -p <crate> --all-targets --all-features` | `CMD-023`, `CMD-024` | comportement/API crate | `pre` |
| `CMD-022` | tests ciblés des crates consommatrices impactées | `CMD-021` | API publique/contrat partagé modifié | `pre` |
| `CMD-023` | `cargo check --workspace` | `CMD-002`, audits applicables | Rust ou dépendance Cargo modifiée | `pre` |
| `CMD-024` | `cargo clippy --workspace --all-targets --all-features -- -D warnings` | `CMD-023` | Rust ou dépendance Cargo modifiée | `pre` |
| `CMD-001` | `cargo fmt --all` | — | Rust ou dépendance Cargo modifiée | `alpha` |
| `CMD-002` | `cargo fmt --all -- --check` | `CMD-001` | Rust ou dépendance Cargo modifiée | `alpha` |
| `CMD-010` | `python3 scripts/audit_rust_workspace_rules.py` | — | Rust/Cargo/workspace/règles Rust concernés | `alpha` |
| `CMD-011` | `python3 scripts/audit_markdown_tables.py ...` | — | Markdown concerné | `alpha` |
| `CMD-012` | `python3 scripts/audit_distribution_layout.py` | — | layout/build/distribution concerné | `alpha` |
| `CMD-020` | `cargo check -p <crate>` | audits applicables | diagnostic ciblé facultatif | `alpha` |
| `CMD-021` | `cargo test -p <crate> --all-targets --all-features` | `CMD-023`, `CMD-024` | comportement/API crate | `alpha` |
| `CMD-022` | tests ciblés des crates consommatrices impactées | `CMD-021` | API publique/contrat partagé modifié | `alpha` |
| `CMD-023` | `cargo check --workspace` | `CMD-002`, audits applicables | Rust ou dépendance Cargo modifiée | `alpha` |
| `CMD-024` | `cargo clippy --workspace --all-targets --all-features -- -D warnings` | `CMD-023` | Rust ou dépendance Cargo modifiée | `alpha` |
| `CMD-025` | `cargo test --workspace --all-targets --all-features` | `CMD-024` | gate rare planifiée / portée transverse incertaine | selon plan |
| `CMD-026` | `cargo tree -p <crate> --edges normal` ou variante ciblée | — | dépendances/features modifiées ou diagnostic | selon portée |
| `CMD-030` | build Desktop `--release` ciblé | gates Rust applicables | runner/distribution Desktop touché | beta |
| `CMD-031` | smoke Desktop release | `CMD-030` | runtime Desktop touché | beta |
| `CMD-040` | `(cd <tauri-app> && cargo tauri dev)` | gates Rust/frontend applicables | smoke interactif Tauri Desktop | `pre`/beta |
| `CMD-040` | `(cd <tauri-app> && cargo tauri dev)` | gates Rust/frontend applicables | smoke interactif Tauri Desktop | alpha/beta |
| `CMD-041` | `(cd <tauri-app> && cargo tauri build)` | gates Rust/frontend applicables | packaging Tauri Desktop final/prefinal | beta/RC |
| `CMD-042` | build Rust `wasm32-unknown-unknown` + `wasm-bindgen --target web` | gates Rust de l'adapter | adapter WASM/Web direct touché | `pre` |
| `CMD-043` | `(cd Web/<game> && npm install && npm run build)` | `CMD-042` si frontend avec WASM | frontend Web direct touché | `pre` |
| `CMD-044` | smoke navigateur du host Web direct | `CMD-043` | Canvas/input/responsive Web touchés | `pre`/beta |
| `CMD-045` | `(cd <tauri-app> && cargo tauri android init)` | environnement Android/Tauri | initialisation unique de la cible Tauri Android | `pre` |
| `CMD-046` | `(cd <tauri-app> && cargo tauri android dev)` | gates Rust/frontend applicables | smoke interactif Tauri Android | `pre`/beta |
| `CMD-042` | build Rust `wasm32-unknown-unknown` + `wasm-bindgen --target web` | gates Rust de l'adapter | adapter WASM/Web direct touché | `alpha` |
| `CMD-043` | `(cd Web/<game> && npm install && npm run build)` | `CMD-042` si frontend avec WASM | frontend Web direct touché | `alpha` |
| `CMD-044` | smoke navigateur du host Web direct | `CMD-043` | Canvas/input/responsive Web touchés | alpha/beta |
| `CMD-045` | `(cd <tauri-app> && cargo tauri android init)` | environnement Android/Tauri | initialisation unique de la cible Tauri Android | `alpha` |
| `CMD-046` | `(cd <tauri-app> && cargo tauri android dev)` | gates Rust/frontend applicables | smoke interactif Tauri Android | alpha/beta |
| `CMD-047` | `(cd <tauri-app> && cargo tauri android build)` | gates Rust/frontend applicables | packaging Tauri Android final/prefinal | beta/RC |
| `CMD-050` | build Rust Android ABI ciblé | gates Rust applicables | Android/JNI/backend natif touché | pre/beta |
| `CMD-051` | `(cd Android && gradle :<app>:assembleDebug)` | `CMD-050` si Rust natif change | Android/app/manifest/Java touché | pre/beta |
| `CMD-050` | build Rust Android ABI ciblé | gates Rust applicables | Android/JNI/backend natif touché | alpha/beta |
| `CMD-051` | `(cd Android && gradle :<app>:assembleDebug)` | `CMD-050` si Rust natif change | Android/app/manifest/Java touché | alpha/beta |
| `CMD-052` | install + smoke AVD | `CMD-051` | Android concerné | beta |
| `CMD-053` | install + smoke appareil réel | `CMD-051` | Android concerné | beta/RC |
| `CMD-060` | `cargo clean --dry-run --verbose` | — | contrôle disque / préparation nettoyage | maintenance |

67
docs/rules/VERSION_WORKFLOW.md
View File

@@ -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