123 lines
6.2 KiB
Markdown
123 lines
6.2 KiB
Markdown
<!-- file: docs/rules/200-GOVERNANCE.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Gouvernance locale Knowledge
|
|
|
|
## Principe
|
|
|
|
La gouvernance de Knowledge sert la qualité, la reprise et la réduction du risque. Elle reste proportionnée au changement : une règle ou une gate doit apporter une preuve, protéger un contrat ou rendre une décision durable ; elle ne doit pas exister uniquement pour ajouter de la cérémonie.
|
|
|
|
## Baseline autoritaire
|
|
|
|
Une version ou tranche Knowledge part des artefacts Knowledge réellement autoritaires : archive/tag ou workspace établi, `VERSION`, règles locales, architecture, plan actif, deltas/histories et preuves opérateur disponibles.
|
|
|
|
Une conversation antérieure, une copie non vérifiée ou une version plus récente d'un référentiel externe ne remplace jamais cette baseline.
|
|
|
|
## Autonomie normative et provenance PGR
|
|
|
|
Knowledge est autonome après adoption. PGR `v0.1.3` est la provenance de la réconciliation effectuée pendant `0.0.2`, pas une dépendance normative vivante.
|
|
|
|
Une nouvelle version, session ou tranche Knowledge MUST NOT rechercher ou charger automatiquement une nouvelle stable PGR. Une comparaison PGR ne peut commencer que si une réévaluation/adoption PGR est explicitement inscrite au scope.
|
|
|
|
Lors d'une telle réévaluation, les décisions sont classifiées `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis les changements retenus sont adaptés et matérialisés dans Knowledge avant fermeture de l'adoption.
|
|
|
|
## Autorité locale et priorité
|
|
|
|
L'ordre d'autorité normal est :
|
|
|
|
```text
|
|
contrat spécifique de tranche/release établi
|
|
-> RULES.md et owners locaux docs/rules/
|
|
-> architecture, plan et validation locaux
|
|
-> provenance externe uniquement pour expliquer une adoption explicitement engagée
|
|
```
|
|
|
|
Un owner externe n'est jamais appliqué implicitement parce qu'il porte un numéro identique ou une version plus récente.
|
|
|
|
## Version canonique
|
|
|
|
`VERSION` contient exactement l'identité SemVer courante de la release Knowledge, sans préfixe `v`. `[workspace.package].version` est un miroir exact de `VERSION` pour le workspace Rust.
|
|
|
|
Les autres numéros restent indépendants lorsque leur sémantique l'exige : révision documentaire, lockfile/package, format ou compteur technique. Une égalité de version n'est jamais imposée uniquement parce que deux champs contiennent un numéro.
|
|
|
|
Le lifecycle Knowledge utilise :
|
|
|
|
```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`. Le tag stable est `vX.Y.Z`. `rel.N` nomme une tranche de clôture et n'est pas une version produit SemVer ; sa forme canonique n'utilise pas de zéro de padding (`rel.1`).
|
|
|
|
## Rôle des phases
|
|
|
|
### Alpha
|
|
|
|
L'alpha porte cadrage, implémentation et changements de scope encore attendus. `alpha.1` sert de gate de cadrage de la release : baseline, règles, mission/plan, décisions ouvertes, risques, stratégie de validation et dimensionnement des tranches doivent être vérifiés avant l'implémentation lourde.
|
|
|
|
Une durée de l'ordre de 15 à 30 minutes peut aider au découpage, mais n'est ni une deadline ni un quota.
|
|
|
|
### Beta
|
|
|
|
La beta sert principalement à stabiliser et réconcilier un scope déjà établi. Une expansion fonctionnelle importante exige un REPLAN explicite.
|
|
|
|
### Release candidate
|
|
|
|
La RC gèle le scope sauf corrections nécessaires à la validation. Elle porte la gate complète de candidate. Un changement fonctionnel important découvert en RC retourne vers une phase adaptée ou déclenche un REPLAN ; il n'est pas masqué dans un simple fix.
|
|
|
|
### Stable
|
|
|
|
La promotion vers `X.Y.Z` doit être proche d'une opération mécanique après une RC propre, tout en exécutant la gate spécifique aux métadonnées/documents/artefacts de promotion.
|
|
|
|
Pour la clôture stable :
|
|
|
|
```text
|
|
rel.1 FAIL / PARTIAL / BLOCKED -> commit X.Y.Z-rel.1
|
|
rel.1.fix.1 FAIL / PARTIAL / BLOCKED -> commit X.Y.Z-rel.1.fix.1
|
|
première clôture réellement PASS -> commit X.Y.Z
|
|
```
|
|
|
|
Le commit `X.Y.Z` inclut le history qui établit le `PASS` stable. Le tag `vX.Y.Z` est créé seulement après ce commit. La vérification de l'archive/tag publiée est une preuve post-tag distincte.
|
|
|
|
## Correctifs de tranche
|
|
|
|
Un `.fix.M` corrige uniquement la tranche immédiatement concernée. Il conserve son scope fonctionnel et peut corriger code, configuration, documentation, validation ou packaging nécessaires à cet objectif.
|
|
|
|
Un fix ne doit pas introduire silencieusement une nouvelle fonctionnalité ou un nouveau chantier. Son compteur repart à `1` pour chaque tranche.
|
|
|
|
À partir de `.fix.3`, une revue du diagnostic et du plan est obligatoire afin de décider explicitement si la poursuite du fix reste appropriée ou si un REPLAN est préférable.
|
|
|
|
## REPLAN
|
|
|
|
Un REPLAN est une décision de pilotage, pas un suffixe SemVer. Il s'applique lorsque le plan ne décrit plus correctement la réalité : dépendance inattendue, responsabilité transverse, architecture, risque, volume ou ordre des tranches significativement modifié.
|
|
|
|
La conclusion d'un REPLAN doit être explicite :
|
|
|
|
```text
|
|
CONTINUE
|
|
SPLIT
|
|
CONTINUE-NEXT-SESSION
|
|
ABANDON
|
|
```
|
|
|
|
Une coupure de conversation ou de session ne crée jamais à elle seule une nouvelle version ou une nouvelle tranche. Le même état continue tant que le scope reste valide.
|
|
|
|
## Abandon et supersession
|
|
|
|
Une version ou prerelease commencée n'est pas forcée vers stable pour préserver une séquence esthétique. En cas d'abandon ou supersession, l'état et la raison sont documentés, les preuves et décisions utiles sont conservées, et la version déjà consommée reste dans l'historique.
|
|
|
|
## Décisions différées
|
|
|
|
Une décision `DEFER` reste indécise jusqu'à son déclencheur réel. Elle n'est pas remplacée par une valeur arbitraire issue d'un exemple, d'un autre projet ou d'un référentiel externe.
|
|
|
|
Les décisions différées structurantes restent dans le profil/architecture Knowledge et ne sont reprises que par un scope explicite ou un REPLAN.
|
|
|
|
## Immutabilité historique
|
|
|
|
Les artefacts historiques restent historiques. Une nouvelle règle s'applique à partir de son adoption et ne réécrit pas deltas, histories, prompts ou décisions anciennes uniquement pour simuler une conformité rétroactive.
|