38 lines
1.3 KiB
Markdown
38 lines
1.3 KiB
Markdown
<!-- file: docs/templates/002-RELEASE_PLAN.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Pattern local — plan de release
|
|
|
|
## Contrat minimal
|
|
|
|
Un plan multi-tranches Knowledge utilise normalement :
|
|
|
|
```text
|
|
## Statut et sources
|
|
## Mission
|
|
## État acquis et questions ouvertes
|
|
## Scope
|
|
## Hors scope
|
|
## Stratégie de validation
|
|
## Trajectoire prévisionnelle
|
|
### alpha.N — ...
|
|
### beta.N — ...
|
|
### rc.N — ...
|
|
### rel.N — ...
|
|
## Déclencheurs de REPLAN
|
|
## Clôture et transition
|
|
## Revue d'horizon
|
|
```
|
|
|
|
Le nombre de tranches n'est pas fixé. Les phases annoncées restent sous `## Trajectoire prévisionnelle` avec un heading `###`.
|
|
|
|
## Règles
|
|
|
|
Le plan pilote le travail restant ; il n'est pas un journal de commandes. Les preuves détaillées vivent dans `history/` et les règles durables vivent chez leur owner local.
|
|
|
|
Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses.
|
|
|
|
La revue d'horizon de fin de release doit réévaluer la prochaine mission et un horizon borné au-delà d'elle. Lorsque `N+1` est suffisamment décidée, la fin de `N` prépare aussi son prompt versionné de démarrage afin que la stable `N` contienne déjà le handoff vers la suite.
|
|
|
|
Le changelog n'est pas une intention du plan : son entrée de release est préparée vers la stabilisation à partir du résultat réellement matérialisé, puis finalisée avant la promotion stable.
|