0.0.1-alpha.2

2026-09-23 07:47:09 +02:00
parent 15fa124184
commit 6f30bc5be2
6 changed files with 322 additions and 5 deletions
--- a/RULES.md
+++ b/RULES.md
@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->

 # Index normatif Project Governance Rules

@@ -70,7 +70,13 @@ Les traductions complètes éventuelles vivent dans des dépôts distincts (`pgr

 ## Documents normatifs détaillés

-Les règles détaillées seront structurées progressivement sous [`docs/rules/`](docs/rules/). Une famille de règles n'est créée que lorsqu'elle possède un contenu réel ; aucun répertoire vide n'est requis pour anticiper une future technologie.
+Les règles détaillées sont structurées progressivement sous [`docs/rules/`](docs/rules/).
+
+Famille actuellement active :
+
+- [`docs/rules/200-GOVERNANCE.md`](docs/rules/200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.
+
+Une famille de règles n'est créée que lorsqu'elle possède un contenu réel ; aucun répertoire vide n'est requis pour anticiper une future technologie.

 ## Modification des règles

--- a/2
+++ b/2
@@ -1 +1 @@
-0.0.1-alpha.1.fix.2
+0.0.1-alpha.2
--- a/deltas/0.0.1/alpha.2.md
+++ b/deltas/0.0.1/alpha.2.md
@@ -0,0 +1,86 @@
+<!-- file: deltas/0.0.1/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.1-alpha.2 — core governance rules
+
+## Baseline
+
+Version attendue avant application :
+
+```text
+0.0.1-alpha.1.fix.2
+```
+
+Le history `history/0.0.1/alpha.1.fix.2.md` MUST avoir été appliqué et committé avant ce delta.
+
+Version après application :
+
+```text
+0.0.1-alpha.2
+```
+
+## Objet
+
+Formaliser les règles communes de versioning et de lifecycle prévues pour `alpha.2`, sans anticiper les contrats détaillés des artefacts workflow réservés à `alpha.3`.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+RULES.md
+docs/rules/000-README.md
+```
+
+ADD :
+
+```text
+docs/rules/200-GOVERNANCE.md
+deltas/0.0.1/alpha.2.md
+```
+
+DELETE : aucun.
+
+## Changements
+
+- `VERSION` passe à `0.0.1-alpha.2` ;
+- la première famille normative détaillée devient active sous `docs/rules/200-GOVERNANCE.md` ;
+- le rôle de `VERSION` est limité à la version SemVer du release unit et n'entre pas en conflit avec les versionings indépendants ;
+- les formes alpha, beta, RC, stable et `.fix.N` sont formalisées ;
+- `alpha.1` devient explicitement le gate de cadrage obligatoire d'une release ;
+- la portée de beta, RC et promotion stable est définie ;
+- REPLAN reste un rôle de tranche alpha sans suffixe SemVer supplémentaire ;
+- abandon et supersession sont gouvernés sans forcer une stable artificielle ;
+- l'interruption d'une session n'est pas une frontière de version ;
+- le principe de proportionnalité est ancré dans la gouvernance détaillée.
+
+## Validation opérateur
+
+```bash
+test "$(cat VERSION)" = "0.0.1-alpha.2"
+
+test -f docs/rules/200-GOVERNANCE.md
+
+grep -Fx '<!-- file: docs/rules/200-GOVERNANCE.md -->' docs/rules/200-GOVERNANCE.md
+grep -F 'PGR MUST NOT imposer une égalité globale' docs/rules/200-GOVERNANCE.md
+grep -F 'alpha.1` MUST servir de gate de cadrage' docs/rules/200-GOVERNANCE.md
+grep -F "L'arrivée à \`.fix.3\` ou au-delà MUST déclencher une revue du plan" docs/rules/200-GOVERNANCE.md
+
+git diff --check
+
+git add VERSION RULES.md docs/rules/000-README.md docs/rules/200-GOVERNANCE.md \
+    deltas/0.0.1/alpha.2.md
+
+git diff --cached --check
+
+git status --short
+```
+
+La revue opérateur vérifie également que `alpha.2` ne définit pas encore en détail les formats `history`, `handoff`, `manifest` ou `prompt`, qui appartiennent à `alpha.3`.
+
+## Transition
+
+PASS : enregistrer `history/0.0.1/alpha.2.md`, committer `alpha.2`, puis passer à `0.0.1-alpha.3`.
+
+FAIL : rester dans `alpha.2` avec `alpha.2.fix.1`, sauf REPLAN si le défaut remet en cause le scope ou le plan.
--- a/docs/rules/000-README.md
+++ b/docs/rules/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/000-README.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->

 # Index des règles PGR

@@ -7,9 +7,13 @@ Les règles détaillées de Project Governance Rules sont organisées ici progre

 `RULES.md` reste le point d'entrée normatif du dépôt et définit les principes fondamentaux, la force normative et la hiérarchie générale.

+## Familles actives
+
+- [`200-GOVERNANCE.md`](200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.
+
 ## Organisation prévue

-Les familles seront créées uniquement lorsqu'elles disposent d'un contenu réel. La trajectoire actuelle prévoit conceptuellement :
+Les autres familles seront créées uniquement lorsqu'elles disposent d'un contenu réel. La trajectoire actuelle prévoit conceptuellement :

 ```text
 100 — general
--- a/docs/rules/200-GOVERNANCE.md
+++ b/docs/rules/200-GOVERNANCE.md
@@ -0,0 +1,165 @@
+<!-- file: docs/rules/200-GOVERNANCE.md -->
+<!-- version: 1 -->
+
+# Governance rules
+
+## Scope
+
+Ce document définit les règles communes de versioning et de lifecycle des releases gouvernées par PGR.
+
+Les contrats détaillés des artefacts `delta`, `history`, `handoff`, `manifest` et `prompt` sont hors scope de cette tranche et seront définis séparément.
+
+## Principe de proportionnalité
+
+La gouvernance MUST servir l'objectif du projet et MUST rester proportionnée au risque et à l'impact du changement.
+
+Une règle, un contrôle ou une étape récurrente SHOULD exister lorsqu'il apporte une valeur identifiable, notamment pour :
+
+- réduire les erreurs et régressions ;
+- préserver une architecture ou un contrat ;
+- rendre une décision explicite ;
+- améliorer la sécurité ou la compatibilité ;
+- faciliter maintenance, reprise ou diagnostic ;
+- rendre une validation reproductible ;
+- réduire le coût total du développement futur.
+
+Une pratique qui ajoute principalement duplication, cérémonie ou coût de validation sans gain de preuve SHOULD être simplifiée, rendue optionnelle ou supprimée.
+
+## Version canonique de release
+
+Chaque release unit gouvernée par PGR MUST avoir une version SemVer courante explicite.
+
+Lorsqu'un dépôt utilise le fichier racine `VERSION`, ce fichier :
+
+- MUST contenir exactement la version SemVer courante du release unit, sans préfixe `v` ;
+- MUST contenir une seule ligne significative ;
+- sert de repère simple entre l'état des sources, Git, les deltas et le lifecycle courant ;
+- MUST NOT être interprété comme la version de tous les formats, schémas, documents, compteurs ou plateformes du projet.
+
+Un manifeste technique MAY refléter exactement `VERSION` lorsque son propre contrat l'exige. Un autre mécanisme de versioning MAY rester indépendant lorsqu'il possède une sémantique différente, par exemple un `versionCode` Android, une révision de document ou une version de protocole.
+
+PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version.
+
+Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative.
+
+## Schéma SemVer PGR
+
+Le lifecycle standard utilise les formes suivantes :
+
+```text
+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` commencent à `1` et progressent de manière monotone dans leur scope.
+
+Le préfixe Git d'une release stable est :
+
+```text
+vX.Y.Z
+```
+
+`rel.N` MAY identifier une livraison ou un artefact de clôture, mais MUST NOT être traité comme une version produit SemVer.
+
+Avant `1.0.0`, PGR recommande la convention suivante lorsqu'elle correspond au projet :
+
+- `X = 0` indique que le contrat public durable n'est pas encore stabilisé ;
+- `Y` identifie une série fonctionnelle ou architecturale ;
+- `Z` identifie une release concrète de cette série ;
+- `0.0.x` MAY être utilisé pour une phase de fondation initiale.
+
+Cette convention pré-1.0 complète SemVer sans modifier sa syntaxe.
+
+## Rôle des phases
+
+### Alpha
+
+`alpha` porte le cadrage, l'implémentation et les changements de scope encore attendus dans la release.
+
+`alpha.1` MUST servir de gate de cadrage de la release. Avant une implémentation lourde, elle doit vérifier de manière proportionnée :
+
+- la baseline et les règles applicables ;
+- le plan ou la mission de la release ;
+- la réalité du dépôt et des dépendances concernées ;
+- les études ou décisions encore ouvertes ;
+- les principaux risques et contraintes ;
+- la stratégie de validation et les smokes nécessaires ;
+- le dimensionnement des tranches.
+
+Une tranche cible généralement un volume de travail cohérent et vérifiable. Une durée de l'ordre de 15 à 30 minutes MAY servir d'heuristique de découpage, mais MUST NOT être traitée comme une deadline ou un quota.
+
+### Beta
+
+`beta` sert principalement à la stabilisation, l'intégration et la correction d'un scope fonctionnel déjà largement établi.
+
+Une beta SHOULD NOT devenir une nouvelle phase d'expansion importante du scope sans REPLAN explicite.
+
+### Release candidate
+
+`rc` représente un scope de release gelé sauf correction nécessaire à sa validation.
+
+La RC MUST porter la gate complète applicable à la release candidate avant promotion stable. Un changement fonctionnel important découvert à ce stade SHOULD revenir vers une phase appropriée plutôt qu'être dissimulé dans une correction RC.
+
+### Stable
+
+La promotion vers `X.Y.Z` SHOULD être proche d'une opération mécanique lorsque la RC correspondante a passé sa gate.
+
+La promotion stable MUST néanmoins exécuter son propre gate proportionné pour vérifier les métadonnées, documents de release et artefacts réellement produits par cette promotion.
+
+Le tag stable canonique est `vX.Y.Z`.
+
+La vérification d'une publication ou d'une archive produite après le tag est une preuve distincte de la validation pré-tag.
+
+## Correctifs de tranche
+
+Une forme `.fix.M` corrige uniquement la tranche immédiatement concernée.
+
+Un fix :
+
+- MUST conserver le scope fonctionnel de sa tranche ;
+- MUST NOT introduire silencieusement une nouvelle fonctionnalité ou un nouveau chantier ;
+- MAY corriger code, configuration, documentation, validation ou packaging nécessaires pour rendre la tranche conforme à son objectif ;
+- remet son compteur `M` à `1` pour chaque nouvelle tranche.
+
+L'arrivée à `.fix.3` ou au-delà MUST déclencher une revue du plan et du diagnostic. Cette revue MAY conclure à la poursuite du fix, mais elle doit vérifier qu'un REPLAN n'est pas préférable.
+
+## REPLAN
+
+REPLAN est un rôle de tranche alpha, pas un suffixe SemVer supplémentaire.
+
+Un REPLAN est approprié lorsque le plan courant ne décrit plus correctement la réalité, par exemple après découverte d'une dépendance, d'un risque, d'une architecture ou d'un volume de travail significativement différent de l'hypothèse initiale.
+
+Un REPLAN doit aboutir explicitement à l'un des résultats suivants :
+
+```text
+CONTINUE
+SPLIT
+CONTINUE-NEXT-SESSION
+ABANDON
+```
+
+Une interruption de conversation ou de session MUST NOT créer artificiellement une nouvelle version. Le même état de version et de tranche continue tant que le scope reste valable.
+
+## Abandon et supersession
+
+Une version ou prerelease commencée n'est pas forcée vers stable uniquement pour préserver une séquence esthétique.
+
+Lorsqu'un travail est abandonné ou superseded :
+
+- l'état MUST être documenté ;
+- la version déjà commencée est considérée comme consommée dans l'historique du projet ;
+- les décisions, études et artefacts utiles SHOULD être conservés ;
+- le contenu obsolète ou dangereux MAY être supprimé lorsque sa suppression et son remplacement sont explicitement justifiés.
+
+Une nouvelle version MAY ensuite repartir d'une baseline saine sans prétendre que la version abandonnée n'a jamais existé.
+
+## Discipline de changement
+
+Un changement de version, de phase ou de scope MUST être motivé par l'état réel du projet et non par la durée d'une conversation, le nombre de commits ou le désir de produire artificiellement une release.
+
+PGR privilégie la traçabilité utile et la progression vers l'objectif du projet plutôt que la multiplication des versions, tests ou documents sans valeur opérationnelle.
--- a/history/0.0.1/alpha.2.md
+++ b/history/0.0.1/alpha.2.md
@@ -0,0 +1,56 @@
+<!-- file: history/0.0.1/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.0.1-alpha.2 — core governance rules
+
+## Statut
+
+PASS
+
+Les règles communes de versioning et de lifecycle de release ont été formalisées sans anticiper les contrats détaillés des artefacts workflow réservés à `alpha.3`.
+
+## Baseline
+
+Version validée par l'opérateur :
+
+```text
+0.0.1-alpha.2
+```
+
+Le delta appliqué était `0.0.1-alpha.2` sur la baseline `0.0.1-alpha.1.fix.2`, dont le history avait été appliqué et committé avant cette tranche.
+
+## Validation opérateur observée
+
+Les contrôles suivants ont été exécutés avec succès :
+
+```bash
+test "$(cat VERSION)" = "0.0.1-alpha.2"
+test -f docs/rules/200-GOVERNANCE.md
+grep -Fx '<!-- file: docs/rules/200-GOVERNANCE.md -->' docs/rules/200-GOVERNANCE.md
+grep -F 'PGR MUST NOT imposer une égalité globale' docs/rules/200-GOVERNANCE.md
+grep -F 'alpha.1` MUST servir de gate de cadrage' docs/rules/200-GOVERNANCE.md
+grep -F "L'arrivée à \`.fix.3\` ou au-delà MUST déclencher une revue du plan" docs/rules/200-GOVERNANCE.md
+git diff --check
+git add VERSION RULES.md docs/rules/000-README.md docs/rules/200-GOVERNANCE.md \
+    deltas/0.0.1/alpha.2.md
+git diff --cached --check
+git status --short
+```
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+La sortie finale observée avant ajout du présent history était :
+
+```text
+M  RULES.md
+M  VERSION
+A  deltas/0.0.1/alpha.2.md
+M  docs/rules/000-README.md
+A  docs/rules/200-GOVERNANCE.md
+```
+
+## Résultat
+
+`alpha.2` est validée sans fix ni REPLAN.
+
+La tranche suivante est `0.0.1-alpha.3`, consacrée aux artefacts workflow, à leur ordre d'application et aux règles de reprise.