v0.0.3-pre.009

This commit is contained in:
2026-08-14 12:51:24 +02:00
parent 6964b71955
commit 2dada316c1
10 changed files with 840 additions and 110 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/001-V0_0_3_PLAN.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Plan KSP 0.0.3
@@ -13,7 +13,7 @@ Transformer le brainstorming KSP en architecture, règles, inventaire et plan su
- `pre.002` — inventaire initial des composants ;
- `pre.003` — graphe de dépendances, correction de l'inventaire et stabilisation des frontières de composition.
Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy), `pre.006` (Data/Materialization/Store), `pre.007` (Acquisition/Workers/Jobs) et `pre.008` (Apps/Services/Scenarios/Control) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy), `pre.006` (Data/Materialization/Store), `pre.007` (Acquisition/Workers/Jobs), `pre.008` (Apps/Services/Scenarios/Control) et `pre.009` (Functional Release Sequence) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
## Décisions structurantes actuelles
@@ -140,18 +140,30 @@ Livré :
### `pre.009` — Plan des premières releases fonctionnelles
- transformer les séries `0.1.x+` en premières releases concrètes ;
- dimensionner chaque release concrète ;
- choisir la première release `0.1.N` ;
- vérifier l'ordre réel core/logging/config/interface/program/store/transport/workers sans introduire de dépendances circulaires ;
- positionner explicitement les apps spécialisées/demos avant toute future app globale ;
- transformer le brouillon de prompt en prompt quasi-final de cette première release concrète.
Livré :
- `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` ;
- `0.1.1` sélectionnée comme première release fonctionnelle ;
- `0.1.1` = `ksp-core-lib` ;
- `0.1.2` = `ksp-logging-lib` ;
- `0.1.3` = `ksp-config-lib` par défaut ;
- `0.1.4` = `ksp-app-config-desk` par défaut ;
- règle de scission de Config si son `pre.001` démontre une charge excessive ;
- ordre candidat, volontairement non numéroté finement, pour `0.2.x` et `0.3.x` ;
- lifecycle standard des releases fonctionnelles ;
- chaque delta commité à partir de `0.1.x` ;
- seul le commit stable reçoit le tag `vX.Y.Z` ;
- brouillon générique `V0_1_X` remplacé par le prompt quasi-final `V0_1_1`.
### `pre.010` — Clôture fondatrice
- validations finales de cohérence ;
- documentation/nettoyage/archivage ;
- synchronisation du changelog si applicable ;
- finalisation du prompt de la première release fonctionnelle.
- relire les règles, architecture, roadmap, plans et IDEAS pour détecter les contradictions restantes ;
- vérifier que la documentation racine/indexée disponible est cohérente ;
- vérifier les versions de fichiers et le versionnement Cargo ;
- effectuer les validations workspace applicables à la fondation ;
- mettre à jour/nettoyer/archiver ce qui doit l'être ;
- synchroniser le changelog si le fichier existe dans la base de travail ;
- finaliser `prompts/001-V0_1_1_START_PROMPT.md` ;
- produire le delta/release stable `0.0.3` et préparer le démarrage de `0.1.1`.
Le nombre de prereleases reste révisable si une tranche dépasse le budget de planification ou si une frontière supplémentaire doit être étudiée.
`pre.010` n'est pas une nouvelle tranche de brainstorming architectural. Une évolution de fond n'y est ouverte qu'en cas d'incohérence critique détectée pendant l'audit final.