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

0.2.0-0-pre.6-fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-18 23:16:45 +02:00
parent ec93eaebb2
commit f2eb58c712
11 changed files with 242 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/rules/VERSION_WORKFLOW.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/VERSION_WORKFLOW.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Versionnement, maturité et livraisons
@@ -104,17 +104,23 @@ La promotion `rc` puis stable d'une version de conception exige une validation h
## Phases de développement
Une version de code suit conceptuellement :
Une version suit conceptuellement :
```text
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** — Une petite version peut combiner planification et première implémentation dans `0-pre.1`.
- **VER-PHASE-003** — Une version lourde peut réserver `0-pre.1` à la planification/décomposition et utiliser plusieurs `pre.N` pour l'implémentation avant alpha/beta.
- **VER-PHASE-004** — La phase de planification doit identifier le scope, les dépendances, les validations attendues et le découpage de livraison sans dupliquer le contenu normatif de ROADMAP, RULES ou de la matrice de commandes.
- **VER-PHASE-005** — La phase de validation vérifie l'état effectivement implémenté ; elle ne réécrit pas rétroactivement le plan initial.
- **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-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-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.
- **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.
- **VER-PHASE-010** — La dernière tranche de développement avant la candidate de publication est réservée à la consolidation : validations finales, documentation durable, `CHANGELOG.md`, `ROADMAP.md`, historique applicable et préparation du prompt de la version/session suivante.
- **VER-PHASE-011** — La release stable est autant que possible mécanique : elle ne doit pas introduire une nouvelle fonctionnalité, une nouvelle décision architecturale ou un nouveau scope non validé dans une candidate précédente.
## Versions Tauri/frontend